Transcript NETCONF WG 68 IETF Prague, CZ

NETCONF WG
68th IETF
Prague, CZ
March 19, 2007
abierman-netconf-mar07
1
NETCONF WG Details

Mailing List
» Discussion: [email protected]
» Subscribe: [email protected]
– ‘subscribe’ in the message body
» Archive: http://ops.ietf.org/lists/netconf/

WG Chairs
» Simon Leinen <[email protected]>
» Andy Bierman <[email protected]>

WG Charter Page
» http://www.ietf.org/html.charters/netconf-charter.html

WG Home Page
» http://www.ops.ietf.org/netconf/
abierman-netconf-mar07
2
Agenda


WG Draft:
» NETCONF Event Notifications
draft-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
abierman-netconf-mar07
3
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
abierman-netconf-mar07
4
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
abierman-netconf-mar07
5
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
abierman-netconf-mar07
6
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
abierman-netconf-mar07
7
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
abierman-netconf-mar07
8
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
abierman-netconf-mar07
9
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?
abierman-netconf-mar07
10
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”/>
</notification>
abierman-netconf-mar07
(‘ncn’ only because in the same XSD)
11
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
abierman-netconf-mar07
12