Network Configuration WG (netconf) IETF #66 Meeting Minutes ======================== Chairs: Simon Leinen Andy Bierman Meeting Notes: Rob Enns Meeting Minutes: Andy Bierman Agenda: - Agenda bashing (5 min) - Netconf System Architecture (B) (10 min) - Framework for Netconf Content (D) (10 min) - A SYSLOG Capability for NETCONF (C) (40 min) - NETCONF Event Notifications (A) (40 min) - NETCONF Notifications: Functional Requirements (45 min) - Determine WG consensus on need and priority of requirements on Juergen's list: http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications Internet Drafts: (A) NETCONF Event Notifications draft-ietf-netconf-notification-02.txt (B) Netconf System Architecture draft-atarashi-netconfmodel-architecture-03.txt (C) A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00.txt (D) Framework for Netconf Content draft-chisholm-netconf-model-05.txt Minutes: 1) WG Status The base set of NETCONF drafts has been approved and is in the RFC Editor queue. 1.1) Port Numbers Well known port numbers 830 to 833 have been assigned by IANA. Refer to the following WEB page for more details: http://www.iana.org/assignments/port-numbers 1.2) URNs XML Registry entries have been added by IANA: Refer to the following WEB page for more details: http://www.iana.org/assignments/xml-registry/ns.html 2) NETCONF System Architecture Some slides regarding the following draft were presented: draft-atarashi-netconfmodel-architecture-03.txt (B) This draft describes the system architecture used in this particular implementation to create a NETCONF-based VLAN management system. Refer to the slides for more details. Some comments from the audience indicated that the Applications area should be more involved if any standards effort beyond the protocol itself is done. The WG position continues to be that applications and network elements should not be tightly integrated, and the protocol should be content-independent. 3) Framework for NETCONF Content Some slides regarding the following draft were presented: draft-chisholm-netconf-model-05.txt (D) This draft has been updated, and includes many guidelines for using XSD to define NETCONF data models. This is an offline effort that continues to evolve. Refer to the slides for more details. NETCONF mechanisms discussed include: - minAccess, maxAccess, definition of conformance - key and keyref definitions - method of defining notifications Issues from the audience related to data organization were discussed. It was agreed this issue needs much more work. 4) A SYSLOG Capability for NETCONF Some slides regarding the following draft were presented: draft-shafer-netconf-syslog-00.txt (C) This draft describes a capability-based extension to the NETCONF protocol that provides a framework for advertising, selecting, filtering, and encoding of SYSLOG message content over the NETCONF protocol. Refer to the slides for more details. There was significant interest in understanding this draft and applying it in a slightly more generic form to the notification work item. The group discussed the scope of the desired notification feature in the context of the entire management system. There are several different interpretations of how NETCONF should be deployed in an existing network environment. The continued use (or not) of SYSLOG and SNMP protocols within a NETCONF-based management system are fairly contentious issues. This draft was discussed further during the interim meeting. 5) NETCONF Event Notifications Some slides regarding the following draft were presented: draft-ietf-netconf-notification-02.txt (A) The features of this draft include: - Subscribe/unsubscribe model - Modification of subscription without loss of notifications - Event classes to enable 'big bucket' filtering. - Ability to carry NETCONF (XML) content. The group discussed the use of Xpath in text messages such as syslog to reference XML data model objects. It was agreed this is possible but could be complicated to implement or use. This draft was discussed further during the interim meeting. 6 ) Notification Requirements First, Simon proposed that the WG not do this notification work, but instead define a small number of SNMP notifications about NETCONF (e.g., config-change). Then the WG will create a new MIB to carry this notification information. Result: The consensus in the room was that this should not be done, and work on notifications should continue instead. It was noted that these choices are not mutually exclusive. It is possible to create such a MIB and continue this notification work. It was also noted that a reason not to do both is that we currently have an easy to use/implement protocol, and do not want to make it much more complex by introducing notifications. There was a discussion of the relative need for notifications in NETCONF, as opposed to continued use of SYSLOG and/or SNMP for this purpose. The need and definition of content-independent notification delivery and filtering was also discussed. The group was presented with 3 choices: 1) don't do notifications 2) support notification delivery via netconf but we don't care about the content 3) we build a generic notification infrastructure The consensus in the room was for option (2). After much discussion it was clear many people did not fully understand the options. Later at the interim meeting, the actual intent and definition of "content-independent notification delivery" was refined, so option (2) is basically correct. It was also noted that a meeting was held between the chairs of the SYSLOG and NETCONF WGs, and the OPS-NM ADs. There will probably be a BoF on standardizing SYSLOG content at a future IETF. The NETCONF WG cannot work on standardizing SYSLOG content. The SYSLOG WG is now in the Security area (and busy doing security-related work). One goal of such a BoF would be to determine the best home for this work in the IETF.