Hi Tom, > On Dec 2, 2023, at 07:35, tom petch <ie...@btconnect.com> wrote: > > My previous message said I was happy with router-id in this i-d. > > No I am not. I was looking at draft-ietf-<the other IGP>-sr-yang. > > I think that this I-D is in error to create its own version of router-id when > rfc8294 has defined one for the IETF to use (and RFC8294 which defines it is > already an import).
I agree. The ietf-sr-ospf.yang model has been around for a long time and has gone through a number of iterations (e.g., incorporating OSPFv3 extensions) - this was missed when RFC 8294 was published. > > I see other minor glitches which I hope to flag next week. Looking forward to seeing the review. Thanks, Acee > > Tom Petch > > > From: julien.meu...@orange.com > Sent: Thursday, November 30, 2023 08:35 > To: tom petch > Cc: lsr@ietf.org > Subject: Re: RtgDir Last Call Review: draft-ietf-ospf-sr-yang > > Hi Tom, > > That looks to me like a human mistake on the CC'ed recipients. Using the > directorate web form may have prevented it, but that would have been > much less fun. > > Thanks for your careful checking. I'd be happy to hear your opinion on > the router-id type. > > Julien > > > On 29/11/2023 17:33, tom petch wrote: > > Why is this review on rt...@ietf.org and not on lsr@ietf.org? > > > > Tom Petch > > ________________________________________ > > From: rtgwg <rtgwg-boun...@ietf.org> on behalf of julien.meu...@orange.com > > <julien.meu...@orange.com> > > Sent: 29 November 2023 16:03 > > To: rtg-...@ietf.org > > Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang....@ietf.org; rt...@ietf.org > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > > drafts as they pass through IETF last call and IESG review, and > > sometimes on special request. The purpose of the review is to provide > > assistance to the Routing ADs. For more information about the Routing > > Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir > > <https://wiki.ietf.org/en/group/rtg/RtgDir> > > > > Although these comments are primarily for the use of the Routing ADs, it > > would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them through > > discussion or by updating the draft. > > > > Document: draft-ietf-ospf-sr-yang-22 > > Reviewer: Julien Meuric > > Review Date: 2023-11-29 > > Intended Status: Standard Tracks > > > > > > *Summary:* > > > > This document is basically ready for publication but has nits that > > should be considered prior to publication. > > > > > > *Comments:* > > > > - The very first paragraph of the introduction/overview section > > summarizes the basis of YANG, XML, JSON, data models... I believe we are > > now far beyond those general considerations and we could skip that > > paragraph. > > - In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf > > "neighbor-router-id" uses type "dotted-quad". This is consistent with > > RFC 8666 which specifies the associated OSPFv3 TLV, but we had a > > discussion about the type for router-id in the TE YANG models. The > > current resolution on TEAS side will be to consider a union of > > dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to > > consider a superset of the existing OSPFv3 TLVs. > > > > > > *Nits:* > > > > - Multiple times in description: s/SR specific/SR-specific/ > > - Multiple times in description: s/flag bits list/flag list/ > > - Multiple times in description: s/flags list/flag list/ > > - The description fields use a mix of "Adj sid", "adj sid", "Adj SID"... > > sometimes with hyphens (not to mention the full expansions). A single > > phrase should be chosen and used all along the module. > > - A few description starts with "The..." (e.g., in > > "ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most > > of them don't. For consistency, it should be dropped from every brief > > description. > > > > - In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting > > pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/ > > - In the same grouping, the description of the container should be > > "Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the > > following list element). > > - In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not > > wrong, but should be consistent with others.] > > - In the same container (p 26): "s/Topology Independent Loop Free > > Alternate/Topology-Independent Loop-Free Alternate/ > > - In section 3 (p 37): s/The YANG modules [...] define/The YANG module > > [...] defines/ > > - In the same section: s/in the modules/in the module/ > > - In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/ > > > > > > Thanks, > > > > Julien > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
