Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 21 Jul 2008 10:11:45 +0200

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 thisFrom [email-masked]  Mon Jul 21 01:11:12 2008
Content-class: urn:content-classes:message
Date: Mon, 21 Jul 2008 10:11:45 +0200
From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
To: "Mark Scott" <[email-masked]>,
	"Sharon Chisholm" <[email-masked]>,
	"Martin Bjorklund" <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

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  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:  &lt;get-schema&gt;/RPC definition:  <get-schema>/

6. Security Considerations

I wostandard 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:  &lt;get-schema&gt;/RPC definition:  <get-schema>/

6. Security Considerations

I would chuld 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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Jul 2008 12:27:10 -0400

hi
 
Thanks for your comments. Reply inline.

________________________________

From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 4:12 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin
Bjorklund
Cc: netconf mailing list; ext Bert Wijnen (IETF)
Subject: Review of draft-ietf-netconf-monitoring-02.txt

 <clip>

 2.1.3. schemas 

<sharon>

Technically,  I think the term should be 'operation' not 'RPC'. We
should make this correction throughout the ID.

</sharon> 

<clip>

Cheers, 
Mehmet

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 22 Jul 2008 12:27:10 -0400

hi

 <clip>

 2.1.3. schemas 

<sharon>

</sharon> 

<clip>

Cheers, 
Mehmet