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

[Russ Housley <[e-mail]>]

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

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