Hi Marc, Sharon, Martin,
I reviewed the draft
NETCONF Monitoring Schema.
Please find my comments
below.
General comments)
- The comments/descriptions in the
YANG and the XSD should be the same.
Abstract)
Remove the word dynamically, IMHO it does not mean anything
Definition of terms)
Remove Element, not used
Operation refers to the notifications, change it!
Mention YANG
I was wondering if schema or model or model fragment is the correct
term ?
2.1.1. capabilities
>From RFC4741: "The device uses capabilities to announce the set of data
models that the device implements."
This to me means that the device MUST advertise all it's models as
capabilities as well. So the models will be included both in the
capabilities and the schemas branch. Please indicate this.
Remove minimally. I think all capabilities MUST be advertised already
in the HELLO message; or are you thinking of new capabilities/models
that appear during a session?
2.1.2. configurations
The list of nodes is the authoritative information on a partial lock.
Please place it before the select leaf. The select is only provided for
completeness, to show the original intent of the locking entity and is
only informational.
2.1.6 Statistics
- Maybe clarify that we only provide Netconf statistics.
- On page 38 for inSessions you have a short _expression_ identifying how
the different counters relate to each other. More such expressions
would be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors -
inBadRpcs - inNotSupportedRpcs
- Add something like: a Netconf message can be either Hello messages or
Rpcs.
Would it be
interesting to count whether sessions end with close, kill, or loss of
transport? The last could indicate problems, while too many kills could
indicate hacking or locking problems
5.1 Netconf Monitoring
Schema
I only briefly checked this part.
- Page 18) It is strange that we have separately ConfigurationDatastore
and ConfigurationDatastoreType and both are TYPEs. A different name
should be chosen for one of them.
- I think ncEvent should also be imported
- a few things don't have a type e.g. lockedNodes, select
- Page 24) Why is ConfigurationDatastoreType not reused from RFC4741?
- Will it be possible
to add new values to SchemaFormat, TransportType and ProtocolType? It
is sure that we will have new things here. (We (Ericsson) already have
e.g. LDAP)
5.2 int:host schema
This should be a separate draft as many other will need it. Is there
today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd?
What is the state of that? Anyone who cares about XSD should start
pushing that draft!
- I think there are some differences between how YANG and this draft
defines domainName. They should be aligned!
Appendix A YANG
- ConfigurationDatastoreType should be defined in a separate
netconfRFC4741 module.
- SchemaFormat,
TransportType and ProtocolType must be choice, as enumerations are not
extensible and it is definite that we will have new values for these.
- Is the corect name RNG or DSDL
- The Netconf container shall be config true. Only containers below it
should be config false. It is quite possible that we will later
(possibly in another draft/rfc) add stuff under netconf that is
configurable or that someone wants to extend it with configurable
settings e.g. access control, max-number of paralel sessions.
-
/netconf/configurations/configuration/locks/lockedBySession should be a
keyref
-
lockedNodes should come before select as lockedNodes is the
authoritative information
- do we need top level containers like schemas? We could have the list
schema directly under /netconf
-
/netconf/subscriptions/subscription/sessionId should be a keyref
X. IANA Considerations
Do we register any XML namespaces? I guess so.
Shall we also start the YANG registry?
regards Balazs
