Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2

Thank you Andy.
Sending to IETF LC now.

Regards, Benoit
> Hi,
>
> I think draft-18 addresses all these issues.
> A guideline about key leaf order has also been added.
>
> Andy
>
>
> On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise <bclaise@cisco.com 
> <mailto:bclaise@cisco.com>> wrote:
>
>     Dear all,
>
>     Here is the part 2 of the AD review, from section 4.21 on.
>
>     Regarding the part 1, thanks Andy for addressing all comments in version 17.
>
>     - section 4.22 "Data Correlation.
>
>     Not sure what you mean by the section title and "Data can be correlated in various ways"?
>     Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
>     I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section
>     is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
>     Note: I read that section multiple times.
>
>     - section 4.22
>         It is sometimes useful to separate configuration data and operational
>         state, so that they do not not even share the exact same naming
>         characteristics.  The correlation between configuration the
>         operational state that is affected by changes in configuration is a
>         complex problem.  There may not be a simple 1:1 relationship between
>         a configuration data node and an operational state node.  Further
>         work is needed in YANG to clarify this relationship.  Protocol work
>         may also be needed to allow a client to retrieve this type of
>         information from a server.  At this time the best practice is to
>         clearly document any relationship to other data structures in the
>         "description" statement.
>
>     Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
>     	
>         Designers SHOULD describe and justify any NMDA exceptions in detail,
>         such as the use of separate subtrees and/or separate leafs.
>
>     ... and I guess confusing in light of the real guidelines in 4.23.3
>     Btw, why is this paragraph in 4.22 and not in 4.23?
>
>     - section 4.23
>
>     	Operational state is now modeled using YANG according to new NMDA,
>
>     Please add a reference to the draft.
>
>     - section 4.26 "YANG 1.1 Guidelines"
>     I'm confused by the title. The entire document is about 1.1, right?
>     I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"
>
>     - section 4.26.1
>
>           Multiple revisions of the same module can be imported, provided that
>           different prefixes are used.
>
>     Readinghttps://tools.ietf.org/html/rfc7950#section-7.1.5
>     <https://tools.ietf.org/html/rfc7950#section-7.1.5>. Any contradiction?
>     Then reading:
>         This MAY be done if the authors can
>         demonstrate that the "avoided" definitions from the most recent of
>         the multiple revisions are somehow broken or harmful to
>         interoperability.
>
>     "avoided" definitions?
>     I simply don't understand this sentence.
>
>     - section 4.26.4
>         The NETCONF Access Control Model (NACM) [RFC6536 <https://tools.ietf.org/html/rfc6536>] does not support
>         parameter access control for RPC operations.
>
>     Let's use draft-ietf-netconf-rfc6536bis
>
>
>     - Appendix B
>
>         YANG Module Registry: Register the YANG module name, prefix,
>               namespace, and RFC number, according to the rules specified
>               in [RFC7950 <https://tools.ietf.org/html/rfc7950>].
>
>     I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
>     See for examplehttps://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6
>     <https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6>
>
>     - Appendix B
>     References -- verify that the references are properly divided
>            between normative and informative references, thatRFC 2119 <https://tools.ietf.org/html/rfc2119>  is
>            included as a normative reference if the terminology defined
>            therein is used in the document
>
>     Refer to RFC8174
>
>     - Appendix B (and maybe some more text somewhere else.
>     To refer to Tom Petch latest email to NETMOD, we should need a few words about:
>        If a YANG module has a Reference or Description clause specifying an
>        I-D, and the I-D is listed as an Informative Reference.
>
>     Regards, Benoit
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>