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

[[e-mail]]

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 [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]
>
> 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
>