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/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 TEXTResulting from the removal of the Reply mode 3 "Reply via an IPv4/IPv6 UDP packet with Router Alert" (see Section 2.2), thisspecification updates Section 4.5 of [RFC8029] by removing thefollowing text:If the Reply Mode in the echo request is "Reply via an IPv4 UDPpacket with Router Alert", then the IP header MUST contain the RouterAlert IP Option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] forIPv6. If the reply is sent over an LSP, the topmost label MUST inthis 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 -
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
