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

[Dhruv Dhody <[e-mail]>]

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

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.


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