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

[Lynne Bartholomew <[e-mail]>]

Hi, Dave.  We've made the additional update per your note below.

The latest files are posted here.  Please refresh your browser:

   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-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9507-lastrfcdiff.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 15, 2023, at 12:05 PM, David R. Oran <[e-mail]> wrote:
> 
> The changes are fine by me. Not picky at all…
> ___________________________
> iDevice - please excuse typos.
> 
>> On Nov 15, 2023, at 1:00 PM, Lynne Bartholomew <[e-mail]> wrote:
>> 
>> Hi again, Dave.
>> 
>> We have made further updates to this document per your notes below.
>> 
>> At risk of sounding overly picky, may we make the following update?
>> 
>> OLD:
>> (in combination with a FreshnessPeriod
>> TLV of value 1 for replies)
>> 
>> NEW (per "TLV with a value of..." as used in Section 4.2 and Appendix A):
>> (in combination with a FreshnessPeriod
>> TLV with a value of 1 for replies)
>> 
>> We also see "FreshnessPeriod TLV of value 1" in RFC 9508.  If you'd like to make the change listed above, may we update 9508 as well?  (Again, we grant that this is a picky request.)
>> 
>> The latest files are posted here.  Please refresh your browser:
>> 
>>  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-lastdiff.html
>>  https://www.rfc-editor.org/authors/rfc9507-lastrfcdiff.html
>> 
>>  https://www.rfc-editor.org/authors/rfc9507-xmldiff1.html
>>  https://www.rfc-editor.org/authors/rfc9507-xmldiff2.html
>> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>>> On Nov 15, 2023, at 4:11 AM, David R. Oran <[e-mail]> wrote:
>>> 
>>> Responses inline.
>>> 
>>>> On 14 Nov 2023, at 16:40, Lynne Bartholomew wrote:
>>>> 
>>>> Hi again, Dave.  Thanks as always for the quick turnaround!
>>>> 
>>>>> maybe we have some chance of returning to the long-abandoned 48 in Auth48? :-)
>>>> 
>>>> We could account for inflation and go for a true AUTH96.
>>>> 
>>>> Regarding this item:
>>>> 
>>>>> It’s somewhat risky to depend on an author’s assessment whether readers will “obviously” see that a HopLimit is in fact a value and saying “value” each time is redundant and perhaps pedantic. I think it reads better just saying “HopLimit” rather than “HopLimit value” but you have a lot of experience (e.g. with Errata) so I’d like to punt to your judgment here. I don’t feel strongly one way for the other.
>>>> 
>>>> We think that the first instance of "HopLimit value" (just after Figure 5) is helpful, but we find the following instances tricky and don't know if, or how, they should be changed:
>>>> 
>>> I agree, that seems right. Specifically, for your suggestions below:
>>> 
>>>> 4: Indicates that the HopLimit reached the 0 value.        (maybe "HopLimit reached 0")
>>>> 
>>> Yes, I like “HopLimit reached 0”.
>>> 
>>>> When a forwarder receives a traceroute request, the HopLimit value is
>>>> checked and decremented ...                                 (might be best to leave this as is)
>>>> 
>>> Ok.
>>> 
>>>> If the HopLimit has not expired (its value is greater than 0), the ...      (maybe "(i.e., is greater than 0)")
>>>> 
>>> Yes, let’s go with “(i.e., is greater than 0)”
>>> 
>>>> If the HopLimit value equals 0, the forwarder generates a traceroute ...    (maybe "If HopLimit equals 0")
>>>> 
>>> Yes, let’s use “If HopLimit equals 0”
>>> 
>>>> ...met, the PT_TR_REPLY Code is set to 4 to indicate that the HopLimit      (maybe "to indicate that the HopLimit reached 0")
>>>> value reached 0.
>>>> 
>>> I like your suggestion of “to indicate that the HopLimit reached 0”.
>>> 
>>>> ... each session will have a HopLimit of value 1 to reach the first hop     (maybe "a HopLimit of 1")
>>>> forwarder, the second request will have a HopLimit of value 2 to ...        (maybe "a HopLimit of 2")
>>>> 
>>> Yes - your suggestions are good.
>>> 
>>>> ... sending requests with increasing HopLimit values and potentially ...    (might be best to leave this as is)
>>>> 
>>> Yes, agree.
>>> 
>>>> We don't want anything to appear redundant or pedantic either; please advise re. the above.
>>>> 
>>>> 
>>>> We made further updates per your notes below and also updated the following, per feedback for 9508:
>>>> 
>>>> MustBeFresh selector --> MustBeFresh TLV
>>>> nonce name --> Nonce name
>>>> Path label --> Path Label
>>>> 
>>> Great, thanks. Getting there!
>>> 
>>>> The latest files are posted here.  Please refresh your browser:
>>>> 
>>>> 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-lastdiff.html
>>>> https://www.rfc-editor.org/authors/rfc9507-lastrfcdiff.html
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9507-xmldiff1.html
>>>> https://www.rfc-editor.org/authors/rfc9507-xmldiff2.html
>>>> 
>>>> We hope that your family medical matters are minimal and quickly resolved!  Wishing you all the best.
>>>> 
>>>> Thanks again!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>> 
>>>>> On Nov 14, 2023, at 5:22 AM, David R. Oran <[e-mail]> wrote:
>>>>> 
>>>>> On 13 Nov 2023, at 15:43, Lynne Bartholomew wrote:
>>>>> Hi, Dave and *Dirk.
>>>>> Dave, thank you for the kind words and your quick reply!
>>>>> maybe we have some chance of returning to the long-abandoned 48 in Auth48? :-)
>>>>> We have updated this document per your notes below.
>>>>>  • 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.
>>>>> As I mentioned in the followup reply on icnping, I’m good with Dirk’s view that we should publish all three together, as long as it doesn’t cause you more work. I’ll try to turn pathsteering around quickly once it pops to the top of the queue.
>>>>> 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.
>>>>> Great.
>>>>> = = = = =
>>>>> 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?
>>>>>  • <!-- [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…"
>>>>> Oops. I found another small problem when looking at this (not saying “object” where it should be in the description), and then failed to fix the original dangling reference.
>>>>> How about:
>>>>> “Trace one or more paths through which a named data object can be reached in the sense that Interest packets can be forwarded towards the application hosting the object.”
>>>>> = = = = =
>>>>> 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?
>>>>> I just answered this on icnping. Let’s do what I said there?:
>>>>> Well, seems [NDNTLV] is itself inconsistent. In titles it says “Data Packet” but in running text it says “Data packet”. When I checked [NDNTLV] I only looked at the titles. I don’t particularly care, so I defer to your judgement - perhaps given we mention these in running text as well it ought to follow the same convention and use “Data packet”.
>>>>> Also, please clarify the "modulo the capitalization consistency checks" note; we could not see where any changes are needed re. this note.
>>>>> It was kind of a “note to self” for me to check that our capitalization was consistent throughout.
>>>>> = = = = =
>>>>> 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.
>>>>> Perfect.
>>>>> = = = = =
>>>>> Regarding our question 19) and "KeywordNameComponent": We added a citation for [NDNTLV]; thank you!
>>>>> Excellent.
>>>>> = = = = =
>>>>> 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
>>>>> It’s somewhat risky to depend on an author’s assessment whether readers will “obviously” see that a HopLimit is in fact a value and saying “value” each time is redundant and perhaps pedantic. I think it reads better just saying “HopLimit” rather than “HopLimit value” but you have a lot of experience (e.g. with Errata) so I’d like to punt to your judgment here. I don’t feel strongly one way for the other.
>>>>> = =
>>>>> 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.
>>>>> See above.
>>>>> I’m available for quick turnaround through this Thursday, but then have some family medical matters which will slow me down. It would be nice to get this to final text and go for author approvals by then.
>>>>> Many thanks,
>>>>> DaveO.
>>>>> = = = = =
>>>>> 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:
>>>>> [snipping out earlier material]
>> 
>>