[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-netconf-notification-01.txt
Hector Trevino (htrevino) wrote:
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.
I wish I could, but this is a volunteer organization.
I have asked many people to do full reviews and to start
prototyping implementations. I haven't received much
interest in either task.
-----------------------
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.
I don't see how you could argue
that we should ignore all the standard
operations we just created in NETCONF-PROT.
The proposed special RPCs don't exist anymore
than a standard data model for configuration notifications.
It's less work to define data models for use with the
netconf protocol than it is to redefine the netconf protocol
functionality.
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.
There is a big difference between a standard data model
with a set of standard parameters, and a standard pointer
off to some proprietary data model.
- 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.
There is interest in this type of content.
Not wide consensus on any particular type of content,
but these seem to keep coming up in examples.
--------------------------------------
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.
It seems to be a TimeFilter mechanism
(get all config that changed since time T)
is more useful than including all the changed
config in a notification.
Which products do this with notifications today? None, AFAIK.
------------------
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.
You have the same <event> subtree listed 3 times in the
filter example. I'm not sure this is legal.
------------------
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
No -- You can wait until the WG discusses it,
and if the WG wants it, it will move to a different section.
---------------------
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/>