Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-mpls-lspping-norao-06

[Greg Mirsky <[e-mail]>]

Hi Dhruv,
thank you for your thoughtful suggestions. I've added more notes below
tagged GIM2>>. Attached, please find the updated working version of the
draft.

Regards,
Greg


On Tue, Feb 6, 2024 at 7:41 PM Dhruv Dhody <[e-mail]> wrote:

> HI Greg,
>
> Thanks for taking my comments into consideration.
>
>>
>>> ## Major
>>>
>>> - It would be incorrect to put RFC 7056 (which is being made historic)
>>> in the
>>> "updates:" list at the top of the page. Note that, one needs to follow
>>> the
>>> "status-change" document process to mark the RFC as historic which
>>> should be
>>> triggered by the AD. The job of this I-D is to articulate the reasons
>>> why the
>>> RFC7506 should be made historic. Update section 1 and section 3
>>> accordingly.
>>> Section 3 could list or refer to existing sections on why RFC 7506
>>> should be
>>> historic.
>>>
>> GIM>> Thank you for pointing this out. Updated the header accordingly.
>>
>
> Dhruv: I think this text in (1) abstract - "It reclassifies RFC 7506 as
> Historic..." and this text in (2) introduction "...and reclassifies RFC
> 7506 [RFC7506] as Historic." and section 3 (3) "This document reclassifies
> RFC 7506 [RFC7506] as Historic." are incorrect.
>
> It should stay instead that "this document explains why RFC 7560 has been
> reclassified as Historic" in all places. I would also suggest to update
> section 3 accordingly
>
GIM2>> Thank you for explaining the process to me. As I understand it,
reclassifying RFC 7506 will take separate efforts and time. Hence my
question, "Would it be more acceptable to state, "This document explains
why RFC 7506 should be reclassified as Historic"?

>
> This IESG statement has some useful information -
> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic
>
> There now exists a new type of document, "status-change" documents, to
>> fill this gap. These documents are kept in the datatracker, are not
>> Internet drafts, and are not published as RFCs, but they are archival
>> documents that are linked to the RFCs whose status is changed
>
>
> An example -
>
> RFC that is marked as Historic - https://datatracker.ietf.org/doc/rfc3540/
> via this status change -
> https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/
> which links to the explanation in draft-ietf-tsvwg-ecn-experimentation
> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/>
>  / https://datatracker.ietf.org/doc/rfc8311/
>
> Hope this helps!
>
>
>
>
>>
>>> - RFC 8029 includes text outside of sections 2.1 and 2.2 that mentions
>>> router
>>> alert. For instance,
>>> https://datatracker.ietf.org/doc/html/rfc8029#section-4.5
>>> tells how to handle it with "MUST" when we now are asking implementation
>>> to
>>> ignore it - ````
>>>    If the Reply Mode in the echo request is "Reply via an
>>>    IPv4 UDP packet with Router Alert", then the IP header MUST contain
>>>    the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69
>>>    [RFC7506] for IPv6.  If the reply is sent over an LSP, the topmost
>>>    label MUST in this case be the Router Alert label (1) (see
>>>    [RFC3032]).
>>>
>>  GIM>> Thank you for catching another reference to the Reply mode 3.
>> Appended the following text to Section 4:
>> NEW TEXT
>>    Resulting from the removal of the Reply mode 3 "Reply via an IPv4/
>>    IPv6 UDP packet with Router Alert" (see Section 2.2), this
>>    specification updates Section 4.5 of [RFC8029] by removing the
>>    following text:
>>
>>    If the Reply Mode in the echo request is "Reply via an IPv4 UDP
>>    packet with Router Alert", then the IP header MUST contain the Router
>>    Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] for
>>    IPv6.  If the reply is sent over an LSP, the topmost label MUST in
>>    this case be the Router Alert label (1) (see [RFC3032]).
>>
>>
> Dhruv: Looks good!
>
>
>
>> ````
>>> - If you do update the text, note that there is an erratum
>>> https://www.rfc-editor.org/errata/eid7639. Please do a check of all
>>> other
>>> instances of "alert" as well in RFC 8029.
>>>
>> GIM>> That was my errata. What would be the right way to handle it?
>>
>
> Dhruv: Since you are removing the text with this update, I guess nothing!
>
> I have my doubts about one more instance -
>
> https://datatracker.ietf.org/doc/html/rfc8029#section-4.3
>
> The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value 69
>> [RFC7506] for IPv6 MUST be set in the IP header.
>
> GIM2>> Thank you pointing this text to me. Would the following text
address your concern:
NEW TEXT:
   Furthermore, this specidication updates Section 4.3 of [RFC8029] as
   follows:

   OLD:

   The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value
   69 [RFC7506] for IPv6 MUST be set in the IP header.

   NEW:

   The Router Alert IP Option of value 0x0 [RFC2113]for IPv4 or value 69
   [RFC7506] for IPv6 MUST be set in the IP header.

   END

>
> Hope you did a check on other instances of "alert" in RFC 8029.
>
>
> --
>
> In one edit in Section 4, where you list the OLD text from RFC 8029, do
> not add a reference to RFC 1122 in OLD text as this should be as listed in
> RFC 8029. It is good that you added reference in the NEW text!
>
> Thanks!
> Dhruv
>