[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
review of draft-ietf-netconf-monitoring-01
My comments on draft-ietf-netconf-monitoring-01:
- General: This document needs a lot of work.
- The first two sentences of the abstract should be moved into the
introduction and the introduction clearly could have a bit more
text.
- Remove the term Managed Object - it does not seem to be used.
- Is 'netconfState' a good idea? How do we in general like to organize
data models?
- In the following text, is the right verb exchanged or announced?
Minimally must contain the same capabilities exchanged during
session setup.
If a device reports more than announced during the session setup,
how can I actually find out what has been announced for a given
session? Is the idea that an implementation can have capabilities
that are only announced on some session??
- Several of the elements (e.g. transport, protocol) are just strings
- so how do we achieve interoperability?
- The description of sourceIdentifier is inconsistent with the XSD.
- Can you you refer to inet:ip-address in the XSD??
- Where are things such as netconf:SessionId or netconf:configNameType
or netconf:filterInlineType defined? Is there a common
capitalization rule for identifiers or is this just random?
- I read:
sessionId:
unique identifier for the notifications. Same value as returned in
'sessions' to allow correlation.
I assume sessionId is an identifier for the notification session, not
for the notifications...
- What is NetconfSubscriptionInfo?? And how does it map to "event
subscriptions"?
- I don't find any of the schema reporting stuff in the XSD.
- I read:
location:
a location from which the schema can be retrieved. Can be either on
the network device (eg: URL), retrievable explicitly via netconf
('netconf') or some network location (eg: URL).
What is the difference between a 'network device' and a 'network
location'??
- Section 3 is all about "will be" but not about how things are
actually done.
- I read:
<identifier> and <version> elements are
mandatory and their values are unique
It is unclear what specifically is going to be unique. All the
identifers? All version numbers? The combinations of identifiers
with version numbers? Something else?
- Is there concensus that we do access control in units of schemas?
- How do I actually retrieve a schema via NETCONF? I know what to do
with a URL but this is where it ends...
- The list-schema example is not even valid XML. I am missing a clear
definition of the proposed NETCONF capability. And whay is
list-schema good for - it seems to do the same as the get operation,
no?
- I suggest to remove the first paragraph of section 4 since this text
is also in the security considerations (where it belongs).
- There needs to be IANA considerations since you need to allocate at
least a URN.
- I would love to have an appendix with a YANG module.
- I did not bother to read the XSD.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
--
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/>