[Idr] Re: Genart last call review of draft-ietf-idr-bgp-sr-segtypes-ext-05

[Ketan Talaulikar <[e-mail]>]

Hi Russ,

Please check inline below with KT2 for responses.

On Sun, Nov 3, 2024 at 11:46 AM Russ Housley <[e-mail]> wrote:
>
>
>
> > On Nov 3, 2024, at 6:13 AM, Ketan Talaulikar <[e-mail]> wrote:
> >
> > Following up on this thread to share the proposed updates for a
> > further/related comment raised on the related document
> > draft-ietf-idr-sr-policy-safi :
> >
> > https://mailarchive.ietf.org/arch/msg/idr/i1ema3XObVS79DaWhmYEu9sr9WI/
> >
> > Thanks,
> > Ketan
> >
> > On Wed, Oct 30, 2024 at 12:58 PM Ketan Talaulikar <[e-mail]> wrote:
> >>
> >> Hi Russ,
> >>
> >> Thanks for your review of the document and your comments/suggestions.
> >>
> >> Since the submission window is currently closed, I've attached the
> >> updated draft along with the diff for the changes. Please let me know
> >> if you have any follow up questions.
> >>
> >> Also, check inline below for responses
> >>
> >> On Fri, Oct 25, 2024 at 8:32 PM Russ Housley via Datatracker
> >> <[e-mail]> wrote:
> >>>
> >>> Reviewer: Russ Housley
> >>> Review result: Almost Ready
> >>>
> >>> I am the assigned Gen-ART reviewer for this draft. The General Area
> >>> Review Team (Gen-ART) reviews all IETF documents being processed
> >>> by the IESG for the IETF Chair. Please treat these comments just
> >>> like any other last call comments.
> >>>
> >>> For more information, please see the FAQ at
> >>> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> >>>
> >>> Document: draft-ietf-idr-bgp-sr-segtypes-ext-05
> >>> Reviewer: Russ Housley
> >>> Review Date: 2024-10-25
> >>> IETF LC End Date: 2024-11-11
> >>> IESG Telechat date: Unknown
> >>>
> >>>
> >>> Summary: Almost Ready
> >>>
> >>>
> >>> Major Concerns:
> >>>
> >>> Section 2.10:  The text says:
> >>>
> >>>   The Segment Types sub-TLVs described above may contain the following
> >>>   flags in the "Segment Flags" field defined in ...
> >>>
> >>> In Table 8 of [I-D.ietf-idr-sr-policy-safi], these are called "SR Policy
> >>> Segment Flags".  In the nine previous sections, the field is just
> >>> labeled "Flags".  Please add some words to clarify.
> >>
> >> KT> Fixed in both this document and the draft-ietf-idr-sr-policy-safi.
> >> Note that I've kept the name "Flags" for the field in the picture due
> >> to space constraints.
>
> I suspected the figures would continue to use "Flags".  I was just expecting words that let th reader know that the two are the same thing.

KT2> The field description of "Flags" field for each of those segment
types point to section 2.10 where the correlation of the "Flags" field
with SR Policy Segment Flags is now introduced in the text.

>
> >>
> >>>
> >>> Section 4:  I suggest a rewrite:
> >>>
> >>>   The security considerations in [I-D.ietf-idr-sr-policy-safi] apply
> >>>   to the new segment types defined in this document.  No additional
> >>>   security considerations are introduced in this document.
> >>
> >> KT> Thanks. I've incorporated your suggestion.
>
> Thanks.
>
> >>
> >>>
> >>> Section 5:  Please consider something similar to the proposed rewrite
> >>> for Section 4.
> >>>
> >>
> >> KT> Done.
>
> Okay.
>
> >>
> >>>
> >>> Minor Concerns:
> >>>
> >>> Section 2.8 and Section 2.9: The SRv6 SID and the SRv6 Endpoint Behavior
> >>> and SID Structure are both optional.  I do not see how a receiver could
> >>> determine when the SRv6 SID is absent and the SRv6 Endpoint Behavior and
> >>> SID Structure is present.  I suspect that this is not allowed, but the
> >>> text does not make this clear.  Please clarify.
> >>>
> >>
> >> KT> Indeed. Have clarified the same. Also did the same in
> >> draft-ietf-idr-sr-policy-safi
>
> I assume that the SRv6 Endpoint Behavior and SID Structure is omitted unless the The SRv6 SID is present.

KT2> Yes

Thanks,
Ketan

>
> >>
> >>>
> >>> Nits:
> >>>
> >>> Abstract and Introduction: Please spell out "BGP SR Policy SAFI" on
> >>> the first occurrence.
> >>>
> >>> Section 2.3: s/present else/present, else/
> >>>
> >>> Section 2.4: s/present else/present, else/
> >>>
> >>> Section 2.5: s/present else/present, else/
> >>>
> >>> Section 2.6: s/present else/present, else/
> >>>
> >>
> >> KT> Fixed all of them.
>
> Okay.
>
> Russ
>