Re: [Int-dir] INTDIR Telechat Review of draft-ietf-mpls-lspping-norao-07.txt

[Greg Mirsky <[e-mail]>]

Hi Donald,
my apologies for the belated response. Thank you for your comments,
questions, and suggestions. Please find my notes below tagged by GIM>>.
Attached, please find the working version of the draft that includes all
the updates mentioned below.

Regards,
Greg

On Fri, Feb 23, 2024 at 8:11 PM Donald Eastlake <[e-mail]> wrote:

> I am an assigned INT directorate reviewer for
> <draft-ietf-mpls-lspping-norao-07.txt>. These comments were written
> primarily for the benefit of the Internet Area Directors. Document
> editors and shepherd(s) should treat these comments just like they
> would treat comments from any other IETF contributors and resolve them
> along with any other Last Call comments that have been received. For
> more details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
>
> The document deprecates the use of the Router Alert Option in both
> IPv4 and IPv6 encapsulated LSP ping (aka MPLS echo request and echo
> response messages) and recommends use of the IPv6 loopback address
> with IPv6 encapsulation rather than an IPv6 mapped IPv4 loopback
> address.
>
> Based on my review, if I was on the IESG I would ballot this document
> as NO OBJECTION.
>
> I have the following DISCUSS/ABSTAIN level issues: None.
>
GIM>> Thank you for your kind consideration of our work.

>
> The following are other issues that SHOULD be corrected before publication:
>
> Section 3's header and one paragraph body don't quite seem
> right/consistent. Is it normal for a Proposed Standard document to
> declare an RFC as Historic? Obsolete, sure, but Historic? Furthermore,
> it just seems odd for this declaration to exist only in the Section 3
> header line and not to appear anywhere in the text body of the
> document. Four times in the body text it says that the document
> explains why 7506 has been reclassified as Historic but only once and
> only in the Section 3 subject line does it claim to actually do that.
>
GIM>> Renamed Section 3 as:

3.  Reclassification of RFC 7506 as Historic

   RFC 7506 [RFC7506] defines the IPv6 Router Alert Option for MPLS
   Operations, Administration, and Management.  This document explains
   why RFC 7506 [RFC7506] has been reclassified as Historic.

If this document is approved and actually causes RFC 7506 to be
> Historic, isn't it more important to mention in the abstract and the
> introduction than that it actually performs that reclassification
> rather than just saying in those places that it provides reasons for
> the reclassification... Very odd.
>
GIM>> Updated Abstract and Introduction to a more assertive statement in
regard to RFC 7506:
In Abstract
   Furthermore, this document explains why RFC 7506 has been
   reclassified as Historic.
In Introduction:
   Therefore, this document updates RFC 8029 [RFC8029] to retire the RAO
   from both LSP ping message encapsulations and explains why RFC 7506
   [RFC7506] has been reclassified as Historic.

Do you think that these updates make the message consistent with the action
in regard to RFC 7506?

>
> I don't like that this draft says it "changes" RFC 8029. RFCs are
> immutable and do not change. Those instances should be changed to say
> that it "updates" RFC 8029. "updates", of course, being the term of
> art in the IETF not implying any actual textural change to the
> "updated" RFC.
>
GIM>> Thank you for your thoughtful suggestion. Changed as following:
   Therefore, this document updates RFC 8029 [RFC8029] in that
   Requirement 3 is removed.
and
   This document updates RFC 8029 [RFC8029] in that
   mode 3 is removed.


> The following are minor issues (typos, misspelling, minor text
> improvements) with the document:
>
> I found the typography in Section 4 just a little hard to parse. In
> particular, towards the end of that section, there are two instances
> where there are two successive paragraphs, the first of which says a
> section is replaced by "the following text:" and the second paragraph
> is the new text. It would be much more obvious at a glance what was
> going on if the second paragraph of new text were indented.
>
GIM>> Thank you for your feedback. I agree that indented text is helpful to
a reader:
   Additionally, this specification updates Section 2.2 of [RFC8029] to
   replace the whole of the section with the following text:

      LSP Ping implementations SHOULD ignore RAO options when they
      arrive on incoming MPLS echo request and MPLS echo reply messages.

   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]).


>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>