 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Marc, Sharon, Martin,
I reviewed the draft NETCONF Monitoring Schema.
Please find my comments below.
General comments:
- I was wondering whether the WG finds it useful if the title of the
draft reflects also the second topic covered in the document,
e.g. "NETCONF Monitoring and Schema Retrieval".
- Since this is a standard track document we should use the RFC 2116
terminology and state whether a Schema element MUST or SHOULD be
used. I could only find in two cases the explanation that an element is
"optional".
- Since we are going to register the XML Schema at IANA I agree that
the schema needs to be self-explaining. For a consistent specification
we need also to define the schema elements in the document sufficiently.
- I did not check the YANG module. I think Martin or other YANG men
can do this better than me.
Comments per chapter:
1. Introduction
The text in the introduction is redundant with the text in Abstract.
I would like to suggest to write here a bit more in detail why we need
Netconf protocol monitoring and Netconf schema retrieval. It should
be made clear why this standard document is important and needed.
1.1. Definition of Terms
We should add the terms "Global Lock" and "Partial Lock" to the terminology
list.
2. XML Schema to Monitor NETCONF
I would change the first sentence for more clearness. I am not sure
whether we are "proposing to allow...". IMO we are standardizing the
data which MUST be used by a NETCONF client to monitor . . .
2.1.1. capabilities
- In chapter 2.1. and 2.1.5. the types of the schema elements have
been specified. I would suggest to do this also in chapters 2.1.1.,
2.1.3., 2.1.4., and 2.1.6..
- I don't understand "Minimally"? I would rather delete this word and
re-formulate more clearly.
- Please state here that this element is a mandatory list and at least
one capability MUST be given.
- IANA does not support the use of a URL to IANA registry in standard
documents. Please refer to the URN by its name or better list the capabilities
defined in the capability URN.
2.1.2. configurations
- I would suggest to define here also the types "GlobalLock" and "PartialLock"
by their name.
- Description of the element lockId is missing.
- The element lockedNodes of the type PartialLock has been defined in the
XML Schema as an optional list. IMO if a partial lock exists then at least one
lockedNodes element should be available.
- I think we should use "MUST" instead of "will" if we think it has to be used.
- Please state that the element "locks" is optional.
2.1.3. schemas
- The schema location is defined in the XML Schema as a non-mandatory
list. This does not fit to the description in 2.1.3.. I think location should
be a mandatory element, or?
- I would delete the statement on <get-schema> RPC in 2.1.3. and add
in chapter "3.1 New NETCONF RPC, <get-schema>" that get-schema is
using the same elements as defined in chapter 2.1.3. The chapter 3.1.
should be self-explaining and include all necessary information.
2.1.4. sessions
s/Idenfities transport/Identifies transport/
2.1.5. subscriptions
- s/List of notifications subscriptions/List of notification subscriptions/
- Please use RFC 2116 terminology to indicate that sessionId MUST
have the same value as returned in 'sessions' to allow correlation.
3.1. New NETCONF RPC, <get-schema>
- I would like to suggest to use the same RPC definition format as
it has been used in NETCONF protocol and Notification standard
documents with following parts.
Description:
Parameters:
Response:
Example:
- The description in the last paragraph in 3.1. focuses on schema
list retrieval and is redundant with chapter 3.2. I would suggest
to put this text into the chapter 3.2.
3.2. NETCONF Schema List Retrieval (<get> monitoring data)
- Last sentence of this chapter is misleading (". . . using the
<get-schema> RPC described _later_ in this draft."). Please refer
to the chapter where <get-schema> is defined by its number,
e.g. ". . . is defined in chapter 3.1 <get-schema>".
- Please give a reference to chapter 7.7. <get> in the NETCONF
protocol where the <get> protocol operation is defined.
5.1. NETCONF Monitoring Schema
s/RPC definition: <get-schema>/RPC definition: <get-schema>/
6. Security Considerations
I would change the text: "The information in this Schema provides
information about . . . " to
"The NETCONF monitoring schema as defined in this document provides
information about . . ."
8. Normative References
Please add draft-ietf-netconf-partial-lock- to the list of informative
references.
X. IANA Considerations
I guess we will ask IANA to register the monitoring schema defined in
chapter 5.1.. Therefor we need also an IANA considerations chapter.
Please see the Notifications RFC 5277 chapter 8. for an example.
Cheers,
Mehmet
_______________________________________________ Netconf mailing list Netconf at ietf.org https://www.ietf.org/mailman/listinfo/netconf