NETCONF Event Notifications
draft-ietf-netconf-notification-14

[Ballot discuss]
[This is a revised discuss deleting resolved issues.  One relatively minor issue remains]

**** excerpt from Blake Ramsdell's secdir review *****

* Is there a risk of sessions accumulating? That is, too many
  create-subscription requests without termination?

I understand from subsequent exchanges with the authors that it is the netconf
server's responsibility to terminate sessions to address. I believe that additional
security considerations text regarding denial of service should note this responsibility.

[Ballot comment]
The restrictions "[replayLogCreationTime] MUST be present
if replay is supported" could be expressed in XML schema, instead
of just documentation. Ditto for "[stopTime] must be used with startTime".

[Ballot discuss]
Section 3.3.1., paragraph 3:
> A notification stream that supports replay is not expected to have an
> unlimited supply of saved notifications available to accommodate any
> replay request.

  DISCUSS: Because a server will have a limited number of saved
  notifications, what happens if a client requests replay with a
  that is earlier than the earliest saved notification the
  server has available? Will the client be able to distinguish the case
  were the server had to throw away earlier notifications due to storage
  requirements from the case where no earlier saved notifications exist?
  (I'm not a management guy, but I can imagine that clients want to
  know.)

[Ballot discuss]
Section 3.3.1., paragraph 3:
> A notification stream that supports replay is not expected to have an
> unlimited supply of saved notifications available to accommodate any
> replay request.

  DISCUSS: Because a server will have a limited number of saved
  notifications, what happens if a client requests replay with a
  that is earlier than the earliest saved notification the
  server has available? Will the client be able to distinguish the case
  were the server had to throw away earlier notifications do to storage
  requirements from the case where no earlier saved notifications exist?
  (I'm not a management guy, but I can imagine that clients want to
  know.)

[Ballot comment]
Notification Architecture

We don't have a notification architecture in the IETF.  It's unfortunate
but true and in my book that limits the extent to which the IESG should
constrain notification sub-systems.  We do have two standardized
publish/subscribe/notification mechanisms (SIP and XMPP) and the extent
to which it's a good idea to create additional such mechanisms is
unclear.  While I am not opposed to netconf having a netconf-embedded
notification subsystem despite the redunancy of that subsystem with SIP
& XMPP, it will be important for netconf events to be visible in
general-purpose notification systems.  I don't expect the typical cell
phone to ever have a Netconf client that keeps a connection to the
Netconf server open, but such devices will have SMS, SIP and/or XMPP
clients for general purpose notifications.  I would be a lot more
comfortable with this specification if it at least recognized some of
these events need to be made available outside the Netconf session.


Section 3.6.1 Nit:
>  parameter.  A Filter only exist as a parameter to the subscription.
s/exist/exists/

Section 7:
>  that it is viewed only by authorized users.  If a user does not have
>  permission to view content via other NETCONF operations, it must not
>  have access that content via Notifications.
s/it/she/
s/access that/access to that/

[Ballot discuss]
Protocol state machine

If I understand correctly, this extension adds two new states to the
netconf protocol state machine.  In addition to the previous "normal
NETCONF session" state, there's a "replay state" and "notification
state".  Can you describe what actions transition between which protocol
states clearly?  My guess would be as follows:

+ startTime
  transitions from "normal NETCONF state" to "replay state"
without startTime
  transitions from "normal NETCONF state" to "notification state" ??
  (this is a guess, the document doesn't seem to describe this)

  transitions from "replay state" to "notification state"

  transitions from "notification state" to "normal NETCONF state"

To achieve interoperability I think the document needs more clarity in
this area.  See also my comments on section 3.3.2.

One additional state issue -- given at least two Netconf bindings
support multiple channels (BEEP and SSH), the explicit state change will
not be a problem for such clients as long as the server permits the same
client to open more than one channel.  However, after skimming both the
SSH and BEEP bindings, it is not clear to me if the Netconf server is
required to support multiple BEEP channels or multiple SSH sessions on
the same TCP connection.  It's important to clarify this point to
determine the impact of the state change model on Netconf.

dateTime

The dateTime XML schema data type makes the timezone optional, in which
case time stamps are ambiguous and non-interoperable.  This document
needs to explicitly require that timezones be present in order to
interoperate.  I observe that dateTime does permit arbitrary fractions
of a second so I do not agree with Dave Ward's DISCUSS on the accuracy
issue, however he's right that a normative reference to XML schema data
types is necessary to clarify this and should be referenced when the
"dateTime" data type is first mentioned.  RFC 3339 discusses these
issues in more detail.

Meaning of XML Schemas

When including an XML Schema in a specification, it's very important to
state clearly in what ways the schema constrains the specification.  Is
the schema normative or is the text normative?  Is it true that all
backwards-compatible versions of this standard must comply with the
schema in version 1.0?  Or is the schema used merely to describe the
entities and attributes in this version and is subject to change in a
future version of this specification?  Does the schema constrain which
XML namespaces can be used within one of these entities? What sort of
schema changes will cause the capability version number to increment?
In the event notifications:1.1 comes along, will servers be expected to
support both versions (that has profound implications to the software
design).

Section 2.1.1:
>        later than the current time.  If the  specified is
>        earlier than the log can support, the replay will begin with
>        the earliest available notification.  This parameter is of type

It's likely important for the client to know if the replay didn't begin
at the startTime the client intended.  As specified currently, the
client gets no indication this happened and the command silently
succeeds either way.  While  can be used to discover the start of
the replay log per section 3.2.5.1, that may not be sufficient if the
client has a higher time precision than the replayLogCreationTime, or if
the replayLogCreationTime is constantly changing (e.g. a server saves
events only for the past N seconds -- so replayLogCreationTime gets
stale).  I suspect there should either be a way for the client to say it
cares that the startTime is precise or a way for the server to tell the
client it was not precise.

Section 3.3.2

I found this section confusing on several fronts.

>  A  notification is sent to indicate that all of the
>  replay notifications have been sent.  If this subscription has a stop
>  time, then this session becomes a normal NETCONF session again.  When
>  a  has been specified,  notification
>  is the last notification sent on the subscription before it
>  terminates and the NETCONF session returns to being a normal NETCONF
>  session.

Q1: Is a  notification sent if there is no startTime?
Q2: The second and third sentence contract each other.  The second
implies the session is a normal session as soon as the
is sent, while the third indicates a  is the last
sent before becoming a normal NETCONF session.  Which is correct?
Q3: Is the second sentence true if the stop time is in the future?  My
reading of the rest of the document implies otherwise.

>  ... The NETCONF server will then accept  operations.

Does this mean the netconf server did not accept  operations prior
to the ?  Can a server accept  operations
while generating notifications?

[Ballot discuss]
** All of the time references are in "type dateTime" which is XMLschema speak is “YYYY-MM-DDThh:mm:ss” (although there is no reference).

Given the output of config events from networking nodes can happen at an incredible rate, why is it felt that seconds are a satisfactory granularity? Most vendors are in fact already implementing event down to the ms. This is critical for fault messages. It is impossible to understand what is happening on a network node with the granularity of seconds.

** The implementation architecture in section 3.2 assumes a centralized event processor. Does this architecture preclude a distributed implementation? Would it necessarily have to have a separate IP?


** Section 3.6 "When multiple filter elements are specified, they are applied
  collectively, so event notifications need to pass all specified
  filter elements in order to be sent to the subscriber. "

The language rules of "collectively" need to be disambiguated. What happens in error conditions? Conflicting requests? Which wins?

[Ballot discuss]
[This is a revised discuss.  The issues wrt security considerations were raised earlier,
but have not received a response.  The second set of issues were raised by Blake
Ramsdell in a secdir review.]

In Section 7, Security Considerations, the document states:

  It is recommended that care be taken to secure execution:

  o  invocation

  o  on read-only data models

  o  content

First, what does "secure execution of" mean?  I expected the subsequent text
to elaborate on the intent for each of the bulleted items, but there wasn't a
very clear linkage.

Second, why isn't important to secure execution of  on read-write
data models?  Are we really referring to retrieving the list of supported
event streams?

Procedural discuss: Blake Ramsdell's security directorate review did not receive
a response.  As with any Last Call comments, a response is needed.

[While final determination depedns upon the response, I did a quick review for
my own determination of severity, and consider the first two issues blocking. 
I believe that additional security considerations text regarding denial of service
is needed to address the first point.  I believe processing rules for handling
incorrectly encoded or illogical time values should also be clarified.]

**** excerpt from the secdir review *****

I don't think any of these comments are showstoppers. I am probably missing
some context as to how the "notification" nodes are generated and whether
someone might try to malform them.

* Is there a risk of sessions accumulating? That is, too many
  create-subscription requests without termination?

* How important is the accuracy of the eventTime field for notification nodes?
  If you put in something that doesn't parse, or that's deliberately bad, is
  that a problem?

* The filtering and the complexity associated with arbitrary XPath syntax for
  specifying filter criteria concerns me. Is there any risk of someone gaming
  the events to elude the filter criteria? Any case matching rules that might
  need to be specified or anything like that?

**** end excerpt from secdir review ****

[Ballot discuss]
[This is a revised discuss.  The issues wrt security considerations were raised earlier,
but have not received a response.  The second set of issues ]

In Section 7, Security Considerations, the document states:

  It is recommended that care be taken to secure execution:

  o  invocation

  o  on read-only data models

  o  content

First, what does "secure execution of" mean?  I expected the subsequent text
to elaborate on the intent for each of the bulleted items, but there wasn't a
very clear linkage.

Second, why isn't important to secure execution of  on read-write
data models?  Are we really referring to retrieving the list of supported
event streams?

Procedural discuss: Blake Ramsdell's security directorate review did not receive
a response.  As with any Last Call comments, a response is needed.

[While final determination depedns upon the response, I did a quick review for
my own determination of severity, and consider the first two issues blocking. 
I believe that additional security considerations text regarding denial of service
is needed to address the first point.  I believe processing rules for handling
incorrectly encoded or illogical time values should also be clarified.]

**** excerpt from the secdir review *****

I don't think any of these comments are showstoppers. I am probably missing
some context as to how the "notification" nodes are generated and whether
someone might try to malform them.

* Is there a risk of sessions accumulating? That is, too many
  create-subscription requests without termination?

* How important is the accuracy of the eventTime field for notification nodes?
  If you put in something that doesn't parse, or that's deliberately bad, is
  that a problem?

* The filtering and the complexity associated with arbitrary XPath syntax for
  specifying filter criteria concerns me. Is there any risk of someone gaming
  the events to elude the filter criteria? Any case matching rules that might
  need to be specified or anything like that?

**** end excerpt from secdir review ****

[Ballot discuss]
[This is a preliminary discuss.  I may revise it in the future, but thought I would
initiate the discussion on this point now.]

In Section 7, Security Considerations, the document states:

  It is recommended that care be taken to secure execution:

  o  invocation

  o  on read-only data models

  o  content

First, what does "secure execution of" mean?  I expected the subsequent text
to elaborate on the intent for each of the bulleted items, but there wasn't a
very clear linkage.

Second, why isn't important to secure execution of  on read-write
data models?  Are we really referring to retrieving the list of supported
event streams?

Procedural discuss: Blake Ramsdell's security directorate review did not receive
a response.  It is unclear if any revisions are required, but a response is needed.

**** excerpt from the secdir review *****

I don't think any of these comments are showstoppers. I am probably missing
some context as to how the "notification" nodes are generated and whether
someone might try to malform them.

* Is there a risk of sessions accumulating? That is, too many
  create-subscription requests without termination?

* How important is the accuracy of the eventTime field for notification nodes?
  If you put in something that doesn't parse, or that's deliberately bad, is
  that a problem?

* The filtering and the complexity associated with arbitrary XPath syntax for
  specifying filter criteria concerns me. Is there any risk of someone gaming
  the events to elude the filter criteria? Any case matching rules that might
  need to be specified or anything like that?

**** end excerpt from secdir review ****

[Ballot discuss]
[This is a preliminary discuss.  I may revise it in the future, but thought I would
initiate the discussion on this point now.]

In Section 7, Security Considerations, the document states:

  It is recommended that care be taken to secure execution:

  o  invocation

  o  on read-only data models

  o  content

First, what does "secure execution of" mean?  I expected the subsequent text
to elaborate on the intent for each of the bulleted items, but there wasn't a
very clear linkage.

Second, why isn't important to secure execution of  on read-write
data models?  Are we really referring to retrieving the list of supported
event streams?

[Ballot discuss]
In Section 7, Security Considerations, the document states:

  It is recommended that care be taken to secure execution:

  o  invocation

  o  on read-only data models

  o  content

First, what does "secure execution of" mean?  I expected the subsequent text
to elaborate on the intent for each of the bulleted items, but there wasn't a
very clear linkage.

Second, why isn't important to secure execution of  on read-write
data models?  Are we really referring to retrieving the list of supported
event streams?

IANA Evaluation comments:

IANA has questions.

This document’s updated IANA Considerations section is unclear,
and we are not sure where to register one of the URIs. Please
confirm that the following actions are correct:

ACTION 1:

Upon approval of this document, IANA will add the following
registrations to the “Capability URNs” registry located at http://www.iana.org/assignments/netconf-capability-urns :

Capability: :notification
Capability Identifier: urn:ietf:params:netconf:capability:notification:1.0
Reference: [RFC- ietf-netconf-notification-12.txt]

Capability: :interleave
Capability Identifier: urn:ietf:params:netconf:capability:interleave:1.0
Reference: [RFC- ietf-netconf-notification-12.txt]


ACTION 2:

Upon approval of this document, IANA will add the following
registrations to the XML ns registry located at
http://www.iana.org/assignments/xml-registry/ns.html :

ID: netmod:notification
URI: urn:ietf:params:xml:ns:netmod:notification
Registration template: [link to template]
Reference: [RFC- ietf-netconf-notification-12.txt]

ID: netconf:notification:1.0
URI: urn:ietf:params:xml:ns:netconf:notification:1.0
Registration template: [link to template]
Reference: [RFC- ietf-netconf-notification-12.txt]

The template for each registration will read as follows:

URI: [URI here]
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.


ACTION 3:

Upon approval of this document, IANA will add the following
registration to the XML schema registry located at
http://www.iana.org/assignments/xml-registry/schema.html :

ID: notification
URI: urn:ietf:params:xml:schema:notification
Filename: [template from section 4]
Reference: [RFC-ietf-netconf-notification-12.txt]

QUESTION: is this URI correct? Please note that the document
should specify the URI rather than the URL for the requested
schema. In general, URLs should not be included in the IANA
Considerations section.

QUESTION: The table that appears to be requesting two capability
URNs is preceded by the sentence, “This document registers three
URIs for the NETCONF XML namespace in the IETF XML registry
[RFC3688].” Is this referring to “urn:ietf:params:xml:ns:netmod:notification,” “urn:ietf:params:xml:ns:netconf:notification:1.0,” and “urn:ietf:params:xml:schema:notification”?

NOTE: The note “-- Editor note to IANA/RFC-Editor: we request that
you make these assignments, in which case it is to be documented
as below” should be removed.

IANA Last Call comments:

Action #1:

Upon approval of this document, the IANA will make the following
assignments in the "NETCONF Capability URNs - per [RFC4741]"
registry located at
http://www.iana.org/assignments/netconf-capability-urns
Capability Capability Identifier Reference
------------------ -------------------------------------------------------- ---
------
:notification URI: urn:ietf:params:netconf:capability:notification:1.0 [RFC-netconf-notification-11]
:interleave URI: urn:ietf:params:netconf:capability:interleave:1.0 [RFC-netconf-notification-11]


Action #2:

Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID + URI + Registration template + REF
---+ -----+-----------------------+---------
netmod:notification + urn:ietf:params:xml:ns:netmod:notification +  + [RFC-netconf-
notification-11]
netconf:notification + urn:ietf:params:xml:ns:netconf:notification:1.0 +  + [RFC-
netconf-notification-11]


Registrant Contact: The IESG.

XML: N/A, the requested URI is an XML namespace.


We understand the above to be the only IANA Actions for this
document.

PROTO shepherd write-up by Bert Wijnen:

    (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?

Bert Wijnen is the doc-shepherd.
Yes, document is ready for publication (modulo some LC comments).

    (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 by key WG members.
I am not aware of any key non-WG member reviews, or which key non-WG members might be needed for further review.
I have no concerns on the level of review that we have had sofar.

    (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 special concerns.

    (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.

No specific concerns.
No IPR claims have been files as far as I know.

    (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 are several (5+) independent (non-author) WG members that have stayed involved throughout the entire process, reviewed every version, and have implementations under way or completed.  There are many WG members who do not strongly support or object to any of the document features.  There is one WG member who objected to the draft throughout the entire process, and would rather NETCONF not have this feature at all.
Summary:  There is quite strong WG consensus 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.)

Nobody has threatened an appeal.

    (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. IDnits is clean (enough) I think.
And I have done syntax check on the XML.

    (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].

There are only normative references, and all IETF related references are already published. I am not 100% sure about the XML-Schema reference and the XPATH reference. I have raised that on IETF LC.

    (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 [RFC2434].  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?

The IANA Considerations section does exist, and it identifies
4 XML namespace URIs to be added to the IETF XML registry [RFC3688].
There are no new registries. The wording could have been friendlier and clearer in that the assignments still need to be made (or so I think). Listed in my IETF LC comments.

    (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 WG has reviewed the XSD closely and believes it is correct.
I have also verified the XSDs (in sect 3.4, 4 and 5 (page 29)) with XSV 2.10-1 of 2005/04/22 13:10:49

    (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
              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

          Working Group Summary
              Was there anything in WG process that is worth noting? For
              example, was there controversy about particular points or
              were there decisions where the consensus was particularly
              rough?

          Document Quality
              Are there existing implementations of the protocol?  Have
              a significant number of vendors indicated their plan to
              implement the specification?  Are there any reviewers that
              merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive issues? If
              there was a MIB Doctor, Media Type or other expert review,
              what was its course (briefly)?  In the case of a Media
              Type review, on what date was the request posted?


announcement-write-up:

    Technical Summary

    This document defines mechanisms that provide an asynchronous message
    notification delivery service for the NETCONF protocol.  This is an
    optional capability built on top of the base NETCONF definition.
    This document defines the capabilities and operations necessary to
    support this service.

    Working Group Summary

    There were some significant differences of opinion regarding two
    aspects of the development of this document, related to design
    choices and implementation cost.

    The first set of issues were related to the notification delivery
    mechanisms, and whether to allow (or force) a session receiving
    notifications to continue processing RPC requests. The notification
    termination mechanisms were also contentious at first. These
    issues were resolved, and the optional 'interleave' capability
    was added as a result.

    The second set of issues were related to the specific behavior
    of the optional notification replay service, including the
    manner in which the agent transitioned to live notification
    delivery, or transitioned to 'normal mode' (after notification
    delivery termination).  These issues were resolved, and the
    'replayComplete' and 'notificationComplete' notification types
    were added as a result.

    Document Quality

    After significant modification and review, there is strong
    WG consensus to publish this document as a Proposed Standard.
    There are at least five vendors, who are non-authors, who
    have indicated that they are in currently implementing
    the draft.

    This document has been thoroughly reviewed within the
    NETCONF WG.  Since this document defines extensions
    to the base protocol, there are no significant data models
    or new security threats introduced which need extensive
    cross-area expert review.  The XSD schema definitions
    and the document examples have been extensively reviewed,
    but since XSD and Xpath are not widely understood, only a
    few WG members reviewed these portions of the document
    for correctness.

(end)

State Change Notice email list have been change to netconf-chairs@tools.ietf.org, draft-ietf-netconf-notification@tools.ietf.org, schishol@nortel.com, htrevino@cisco.com, bertietf@bwijnen.net, from netconf-chairs@tools.ietf.org, draft-ietf-netconf-notification@tools.ietf.org, schishol@nortel.com, htrevino@cisco.com