Hello Benoit, I have incorporated your comments into -14 that I will post shortly. Please see replies inline for individual items.
Thanks --- Alex -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Benoit Claise Sent: Tuesday, December 12, 2017 7:31 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; Ladislav Lhotka <[email protected]>; [email protected]; [email protected] Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-11: (with DISCUSS and COMMENT) Dear draft-ietf-i2rs-yang-l3-topology, Checking v13 now, as the document is on the telechat in 2 days, it seems that none of my feedback below was into account or even discussed. The feedback below was on v11, sent on Sept 27th. Regards, Benoit > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-11: Discuss > > 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-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Preliminary note: I hope I'm doing the right thing by updating this > DISCUSS point as I understand that the document is back to the WG. > However, since I reviewed the version 11, since some of my ballot > points have been addressed (thank you), and since I wanted to share my > feedback publicly, here is my feedback. > > 1. The examples. > In the AUTH48 for the RESTCONF RFC, the example YANG module discussion > came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology > were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago. > > Look at this: > > module example-ietf-ospf-topology { > ... > namespace > "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; > ... > description > "This module defines a model for OSPF network topologies. > Copyright (c) 2017 IETF Trust and the persons identified as > authors of the code. > > They are using the IANA-controlled namespace w/o registering it. > > This module *really* looks like a proper normative module, rather than > an example. They went to far in trying to mimic a real module. > > It is clear that we need more guidelines in 6087 for how to write > example modules. > > I was going to ask if this module passed YANG doctor review - then I > checked and saw that version -02 was reviewed, which didn't include > this example. How should we (the YANG doctors) handle such a case? > > In this case they should: > > 1. change the name to example-ospf-topology > 2. change the namespace to urn:example:ospf-topology > 3. remove the top-level statements: > organization, contact, revision > > 4. change the top-level description to what the text in the draft > says: > > description > "This module is intended as an example for how the > Layer 3 Unicast topology model can be extended to cover > OSFP topologies."; > > (same for the other example module) <ALEX> done. We only have one example module now. </ALEX> > > As I mentioned to the authors, respective chairs and AD already, we > should follow the decision in this NETMOD email thread > https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html > This will hopefully resolve fast. Once settled, the examples should be updated. > > 4. > > leaf-list router-id { > type inet:ip-address; > description > "Router-id for the node"; > } > > My initial DISCUSS was: We don't want to wait for > https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we > should expedite this publication), but any good reason why this is > aligned with its definition? > typedef router-id { > type yang:dotted-quad; > description > "A 32-bit number in the dotted quad format assigned to each > router. This number uniquely identifies the router within an > Autonomous System."; > } > > My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, > it makes sense to import its router-id <ALEX> This is only used in the example. The point of the example is to show how the model can be extended, not to define something normative, hence I don't think there is a need to introduce a dependency here which would only be distracting. </ALEX> > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - YANG definition "YANG: A data definition language for NETCONF" > I would use: > YANG is a data modeling language used to model configuration data, > state data, Remote Procedure Calls, and notifications for network > management protocols [RFC7950] > <ALEX> done </ALEX> > - There are multiple slightly different definitions of the datastore > in the different RFCs. > Let's not add to the confusion. > Pick one (RFC6241 should be the latest one) and mention the reference. > <ALEX> done (already in -13) </ALEX> > - section 7 > OLD: > The moodel defines > NEW: > The model defines > <ALEX> done </ALEX> > > . > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
