Re: [auth48] RFCs-to-be 9507 and 9508

["\"David R. Oran\"" <[e-mail]>]

Capitalize ParametersSha256DigestComponent in all cases please.

On 6 Mar 2024, at 14:01, Lynne Bartholomew wrote:

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