Re: [auth48] AUTH48: RFC-to-be 9508 <draft-irtf-icnrg-icnping-12> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Document title:  For ease of the reader (and per
RFC 8793), we expanded "ICN" as "Information-Centric Networking".
Please let us know any concerns.

Original:
 ICN Ping Protocol Specification

Currently:
 Information-Centric Networking (ICN) Ping Protocol Specification -->


2) <!-- [rfced] Please ensure that the guidelines listed in Section 2.1
of RFC 5743 have been adhered to in this document.  See
<https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1>. -->


3) <!-- [rfced] Section 1:  This sentence is difficult to follow.  If
the suggested text is not correct, please provide clarifying text.

Original:
 In IP,
 where routing and forwarding are based on IP addresses, ICMP echo and
 ICMP echo response are the protocol mechanisms used for this purpose,
 generally exercised through the familiar ping utility.

Suggested:
 In IP,
 where routing and forwarding are based on IP addresses, ICMP echo
 request and reply packets are the protocol mechanisms used for this
 purpose, generally exercised through the familiar ping utility. -->


4) <!-- [rfced] Section 1:  For ease of the reader, we expanded "CCNx"
as "Content-Centric Networking" and "NDN" as "Named Data Networking"
per RFC 8793.  If these expansions are incorrect, please provide the
correct definitions.

Original:
 This document proposes protocol mechanisms for a ping equivalent in
 ICN (CCNx [RFC8609] and NDN [NDNTLV]) networks.

Currently:
 This document proposes protocol mechanisms for a ping equivalent in
 ICN networks (Content-Centric Networking (CCNx) [RFC8609] and Named
 Data Networking (NDN) [NDNTLV]). -->


5) <!-- [rfced] Section 1:

a) As it appears that the new protocol and not the traceroute
protocol of TCP/IP will aid the experimental deployment of ICN
protocols, we updated this sentence accordingly.  If this is
incorrect, please provide clarifying text.

Original:
 This document describes the design of a
 management and debugging protocol analogous to the ping protocol of
 TCP/IP, which will aid the experimental deployment of ICN protocols.

Currently:
 This document describes the design of a
 management and debugging protocol analogous to the ping protocol of
 TCP/IP; this new management and debugging protocol will aid the
 experimental deployment of ICN protocols.

b) This sentence did not parse.  We updated it as follows.  If this
is incorrect, please clarify how "variance" relates to the other
items in the list.

Original:
 Note that a measurement
 application is needed to make proper use of ICN Ping in order to
 compute various statistics, such as the variance, average, maximum
 and minimum RTT values as well as loss rates.

Currently (using "variance in round-trip times" in Section 3 as a
  guide):
 Note that a measurement application is needed to make proper
 use of ICN Ping in order to compute various statistics, such as
 variance in Round-Trip Times (RTTs); average, maximum, and
 minimum RTT values; and loss rates. -->


6) <!-- [rfced] Sections 1 and subsequent:  We see that "RTT" is
used three times in the original approved document.
"round-trip time", on the other hand, is used six times in running
text after it is defined.  Would you like to use "RTT" instead of
"round-trip time" after "RTT" is first defined? -->


7) <!-- [rfced] Section 1:  With the exception of the "consensus"
sentence, we removed the last paragraph of this section, as the rest
of it is addressed by the Status of This Memo section as provided in
published IRTF RFCs and the paragraph is not repeated in the body of
RFCs.  Please let us know any concerns.

Original:
 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.  This document defines an Experimental Protocol for the
 Internet community.  This document is a product of the Internet
 Research Task Force (IRTF).  The IRTF publishes the results of
 Internet-related research and development activities.  These results
 might not be suitable for deployment.  This RFC represents the
 consensus of the Information-Centric Networking Research Group of the
 Internet Research Task Force (IRTF).  Documents approved for
 publication by the IRSG are not candidates for any level of Internet
 Standard; see Section 2 of RFC 7841.

Currently:
 This RFC represents the consensus of the Information-Centric
 Networking Research Group (ICNRG) of the Internet Research Task Force
 (IRTF). -->


8) <!-- [rfced] Section 2:  We found this sentence confusing as written,
as error messages are generally discussed in the context of reply
messages.  Should "generated by" be "triggered by" or perhaps
"generated in response to" here?

Original:
 Any ICMP error messages,
 such as "no route to destination", generated by the ICMP Echo Request
 message are returned to the client and reported. -->


9) <!-- [rfced] Section 3:  Does "This single forwarding semantic" mean
"This particular type of forwarding semantic" or "This type of
semantic that forwards single packets" (in which case perhaps "single
forwarding" should be hyphenated or the text should be rephrased)?

Please note:  We also asked this question regarding the same text in
RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 This single forwarding semantic subsumes the functions of
 unicast, anycast, and multicast. -->


10) <!-- [rfced] Section 3:  To what does "as close as possible" in
this sentence refer?  If the suggested text is incorrect, please
clarify.

Please note:  We asked a similar question in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11).

Original:
 In the same way, the encoding of a ping echo reply
 should allow for forwarder processing as close as possible to that
 used for data packets.

Suggested:
 In the same way, the encoding of a ping echo reply
 should allow for forwarder processing in as similar a way as
 possible to that used for data packets. -->


11) <!-- [rfced] Please review each artwork element.  Should any artwork
element be tagged as sourcecode?  Please see
<https://www.rfc-editor.org/materials/sourcecode-types.txt>; if the
current list of preferred values for "type" does not contain an
applicable type, please let us know.  Also, it is acceptable to leave
the "type" attribute not set. -->


12) <!-- [rfced] Figures 1 through 6:  Should the bit ruler lines
(0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1)
be centered over the diagrams instead of left-justified to match
use in RFC 8690?

Please note:  We also asked this question in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11). -->


13) <!-- [rfced] Section 4.1:  Will "fixed header Path label TLV" be
clear to readers?  Is a bullet item missing?

We ask because in RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11)
we see the text "a new optional fixed header added to the packet header:"
followed by a bullet item.

Original:
 Compared to the typical format of a CCNx packet header from
 [RFC8569], in order to enable path steering of Echo Requests, there
 is an optional fixed header Path label TLV as specified in section
 3.1 of [I-D.irtf-icnrg-pathsteering] added to the packet header:

 The message format of an echo request is presented below: -->


14) <!--[rfced] Sections 4.1 and 4.2: We note that MessageType = 0x0005 Echo
Request (Figure 2) and Echo Reply (Figure 5). Is this correct? -->


15) <!-- [rfced] Sections 4.2 and 5.2:  The current section titles seem
to indicate that the packet types are ICMP as opposed to ICN (e.g.,
the titles of Sections 4.1 and 5.1 are "ICN Ping Echo Request CCNx
Packet Format" and "ICN Ping Echo Request NDN Packet Format",
respectively).  Should either "ICMP" or "ICN" be added to these
section titles (4.2 and 5.2) so that the distinction is clear to
readers?

Please note:  We asked a similar question regarding 
Sections 4.2 and 5.2 of RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 4.2.  Ping Echo Reply CCNx Packet Format
...
 5.2.  Ping Echo Reply NDN Packet Format -->


16) <!-- [rfced] Section 4.2:  Figures 5 and 6 have identical titles,
but the diagrams have different fields.  Should the title of
Figure 6 be changed in order to distinguish it from Figure 5?

Please note:  We also asked this question regarding a similar
situation in RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 Figure 5: Echo Reply Message Format
...
 Figure 6: Echo Reply Message Format

Possibly:
 Figure 5: Echo Reply Message Format
...
 Figure 6: Echo Reply PayloadType TLV Format -->


17) <!-- [rfced] Section 4.2:  In item 3), are the three listed
scenarios the only possible TLV return codes, or are they provided as
three examples?  In other words, should "i.e.," ("that is") be
"e.g.," ("for example") here?

Original (the entire paragraph is included for context):
 The PayloadType TLV is presented below.  It is of type
 T_PAYLOADTYPE_DATA, and the data schema consists of 3 TLVs: 1) the
 name of the sender of this reply (with the same structure as a CCNx
 Name TLV), 2) the sender's signature of their own name (with the same
 structure as a CCNx ValidationPayload TLV), 3) a TLV with a return
 code to indicate what led to the generation of this reply (i.e.,
 existence of a local application, a CS hit or a match with a
 forwarder's administrative name as specified in Section 6). -->


18) <!-- [rfced] Section 5.1:  We could not find any instances of
"KeywordNameComponent", "Keyword-Name-Component", or
"Keyword Name Component", or lowercase versions of same, in any
published RFCs.  As this appears to be a proper term (due to the
capitalizations), will readers know where this term comes from?

Please note:  We also asked this question regarding similar text in
RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 The name field of an echo request consists of the name prefix to be
 pinged, a nonce value (it can be the value of the Nonce field) and
 the suffix "ping" to denote that this Interest is a ping request
 (added as a KeywordNameComponent). -->


19) <!--[rfced] Section 5.1: FYI, we've updated "MustBeFresh element" to
"MustBeFresh selector" per RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).
Please let us know of any concerns.

Original:
 Since the NDN packet format does not provide a mechanism to prevent
 the network from caching specific data packets, we use the
 MustBeFresh element for echo requests...

Currently:
 Since the NDN packet format does not provide a mechanism to prevent
 the network from caching specific data packets, we use the
 MustBeFresh selector for echo requests...
-->        


20) <!--[rfced] Section 5.2: In Figure 10, should "EchoReplyCode" be
"PT_ECHO_REPLYCode"? This would reflect changes made in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11). Additionally, should
"ECHOREPLYCODE-TLV-TYPE" be changed?-->


21) <!-- [rfced] Section 6:  Should "Nonce name segment" be "nonce name
segment" per RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11), or
vice versa?  It would be ideal if both documents expressed this term
consistently.

Original:
 When a forwarder receives an echo request, it first extracts the
 message's base name (i.e., the request name with the Nonce name
 segment excluded as well as the suffix "ping" and the
 ParametersSha256DigestComponent in the case of an echo request with
 the NDN packet format). -->


22) <!-- [rfced] Section 6:  Do the three instances of "face" in this
section (two in text and one in Figure 11) mean "interface" or
something else?  If "face" is as intended, will this term be clear to
readers?

If "interface" is intended, may we update Figure 11 to use "IF"
within the figure instead of "face" and add an "IF = interface"
footnote?

Please note:  We asked a similar question regarding "face" in
Section 6 of RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 In some cases, the forwarder originates an echo reply, sending the
 reply downstream through the face on which the echo request was
 received.
...
 *  The echo request base name matches (in a Longest Prefix Match
    manner) a FIB entry with an outgoing face referring to a local
    application.
...
 | (base
 | matches
 | local app
 + face) -->


23) <!-- [rfced] Section 6:

a) As it appears that "LPM" stands for "Longest Prefix Match" as used
in the bullet item just previous to this paragraph, we added the
expansion where the term is first used.  If this is incorrect, please
provide the correct definition of "LPM".

Please note:  We also asked a similar question in RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).

Original:
 *  The echo request base name matches (in a Longest Prefix Match
    manner) a FIB entry with an outgoing face referring to a local
    application.

Currently:
 *  The echo request base name matches (in a Longest Prefix Match
    (LPM) manner) a FIB entry with an outgoing face referring to a
    local application.

b) Please clarify the meaning of "based on the name including".
Does it mean that the name must include the nonce typed name segment
and the suffix "ping" in the case of an echo request with the NDN
packet format, or does it mean "name, including" (i.e., "the name,
where it includes ...")?

Original:
 If none of the conditions to reply to the echo request are met, the
 forwarder will attempt to forward the echo request upstream based on
 the path steering value (if present), the results of the FIB LPM
 lookup and PIT creation (based on the name including the nonce typed
 name segment and the suffix "ping" in the case of an echo request
 with the NDN packet format). -->


24) <!-- [rfced] Figure 11:  Do the instances of "path label" (e.g.,
"(path label)", "(no path label)") in this figure refer to the Path
label TLV (in which case it should be "Path label") or is it used
more generally here? -->


25) <!-- [rfced] Section 7:  To clarify this text, may we update as
suggested?

Please note:  We also asked this question in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11).

Original:
 Based on the current usage of the LINK Object by the NDN team, a
 forwarder at the border of the region where an Interest name becomes
 routable must remove the LINK Object from incoming Interests.

Suggested:
 At the time of this writing, and based on usage of the LINK Object
 by the NDN team [NDNLPv2], a forwarder at the border of the region
 where an Interest name becomes routable must remove the LINK Object
 from incoming Interests. -->


26) <!-- [rfced] Section 7:  To what does "it" refer in this sentence -
the network region, the prefix, or something else?  Please clarify.

Please note:  We asked a similar question in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11).

Original:
 Within the network region that the locally-scoped
 prefix is routable, the state is based only on it. -->


27) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->


28) <!-- [rfced] Terminology: Please let us know if any changes are
needed for the following.

a) The following term was used inconsistently in this document.
We chose to use the latter form.  Please let us know any objections.

 Sender's name / Sender's Name (TLV type; per Figure 6) 

b) The following terms appear to be used inconsistently in this
document.  Please let us know which form is preferred.

 content-object / content object / Content Object *

 Echo reply (Section 2) / Echo Reply / echo reply

 Echo Request / echo request
   (We see that RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11)
   uses "Echo Request".)

 Freshness Period TLV / FreshnessPeriod TLV *

 ICMP echo / ICMP Echo (e.g., "ICMP echo and ...",
   "ICMP Echo approach")

 ICN Ping / ICN ping (used generally, e.g., "ICN Ping is ...",
   "ICN ping client application")

 InterestReturn / Interest-Return / Interest-return
   (We see that RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11)
   uses "InterestReturn" consistently.

    We suggest removing the hyphen and initial-capitalizing "return",
    per RFC 8569.)

 Link Object / LINK Object *

 NDN Data packet / NDN data packet *

 * Please note:  We found the same variations in RFC-to-be 9507
   (draft-irtf-icnrg-icntraceroute-11) and asked about these items in
   that document as well.  It would be ideal if both documents
   expressed these terms consistently.

c) Please confirm that capitalization versus lowercase for the
following is as desired:

Please note:  We asked a similar question in RFC-to-be 9507
(draft-irtf-icnrg-icntraceroute-11).

 Path label TLV
 path steering TLV

d) Should the instances of "ICN ping protocol" be "ICN Ping protocol"
per "Ping protocol" as used in the Abstract?

Please note:  In RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11),
we asked about the use of both "ICN Traceroute protocol" (Abstract)
and "ICN traceroute protocol" (Section 3).  It would be ideal if
capitalization style were made consistent in both documents. -->


Thank you.

RFC Editor/lb/ap


On Nov 10, 2023, at 4:01 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/11/10

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9508.xml
   https://www.rfc-editor.org/authors/rfc9508.html
   https://www.rfc-editor.org/authors/rfc9508.pdf
   https://www.rfc-editor.org/authors/rfc9508.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9508-diff.html
   https://www.rfc-editor.org/authors/rfc9508-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9508-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9508

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9508 (draft-irtf-icnrg-icnping-12)

Title            : ICN Ping Protocol Specification
Author(s)        : S. Mastorakis, D. Oran, J. Gibson, I. Moiseenko, R. Droms
WG Chair(s)      : 
Area Director(s) :