Thanks Greg for handling my comments!
On Tue, Feb 13, 2024 at 11:06 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:
Hi Dhruv,thank you for your prompt reply, and my apologies for the confusion my sloppy response caused. A couple of follow-up notes tagged GIM3>> below. I've attached the updated working version of the draft.Regards,GregOn Mon, Feb 12, 2024 at 9:16 PM Dhruv Dhody <dd@xxxxxxxxxxxxxx> wrote:Hi Greg,On Mon, Feb 12, 2024 at 5:20 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote: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,GregOn Tue, Feb 6, 2024 at 7:41 PM Dhruv Dhody <dhruv.ietf@xxxxxxxxx> 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 accordinglyGIM2>> 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"?Dhruv: Yes! Thanks!<snip>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.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] asfollows:OLD:The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value69 [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.ENDDhruv: Did you forget to update the text in NEW? Except for a missing space after [RFC2113] there seems to be no difference between OLD and NEW!GIM3>> Indeed. It is like this:Furthermore, this specification updates Section 4.3 of [RFC8029] asfollows:OLD:The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value69 [RFC7506] for IPv6 MUST be set in the IP header.NEW:The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value69 [RFC7506] for IPv6 MUST NOT be set in the IP header.ENDWDYT?Hope you did a check on other instances of "alert" in RFC 8029.Dhruv: I hope you did that as it would be good to get you as an expert to review it.--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!Dhruv: When we quote the OLD text from RFC 8029, it should be verbatim. By adding reference RFC 1122 [RFC1122] is making a change. Please remove that in OLD text, and you can add it in NEW text.GIM3>> Now I got it!Thanks!DhruvThanks!Dhruv
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
