NETCONF WG 65 th IETF Dallas, TX USA March 20, 2006

1. NETCONF WG65th IETFDallas, TX USAMarch 20, 2006

2. NETCONF WG Details • Mailing List • Discussion: netconf@ops.ietf.org • Subscribe: netconf-request@ops.ietf.org • ‘subscribe’ in the message body • Archive: http://ops.ietf.org/lists/netconf/ • WG Chairs • Simon Leinen <simon@switch.ch> • Andy Bierman <ietf@andybierman.com> • WG Charter Page • http://www.ietf.org/html.charters/netconf-charter.html • WG Home Page • http://www.ops.ietf.org/netconf/

3. NETCONF Drafts • Completed Work • NETCONF Configuration Protocoldraft-ietf-netconf-prot-12.txt • Using the NETCONF Protocol Over SSHdraft-ietf-netconf-ssh-06.txt • Using the NETCONF Protocol Over BEEPdraft-ietf-netconf-beep-10.txt • Using the NETCONF Protocol Over SOAPdraft-ietf-netconf-soap-08.txt • Current Work • NETCONF Event Notificationsdraft-ietf-netconf-notification-00.txt

4. NETCONF WG Agenda • Status of Completed WG Documents (10 min) • NETCONF Experimental Namespace and Extension Registry (15 min) • Discuss need/interest in an experimental "branch" for NETCONF protocol extensions. • NETCONF Implementation Guide (15 min) • Discuss need/interest in an Informational RFC to help NETCONF protocol developers produce interoperable implementations • NETCONF Event Notifications (90 min) • Discuss current Notifications draft • Identify areas of WG consensus (or lack thereof) • Identify all open issues • Open Discussion / Unchartered Items (20 min) • NETCONF Data Modeling • Access Control Model • ???

5. Administrivia • Agenda bashing • Volunteers • Note takers for the minutes • Jabber scribe • Jabber proxy • Please use the microphones when asking questions • Speakers, please announce slide changes (for the benefit of remote attendees)

6. Completed Work Status • NETCONF “Version 1” ready for approval by the IESG • NETCONF Configuration Protocoldraft-ietf-netconf-prot-12.txt • Using the NETCONF Protocol Over SSHdraft-ietf-netconf-ssh-06.txt • Using the NETCONF Protocol Over BEEPdraft-ietf-netconf-beep-10.txt • Using the NETCONF Protocol Over SOAPdraft-ietf-netconf-soap-08.txt • IANA Port Assignment issue is the last detail remaining to be resolved

7. NETCONF Experimental • The NETCONF ‘base’ namespace and capability registry requires standards action for modification • Another namespace would be needed for non-standards track extensions, even if added by this WG • This is an IESG concern, which needs to be addressed • A separate IANA registry for URNs identifying experimental NETCONF protocol extensions is proposed: • urn:ietf:params:netconf:experiment:<exp-name>:<exp-version> • urn:ietf:params:netconf:experiment:batch:1.0 • Provides a freely available, centralized source of NETCONF extension and experiment information • Help promote interoperability of NETCONF extensions • Details: • First-come, first-serve naming rights • Required Documentation: Capability template (may need new Experiment template)

8. NETCONF Implementation Guide • Purpose: • Help new NETCONF protocol developers more easily create inter-operable implementations • Examples: • RFC 2683 - IMAP4 Implementation Recommendations • IPFIX Implementation Guidelines draft-boschi-ipfix-implementation-guidelines-01.txt • An Implementation Guide for RTP MIDIdraft-ietf-avt-rtp-midi-guidelines-15.txt • Phase 1: • Collect implementation experience, advice, pitfalls, etc. • Phase 2: • Publish Informational RFC

9. NETCONF Event Notifications • Document: • draft-ietf-netconf-notification-00.txt • Issue Areas • Notification Architecture • Configurability • Notification Message Definition • Event Classes • Transport Details • Security • Normative Data Model for monitoring • Non-normative extensions • Examples within normative text • XSD

10. NETCONF Notification Architecture • Shared session vs. dedicated session • Best current practice does not send notifications to the same port number (or same connection) as operations • How important is the ability to intermix RPC operations and notifications in the same session? • Overlay notification model on RPC model or create a separate model for Notifications? Content Operations Content RPC Notification Transport Transport RPC Model Notification Model

11. Notification Architecture (cont.) • One-Way RPC vs. Plain Notification • Should this extra layer be in the architecture and PDU? • Subscription vs. Long-lived RPC Model • Given: Manager sends an RPC to start receiving notifications • For dedicated sessions, a long-lived RPC is a simple approach that is already defined • Agent sends <rpc-reply>, then <notification> elements as needed, but never sends the closing </rpc-reply> element • If the ‘start-notifications’ RPC cannot be completed, the usual <rpc-reply> with an <rpc-error> is sent instead • Manager terminates the session to stop receiving notifications • Is the Modify subscription operation really needed? • Manager could start up a new notification session with the new desired parameters, then shutdown the old notification session to avoid missing any notifications

12. Notification Configurability • 3 Combined Filter Configuration Methods • By Event Classes • encoded as empty elements like <state/> • By Content Filter (subtree or XPath) • By Named Profile • a string that names a non-volatile configuration of unspecified content • Another filtering approach: • Event Class string + optional Event Sub-class element • Each class can define the structure of its own sub-class element, typically a string • Need for modify-subscription RPC not clear • Need for multiple subscriptions per session not clear

13. Notification Message • Current definition example (w/o namespace junk)<one-way-rpc message-id=“101”> <notification> <subscription-id>123456</subscription-id> <event-classes><fault/><configuration/></event-classes> <sequence-number>7</sequence-number> <date-time>2006-03-20T09:14:00Z</date-time> <data> ….. </data> </notification></one-way-rpc> • Taken from XSD; doc. examples do not follow the XSD • Why do we need to include multiple event-classes in one notification? Do we need to allow a single event type to be given multiple event-class classifications?

14. Event Classes • Pre-determined feature set defined by the event classes:

15. Other Notification Issues • Additional Incomplete or Controversial sections • Transport Specific Details • Security Considerations (empty section) • Normative Data Model for monitoring • Doesn’t follow container model in Framework • Should this be mandatory or even included in this document? • Non-normative extensions • Appendix A: Potential Event Content • Appendix B: Configuration Event Class Notifications • Appendix C: NETCONF Event Notifications and Syslog • Examples within normative text do not match XSD • XSD complicated and contains some errors