Subject: [Netconf] comments on draft-ietf-netconf-with-defaults-08.txt

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jun 2010 11:44:59 +0200 (CEST)

Hi,

I have reviewed this document, and here are my comments:

--------------------------------------------------
2.1.2.  'report-all' <with-defaults> Retrieval

This is the first mentioning of "<with-defaults> Retrieval".  What is
it?

Aha.  On a second reading I think I understand what you mean.  I
suggest the following text:

NEW:

 2.1.1.  'report-all' Basic Mode Retrieval

   When data is retrieved from a server using the 'report-all' basic
   mode, and the <with-defaults> parameter is not present, all data
   nodes MUST be reported.

 2.1.2.  'report-all' <with-defaults> Retrieval

   When data is retrieved with a <with-defaults> parameter equal to
   'report-all', all data nodes MUST be reported, including any data
   nodes considered to be default data by the server.

And similar for the other modes in 2.2 and 2.3.

Also, I think the title of 2.1 is misleading:

  2.1.  'report-all' Basic Mode

since 2.1.2 applies to *all* basic modes.

Actually, the title of section 2 is also misleading.

Maybe a solution is to move section 2.1.2 to Section 3, which
introduces the <with-defaults> parameter.

--------------------------------------------------
2.1.3

2.2.3 and 2.3.3 talks about how the wd:default attribute is to be
handled.  Shouldn't 2.1.3 also talk about this?  If the idea is that a
report-all server cannot also support report-all-tagged, this should
be mentioned.

--------------------------------------------------
2.1.4

   All data nodes MUST be saved in non-volatile storage.

If a device advertises :startup and :writable-running, and I create a
new list entry in running, the device will create some default nodes.
But at this point they are not stored in nv-storage...

I would prefer to not talk about n-v at all; and instead say:

   All data nodes MUST be stored in the NETCONF datastore.

(similar for the other modes)

--------------------------------------------------

2.2.3

  s/same affect/same effect/

--------------------------------------------------
2.2.3 and 2.3.3

  If all NETCONF sub-operation parameters are valid,

What is a "sub-operation parameter"?

--------------------------------------------------
2.2.3

The last sentence says:

   If the data
   node within the NETCONF message contains a value in this case, it
   MUST be equal to the schema default value.

What happens otherwise?

--------------------------------------------------
3.

   The <with-defaults> parameter contains one of the three basic mode
   enumerations defined above,

+ 'report-all-tagged'

--------------------------------------------------
4.6.1

The document makes a clear distinction between the new capability and
the new YANG module.  But section 4 mixes the two.  Specifically
section 4.6.1 talks about the <with-defaults>  parameter which is
defined in the YANG module in section 5.  I think the text in 4.6.1
should be moved into the YANG module.

--------------------------------------------------
4.6.1

   If an unsupported value is used, the NETCONF server MUST return an
   <rpc-reply> with an <rpc-error> element.  The <error-tag> SHOULD be
   'invalid-value', and the <error-app-tag> SHOULD be 'with-defaults-
   mode-not-supported'.

Why are these SHOULD?  I suggest MUST.

I also agree with whoever had the comment that the error-app-tag is
not really necessary in this case.  So I suggest:

  The <error-tag> MUST be 'invalid-value'.

--------------------------------------------------
4.6.2

The last paragraph starts with:

  If this editing mode is used, then ...

What is "this editing mode"?

--------------------------------------------------
The YANG module in section 5.

Checking our own rules in netmod-guidelines:

$ pyang --ietf [email-masked]

[email-masked]:93: error: IETF rule: statement "grouping" must have a "description" substatement
[email-masked]:102: error: IETF rule: statement "augment" must have a "description" substatement
[email-masked]:107: error: IETF rule: statement "augment" must have a "description" substatement
[email-masked]:112: error: IETF rule: statement "augment" must have a "description" substatement

--------------------------------------------------
The XSD in 6.

The XSD does not compile.  Since the attribute is global, the 'form'
attribute cannot be given.

OLD:

  <xs:attribute name="default"
                type="xs:boolean"
                form="qualified"
                default="false">

NEW:

  <xs:attribute name="default"
                type="xs:boolean"
                default="false">

/martin