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.
- 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.
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
