[auth48] RFCs-to-be 9507 and 9508

[Lynne Bartholomew <[e-mail]>]

Dear authors,

We are preparing RFCs-to-be 9507 and 9508 for publication.

Apologies for not spotting this earlier.  We see both "ParametersSha256DigestComponent" and "parametersSha256DigestComponent" in these two documents, as follows:

rfc9507.txt:   element is present, a ParametersSha256DigestComponent (Section 6) is
rfc9507.txt:   suffix "traceroute" and the ParametersSha256DigestComponent in the
rfc9508.txt:   parametersSha256DigestComponent (Section 6) is added as the last name
rfc9508.txt:   ParametersSha256DigestComponent in the case of an Echo Request with

Are the different capitalization styles correct, or should one form be used?  Although neither of these documents cites RFC 9139, we see that RFC 9139 uses "ParametersSha256DigestComponent".

Please advise.  We will wait to hear from someone before proceeding.

Thank you!

RFC Editor/lb

> On Nov 10, 2023, at 4:02 PM, [e-mail] wrote:
> 
> 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) : 
> 
>