Sharon Chisholm wrote:
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.
The WG will need to agree on the list on classes.
Currently there is no agreement.
This could take 3 - 6 extra months to reach
consensus on what the event types are allowed to be,
and the exact requirements and text related to each event type.
Putting some details in a non-normative appendix
instead of normative text is not acceptable.
It doesn't lessen the requirement for WG consensus
just because it's located in an appendix.
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.
Agreement on all semantics of all event classes is the key issue.
The form of the registry is irrelevant.
--------------------------------------
<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.
I don't -- especially if notifications end up as
an optional capability.
<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?
From my reading of the text, examples, and XSD, it appears
this is not clearly defined. Let's see what others think.
It looked to me that it didn't change much, except you added
a sentence that says there is supposed to be a schema that
tells the manager what is in the named profile.
I think we just need a plain data model that contains all of the
configurable
parameters. This data model must be the same for all implementations.
That's because this is supposed to be a standard.
The netconf protocol already has RPCs for manipulating data models,
already deals with all aspects of NV-storage, etc.
We don't need to introduce the concept of named profiles.
It's just more complexity without purpose.
----------------
<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.
If there was a clearly specified architecture section, it would be
totally obvious how the notification "message flow" differed
from the RPC message flow.
Positive Response : none
This doesn't really provide enough discussion of the message flow
or architecture.
------------------
<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.
I don't want to confuse implementors by implying in the
examples that including all the config sections that changed
in a notification is a good idea, or part of the standard.
------------------
<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
Real big problem.
Won't get through the WG Chairs or the IESG.
It is not acceptable to block this document for unchartered work.
The min and max access allowed in terms of all netconf operations
will be defined in English text in a normative section.
The addition of <appInfo> elements for this purpose is not required,
not useful to off-the-shelf tools, and therefore not important.
The data models in NETCONF documents can be updated after
this sort of thing is standardized.
-----------------
<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.
The <neb> example is fairly broken.
There is no way to do an OR-expression on 1 field
like the example seems to imply.
------------------
<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
I think the entire Callhome section is under-specified and
the whole approach is convoluted. We already have NV-stored
data models in netconf. We could easily have a traditional
notification architecture without any subscription mechanism,
instead of an agent that connects to a manager and says
"ask me to start sending you notifications".
How does the agent know to ask?
Because it was configured in its NV-storage.
There could just as easily be the entire notification config
as well.
I've never met any operators who would rather miss critical
notifications than "risk" the wasted bandwidth of an agent sending
out critical alarms but nobody is listening.
It seems to me that holding all notifications
until some manager app reconnects after a reboot
and asks for them, amounts to a polling architecture.
It doesn't scale well either.
--------------------
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.
The WG never even discussed this issue.
There was no discussion of adding new event classes,
only discussion of removing some event classes.
Now that the document is a WG-controlled document,
only changes that the WG agrees on are supposed to
show up in new versions.
Many vendors and operators at the IAB NM Workshop
were very clear in their request -- no proxy in netconf.
It was seen as complexity without purpose.
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
Andy
--
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/>