NETCONF WG 68 th IETF Prague, CZ March 19, 2007

1. NETCONF WG68th IETFPrague, CZMarch 19, 2007

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. Agenda • WG Draft: • NETCONF Event Notificationsdraft-ietf-netconf-notification-06.txt • Agenda • NETCONF Notifications: Final WG Review • discuss WGLC mailing list comments • identify any remaining unresolved issues • discuss and resolve as many identified issues as possible

4. Notification Draft Status • 3 week WGLC completed March 16 • Several comments made (thanks) • Only minor issues remain • Expect next draft to be the final version submitted to IESG

5. Notification Manager Interface • Stream Discovery: • <get> of /ncn:eventStreams (namespace is TBD) • Start: • <create-subscription> • start receiving notification with or without replay • NETCONF stream used if none specified • specify optional filter or profile (i.e., stored filter) • Stop: • <kill-session> (from a different session) • drop transport connection (from same session) • Receive Notification: • <notification> • ‘replay complete’ is the only notification content defined

6. Namespace and Data Organization Issues • urn:ietf:params:xml:ns:netmod:event:1.0 • <eventStreams> element • <namedProfile> • <namedProfiles> (contains ref to <namedProfile>) • urn:ietf:params:xml:ns:netconf:notification:1.0 • <create-subscription> • <notification> • urn:ietf:params:xml:ns:netconf:replayNotification:1.0 • <replayCompleteNotification> • Seems to be WG consensus to have 1 XSD and NS • which target namespace? • Seems to be WG consensus for ‘foo-bar’ naming style instead of ‘fooBar’ style

7. Event Class Issues • Do we need to add this field to the Replay Complete notification? • This kind of field is a registry entry • registration type is OBJECT IDENTIFIER in SMIv2 • registration type is QName in XML • currently using string which allows naming collisions between vendors • same issue applies to <error-app-tag> in <rpc-error> • Don’t really want to start this registry and populat it, as part of the Notification (protocol) work • Propose leaving event class out of the Replay Complete notification

8. Create Subscription Issues • <create-subscription> RPC method • type: rpc method type extension (no issues) • content: stream, optional filter or profile (no issues) • error response: • new error codes not needed, use existing error-tag values • Is an <rpc-error> with a special warning about start and stop times that produce no output really needed? • documentation: • list RPC parameter names and data types here • should replay section text related to this RPC method be moved? Currently have partial documentation because of start-time and stop-time. • namespace URI: (ncn) • want 1 new namespace for all NETCONF Notification XML definitions

9. Notification Structure Issues • <notification> • currently defined with a mandatory <data> container like an <rpc-reply> • should this work like the <rpc> container instead? • NotificationType, like RpcOperationType, is the abstract base for notifications • Each notification defines its own FooNotificationType as an extension to NotificationType • Only the ‘notification type’ element is required to be present, like the ‘RPC method node’ element • Common ‘header’ fields that are approved later by the NETMOD WG (e.g., event-class and timestamps) can be added as attributes to the <notification> element in the future

10. Replay Issues • <replayCompleteNotification> • change name to <replay-complete> ? • change contents from (timestamp + counter) to empty? • send as first notification if all parameters well-formed, but no notifications selected? • What if valid start/stop times are in the future? • What if the time changes (e.g., daylight savings time)? • several boundary conditions to document • What if a timezone is specified but the agent does not have one set, or it is set differently?

11. Replay Complete Notification Issues CURRENT: <notification xmlns=“ncn”> <ReplayCompleteNotification xmlns=“replayNotification”> <event-class>informational</event-class> <timeGenerated>2007-03-19T18:42:00.000-01:00</timeGenerated> <numberEventsReplayed>7482</numberEventsReplayed> </ ReplayCompleteNotification> </notification> PROPOSED: <notification xmlns=“ncn”> <replay-complete xmlns=“ncn”/> (‘ncn’ only because in the same XSD) </notification>

12. Documentation Issues • Examples • Move examples section to a non-normative appendix • Fix examples and align naming style with NETCONF • Check XSD and examples with XSD validator • Add examples for <create-subscription> in that section • IANA Considerations section • namespace URI for NETCONF Notifications 1.0 • any other registry requests for IANA? • XSD Issues • Fix bugs, remove unused imports • Combine all 3 XSDs into 1 XSD • Use named, reusable <complexType> instead of unnamed <complexType> within an <element> decl