----- Original Message ----- From: "Xufeng Liu" <Xufeng_Liu@xxxxxxxxx> Sent: Tuesday, January 23, 2018 10:18 PM > Hi Tom, > > Thanks for the thought. Section 3 includes the complete tree diagram for the model. We have received different suggestions and opinions on this topic. I have read your comments on the NETMOD mailing list. Your opinion is appreciated. However, we have also received comments to request the complete, un-altered tree diagram for easy referencing. Some implementers mentioned that the tree diagram is the first section they look at, and the one that needs to be referenced often. > > I'd hope a consensus on this. For now, we'd keep it as is. OK. I can live with it. Tom Petch > Thanks, > > - Xufeng > > > -----Original Message----- > > From: tom p. [mailto:daedulus@xxxxxxxxxxxxx] > > Sent: Saturday, January 13, 2018 8:03 AM > > To: Xufeng Liu <Xufeng_Liu@xxxxxxxxx>; ietf <ietf@xxxxxxxx> > > Cc: draft-ietf-rtgwg-yang-rip@xxxxxxxx; rtgwg-chairs@xxxxxxxx; > > yingzhen.qu@xxxxxxxxxx; Alia Atlas <akatlas@xxxxxxxxx> > > Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model > > for Routing Information Protocol (RIP)) to Proposed Standard > > > > Xufeng > > > > Looks good > > > > The only outstanding thought is about the tree diagram where the netmod I-D > > says "As tree diagrams are intended to provide a simplified > > view of a module, diagrams longer than a page should generally be > > avoided. " > > but, as was discussed on the netmod WG list, this can be hard to achieve. You > > currently have four pages and the only way I can see to split this would be to > > separate the ipv4 and ipv6 sections with a brief paragraph, just a sentence, > > separating the three parts of the tree diagram, albeit with one long part and two > > short parts. I would consider this worth the effort but leave it up to you. > > > > If you look at the OSPF and BFD YANG tree diagrams you can see how sub- > > dividing can work. > > > > (My own take is that too a long tree diagram reflects a too flat module structure > > and that the module structure should be changed, but this view has yet to gain > > traction!) > > > > I take your point about the description clauses. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Xufeng Liu" <Xufeng_Liu@xxxxxxxxx> > > Sent: Friday, January 12, 2018 8:18 PM > > > > > > > Hi Tom, > > > > > > Thanks for your valuable comments. We have updated the document with > > https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rip-08, to address these > > comments. > > > > > > Regards, > > > - Xufeng > > > > > > > -----Original Message----- > > > > From: tom p. [mailto:daedulus@xxxxxxxxxxxxx] > > > > Sent: Wednesday, December 20, 2017 12:13 PM > > > > > > > > I think that this I-D falls somewhat short of the standard > > necessary for > > > > advancement. > > > > > > > > 'reference' statements are almost wholy lacking from the YANG > > module and > > > > while it might be reasonable to expect the reader to know where to > > find > > > > information on RIP or RIPng, I do not think that that extends to > > other IGP or > > > > IPsec. If you want to see how it SHOULD be done, look at > > > > draft-ietf-netmod-rfc7277bis-01 One or more 'reference' > > > > statement per 'container' or'leaf' > > statement is a good > > > > starting point. > > > [Xufeng] The situation is different from RFC7277, where attributes > > from different referenced documents are put together in a same container. In > > the RIP model, almost all attributes refer to the same three documents RFC2453, > > RFC2080, and RFC1724. If we add them to each container or leaf, we'd have to > > repeat these three everywhere. Therefore we put the references at the > > beginning to avoid the repetition. In case when some specific reference is > > needed, such as authentication, we add the reference to RFC8177 in that > > container. Is this ok? > > > > > > > > > > > Talking of which, > > > > [I-D.bjorklund-netmod-rfc7223bis] > > > > [I-D.bjorklund-netmod-rfc7277bis] > > > > [I-D.acee-netmod-rfc8022bis] > > > > have all been replaced. I am unclear whether or not this > > invalidates the > > > > announcement, since these appeared in the announcement as downrefs. > > > [Xufeng] Updated in the new version. > > > > > > > > Common (best) practice is to then include all the references from > > the YANG > > > > module in a separate section immediately prior to the module itself > > so that the > > > > reader can readily find them. > > > > Again > > > > draft-ietf-netmod-rfc7277bis-01 Section 4 is an example of > > > > how to do this. > > > [Xufeng] We use Sec 1.3 for this purpose. > > > > > > > > The YANG module does reference > > > > RFC 1724 > > > > but I think that that makes it Normative not Informative, as it > > currently is. > > > [Xufeng] Changed it to normative as you suggested. > > > > > > > > The Abstract is limp. > > > > "This document describes a data model for the Routing Information > > > > Protocol (RIP). " > > > > So what?. This should tell me what I can do, e.g. configure, > > manage, get > > > > statistics or what? > > > > draft-ietf-netmod-rfc7277bis-01 > > > > gives a better example. At this point in time, with NMDA causing > > significant > > > > changes, the Abstract would do well to mention where the I-D stands > > with > > > > regard to this. > > > [Xufeng] Updated with more information as you suggested. > > > > > > > > There is now an emerging RFC on tree diagrams > > > > draft-ietf-netmod-yang-tree-diagrams-03 > > > > The authors might consider using and referencing this. > > > [Xufeng] New version references the latest draft now. > > > > > > > > Tom Petch > > > > > > > > > ----- Original Message ----- > > > > > From: "The IESG" <iesg-secretary@xxxxxxxx> > > > > > Sent: Tuesday, November 28, 2017 4:29 PM > > > > > > > > > > > > The IESG has received a request from the Routing Area Working > > Group > > > > WG > > > > > > (rtgwg) to consider the following document: - 'A YANG Data Model > > for > > > > > Routing > > > > > > Information Protocol (RIP)' > > > > > > <draft-ietf-rtgwg-yang-rip-06.txt> as Proposed Standard > > > > > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > > > solicits > > > > > final > > > > > > comments on this action. Please send substantive comments to the > > > > > > ietf@xxxxxxxx mailing lists by 2017-12-12. Exceptionally, > > comments > > > > may > > > > > be > > > > > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > > > > beginning of > > > > > > the Subject line to allow automated sorting. > > > > > > > > > > > > Abstract > > > > > > > > > > > > > > > > > > This document describes a data model for the Routing > > Information > > > > > > Protocol (RIP). Both RIP version 2 and RIPng are covered. > > > > > > > > > > > > > > > > > > >