comments on draft-ietf-netconf-notification-03

[Andy Bierman <ietf@andybierman.com>]

Hi,

Some comments may have already been raised by others...

Andy



General:
  - Getting much closer to being ready for WGLC


Abstract:
  - What framework is actually defined by this document?
  - Implications about mappings or just mappings?

  Suggest:

    This document defines mechanisms which provide an
    asynchronous event notification delivery service for
    the NETCONF protocol.  It defines the capabilities,
    operations, transport mappings, and data models needed 
    to support this service.


Sec 1.2, para 3:

  OLD:

    A capability may be defined

  NEW:

    A capability may be advertised


Sec 2.1.1:

The term 'operation' is used to refer to an RPC method.
I know this is a nit, but it should be mentioned somewhere
(terms section).

<create-subscription> Parameters:

What happens if both the filter and named profile are specified?
How are they combined, or is this an error?

Positive response:

This should be <ok> instead of a <data> element containing
the subscription ID.  The WG decided there is only one
stream active per session.  That means there is no need for 
a subscription ID in the document.

Sec 2.2.1:

Mention that <notification> is a top level element,
to make it clear this is not another RPC method as
in the previous section.

The Positive Response and Negative Response document
format is only for RPC methods, so this text should be
removed instead of saying 'none'. The current text is
confusing because <notification> is a sibling of <rpc>
and <rpc-reply> and the behavior for <rpc-reply> is
not relevant.

Sec 2.3:

Remove "or via some action outside the scope of this document".
There is no need to mention any unknown and undefined extensions
that may be present on a particular implementation.

Sec 3.1:

The capabilities URN format is different than the NS format.
(Use the other one.)

Sec 3.2.6.2:

Remove the statement about multiple subscriptions
via multiple channels per NETCONF session.  There
is no concept of multiple channels within a NETCONF session.

Sec 3.3:

Not clear of the purpose of this section.
Expand and clarify.

Sec 3.2.5.3:

How about if we compromise on the controversial 'access control'
<appInfo> extensions?

How about if we leave <maxAccess> in (if we can agree on
the enumeration values), but take out <minAccess>?

As I have pointed out several times, the concept of minAccess
should be associated with a conformance statement, not
with the data model itself (as in SMIv2).  There are several
people who have expressed different (incompatible) ideas
for the NETCONF access control model.  This issue will need to 
be worked out on the mailing list.

Sec 3.5:

It is not clear why this section is needed, especially
towards the end of the document.  The 1-way message 
is not similar to a 2-way RPC message.  It is a totally
different concept, different XML syntax, and different
message semantics.

Sec 3.6:

Why do we need the complexity of combining RPC parameter
filters and stored profile filters?  IMO this should
be an XML choice.

Sec 4:

 - subscriptionID should be removed, and added later if we ever
   define a standard use for it.
 
 - SequenceNumber is declared with a base type of 'integer',
   which means it is infinite and there is no common wrap point.
   Suggest changing 'integer' to 'unsignedInt'.

 - the create-subscription element has a 'startTime' child
   parameter that has not been mentioned at all at this point
   in the document.

 - the <interface> element in the example should be in a
   container called <interfaces>. Also, any assumptions about
   naming and keys in the examples need to be stated.

Sec 5.2.1:

 - We should remove any reference to non-existent BEEP modifications
   in this document.  This is not an option.  Stuff like this will only
   get stuck later anyway in the publication process.

 - The NETCONF over BEEP authors (and others clueful in BEEP)
   need to provide input on all of sec. 5.2

 - rpc-one-way is still in the document.  This doesn't belong,
   and is not explained.

Sec 5.3:

 - Para 2 seems a bit unclear, and needs punctuation.
   Explain why it is more important.

Sec 6.1:

 - This example assumes some data model with a root named
   <neb>, with a child element named <event>.  Change 'neb'
   to 'top' to be more consistent with other examples.

 - The example showing a child node of <event> named <card>
   is not very clear, or a realistic data model.  

Sec 7.1:

 - The warning message is not very clear.  It needs to be
   completely specified in the Negative Response section (7.5.1).

Sec 8:

 - The Security Considerations need to be specified.  This cannot
   remain TBD as we go move towards WG Last Call.