Telechat Review of draft-ietf-mpls-lspping-norao-07
review-ietf-mpls-lspping-norao-07-intdir-telechat-eastlake-2024-02-23-00

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.

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

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.

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.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com