Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
Mach One additional thought on tree diagrams. This is now RFC8340 and YANG guidelines 6087bis section 3.4 says " If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. " whereas you currently have it as a Normative Reference (well, perhaps two related thoughts:-( Tom Petch - Original Message - From: "Alissa Cooper" <ali...@cooperw.in> Sent: Monday, April 09, 2018 8:50 PM > On Apr 8, 2018, at 9:20 AM, Mach Chen <mach.c...@huawei.com> wrote: > > Hi Tom, > >> -Original Message- >> From: t.petch [mailto:ie...@btconnect.com] >> Sent: Sunday, April 08, 2018 7:42 PM >> To: Mach Chen <mach.c...@huawei.com>; Alissa Cooper >> <ali...@cooperw.in>; The IESG <i...@ietf.org> >> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; i2rs-cha...@ietf.org; >> sha...@ndzh.com >> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data- >> model-10: (with COMMENT) >> >> Original Message - >> From: "Mach Chen" <mach.c...@huawei.com> >> To: "Alissa Cooper" <ali...@cooperw.in>; "The IESG" <i...@ietf.org> >> Cc: <i2rs@ietf.org>; <draft-ietf-i2rs-rib-data-mo...@ietf.org>; >> <i2rs-cha...@ietf.org>; <sha...@ndzh.com> >> Sent: Sunday, April 08, 2018 9:23 AM >> >>> Hi Alissa, >>> >>> Thanks for your comments! >>> >>> Please see my responses inline... >>> >>>> -Original Message- >>>> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper >>>> Sent: Tuesday, April 03, 2018 11:10 PM >>>> To: The IESG <i...@ietf.org> >>>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; >> i2rs-cha...@ietf.org; >>>> sha...@ndzh.com >>>> Subject: [i2rs] Alissa Cooper's No Objection on >> draft-ietf-i2rs-rib-data-model-10: >>>> (with COMMENT) >>>> >>>> Alissa Cooper has entered the following ballot position for >>>> draft-ietf-i2rs-rib-data-model-10: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to >> all email >>>> addresses included in the To and CC lines. (Feel free to cut this >> introductory >>>> paragraph, however.) >>>> >>>> >>>> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ >>>> >>>> >>>> >>> >>> -- >>>> COMMENT: >>> >>> -- >>>> >>>> Sec 1.2: >>>> >>>> "YANG tree diagrams provide a concise representation of a YANG >> module, >>>> and SHOULD be included to help readers understand YANG module >>>> structure." >>>> >>>> This document does not seem like an appropriate place to have >> normative >>>> guidance about this. And if this sentence is removed, I don't see >> the point of >>>> including Section 1.2 otherwise. This would also imply deleting the >> reference to >>>> I-D.ietf-netmod-yang-tree-diagrams. >>> >>> This results from a YANG doctor review. I saw it also occurs in other >> published documents. I personally think it's no harm to keep it, how do you >> think? >> >> Mach >> >> I think that this is very odd. >> >> YANG guidelines rfc6087bis says >> " YANG tree diagrams provide a concise representation of a YANG >> module, >> and SHOULD be included to help readers understand YANG module >> structure. Guidelines on tree diagrams can be found in Section 3 of >> [I-D.ietf-netmod-yang-tree-diagrams]. >> " >> which I think is the correct guidance in the correct place. >> >> A quick look at the recently published RFC8343, RFC8344, RFC8345, >> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then >> I would regard those other I-D as being in error. >> >> If I look back at a thread from Ebben for a yang doctor review of an
Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
Original Message - From: "Mach Chen"To: "Alissa Cooper" ; "The IESG" Cc: ; ; ; Sent: Sunday, April 08, 2018 9:23 AM > Hi Alissa, > > Thanks for your comments! > > Please see my responses inline... > > > -Original Message- > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper > > Sent: Tuesday, April 03, 2018 11:10 PM > > To: The IESG > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; i2rs-cha...@ietf.org; > > sha...@ndzh.com > > Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: > > (with COMMENT) > > > > Alissa Cooper has entered the following ballot position for > > draft-ietf-i2rs-rib-data-model-10: No Objection > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ > > > > > > > > -- > > COMMENT: > > -- > > > > Sec 1.2: > > > > "YANG tree diagrams provide a concise representation of a YANG module, > >and SHOULD be included to help readers understand YANG module > >structure." > > > > This document does not seem like an appropriate place to have normative > > guidance about this. And if this sentence is removed, I don't see the point of > > including Section 1.2 otherwise. This would also imply deleting the reference to > > I-D.ietf-netmod-yang-tree-diagrams. > > This results from a YANG doctor review. I saw it also occurs in other published documents. I personally think it's no harm to keep it, how do you think? Mach I think that this is very odd. YANG guidelines rfc6087bis says " YANG tree diagrams provide a concise representation of a YANG module, and SHOULD be included to help readers understand YANG module structure. Guidelines on tree diagrams can be found in Section 3 of [I-D.ietf-netmod-yang-tree-diagrams]. " which I think is the correct guidance in the correct place. A quick look at the recently published RFC8343, RFC8344, RFC8345, RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then I would regard those other I-D as being in error. If I look back at a thread from Ebben for a yang doctor review of an earlier version of this I-D, the text I see proposed is " >A simplified graphical representation of the data model is used in >this document. The meaning of the symbols in these diagrams is >defined in [I-D.ietf-netmod-yang-tree-diagrams]. " which I think is rather different. Tom Petch (not a YANG doctor) > > > > Sec 2.1: Again here I'm confused about the use of normative language. Why do > > you need to specify normative requirements for what this very document is > > specifying? Or are these supposed to be requirements on implementations? > > OK, how about this: > > "...a RIB data model needs to specify a way for an external entity to learn about the functional capabilities of a network device." And > > " The RIB data model needs a way to expose the nexthop chaining capability supported by a given network device." > > > > > Sec 2.5: s/causes/caused/ > > Done > > The above updates will be reelected in version-11. > > Thanks, > Mach > > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] [yang-doctors] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
Original Message - From: "Mahesh Jethanandani"Sent: Thursday, February 22, 2018 12:43 AM > > > On Feb 20, 2018, at 7:24 AM, Amit Dass wrote: > > > > Hi Ebben, > > > > I have updated the draft based on your comments. Could you please have a look at the same and provide your feedback? > > The indentations are all over the place for the new references that have been added. > > More importantly, and this discussion is still open in front of YANG doctors, adding a reference statement to an import statement, seems to imply a import by revision. As an example, the import of ietf-interfaces has a reference to RFC 7223. But we know that ietf-interfaces is going to updated soon by whatever RFC number gets assigned to rfc7223bis. Expect further guidance on this. Mahesh As you doubtless know, this I-D is expected to be approved on March 8th, so there is a certain urgency about this. The latest guidelines, draft-ietf-netmod-rfc6087bis-18, include For every import or include statement that appears in a module contained in the specification, which identifies a module in a separate document, a corresponding normative reference to that document MUST appear in the Normative References section. which seems clear and right to me. This also says to me that a specific version of the module is referenced via the Normative References whether or not the import has a revision clause. and it also says If an import statement is for a module from a stable source (e.g., an RFC for an IETF module), then a reference-stmt SHOULD be present within an import statement. So for me there is (almost) always a reference statement to an RFC (or I-D) even, or especially when, no particular revision is wanted. This is what has coloured my comments on YANG modules. Tom Petch > Also, I do not see normative references to RFC 6991, and RFC 7223 in the text of the document. If this is not clear, see rfc7223bis, where in Section 3.1, there is normative reference to RFC7224 for the iana-if-types module that is imported by the ietf-interfaces module. > > Cheers. > > > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ > > > > Best regards, > > Amit > > > > -Original Message- > > From: Ebben Aries [mailto:e...@juniper.net] > > Sent: Thursday, January 18, 2018 9:33 AM > > To: yang-doct...@ietf.org > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i...@ietf.org > > Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09 > > > > Reviewer: Ebben Aries > > Review result: On the Right Track > > > > 1 module in this draft: > > - ietf-i2rs-...@2017-12-05.yang > > > > No YANG validation errors or warnings (from pyang 1.7.3 and yanglint 0.14.59) > > > > 0 examples are provided in this draft (section 3.12 of > > draft-ietf-netmod-rfc6087bis-15) > > > > Module ietf-i2rs-...@2017-12-05.yang: > > - yang-version statement missing - should be 1.1 > > - prefix 'iir' is recommended for this module, would 'rib' suffice better? > > - import "ietf-inet-types" should reference RFC 6991 per (not as a comment) > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7 > > - import "ietf-interfaces" should reference RFC 7223 per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7 > > This should reference rfc7223bis. > > > - import "ietf-yang-types" should reference RFC 6991 per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7 > > - Since this module imports "ietf-interfaces", a normative references must be > > added per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9 > > - prefix "if" in the import "ietf-interfaces" can remove quotes to remain > > consistent with other imports > > - Remove WG Chairs from contact information per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C > > - Module description must contain most recent copyright notice per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C > > - Module description should contain note to RFC Ed. and placeholder reference > > to RFC when assigned > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C > > - Add placeholder reference and note to RFC Ed. for RFC when assigned > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C > > - Security Considerations should be updated to reflect new template at > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > - Section 1.2 should be replaced with reference to > > draft-ietf-netmod-yang-tree-diagrams-02 rather (as-is in other i2rs YANG > > drafts in progress) per > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-2.5. 1 > > - This module contains '12' features. While it is understood the purpose of > > these features in the module, take precaution as to complexity for clients > > if they need to understand