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

[Andy Bierman <ietf@andybierman.com>]

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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>