IETF68
OPS-NM Area
NETCONF WG
April 18, 2007

Minutes by Andy Bierman from notes by David Harrington

Documents:

A) draft-ietf-netconf-notification-06.txt

Minutes:

1) WG Status

   The WG is trying to finish the Notifications draft and resolve
   all open issues identified in the recent WG Last Call.

2) Notification Issues

2.1) Namespace Issues

The group discussed how the namespace assignments (and therefore
number of XSD definitions in the document) should be used.
There were arguments for between 1 and 3 different namespaces.
See slide 6 for more details on the different choices.
The group did completely resolve this issue, but there does
not seem to be enough consensus to change the current proposal,
which is 3 separate namespaces and XSDs for the XML definitions
in the draft.

2.2) Naming Style

The group discussed the different element naming styles used
in the document, e.g., foo-bar and fooBar.  There was not consensus
to make any changes to the current element names, or to force
one style or the other within NETCONF data models.

2.3) Replay Notification Content

The individual data fields within the replayCompleteNotification
were discussed.  In the end, the group decided that none of them
were really needed, so the notification to indicate the notification
replay is complete is an empty element:

  <notification>
    <replayCompleteNotification/>
  </notification>

2.4) Create Subscription Method

A new protocol operation called 'create-subscription' is being
added to cause the agent to start delivering notifications to
the manager.

A number of minor issues were discussed, like moving some text
around to make this section more complete, and remove some
of the forward references in the document.

The error codes used were also discussed.
Any new error codes or error data elements added to the <rpc-error>
element would require the base protocol (RFC 4741) to be republished.
Therefore, the group decided that the notification draft must
reuse the <rpc-error> mechanism and not extend it in any way.
The error-message field can be used to describe specific corner-case
conditions, such as 'stop-time before start-time'.

2.5) Examples

The examples in the draft are non-normative text, which is usually placed
in an appendix when an entire section is non-normative.
The organization and correctness of all the examples is still
an open issue, to be reviewed in the next version of the draft.

2.6) Monitoring Data Model

There are many objections to the session-specific state data that
is included in the draft, for retrieval with the <get> operation.
The group was in general agreement that data models should
only be included in the document if they are really needed for
interoperability.

2.7) Transport Issues

The group discussed whether or not the SOAP and BEEP transport
mappings must be supported for NETCONF notification delivery.
There does not seem to be enough interest and expertise in the
WG in writing the specific documentation needed to extend the
original transport mapping documents to support notifications.

It is not clear what specific text is needed to extend the
SSH transport mapping, but it is believed to be very minor.
There are a few places where the <rpc> element is mentioned
specifically, and the <notification> element should also be
mentioned in those cases.

The group decided that support for the BEEP and SOAP transports
can continue in the background (if enough interest), but that
updating these documents was not a priority, and should not block
publication of the Notifications document, or the SSH transport mapping.

The actual publication of the transport updates for SSH will
need to be in some document.  It is not clear which packaging
choice should be taken yet:
  1) include SSH transport details in Notification document
     since they are mandatory-to-implement and other mappings
     are not ready anyway.
  2) publish details in an addendum RFC to the SSH transport RFC
  3) publish details in a replacement RFC for the SSH transport RFC

2.8) IANA Considerations

There needs to be a section added which identifies all the
requests that will be made of IANA, such as namespace registry
definitions.

3) Summary

The next version of the Notifications draft is expected
to contain many updates and corrections that have been
identified on the mailing list, and the changes agreed upon
at this meeting.  A new WG Last Call will be held for this
draft, when it is published.