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

Hi Tom, 

> On Dec 2, 2023, at 07:35, tom petch <ietfa@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.meuric@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 rtgwg@ietf.org and not on lsr@ietf.org?
> >
> > Tom Petch
> > ________________________________________
> > From: rtgwg <rtgwg-bounces@ietf.org> on behalf of julien.meuric@orange.com <julien.meuric@orange.com>
> > Sent: 29 November 2023 16:03
> > To: rtg-ads@ietf.org
> > Cc: rtg-dir@ietf.org; draft-ietf-ospf-sr-yang.all@ietf.org; rtgwg@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