Re: [auth48] *[Document Shepherd] Re: AUTH48: RFC-to-be 9507 <draft-irtf-icnrg-icntraceroute-11> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Dirk.  Thank you for your quick reply on this!

We will hold publication of 9507 and 9508 until pathsteering is ready.  We've noted this on <https://www.rfc-editor.org/auth48/rfc9507> and <https://www.rfc-editor.org/auth48/rfc9508>.

Thanks again!

RFC Editor/lb

> On Nov 13, 2023, at 5:36 PM, Dirk Kutscher <[e-mail]> wrote:
> 
> Hi Lynne,
> 
>> * Dirk, as Document Shepherd, do you have any preferences related to publishing draft-irtf-icnrg-pathsteering-07 along with this document and RFC-to-be 9508?  Whether or not we wait for draft-irtf-icnrg-pathsteering-07 doesn't affect our process in any way, but if you would like to hold publication of RFCs-to-be 9507 and 9508 for draft-irtf-icnrg-pathsteering-07, we are happy to do so.
> 
> thanks much for considering – yes, I think we should publish the three RFCs together and hold publication of 9507 and 9508 until pathsteering is ready.
> 
> Thanks,
> Dirk
> 
> 
>> 
>> Dave, some follow-up questions/notes for you:
>> 
>> Regarding our question 7) and your reply (that the existing text is strictly correct):  Thank you for clarifying.  We wanted to ensure that the text will be clear to readers, and per your note, all sounds fine.
>> 
>> = = = = =
>> 
>> Regarding our question 8) and your reply:  Apologies, but we could not determine from the reply what "it" refers to.  Does it refer to the application?  Will the meaning be clear to readers?
>> 
>>>> 8) <!-- [rfced] Section 3: To what does "it" refer in this sentence?
>>>> Original ("an named data" has been fixed):
>>>>    • Trace one or more paths along which an named data of an
>>>> application can be reached in the sense that Interest packets can
>>>> be forwarded toward it. -->
>>> 
>>> Probably ought to change to:
>>> "Trace one or more paths along which a named data object of an application…"
>> 
>> 
>> = = = = =
>> 
>> Regarding your replies to our questions 9) and 10):
>> 
>> We see "Data packet" in one of the replies, but please note that this document currently uses "data packet" and "NDN Data Packet".  Are additional capitalization changes needed in this document and (if applicable) RFC-to-be 9508?
>> 
>> Also, please clarify the "modulo the capitalization consistency checks" note; we could not see where any changes are needed re. this note.
>> 
>> = = = = =
>> 
>> Regarding our question 25)b) and your reply, which introduces the term "Interest Lifetime" in this document:  We added a citation for RFC 8609 as information for the reader.  Please let us know any objections.
>> 
>> = = = = =
>> 
>> Regarding our question 19) and "KeywordNameComponent":  We added a citation for [NDNTLV]; thank you!
>> 
>> = = = = =
>> 
>> Regarding these replies in our question 27)b):
>> 
>>> Please use "HopLimit" I don’t think "value" adds anything.
>> 
>> 
>> Does this note indicate that we should also remove "value" from the following?
>> 
>> Currently:
>> a match with a forwarder's name, or the HopLimit value of the
>> ...
>> When a forwarder receives a traceroute request, the HopLimit value is
>> ...
>> If the HopLimit value equals 0, the forwarder generates a traceroute
>> ...
>> met, the PT_TR_REPLY Code is set to 4 to indicate that the HopLimit
>> value reached 0.
>> ...
>> sending requests with increasing HopLimit values and potentially
>> 
>> =   =
>> 
>>> Capitalize per [NDNTLV], so "NDN Data Packet"
>> 
>> 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/rfc9507.txt
>>  https://www.rfc-editor.org/authors/rfc9507.pdf
>>  https://www.rfc-editor.org/authors/rfc9507.html
>>  https://www.rfc-editor.org/authors/rfc9507.xml
>>  https://www.rfc-editor.org/authors/rfc9507-diff.html
>>  https://www.rfc-editor.org/authors/rfc9507-rfcdiff.html
>>  https://www.rfc-editor.org/authors/rfc9507-auth48diff.html
>> 
>>  https://www.rfc-editor.org/authors/rfc9507-xmldiff1.html
>>  https://www.rfc-editor.org/authors/rfc9507-xmldiff2.html
>> 
>> 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 18:55, [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 Traceroute Protocol Specification
>>> Currently:
>>> Information-Centric Networking (ICN) Traceroute 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: Are transit forwarders and delays the only
>>> characteristics that would be examined, or should "i.e.," ("that is")
>>> be "e.g.," ("for example") here?
>>> Original ("fundamendal" has been corrected):
>>> To this end, the problem of
>>> ascertaining the characteristics (i.e., transit forwarders and
>>> delays) of at least one of the available routes to a name prefix is a
>>> fundamendal requirement for instrumentation and network management. -->
>>> It might be better to spell this out better than just the short parenthetical phrase. How about a minor rewrite into two sentences:
>>> “To this end, the ability ascertain the characteristics of at least one of the available routes to a name prefix is a fundamental requirement for instrumentation and network management. These characteristics include, among others, route properties such as which forwarders were transited and the delay incurred through forwarding.”
>>>    • <!-- [rfced] Section 1: 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 traceroute
>>> 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 traceroute protocol of TCP/IP;
>>> this new management and debugging protocol will aid the experimental
>>> deployment of ICN protocols. -->
>>> Good change.
>>>    • <!-- [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. No concerns here.
>>>    • <!-- [rfced] Section 3: We changed "NDN and CCN protocols" to
>>> "Named Data Networking (NDN) and Content-Centric Networking (CCNx)
>>> protocols", using the expansions provided in RFC 8793. If these
>>> expansions are incorrect, please provide the correct definitions.
>>> Original:
>>> In the NDN and CCN protocols, the communication paradigm is based
>>> exclusively on named objects.
>>> Currently:
>>> In the Named Data Networking (NDN) and Content-Centric Networking
>>> (CCNx) protocols, the communication paradigm is based exclusively on
>>> named objects. -->
>>> Correct.
>>>    • <!-- [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)?
>>> Original:
>>> This single forwarding semantic subsumes the functions of
>>> unicast, anycast, and multicast. -->
>>> 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?
>>>    • <!-- [rfced] Section 3: To what does "it" refer in this sentence?
>>> Original ("an named data" has been fixed):
>>>    • Trace one or more paths along which an named data of an
>>> application can be reached in the sense that Interest packets can
>>> be forwarded toward it. -->
>>> Probably ought to change to:
>>> “Trace one or more paths along which a named data object of an application…”
>>>    • <!-- [rfced] Section 3: To what does "as similar as possible" in
>>> these sentences refer? If the suggested text is incorrect, please
>>> clarify.
>>> Original:
>>> In order to provide stable and reliable diagnostics, it is desirable
>>> that the packet encoding of a traceroute request enable the
>>> forwarders to distinguish this request from a normal Interest, while
>>> also preserving forwarding behavior as similar as possible to that
>>> for an Interest packet. In the same way, the encoding of a
>>> traceroute reply should allow for processing as similar as possible
>>> to that of a data packet by the forwarders.
>>> Suggested:
>>> In order to provide stable and reliable diagnostics, it is desirable
>>> that the packet encoding of a traceroute request enable the
>>> forwarders to distinguish this request from a normal Interest while
>>> also preserving forwarding behavior in as similar a way as possible
>>> to that for an Interest packet. In the same way, the encoding of a
>>> traceroute reply should allow for processing in as similar a way as
>>> possible to that for a data packet by the forwarders. -->
>>> 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:
>>> “…while also diverging as little as possible from the forwarding behavior for an Interest packet. In the same way, the encoding of a Traceroute Reply should minimize any processing differences from those employed for a Data packet by the forwarders.”
>>>    • <!-- [rfced] Section 3: This sentence does not parse. If the
>>> suggested text is not correct, please clarify what "further enabling"
>>> refers to.
>>> Original:
>>> To this end, we need some
>>> encoding in the traceroute requests to make each request for a common
>>> prefix unique, and hence avoid PIT aggregation and further enabling
>>> the exact matching of a response with a particular traceroute packet.
>>> Suggested:
>>> To this end, we need some
>>> encoding in the traceroute requests to make each request for a common
>>> prefix unique, hence avoiding PIT aggregation and further enabling
>>> the exact matching of a response with a particular traceroute packet. -->
>>> The change is fine, modulo the capitalization consistency checks.
>>>    • <!-- [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] Authors and [Document Shepherd]:
>>> Sections 4.1 and subsequent: Please note that per IANA and as shown
>>> on https://www.iana.org/assignments/ccnx/ , we have changed all
>>> instances of "TrRequest" and "TrReply" in this document to
>>> "PT_TR_REQUEST" and "PT_TR_REPLY", respectively. (We also changed
>>> "TrReplay" to "PT_TR_REPLY" in Section 9.)
>>> These changes per IANA are correct.
>>> Please let us know if "TRREPLYCODE-TLV-TYPE" in Figure 11 should be
>>> changed to "PT_TR_REPLYCODE-TLV-TYPE"; we ask because we see that
>>> this is now the only string that contains "TRR".
>>> No, the original is correct as this is according to the conventions used in the NDN packet format specification (reference [NDNTLV]).
>>> Please review carefully (e.g., the updates to the text, several
>>> figures, and Section 9), and let us know any objections.
>>> The note from IANA (we believe that "T_TR_REQUEST" was meant to be
>>> "PT_TR_REQUEST"):
>>> = = =
>>> NOTE: this document needs these agreed-upon changes to the IANA
>>> Considerations section:
>>>    • The first sentence's "TrRequest" and "TrReply" have been
>>> registered as "T_TR_REQUEST" and "PT_TR_REPLY"
>>>    • The second sentence should be removed, as the "nonce" registration
>>> was made via a related document
>>> = = = -->
>>> IANA change is correct,
>>>    • <!-- [rfced] Figures 1 through 7: 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? -->
>>> Don’t care. Whatever RFCed thinks looks better.
>>>    • <!-- [rfced] Section 4.1: We received this note from IANA:
>>> "The second sentence [in Section 9] should be removed, as the
>>> "nonce" registration was made via a related document"
>>> Per https://www.iana.org/assignments/ccnx/ , the "nonce" appears to
>>> be "T_NONCE", and the related document appears to be
>>> draft-irtf-icnrg-icnping. Should we replace "Section 9" with an
>>> in-text citation for draft-irtf-icnrg-icnping and also add an
>>> Informative Reference entry for draft-irtf-icnrg-icnping?
>>> Seems reasonable. We were progressing this in in parallel with icnping, so it wasn’t clear which would wind up with the definitive allocation request to IANA.
>>> Please see the IANA page and
>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnping/12/ , and
>>> advise.
>>> Original:
>>> The format of this TLV
>>> is a 64-bit nonce. See Section 9 for the value assignment. -->
>>>    • <!-- [rfced] Sections 4.2 and 5.2: The current section titles seem
>>> to indicate that the packet types are something other than ICN (e.g.,
>>> the titles of Sections 4.1 and 5.1 are "ICN Traceroute Request CCNx
>>> Packet Format" and "ICN Traceroute Request NDN Packet Format",
>>> respectively). Should "ICN" be added to these section titles (4.2
>>> and 5.2) so that any needed distinction is clear to readers?
>>> Original:
>>> 4.2. Traceroute Reply CCNx Packet Format
>>> ...
>>> 5.2. Traceroute Reply NDN Packet Format -->
>>> Ok to add “ICN” in front of these, though I doubt anyone would think they were anything else once they got past the introduction.
>>>    • <!-- [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?
>>> Original:
>>> Figure 5: Traceroute Reply Message Format
>>> ...
>>> Figure 6: Traceroute Reply Message Format
>>> Possibly:
>>> Figure 5: Traceroute Reply Message Format
>>> ...
>>> Figure 6: Traceroute Reply PayloadType TLV Format -->
>>> Good catch. Yes the change is correct.
>>>    • <!-- [rfced] Section 4.2: This sentence does not parse. If the
>>> suggested text is not correct, please clarify what "whether" refers
>>> to.
>>> Also, please search for the word "existence" in
>>> draft-irtf-icnrg-icnping-12 as well, to see if any updates are needed
>>> there in order to synchronize these two documents.
>>> I’ll do that in our reply to the Auth48 on icnping.
>>> Original:
>>> 3) a TLV with return codes to indicate whether the request was
>>> satisfied due to the existence of a local application, a CS hit
>>> or a match with a forwarder's name, or the HopLimit value of the
>>> corresponding request reached 0.
>>> Suggested:
>>> 3) a TLV with return codes to indicate whether the request was
>>> satisfied due to the existence of a local application, a CS hit,
>>> a match with a forwarder's name, or the HopLimit value of the
>>> corresponding request reaching 0. -->
>>> Yes. Good change.
>>>    • <!-- [rfced] Section 4.2: Do the colons after the numbers indicate
>>> that these are actual values (e.g., "value of 1", "value of 2" ...,
>>> Yes, they are the actual values.
>>> in which case perhaps we could use "Value = 1:", "Value = 2:" ...),
>>> or is this a numbered list (in which case the colons should be
>>> periods)?
>>> Alternatively, if values 1 through 4 are indicated, we could change
>>> "The assigned values" to "The four assigned values".
>>> Sure, that’s fine.
>>> Original ("the the" has been corrected):
>>> The structure of the TrReply Code TLV is presented below (16-bit
>>> value). The assigned values are the following:
>>> 1: Indicates that the target name matched the administrative name of
>>> a forwarder (as served by its internal management application).
>>> 2: Indicates that the target name matched a prefix served by an
>>> application (other than the internal management application of a
>>> forwarder).
>>> 3: Indicates that the target name matched the name of an object in a
>>> forwarder's CS.
>>> 4: Indicates that the the Hop limit reached the 0 value. -->
>>>    • <!-- [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?
>>> 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 of a request consists of the target name, a nonce value (it
>>> can be the value of the Nonce field) and the suffix "traceroute" to
>>> denote that this Interest is a traceroute request (added as a
>>> KeywordNameComponent). -->
>>>    • <!-- [rfced] Section 6: As it appears that "LPM" stands for
>>> "Longest Prefix Match" as used a few paragraphs later, we moved the
>>> expansion here (where the term is first used). If this is incorrect,
>>> please provide the correct definition of "LPM".
>>> 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”
>>>    • Change “Longest Prefix Match” to “Longest Name Prefix Match” globally.
>>>    • Change “LPM” to “LNPM” globally.
>>> Also, does "if present" refer only to the path steering value, or
>>> does it refer to all items in the list?
>>> Only to the path steering value.
>>> Original:
>>> If the HopLimit has not expired (its value is greater than 0), the
>>> forwarder will forward the request upstream based on CS lookup, PIT
>>> creation, LPM lookup and the path steering value, if present.
>>> ...
>>>    • The target name matches (in a Longest Prefix Match manner) a FIB
>>> entry with an outgoing face referring to a local application.
>>> Currently:
>>> If the HopLimit has not expired (its value is greater than 0), the
>>> forwarder will forward the request upstream based on CS lookup, PIT
>>> creation, Longest Prefix Match (LPM) lookup, and the path steering
>>> value, if present.
>>> ...
>>>    • The target name matches (in an LPM manner) a FIB entry with an
>>> outgoing face referring to a local application. -->
>>> Modulo changing LPM to LNPM as above, this is fine.
>>>    • <!-- [rfced] Section 6: Should "outgoing face" be "outgoing
>>> interface" in this bullet item? If not, please confirm that "face"
>>> as used in this context will be clear to readers.
>>> “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:
>>>    • The target name matches (in a Longest Prefix Match manner) a FIB
>>> entry with an outgoing face referring to a local application. -->
>>> Yes, but make the global change to “Longest Name Prefix Match”.
>>>    • <!-- [rfced] Section 7: To clarify this text, may we update as
>>> suggested?
>>> Original:
>>> Based on the current deployment of the LINK Object by the NDN team, a
>>> forwarder at the border of the region, where an Interest name becomes
>>> routable has to remove the LINK Object from the incoming Interests.
>>> Suggested:
>>> At the time of this writing, and based on the current deployment of
>>> the LINK Object by the NDN team [NDNLPv2], a forwarder at the border
>>> of the region where an Interest name becomes routable has to remove
>>> the LINK Object from the incoming Interests. -->
>>> Fine. Good change.
>>>    • <!-- [rfced] Section 7: This sentence is confusing as written. If
>>> the suggested text is not correct, please provide clarifying text
>>> regarding the use of "conditions".
>>> Original:
>>> There are two conditions for a forwarder to
>>> perform this rewriting operation on a request:
>>> Suggested (assuming that both conditions must be met):
>>> A forwarder will perform this rewriting operation on a request if
>>> the following two conditions are met: -->
>>> Fine change.
>>>    • <!-- [rfced] Section 7: This sentence does not parse. Please
>>> clarify the text, including what "it" refers to.
>>> Original:
>>> The state maintained along the path, where the locally-scoped name is
>>> not routable, is based on the routable prefix along with the locally-
>>> scoped prefix, while within the network region that the locally-
>>> scoped prefix is routable is based only on it. -->
>>> 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] Appendix A:
>>> a) Does "first one" here mean "first request", "first name", or
>>> something else? Please clarify.
>>> Original:
>>> When generating a series of requests for a specific name, the first
>>> one will typically not include a Path label TLV, since no TLV value
>>> is known.
>>> Should be “the first request”.
>>> b) To what does "which will have semantics ..." refer in this
>>> sentence - the lifetime or the request?
>>> Original:
>>> It will also set the lifetime of a request,
>>> which will have semantics similar to the lifetime of an Interest. -->
>>> It refers to the semantics of the Interest lifetime in an Interest packet.
>>> How about:
>>> “The client also sets the lifetime of the Traceroute Request, which carries the same semantics as Interest Lifetime in an Interest.”
>>>    • <!-- [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”
>>> Freshness Period TLV / FreshnessPeriod TLV
>>> It’s “FreshnessPeriod” in [NDNTLV] so please use that.
>>> hop limit / Hop limit / HopLimit
>>> (e.g., "hop limit value", "HopLimit value")
>>> Please use “HopLimit” I don’t think “value” adds anything.
>>> ICN traceroute / ICN Traceroute (in running text)
>>> Yes, please capitalize “Traceroute”
>>> ICN Traceroute protocol (Abstract) /
>>> ICN traceroute protocol (Section 3)
>>> Ditto.
>>> Link Object / LINK Object
>>> NDNTLV uses “Link Object” so let’s stick with that.
>>> NDN Data packet / NDN data packet
>>> Capitalize per [NDNTLV], so “NDN Data Packet”
>>> c) Please confirm that capitalization versus lowercase for the
>>> following is as desired:
>>> hop-by-hop path steering TLV
>>> I’d change to “hop-by-hop Path Steering TLV”
>>> Path label TLV
>>> “Path Label TLV”
>>> Path Steering hop-by-hop header TLV
>>> this is fine
>>> path steering TLV -->
>>> “Path Steering TLV”.
>>> Thank you.
>>> Thank YOU!!!
>>> RFC Editor/lb/ap
>>> On Nov 10, 2023, at 3:54 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/rfc9507.xml
>>> https://www.rfc-editor.org/authors/rfc9507.html
>>> https://www.rfc-editor.org/authors/rfc9507.pdf
>>> https://www.rfc-editor.org/authors/rfc9507.txt
>>> Diff file of the text:
>>> https://www.rfc-editor.org/authors/rfc9507-diff.html
>>> https://www.rfc-editor.org/authors/rfc9507-rfcdiff.html (side by side)
>>> Diff of the XML:
>>> https://www.rfc-editor.org/authors/rfc9507-xmldiff1.html
>>> Tracking progress
>>> The details of the AUTH48 status of your document are here:
>>> https://www.rfc-editor.org/auth48/rfc9507
>>> Please let us know if you have any questions.
>>> Thank you for your cooperation,
>>> RFC Editor
>>> RFC9507 (draft-irtf-icnrg-icntraceroute-11)
>>> Title : ICN Traceroute Protocol Specification
>>> Author(s) : S. Mastorakis, D. Oran, I. Moiseenko, J. Gibson, R. Droms
>>> WG Chair(s) :
>>> Area Director(s) :
>>> DaveO