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

[Robert Moskowitz <[e-mail]>]

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.

These terms are derived from RATS Arch, rfc9334.  claim, evidence, and 
endorsement are defined there, but they are general in terms of what is 
making them.  My adding "self" clears this up and the RATS people who 
have reviewed this draft have not that the "self" addition is not 
needed.  It does clear up some usages of RATS terms here.

Readers may well have to go to 9334 for these terms to get the full 
understanding, but some will just see it and move on.

>>
>>>
>>>>> 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.

I don't think any compiler would throw an error parsing this so leave 
it.  I was only commenting on the rules that I learned some 65 years 
ago...  :)


>
>>
>>>
>>>>> 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).

OK.  I bow to your expertise in this matter of language!

>
>
>> 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?

Unfortunately, not yet.  drip-registries needs another round of updates 
(in the works) before we get to that point.

I do worry, a little, about multiple uses of terms, but often it is just 
how it is.


>
> Thank you,
> RFC Editor/sg

And thank you.

Bob