Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review

[Sandy Ginoza <[e-mail]>]

Greetings all,

Thank you for your quick review. The updated files are available here:

   https://www.rfc-editor.org/authors/rfc9374.txt
   https://www.rfc-editor.org/authors/rfc9374.pdf
   https://www.rfc-editor.org/authors/rfc9374.html
   https://www.rfc-editor.org/authors/rfc9374.xml

Diffs of the most recent updates only: 
   https://www.rfc-editor.org/authors/rfc9374-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9374-lastrfcdiff.html (side by side)

AUTH48 diff:
   https://www.rfc-editor.org/authors/rfc9374-auth48diff.html

Comprehensive diff: 
   https://www.rfc-editor.org/authors/rfc9374-diff.html
   https://www.rfc-editor.org/authors/rfc9374-rfcdiff.html (side by side)


Please see comments in-line.   In addition, please review the updated files and let know if any changes are needed. 

This still applies: 

> [note that resolved issues have been snipped]



>>>> 20) <!-- [rfced] We are having trouble parsing "88-byte self-proof
>>>> evidence".  If possible, please clarify.
>>>> 
>>>> Original:
>>>>    The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an
>>>>    88-byte self-proof evidence (timestamp, HHIT, and signature of these)
>>>>    to provide proof to Observers of Remote ID ownership (GEN-1 in
>>>>    [RFC9153]).
>>>> -->
>>> The term "evidence" (and "endorsement") are defined in drip-arch and are from RATS rfc 9334.  Sec 2.3 says to look in drip-arch for terms.  We had quite a debate on the list about where terms are defined in our documents.
>>> 
>>> Perhaps first time "evidence" and "endorsement" are used point to rfc9334?
>>> 
>>> These terms/concepts are really important in DRIP and heavily used in drip-auth.
>> 
>> [rfced] We have not made any changes, but we wonder if “self-proving evidence” is meant?
> 
> I can see that is a better way to express the concept.  I see "self-proof evidence" used earlier in the para.  Use that.
> 
> Don't change self-claims or self-endorsement as those are different beasts.

Please note that I don't fully understand what is meant by "self-proof evidence”, but I have left the phrase as it is based this discussion.  In addition, it appears you wanted the other instance of “self-evidence” to be “self-proof evidence”.  We have updated this sentence as shown below. Please let us know if any updates are needed. 

Original:

   In practice, the Wrapper and Manifest authentication
   formats (Sections 6.3.3 and 6.3.4 of [drip-authentication])
   implicitly provide this self-evidence.

Current: 
   In practice, the Wrapper and Manifest
   authentication formats (Sections 6.3.3 and 6.3.4 of [DRIP-AUTH])
   implicitly provide this self-proof evidence. 



> 
>> 
>>>> 45) <!-- [rfced] Would you like to make use of <sup> for superscript
>>>> in this document? You can see how it looks here:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9374-sup.html
>>>> https://www.rfc-editor.org/authors/rfc9374-sup.pdf
>>>> https://www.rfc-editor.org/authors/rfc9374-sup.txt
>>>> 
>>>> Note: In the HTML and PDF, it appears as superscript.
>>>> In the text output, <sup> generates a^b.
>>>> -->
>>> I did not even consider what would work here for .txt and .pdf and .html.
>>> 
>>> So please do what works best!  Maybe I will learn something for future use!
>> 
>> [rfced] We have updated the document to use superscript.  Please review.  In particular, please review this instance in the text and html output (at minimum) to ensure the groupings are correct:
>> 
>> Original:
>>        p = 1 - e^{-k^2/(2n)}
>> 
>> TXT:
>>        p = 1 - e^({-k^2/(2n)})
>> 
>> HTML:
>>    https://www.rfc-editor.org/authors/rfc9374.html#appendix-D
> 
> Both changes are fine.  Just as a comment, in pure math precedence rules the added set of parens is not needed.
> 
> I do see that you also changed table 15 for superscripts and that is fine too.

The added parens around {-k^2/(2n)} is being added by xml2rfc.  This is what currently appears in the XML:

<t>p = 1 - e<sup>{-k<sup>2</sup>/(2n)}</sup></t>

If you prefer the parens be removed, please let us know and we will discuss the issue with the tools team.  


> 
> 
>> 
>>>> 46) <!-- [rfced] Please review the following regarding terminology:
>>>> 
>>>> a) Throughout the text, the following term appears to be used
>>>> inconsistently. Please review these occurrences and let us know if/how they
>>>> may be made consistent.
>>>> 
>>>> authentication message vs Authentication Message
>>>> 
>>>> b) Note that instances of "IPV6" have been updated to "IPv6" (lowercase v).
>>>> 
>>>> c) In addition, note that we have used the following articles.  Please let us know if any corrections are needed.
>>>> 
>>>> an HI (read "hy")
>>>> an HDA (read as letters, i.e., an eche dee aye)
>>>> a HIP (read as the word hip)
>>>> a HIT (read as the word hit)
>>>> a HHIT - how is this read?
>>>> -->
>>> We were very careful where we capitalized authentication message vs Authentication Message
>>> 
>>> Are we talking about the actual ASTM Authentication Message (msg type 0x2) or speaking about an authentication message.  So please the case alone.  Lots of reviews on this usage.
>>> 
>>> b)  thank you.
>>> 
>>> HI should probably be "a HI" as you allude?
>>> HDA, HIP, and HIT are right above.
>>> 
>>> HHIT is read by letter or "H HIT".  So that seems it should be an HHIT.
>> <atw>
>> in conference with Stu, user may not understand this subtle distinction! Perhaps text is needed the terminology section to enlighten that capitalization means F3411 specifically and uncapitalized is generic.
>> <atw>
>> 
>> 
>> [rfced] We have not made any changes - please let me know if any corrections are needed.
> 
> All "an HHIT" should be changed to "a HHIT", as we always say the "H":  "H HIT" or "H H I T".  As I believe "a" is used for the the letter "H".

As the first H is being read as a letter, “an” is the correct article (i.e., an āCH-hit).  


> I prefer to leave the mixed writing of "authentication message" and "Authentication Message".

Ok - we have not made any changes.



>>  - [rfced] New questions regarding Section 4.5: DRIP Entity Tag (DET) Registry
>> 
>> a) Apologies if I am missing something obvious here, but to what registry does this refer?  This document uses "DET Registry” and Section 4.5 is entitled "DRIP Entity Tag (DET) Registry”.  Section 4.5 references draft-ietf-drip-registries.  I expected draft-ietf-drip-registries to create a DET registry, but it refers back to this document, which creates the "Drone Remote ID Protocol” Registry.  Is it correct that DET Registry refers to the DRIP Registry <https://www.iana.org/assignments/drip/drip.xhtml>?   Can this text be clarified?
> 
> In sec 4.5 the registries for DETs that will be maintained by HDAs is discussed with pointer to drip-registries where the process and some of these registries (public and private) are defined.  This section does not reference any IANA registries.
> 
>> b) Is [DRIP-REG] being referred to here because it defines the registration process?  If so, where are these procedures defined?
> 
> In drip-reg which is not complete and so referencing any sections in it would be problematic.

We have not made any changes.  Is there a registry name or some other way to identify the registry to help the reader?  

Thank you,
RFC Editor/sg