Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

From: Qin Wu <[email-masked]>
Date: Tue, 17 Oct 2017 05:04:56 +0000

I have reviewed this draft and have the following comments to this draft:

1.      I want to understand the relationship between draft-dsdt-nmda-guidelines-01 and draft-ietf-netmod-rfc6087bis-14, it looks some of pieces have been merged into draft-ietf-netmod-rfc6087bis-14 and some of pieces have been moved to draft-ietf-netmod-revised-datastores-04, Would you like to clarify this in details.

2.      Section 4.6.5, 1st paragraph, 1st sentence

Have difficulty to parse this sentence, what it is emphasize here is when combined with several modules, the XPATH expression being evaluated is different from one that has been evaluated within a single module, am I correct? If the answer is yes, I believe this sentence needs to be improved.

3.      Section 4.6.5

s/ when /foo/services/*/active/" when /foo/services/*/active"

4.      Section 4.11.4

What the second version is referred to? Correct one?

5.      Section 4.11.5

"When used within a list key, only one value can (and must)

exist for this key leaf.  The type "empty" SHOULD NOT be used for a

key leaf since it is pointless."

It looks these two sentences contradict with each other? The first sentence says 'empty' data type could be used as a list key(The confusion is what one value is is not clear),

The second sentence says the 'empty' data type should not be used as list key. Could you give an example on how to use 'empty' data type with a list key leaf.

6.      Section 4.12.2

s/-top-level/top-level

Can not parse the first paragraph.

7.      Section 4.23.2, 2nd paragraph

What the value set is referred to? Take admin-state leaf and oper-state leaf as an example, if both admin-state and oper-state are set to uint32, do you mean values range set for admin-state

e.g.,range "0..100" is different from value range set for oper-state, e.g.,"101..200", Do you mean "admin-state" value set is configured value set?

8. Section 4.23.2 3rd paragraph, 4th paragraph

    How the 4th  paragraph is related to 3nd paragraph?

In 3nd paragraph, it discuss two list have two different key

In 4th paragraph, it discusses two list have keys with same type

9.      Section 4.23.3.1

Why there is no example for Temporary non-NMDA Modules?

10.  Section 4.23.3.1, 2nd paragraph

s/ the deprecated <get>

operation/with the deprecated <get> operation

11.  Section 4.23.3.1 3rd paragraph

when we need to create temporary non-NMDA model from NMDA model? Since when we transition to NMDA model, why we should transition back to temporary Non-NMDA model?

How temporary non-NMDA Modules is different from temporary NMDA modules? This is something I feel very confused.

12.  Section 4.23.3.1 said:
"   o  Retain or create only the top-level nodes that have a "config"
      statement value "false".  These subtrees represent config=false
      data nodes that were combined into the configuration subtree, and
      therefore not available to non-NMDA aware clients.  Set the
      "status" statement to "deprecated" for each new node.

"

Where  these subtrees are defined? It is not clear to me by reading the first sentence in this bullet.

13.  Section 4.23.3.4

How "create a Temporary NMDA Module" is different from "Convert an old Non-NMDA Module" described in section 4.23.3.3

When do we need to create a temporary NMDA module?

14.  Section 4.26.4
s/access access control/access control

-Qin
-------- Forwarded Message --------
Subject:

[netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

Date:

Tue, 12 Sep 2017 18:21:49 +0000

From:

Kent Watsen <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

This starts a two-week working group last call on:

    Guidelines for Authors and Reviewers of YANG Data Model Documents

    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.

  * I have reviewed this draft and found the following issues: ...

Thank you,

NETMOD WG Chairs

_______________________________________________

netmod mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/netmod

.

________________________________