It is an LSR WG document (LSR list copied and RTGWG list removed). Thanks, Acee P.S. Why are you using a different Email that isn’t subscribed to [email protected]? ;^)
> On Nov 29, 2023, at 11:33, tom petch <[email protected]> wrote: > > Why is this review on [email protected] and not on [email protected]? > > Tom Petch > ________________________________________ > From: rtgwg <[email protected]> on behalf of [email protected] > <[email protected]> > Sent: 29 November 2023 16:03 > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RtgDir Last Call Review: draft-ietf-ospf-sr-yang > > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
