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

[Lynne Bartholomew <[e-mail]>]

Apologies; forgot the closing parenthesis here:

Regarding our question 13) and your reply ("... in the Ping Echo reply and included in the Ping Echo request ...: should be
Regarding our question 13) and your reply ("... in the Ping Echo reply and included in the Ping Echo request ...):

> On Nov 13, 2023, at 4:59 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Dave.  Thank you for your quick reply and kind words re. this document as well!
> 
> We asked the Document Shepherd about whether or not to wait for draft-irtf-icnrg-pathsteering-07 when we emailed re. RFC-to-be 9507 and will wait for his reply.
> 
> Please note that we have a new question for this document (9508):
> 
> <!-- [rfced] Section 9:  FYI, because this document creates the "CCNx
> Echo Reply Codes" registry, we added a sentence regarding the registration
> procedure.  Please let us know any objections.
> 
> Currently:
> IANA has created a new registry called "CCNx Echo Reply Codes".  The
> registration procedure is Specification Required [RFC8126]. -->
> 
> 
> We have some follow-up questions for you:
> 
> Regarding our question 13) and your reply ("... in the Ping Echo reply and included in the Ping Echo request ...":  Please review the usage of lowercase "ping" in this document (36 instances, by our current count).  Should all instances of "ping" be changed to "Ping"?  RFC-to-be 9507 currently has "... new tools analogous to ping and traceroute".
> 
> = = = = =
> 
> Regarding our question 19) and your reply:
> 
>> The [NDNTLV] specification doesn’t say anything about what these TLVs are - it doesn’t use either "element" or "selector". The safest thing is to say "MustBeFresh TLV".
> 
> It appears that we should make this update in RFC-to-be 9507 as well.  Please confirm.
> 
> = = = = =
> 
> Regarding these items from our question 28)b):
> 
>>> 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".)
>> Use "Echo Request".
> 
> 
> We also used "Echo Reply".  Please let us know any concerns.
> 
>> Capitalize per [NDNTLV], so “NDN Data Packet” (same as I suggested for icntraceroute)
> 
> We updated accordingly, but we see "NDN Data packet" on <https://docs.named-data.net/NDN-packet-spec/current/data.html>.  Please confirm that "Packet" is as desired for this document.
> 
> = = = = =
> 
> The updated XML and output files are posted here.  Please refresh your browser to view the latest:
> 
>   https://www.rfc-editor.org/authors/rfc9508.txt
>   https://www.rfc-editor.org/authors/rfc9508.pdf
>   https://www.rfc-editor.org/authors/rfc9508.html
>   https://www.rfc-editor.org/authors/rfc9508.xml
>   https://www.rfc-editor.org/authors/rfc9508-diff.html
>   https://www.rfc-editor.org/authors/rfc9508-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9508-auth48diff.html
> 
>   https://www.rfc-editor.org/authors/rfc9508-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9508-xmldiff2.html
> 
> Please review our updates carefully, and let us know if anything is incorrect.
> 
> Thanks again!
> 
> RFC Editor/lb
> 
> 
>> On Nov 11, 2023, at 6:59 AM, David R. Oran <[e-mail]> wrote:
>> 
>> Thanks for the great copy-editing!
>> Responses to the suggested changes are embedded below. It’s probably safer to let you edit the XML, but after confirming these responses/changes, if you want the authors to do it, we’re happy to.
>> One question I have is whether, given the Pathsteering in the RFC Editor queue, we should do final publication of all three specifications together in order for the references to line up. These are not normative dependencies but if it makes your job easier to sync up the references to final RFC numbers, that’s fine with the authors,
>> On 10 Nov 2023, at 19:02, [e-mail] wrote:
>> Authors,
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>    • <!-- [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 -->
>> Yes.
>>    • <!-- [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 . -->
>> I believe these have been adhered to. I checked this a while ago but didn’t re-check on this Auth48 version.
>>    • <!-- [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. -->
>> Fine change.
>>    • <!-- [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]). -->
>> Yes, fine change.
>>    • <!-- [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.
>> Yes. fine change.
>> 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. -->
>> Well, “variance” is a statistic, along with the other ones (average, maximum, minimum”) so the original text is strictly speaking correct. However, perhaps a better wording might be:
>> “Note that a measurement application is needed to make proper use of ICN Ping in order to compute various statistics, such as average, maximum, and minimum round trip time (RTT) values, variance in RTTs, and loss rates.”
>>    • <!-- [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? -->
>> Don’t care, but just using the RTT acronym is fine too.
>>    • <!-- [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). -->
>> Fine.
>>    • <!-- [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?
>> “generated in response to” seems most accurate 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. -->
>>    • <!-- [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).
>> Right. I responded there as well, where I said:
>> The intended meaning of “single” here is that there is only one forwarding semantic applied in all cases, so the existing text is strictly correct. It refers back the prior sentence where the forwarding semantic is defined as “…multi-path and multi-destination stateful Interest forwarding and multi-destination data delivery to units of named data.”
>> I can’t think of a better phrasing at the moment. Suggestions?
>> Original:
>> This single forwarding semantic subsumes the functions of
>> unicast, anycast, and multicast. -->
>>    • <!-- [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).
>> Right I replied there with some suggest text changes which I suggest we mirror here. See below:
>> 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. -->
>> I’m not sure that “similar in a way” conveys the meaning as well as the original, which is to diverge from the processing of interest packets as little as possible. Perhaps a better way to say this is:
>> “It is desirable that the packet encoding of a Ping Echo request enable the forwarders to distinguish a ping from a normal Interest, while diverging as little as possible from the forwarding behavior for an Interest packet. In the same way, the encoding of a Ping Echo reply should minimize any processing differences from those employed for a Data packet by the forwarders.”
>>    • <!-- [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. -->
>> Yes, all the artwork are just regular packet layouts or data formats.
>>    • <!-- [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). -->
>> Don’t care. Whatever RFCed thinks looks better. (That’s what I said for icntraceroute as well).
>>    • <!-- [rfced] Section 4.1: Will "fixed header Path label TLV" be
>> clear to readers?
>> I think so.
>> 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:
>> I suppose we ought to mirror the txt in icntraceroute, just for consistency. That would make the text here be:
>> “Compared to the typical format of a CCNx packet header [RFC8609], there is a new optional fixed header added to the packet header:
>>    • A Path Steering hop-by-hop header TLV, which is constructed hop-by-hop in the Ping Echo reply and included in the Ping Echo request to steer consecutive requests expressed by a client towards a common or different forwarding paths. The Path label TLV is specified in [I-D.irtf-icnrg-pathsteering]”
>> The message format of an echo request is presented below: -->
>>    • <!--[rfced] Sections 4.1 and 4.2: We note that MessageType = 0x0005 Echo
>> Request (Figure 2) and Echo Reply (Figure 5). Is this correct? -->
>> Per the IANA registrations, these ought to be:
>> 0x05 in Figure 2 and
>> 0x06 in Figure 5
>>    • <!-- [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?
>> The distinction should be clear, but adding “ICN” to the front of each makes things crystal clear.
>> Please note: We asked a similar question regarding
>> Sections 4.2 and 5.2 of RFC-to-be 9507 (draft-irtf-icnrg-icntraceroute-11).
>> I said the same for icntraceroute.
>> Original:
>> 4.2. Ping Echo Reply CCNx Packet Format
>> ...
>> 5.2. Ping Echo Reply NDN Packet Format -->
>>    • <!-- [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 -->
>> Good catch. Change is correct.
>>    • <!-- [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?
>> They are the only ones defined in this specification. They are registered by IANA in the registry “CCNx Echo Reply Codes”, which has a policy of “Specification Required”.
>> 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). -->
>> Given the above, I guess “i.e.” in the text is correct.
>>    • <!-- [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).
>> answer is the same as for icntraceroute:
>> that’s because they are defined in the NDN specifications, which are not IRTF or IETF documents.
>> Do you think we need another explicit reference to [NDNTLV] inserted in this text to make it clear?
>> 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). -->
>>    • <!--[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...
>> -->
>> The [NDNTLV] specification doesn’t say anything about what these TLVs are - it doesn’t use either “element” or “selector”. The safest thing is to say “MustBeFresh TLV”.
>>    • <!--[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?-->
>> No, the original is correct as this is according to the conventions used in the NDN packet format specification (reference [NDNTLV]).
>>    • <!-- [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.
>> I would capitalize “Nonce” in both documents.
>> 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). -->
>>    • <!-- [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).
>> same answer as in icntraceroute:
>> “Face” is the term of art in the NDN and CCNx specifications, so I think it’s clear, at least in the sense that a reader won’t understand this specification without having read and understood the (normative) reference to RFC8609.
>> 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) -->
>>    • <!-- [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.
>> Please follow the changes I suggested in icntraceroute:
>> Actually, the other ICN specifications say “Longest Name Prefix Match” since that properly distinguishes the algorithm from what is conventionally “longest prefix match” in the TCP/IP world. So, how about we do the following in text talking about ICN protocols
>>    • Change “Longest Prefix Match” to “Longest Name Prefix Match” globally.
>>    • Change “LPM” to “LNPM” globally.
>> 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). -->
>> perhaps a better wording would be to just split the sentence into two rather than using a parenthetical:
>> “…the results of the FIB LNPM lookup and PIT creation. These lookups are based on including the Nonce and the suffix "ping" as name segments of the Name in the case of an echo request with the NDN packet format.”
>>    • <!-- [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? -->
>> doesn’t really matter, but it does refer to the Path Label TLV, so we could change it. The cosmetic difficulty is that the figure is really squeezed to fit in the text rendering as it is, and adding “TLV” would likely further blow out the line limits
>>    • <!-- [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. -->
>> Fine. Good change.
>>    • <!-- [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. -->
>> As I answered in icntraceroute:
>> Wow, how’d we write such a mess :-)
>> I think this really ought to say:
>> “The state along the path depends on whether the request is traversing the portion of the network where the locally-scoped name is routable. In this case the forwarding can be based entirely on the locally-scoped name. However, where a portion of the path lies outside region where the locally-scoped name is routable, the border router has to rewrite the name of a reply and prepend the routable prefix of the corresponding request to ensure the generated replies will reach the client.”
>>    • <!-- [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. -->
>> I only re-skimmed but I didn’t find any concerns either.
>>    • <!-- [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)
>> Let’s keep capitalized “Name”, though in his context it doesn’t really matter.
>> 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 *
>> use “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".)
>> Use “Echo Request”.
>> Freshness Period TLV / FreshnessPeriod TLV *
>> It’s “FreshnessPeriod” in [NDNTLV] so please use that.
>> ICMP echo / ICMP Echo (e.g., "ICMP echo and ...",
>> "ICMP Echo approach")
>> Looks better to capitalize ”Echo”
>> ICN Ping / ICN ping (used generally, e.g., "ICN Ping is ...",
>> "ICN ping client application")
>> Capitalize “Ping” I think.
>> 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.)
>> 
>> Yes. Please.
>> Link Object / LINK Object *
>> NDNTLV uses “Link Object” so let’s stick with that.
>> 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.
>> Capitalize per [NDNTLV], so “NDN Data Packet” (same as I suggested for icntraceroute)
>> 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
>> “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. -->
>> Yes. Make it so.
>> Thank you.
>> 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) :
>> DaveO
>