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

[Andy Bierman]

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  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.
>
> Reading 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 
> ] 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 ].
>
> I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" 
> registry is specified in RFC6020/.
> See for example 
> 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, that RFC 2119 
>  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
> https://www.ietf.org/mailman/listinfo/netmod
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-rfc6087bis-18.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Guidelines for Authors and Reviewers of YANG Data 
Model Documents
Author  : Andy Bierman
Filename: draft-ietf-netmod-rfc6087bis-18.txt
Pages   : 71
Date: 2018-02-20

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-18
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Kent Watsen]

> Kent
> 
> You illustrate beautifully the problem I would like a solution to.
>
> The current thinking AFAICT is that tree-diagrams
> should be an Informative Reference.
>
> Therefore, the RFC Editor will not hold publication until an RFC number
> is assigned.
> 
> Therefore, a note asking the I-D reference to be updated to reflect the
> assigned RFC number is null - the RFC can be published with the
> reference as an i-d and not as an RFC which is what I expect the RFC
> Editor to do.
> 
> QED


Except I know that this draft will be stuck in MISREF state and tree-diagrams
will in fact be assigned an RFC number by the time this draft is published.

K.


> Note that this is not the case of a Normative i-d reference being buried
> in the YANG module and not being.noticed by the RFC Editor; that problem
> I am content with.
>
>
>Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
>



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, February 14, 2018 6:03 PM

> Buggers, I thought we caught that tree-diagrams informative/normative
thing before.
>
> Regardless, Clyde, please note that I think I was wrong before from
the shepherd write-up regarding idnits having a problem:
>
> """
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1340,
>  but no explicit reference was found in the text
>  '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a
"Keys...'
>
>This is a bug in idnits, whereby a reference that splits two lines
is
>not found.
> """
>
> Looking at the XML, it seems that references are not specified
correctly.
>
> CURRENT:
>
> This module imports typedefs from [RFC7223], groupings from
> [I-D.ietf-netconf-keystore], and
[I-D.ietf-netconf-tls-client-server], and it references [RFC5424],
> [RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].
>
> SHOULD BE:
>
> This module imports typedefs from ,
groupings from
> , and , and it references ,
> , , and  and .
>
> Right?
>
> And while you're at it, please update the reference to the
tree-diagrams draft (-06 is current).  Also, missing is an RFC Editor
note requesting that the I-D reference to be updated to reflect the
assigned RFC number.

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that
tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC number
is assigned.

Therefore, a note asking the I-D reference to be updated to reflect the
assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED

Note that this is not the case of a Normative i-d reference being buried
in the YANG module and not being.noticed by the RFC Editor; that problem
I am content with.


Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod