ICN Traceroute Protocol Specification
draft-irtf-icnrg-icntraceroute-11

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-irtf-icnrg-icntraceroute and RFC 9507, changed IRTF state to Published RFC)

(Via drafts-eval@iana.org): IESG/Authors/ISE:

As with draft-irtf-icnrg-icnping, we're unable to determine what this document is asking IANA to do.

The IANA Considerations section states that "The exact numeric values of the field types of Traceroute requests and Traceroute replies are to be assigned in the Packet Type IANA Registry for CCNx (see section 4.1 of [RFC8569]."

It isn't clear whether RFC 8569 is being cited as the document that created the CCNx Packet Types registry or whether IANA is being instructed to source the registrations from that document. But RFC 8569 doesn't have a Section 4.1, and it isn't listed as a reference anywhere in in the CCNx registry group at https://www.iana.org/assignments/ccnx.

For any registrations that need to be made, please use the IANA Considerations section to provide the text that IANA needs to populate the "Name" field (and the "Reference" field, if the registrations should refer to a document other than this one) in the CCNx Packet Types registry at https://www.iana.org/assignments/ccnx.

If there are only two registrations, you could either provide a table that replicates the fields in the registry or change the existing paragraph to something like 'IANA will assign TBD1 to "foo" and TBD2 to "bar" in the CCNx Packet Types registry established by RFC8609.' (The RFC Editor can change "will assign" to "has assigned" and replace TBD1 and TBD2 with the assigned numbers.)

Amanda Baber
IANA Operations Manager

[Ballot comment]
Nit: section 4.1 of icnrg-ping had considerations for the (base64) encoding of the nonce. Perhaps good to be consistent on whether such considerations are needed.

[Ballot comment]
This document specifies an analogue to the traceroute functionality commonly used on IP networks for ICN and CCNx; it is ready for publication as an IRTF RFC.

My only question is high-level, and of the form "why didn't you write a completely different document?" and as such can be safely ignored: the design (intentionally) sticks as closely as possible to an analog to (Paris/Tokyo) Traceroute, which has the advantage of least surprise for people familiar with IP networks. Have there been attempts to implement an analogue to IP Record Route for ICN?

Request for posting confirmation emailed to previous authors: David Oran , Ilya Moiseenko , Jim Gibson , Ralph Droms , Spyridon Mastorakis , icnrg-chairs@ietf.org, irtf-chair@irtf.org

# Document Shepherd

Dirk Kutscher

# Technical Summary
This document specifies consumer and forwarder behavior as well as message formats for a traceroute protocol for CCNx and NDN systems.
It also describes the specific differences of ICN-traceoute to IP-ICMP-based traceroute as well as security considerations.

ICN-traceroute is part of an instrumentation toolset for ICN. There is another specification (https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnping/) that falls into the same space.

# Document Quality
The document has been worked on since 2016 and has seen good feedback from different ICN teams, especially with respect to compatibility to protocol formats. The ICNRG last call has led to some corrections in this direction, and the document is now considered ready for publication.