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

[Robert Moskowitz <[e-mail]>]

I won't be able to look at this until Wed morning.

But thank you for your work.

On 3/6/23 17:24, Sandy Ginoza wrote:
> 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