Subject: [Netconf] netconf-monitoring-03 comments

From: WashamFan <[email-masked]>
Date: Sat, 28 Feb 2009 16:27:04 +0800

Hi,

1)
para2 & a part of para3, abstract: 

   Today, NETCONF capabilities exchange is the only standardized method
   a client can use to discover the functionality supported by a NETCONF
   server.  This works well for static protocol capabilities but is not
   well suited for capabilities which could change during a session.

   Considerations such as different schema formats, feature optionality
   and access controls can all impact the applicability and level of
   detail the NETCONF server sends to a client during session setup.
   Through updated monitoring data NETCONF clients can adjust their
   capabilities throughout a session.

sec 2.1.1:

   The list of capabilities supported by the NETCONF server.  The list
   MUST include all capabilities exchanged during session setup still
   applicable at the time of the request.  This ensures consistency with
   the initial capabilities exchanged while allowing for potential
   modifications during a session.

IIRC, There was a discussion about if capabilities exchanged at the begin 
of a session should be changed later. I don't know if there has been a
consensus on this issue.

2)
para1, sec 1

   This document defines NETCONF content via [XMLSchema] to be used to
   monitor the NETCONF protocol.  It provides information about NETCONF
   sessions and subscriptions.

Why leaving out capabilities, configurations, schemas, statistics?

3)
sec 2.1.2:

name (type: NETCONFDatastoreType)
     Enumeration of supported datastores; candidate, running, startup.

I am not sure if user-defined datastores should be considered here.

4)
last para2,sec 2.1.3:

At least one schema entry SHOULD be available to support retrieval.

That makes little sense. s/schema entry/location/. I suggest add some
text to state multiple locations are allowed. Because I don't see
that until I read the XSD.

5)
sec 2.1.4:

sessionId (type: SessionId)
     Unique identifier for the session.

Would you like to add some text to state how to identify non-Netconf sessions?

6)
para1, sec 3.2:

   Since the same schema may be supported in
   multiple locations and/or have multiple versions and/or multiple
   formats no particular attribute is unique.

This sentence is a little confused to me maybe as I am not an native speaker.

7)
last character, para3, sec 3.2:

http.i

???

8) There is some inconsistency betweem some place in sec2 and
XSD defined in sec5. I assume the XSD is correct, 

para2, sec 2.1.4:
sessions (type: ManagementSessionInfo):
s/ManagementSessionInfo/ManagementSession/

para2, sec 2.1.6:
managementStatistics(type: ManagementPerformanceStatistics):
s/managementStatistics/statistics/
s/managementPerformanceStatistics/managementStatistics/

9) a typo:
sentence 3, para1, sec 3.2:
Available schema for the requesting session are
s/shema/schemas/

10) one more thing, it is a little confused to state
capabilities (type:  xs:anyURI)        <-- sec 2.1
xs:anyURI is not the type of capabilities, capabilities
is sequence of capability whose type is xs:anyURI.
And this exists in some other places, too.

washam