Hi Tom, I believe I’ve addressed your awkward English comments in the -18 version. See a couple more inline responses below. > On May 3, 2023, at 6:46 AM, t petch <ietfa@xxxxxxxxxxxxx> wrote: > > On 01/05/2023 19:13, Yingzhen Qu wrote: >> Hi Tom, >> >> Thanks for your review and comments. Please see my answers below inline. >> >> Thanks, >> Yingzhen >> >> On Thu, Apr 27, 2023 at 2:33 AM tom petch <daedulus@xxxxxxxxxxxxx> wrote: >> >>> I thought that I had commented on this Last Call but perhaps not. >>> >>> The English is quirky, e.g. mixed singular and plural, missing definite >>> and indefinite articles and such like but I do not think that that >>> impairs my understanding. >>> >>> [Yingzhen]: Would you please provide some details? I expect the RFC editor >> will fix English grammar issues if there are any. > > In several places, 'RIB' should be 'a RIB' or 'the RIB' and as I commented two years ago, the meaning is slightly different so while the RFC Editor will make a change, it could make a change to the meaning. > > Likewise from two years ago, I want the Abstract to lead into the Introduction which leads into the body of the I-D and I do not see that. The I-D is bitty, with four sets of augments with little in common, apart from beng related to routing, and I think it easy for a reader to be confused since this is not spelt out and the descriptions do not make this clear to me. > > I think that you should make the descriptions more precise and consistent. The comment about the next hop list is a small example of this - you have changed the wording but I do not think it an improvement. > > I think you should be explicit about what the augments add; what I see is: > - for static RIB only, for IPv4 and IPv6, preference and tag are added to the simple next hop and each entry in the next hop list. Static is a routing protocol and the static routes are configurable. Semantically, it is not the same as the RIBs defined per address family. > > - for every RIB, without constraint, statistics are added, for active routes and memory used > > - for every route in every RIB, without constraint, metric and tag are added > > - for every next hop, simple or list, in every route in every RIB, without constraint, a repair path is added. This should be clear in tree diagrams in the draft. As far as the descriptions, it isn’t reasonable to require the description to completely describe the base module data nodes. Thanks, Acee > > I have to reverse engineer the YANG to get this and think that that is asking too much of some readers. > > It is unusual to have so many augments with no constraints, so I think that that needs mentioning, hence my use of 'every'. > > Tom Petch >> >> >>> Contacts needs https: >>> >> [Yingzhen]: fixed. >> >> >>> The examples use the line folding convention which needs a reference >>> else our XML reviewers will complain >>> >> [Yingzhen]: Added a reference to RFC 8792. >> >> What makes life more difficult is the terminology which I find >>> inconsistent e.g. tag, route tag, administrative tag - are these the >>> same or different? and if different, which is the YANG leaf tag? RIP >>> has a tag which I think different but perhaps confusing to those who are >>> familiar with it. >>> >> [Yingzhen]: There is no RFC for a RIB definition, and we picked commonly >> used terms in the industry. when you say "RIP has a tag", do you mean the >> RIP example in Appendix C in RFC 8349? If so, leaf "tag" applies to a route. >> >> >>> The Introduction sounds very generic in its talk of routing protocols >>> but I think that it promises more than it delivers; the YANG description >>> seem to do the same in places. The reality is that in some places only >>> static routes are augmented; what about dynamic routes? And where they >>> are augmented then I think that that needs calling out. In a similar >>> vein, I think the first paragraph of s.3 wrong. >>> >>> [Yingzhen]: Dynamic routes are augmented by routing protocol models, for >> example, OSPF model (RFC 9129) has the following: >> >> augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: >> >> +--ro metric? uint32 >> >> +--ro tag? uint32 >> +--ro route-type? route-type >> >> >>> 'The following tree snapshot' looks like an extract to me, not a snapshot. >>> >> [Yingzhen]: It's part of the entire tree. What do you suggest as the right >> term? >> >> >>> I have commented in the past about active route and I still find it >>> tautological. >>> >>> Authors address gmail.com.com? >>> >> [Yingzhen]: fixed. >> >> Tom Petch >>> >>> On 17/04/2023 22:40, The IESG wrote: >>>> >>>> The IESG has received a request from the Routing Area Working Group WG >>>> (rtgwg) to consider the following document: - 'RIB Extension YANG Data >>> Model' >>>> <draft-ietf-rtgwg-yang-rib-extend-14.txt> as Proposed Standard >>>> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
