[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ietf-netconf-notification-01.txt
hi
Thanks for the review ....
<Andy>
- 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.
</Andy>
The subscription command is easier then other 'traditional' models for
the person doing the subscribing. We have modified the named profiles to
be a persistent set of information related to subscriptions for those
who are more interested in that approach. I'm hoping by 'traditional
notification generator' that you don't mean you wish to duplicate an
SNMP notification generator in Netconf. That model is one that we should
learn from and move on.
<Andy strongly objecting to multiple subscriptions per session>
It seems more work to me to preclude it then allow it. There are
advantages to being able to organize two different sets of filters into
two different subscriptions.
<Andy>
- 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.
</Andy>
I strong support the inclusion of event classes in the document. I
thought we had agreed we had consensus that this was useful and should
be included? It lets the consumer of the message know what the content
will be and enables the receiver to route the notification to the
appropriate consumers. It is very useful and comparable in data model
bleed to candidate and running configuration in the base protocol work.
The idea here it to only specify the class and defer the content of the
message to the datamodel.
We still have the open discussion on what the initial set of values is
and how they will be extended. There was discussion about a more
URI-based extension instead of an enumerated list, but as was discussed,
there are some serious disadvantages to this approach. This is similar
to the enumerated list versus rowPointer debate we always had in SNMP.
One-stop-shopping of enumerated lists provide much more ease of use and
predictability then open-ended where-can-I-find-all-the-values things
like URIs. URIs are good for big things like protocol operations and
Schema namespace, but not for everything. Either way, putting the list
in IANA seems reasonable.
--------------------------------------
<Andy>
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.
</Andy>
The text is more there because it needs to be somewhere. I like the idea
of updating the existing three transport documents (once they get
published) then creating separate ones.
<Andy>
----------------
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.
-----------------
</Andy>
ok
<Andy>
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.
</Andy>
Sorry? In the latest specification, the data model associated with the
named profile is clearly defined. It's even read-write. What exactly is
it you are looking for?
----------------
<Andy>
<notification>
Positive Response: no response, etc.
This only applies to RPCs, so it can be removed here.
</Andy>
I disagree. I think it should be explicitly stated that there is no
response. First of all, because we could have made these acknowledged
events built on RPCs and second of all I still say the average reader
thinks about the Netconf operations rather then the RPC analogy we have
chosen to express them with.
------------------
<Andy>
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.
</Andy>
We have added this disclaimer to other examples, but not those in
section 5. We can do that. We have identified two types of configuration
change events. The first provides more of a summary of changes in some
useful format (new interface up or something) and the second would
actually mirror the configuration command sent. The latter is necessary
for security audit logs.
Notifications always have access control issues. People need to have
permission to see the data that is in the notifications.
------------------
<Andy>
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.
</Andy>
Yeah, that is a bit of a problem. We need this mechanism, but we don't
have a standard one yet. So, we are using the one defined in
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-05.txt
-----------------
<Andy>
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.
</Andy>
Hmmm. Need to look into these.
------------------
<Andy>
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.
</Andy>
Just the session lifecycle or the CallHome thing? Our understanding was
that there was consensus to look at how to address the callHome thing
and the session lifecycle is discussion related to that feature. If
there is no consensus for the callHome thing, we can move it back to the
design alternative appendix
--------------------
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.
</Andy>
We'll have to look into it. I suspect this is a misinterpretation of
what is written rather then this design alternative was proposing
something in violation of what is the in the PROTO draft.
---------------------
<Andy>
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.
</Andy>
We were not sure if there was consensus for this feature to be moved to
the main body of the document. We did add the new event class to support
the tunnelling though.
We don't specify how to encode any of the other event content. I don't
know if we should be doing it for this one case.
---------------------
<Andy>
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.
</Andy>
While we did delete the sections that provided examples for
non-configuration notifications, we were hesitant to delete this section
because we actually referred to it during discussions last month. It
might be useful to keep around for a bit longer.
Sharon
--
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/>