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

[Ketan Talaulikar <[e-mail]>]

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.

>
> 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.

>
> Section 5:  Please consider something similar to the proposed rewrite
> for Section 4.
>

KT> Done.

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

>
> 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.

Thanks,
Ketan

>
>