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 <ketant.ietf@xxxxxxxxx> 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 > <noreply@xxxxxxxx> 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 > > > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
