Network Configuration Protocol (NETCONF) Base Notifications
RFC 6470

[Ballot comment]
The security consideratiions could be improved by discussing what threat is posed by the specific data points.

For example, netconf-config-change "indicates that the system configurastion has changed." I don't understand just what vulnerability this describes; is the concern about disclosing information about the system? or alerting a listening attacker that the system might now be more vulnerable? The sensitivity/vulnerability is not described. Ditto for many of these bullets.

[Ballot comment]
I must be missing something: exactly how are notifications pushed from client to server in NETCONF? RFC 6241 appears to define NETCONF as an RPC technology, whereby the client sends a request and the server sends a response. It would be good to spell out the push mechanism a bit more clearly, or cite the relevant section of the appropriate specification.

[Ballot comment]
idnits 2.12.12 reported:

    Unused Reference: 'RFC6021' is defined on line 623, but no explicit
    reference was found in the text

[Ballot comment]
I assume the ";" in the following could be removed:

    } // container changed-by-parms;

it just stuck out because none of the other single line comments ended with ;.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Network Configuration Protocol (NETCONF) Base Notifications) to Proposed Standard


The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Network Configuration Protocol (NETCONF) Base Notifications'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The NETCONF protocol provides mechanisms to manipulate configuration
  datastores.  However, client applications often need to be aware of
  common events such as a change in NETCONF server capabilities, that
  may impact management applications.  Standard mechanisms are needed
  to support the monitoring of the base system events within the
  NETCONF server.  This document defines a YANG module that allows a
  NETCONF client to receive notifications for some common system
  events.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netconf-system-notifications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netconf-system-notifications/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?


I, Mehmet Ersue, am the Document Shepherd for this document.
I have personally reviewed this version of the document and I
believe it is ready for publication.

Adequate review has occurred from WG members, and it has been
reviewed especially by Martin Bjorklund, Muthumayan Madhayyan,
Randy Presuhn, Dan Romascanu, Phil Shaefer, Juergen Schoenwaelder,
Kent Watson, and Bert Wijnen. The issues raised in the reviews have

been discussed on the mailing list and fixed in the last versions.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had adequate review from working group and
non-working group members, mostly from NETCONF and NETMOD WGs.
I do not have any concerns about the depth or breadth of review.



(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no concerns about the technical merit of the document.
There are no IPR disclosures filed on this document.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong consensus in the WG to publish this document.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. There are no nits in this draft.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has only normative references.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

IANA considerations are complete and consistent with RFC 3688.
The draft requests to register one XML namespace URN and one
module name in the 'YANG Module Names' registry.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The YANG module in the document has been checked for validity.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document defines a YANG module that allows a NETCONF client
to receive notifications for some common system events. As such
the document supports the monitoring of base system events within
the NETCONF server.

Working Group Summary

The document has been longly discussed in the Working Group,
including several WG Last Calls. The comments and reviews helped
to improve the document a lot and the current version reflects the

consensus of the Working Group.
There was some debate on the scope of the draft. Kent Watsen was
the only person who proposed the document to cover a much bigger
scope. The system-startup notification has been removed after some

discussion.
The last WGLC did raise only minor issues. The changes have been
accepted by the WG with some additional discussion and bug fixing.


Document Quality

It is expected that NETCONF implementations will be extended once
this document gets published as proposed standard.


Mehmet Ersue
Document Shepherd