1 / 12

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

This document discusses the details and agenda of the NETCONF WG 68th IETF in Prague. It focuses on the Notification Draft and Create Subscription Issues, including namespace and data organization, event class issues, and replay issues.

donaldcollins
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related