Subject: comments on draft-ietf-netconf-notification-01.txt

From: Andy Bierman <[email-masked]>
Date: Tue, 02 May 2006 10:38:38 -0700

Hi,

This is not a full review.
I'm still waiting for some WG members to do that.

-----------------------

General comments:

  - The draft still lacks any discussion of why we need this
    document, what role it plays in the overall netconf architecture.

  - The use of special RPCs, named profiles, and a read-only data model
    goes against the core concept of netconf -- use the standard operations
    to manipulate standard read-write data models.  The convoluted manner
    in which a traditional notification generation application would be
    realized would win a Rube Goldberg Machine Contest.

    I strongly object to this design approach.

  - multiple subscriptions per session

    I strongly object to this feature.
    There is no rationale given for it.
    Netconf has a single-user session model.
    The NMS can use modify-subscription instead of creating multiple
    subscriptions.  The NMS, not the agent, should provide this
    additional, programmable classification service.  The complexity
    added to the document to move this classification service to
    the agent is unwarranted, and the feature is totally redundant.

  - Event classes

    I strongly object to this document defining the mandatory set of
    event classifications.  This document should simply define a
    field that contains a constrained string, which can be used for
    filtering purposes.  The list still contains enumerations such as
    'metrics' and 'heartbeat' which were supposed to be removed.
    There are under-specified semantics and requirements for many
    of these classifications.

    The actual set of standard events is a modeling problem, and is
    out of scope in this WG.

--------------------------------------

page 4:

   "discusses implications for the mapping of application protocols"

Is this document doing to define the normative procedures
for supporting notifications on each transport?  I think
this would be better than generating 4 RFCs instead of 1,
but the WG needs to decide where the normative transport-specific
text will be located.

----------------

page 4:

NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

---------------

sec. 2:

There are no examples shown for each RPC operation.
There should be examples here instead of spread out
in the end of the document.

----------------

page 6:

<create-subscription>

"This command .."

Wrong terminology.
Use RPC method or operation.

-----------------

page 6:

<named-profile>

This is still an opaque, under-specified proprietary hack.
There should be a read-write standard data model with
standard parameters -- and nothing else.

I strongly object to this parameter.
If vendors want to ignore the standard parameters
and use their own instead, then XML already allows them to
do that -- we should not help them hack around the standard
within the standard itself.

----------------

<notification>

Positive Response: no response, etc.

This only applies to RPCs, so it can be removed here.

------------------

notification examples in section 5:

It should be made clear they are only examples
and are not normative.  The examples need to be explained
as well.

These examples are unrealistic.
I don't think it's proper for the agent to return a copy of all
the config that actually changed in a 'config-change' notification.
This could be really verbose, introduce access control problems,
and it's not really needed anyway, if the NMS is designed correctly.

------------------

schema comments

- an unspecified access control model is thrown in
   with these 'minAccess' and 'maxAccess' <appinfo> additions.
   There is no agreement in the WG on these XSD extensions,
   or understanding of the functional requirements.

-----------------

filter example comments

Sec 6.2 introduces additional 'severity=foo' filtering syntax
without really explaining it.

Not sure what this <neb> element is in the example.

<netconf:filter> is broken XML -- there is no 'netconf' prefix
or an xmlns declared in the example.

------------------

section 7.1.1.1 session lifecycle

The WG did not discuss or approve any such feature.
This watchdog-timer design doesn't work in a mixed-mode
session very well.  The netconf agent never abruptly
terminates a live session.  The lack of architecture discussion
in this document jumps out in this section.  There is no
mention of the agent constantly starting and tearing down sessions
anywhere else.

This section needs to be removed.

------------------

Appendix A: Design Alternatives

A.1 Suspend and Resume

This section introduces even more complexity with new
<suspend-subscription> and <resume-subscription> RPCs.

I strongly object to all of these specialized RPCs.
If we have a proper read-write data model, the standard
operations such as <edit-config> provide all the
configuration manipulation features we need.

The agent already has code to implement <edit-config>.
All of these special RPCs which are used to avoid <edit-config>
add extra code and complexity to the agent.

--------------------

A.2 Lifecycle

This section is incorrect and needs to be removed.
The NETCONF-PROT document already mandates certain
non-volatile storage requirements.  This section
contradicts that normative text.

---------------------

Appendix B: Syslog within NETCONF events

events --> notifications

This section does dot clearly define how to encode the
XML PDU.  This should be a normative section (and fully
specified) or removed from the document.

Notification forwarding options needs to be agreed upon
by the WG, and fully explained in a detailed architecture
section.

There is no proxy in netconf, and I aim to keep it that way.

---------------------

Appendix C: Example Configuration Notifications

This section needs to be removed.
If the WG can agree of fully-specified standard notifications,
then they will included in normative text.

-------------------

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 3 May 2006 11:59:55 +0200

W.r.t.
>     document, what role it plays in the overall netconf architecture.

I wonder where we are with the discussion of that topic of why we
need notifications and if we need them, what exactly we need them for.
Remember that Juergen was/is keeping track at:

  http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications

It is (iirc) just a list of what people have posted, and it does NOT 
represent WG consensus as to what the motivations and requirements are.
Should we try to see if we (as a WG) can get to consensus on that?

Bert

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Wed, 3 May 2006 09:32:35 -0700

--- cut --- 

Question below.
Hector

> 
> > 
> > 
> > -----------------
> > <Andy>
> > 
> > filter example comments
> > 
> > Sec 6.2 introduces additional 'severity=foo' filtering 
> syntax without 
> > really explaining it.
> > 
> > <netconf:filter> is broken XML -- there is no 'netconf' 
> prefix or an 
> > xmlns declared in the example.
> > </Andy>
> > 
> > Hmmm. Need to look into these. 
> 
> 
> The <neb> example is fairly broken.
> There is no way to do an OR-expression on 1 field like the 
> example seems to imply.
> 
> 

HT: Ok, perhaps this is a mis-interpretation of the subtree filtering
use. Reading the NETCONF text it appeared that the XML in the filter
example would be treated as an OR operation. If this is a
misinterpretation could you please clarify and point me to the
appropriate rule below. 

In the example there is a node called "severity" which is repeated
multiple times with diff values. Looking at the list below, if this is
considered a "list" then the example is not valid, perhaps there are
others. Anyway, if you could clarify I'd appreciate it.
thanks

"6.2.5.  Content Match Nodes

   A leaf node which contains simple content is called a "content match
   node".  It is used to select some or all of its sibling nodes for
   filter output, and represents an exact-match filter on the leaf node
   element content.  The following constraints apply to content match
   nodes:

   o  A content match node must not contain nested elements (i.e., must
      resolve to a simpleType in XSD).

   o  Multiple content match nodes (i.e., sibling nodes) are logically
      combined in an "AND" expression.

   o  Filtering of mixed content is not supported.

   o  Filtering of list content is not supported.

   o  Filtering of whitespace-only content is not supported.
o  Leading and trailing whitespace characters are ignored, but any
      whitespace characters within a block of text characters are not
      ignored or modified.

   If all specified sibling content match nodes in a subtree filter
   expression are 'true', then the filter output nodes are selected in
   the following manner:

   o  Each content match node in the sibling set is included in the
      filter output.

   o  If any containment nodes are present in the sibling set then they
      are processed further, and included if any nested filter criteria
      are also met.

   o  If any selection nodes are present in the sibling set then all of
      them are included in the filter output.

   o  Otherwise (i.e., there are no selection or containment nodes in
      the filter sibling set) all the nodes defined at this level in the
      underlying data model (and their subtrees, if any) are returned in
      the filter output.

   If any of the sibling content match node tests are 'false', then no
   further filter processing is performed on that sibling set, and none
   of the sibling subtrees are selected by the filter, including the
   content match node(s)."