NETCONF WG 66 th IETF Montreal, QC, Canada July 14, 2006

NETCONF WG Details  Mailing List  Discussion:  Subscribe:  ‘subscribe’ in the message body  Archive:  WG Chairs  Simon Leinen  Andy Bierman  WG Charter Page   WG Home Page 

Administrativia  Volunteers  Note takers for the minutes  Jabber scribe (please announce slide numbers)  Jabber proxy  Please use the microphones when asking questions

Interim Meeting Today (Friday 14 July) 1PM – 6PM Tomorrow (Saturday 15 July) 9AM – 6PM Hotel Delta Centre-Ville, St. Charles room

Four drafts are in the RFC Editor Queue Port numbers have been assigned  830 netconf-ssh  831 netconf-beep  832 netconfsoaphttp  833 netconfsoapbeep Further IANA actions required(capabilities registry, XML namespace etc.)? Submitted Drafts

Active Drafts  WG Draft:  NETCONF Event Notifications draft-ietf-netconf-notification-02.txt  Individual Submissions:  A SYSLOG Capability for NETCONF draft-shafer-netconf-syslog-00.txt  Netconf System Architecture draft-atarashi-netconfmodel-architecture-03.txt  Framework for Netconf Content draft-chisholm-netconf-model-05.txt

Agenda  Agenda bashing (5')  Netconf System Architecture (B) (10')  Framework for Netconf Content (D) (10')  A SYSLOG Capability for NETCONF (C) (40')  NETCONF Event Notifications (A) (40')  NETCONF Notifications: Functional Requirements (45')  determine WG consensus on need and priority of requirements on Juergen's list:

Requirements list (1/2) solution should focus on notification support for configuration [AB] solution should support structured hierarchical data [BL, SC] solution should be able to carry configuration fragments [?] solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) [BL] solution should provide reliable delivery of notifications [BL] solution should support preconfigured notification destinations [AB] solution should support agent initiated connections [KW] solution should provide a subscription mechanism [HT] solution should support multiple subscriptions [RP] solution should provide a filtering mechanism [HT] solution should support notification names [BL] solution should support notification timestamps [BL]

Requirements list (2/2) solution should support notification classes [SC] solution should support notification info [BL] solution should provide the ability to specify the content of notifications to ensure predictability [SC] solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism [AB] solution should allow notifications to refer to prior configuration change RPCs solution should not bind subscriptions to a connection [RP] channels for configuration change notifications should share fate with a session that includes a configuration channel [DP] solution should support replay of locally logged notifications [KW] solution should support message chunking capability in cases channels carry mixed RPCs [KW] solution should scale to nodes which may emit notifications [BL] solution should scale to order nodes to send notifications [BL]