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

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

Thanks for sending comments. See some responses in-line
Hector
 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, May 02, 2006 11:39 AM
> To: Netconf (E-mail)
> Subject: comments on draft-ietf-netconf-notification-01.txt
> 
> Hi,
> 
> This is not a full review.
> I'm still waiting for some WG members to do that.

HT: Could you please include the names of the reviewers so we get an
idea of what the various interested people are saying.

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

HT: Ok. 
> 
>   - 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.

HT: The notification related RPCs give the user a convinient way to
request notification forwarding. While I agree that you could achieve
the same by using the NETCONF RPCs against a data model, such model does
not exist and there isn't much work in this area. Therefore, I don't see
how you can argue this point. 

The named profiles provide a way to pre-configure subcription
information. What is the objection to this? In previous e-mails I
thought you also suggested having "profiles" with pre-configured
destinations. The idea is to allow for read/write access to the
subscription information. 

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

HT: I thought we had agreed to at least config change and syslog. 
> 
> --------------------------------------
> 
> 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.

HT: Ok 
> 
> ----------------
> 
> page 4:
> 
> NETCONF[NETCONF] --> NETCONF [NETCONF-PROTO]

HT: OK
> 
> ---------------
> 
> 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.

HT: OK
> 
> ----------------
> 
> page 6:
> 
> <create-subscription>
> 
> "This command .."
> 
> Wrong terminology.
> Use RPC method or operation.

HT: OK
> 
> -----------------
> 
> 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.

HT: Ok  
> 
> ------------------
> 
> 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.

HT: OK, will update description. Regarding you second part of the
comment... the definition of a config change
notification allows for the inclusion (or not) of the changes that took
place. Depending on the managed device, this is actually a
desired/useful behavior. In some cases the device will send a change
notification with an ID & the management station may retrieve the
associated information. In other cases, the device will send all the
changes in a notification. I disagree the examples are unrealistic. 
I think the comment on access control is too generic & this may or may
not be true depending on the deployment. 

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

HT: OK, will add explanatory text
> 
> Not sure what this <neb> element is in the example.

HT: It's just a tag to represent the top of a model that doesn't exist.
Same as top in the NETCONF examples. Will clarify. 
> 
> <netconf:filter> is broken XML -- there is no 'netconf' 
> prefix or an xmlns declared in the example.

HT: No, it's not broken XML. It is correct based on the XSD that it was
generated against. Will update to make sure there is no
misunderstandings. 
> 
> 
> ------------------
> 
> 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.

HT: Will look at text 

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

HT: Ok. So can we agree to make updates and move this section into the
main body 
> 
> ---------------------
> 
> 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.

HT: OK
> 
> -------------------
> 
> 
> 
> 
> 
> 
> 
> 
> --
> 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/>
> 

--
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/>