ICN Ping Protocol Specification
draft-irtf-icnrg-icnping-12

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

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

IANA has completed its review of draft-irtf-icnrg-icnping-09.

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 Echo requests and Echo 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.

If the paragraph should be referring to this document's Section 4.1 and 4.2, it isn't clear how IANA should fill in the "Name" field in the registry.

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

Thank you,

Amanda Baber
IANA Operations Manager

[Ballot comment]
Nit: section 4.1 says "The nonce can be encoded as a base64 string."

Given there are many ways to do base64 encoding, this is a bit vague. But I suppose the encoding details are not important here but any encoding is really OK. Perhaps shortly clarifying why encoding is needed (to comply with name encoding rules?) would be useful or if there's value for consistent encoding, making that explicit with e.g., "base64-encoded string with the URL-safe alphabet as defined in Section 5 of [RFC4648], with padding omitted".

[Ballot comment]
This document presents a clear design and implementation of IP-analog "ping" functionality for NDN and CCnx. It is ready for publication on the IRTF stream.

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 ping protocol for CCNx and NDN systems.
It also describes the specific differences of ICN-ping to IP-ICMP-based ping as well as security considerations.

ICN-ping is part of an instrumentation toolset for ICN. There is another specification (https://datatracker.ietf.org/doc/draft-irtf-icnrg-icntraceroute/) 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.