Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang

[Acee Lindem <[e-mail]>]

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 [e-mail]? ;^) 

> On Nov 29, 2023, at 11:33, tom petch <[e-mail]> wrote:
> 
> Why is this review on [e-mail] and not on [e-mail]?
> 
> Tom Petch
> ________________________________________
> From: rtgwg <[e-mail]> on behalf of [e-mail] <[e-mail]>
> Sent: 29 November 2023 16:03
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
>