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

[Robert Moskowitz <[e-mail]>]

On 2/26/23 18:59, [e-mail] wrote:
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] For readability, we suggest the following update:
>
> Original:
>     This document describes the use of Hierarchical Host Identity Tags
>     (HHITs) as self-asserting IPv6 addresses and thereby a trustable
>     identifier for use as the Unmanned Aircraft System Remote
>     Identification and tracking (UAS RID).
>
> Perhaps:
>     This document describes the use of Hierarchical Host Identity Tags
>     (HHITs) as self-asserting IPv6 addresses, which makes them trustable
>     identifiers for use as an Unmanned Aircraft System Remote
>     Identification (UAS RID) and tracking.
> -->

I agree with this change/improvement.

> 2) <!-- [rfced] Does "This" refer to this document or RFC 9153 (i.e., is
> RFC 9153 the foundational document)?
>
> Original:
>     Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an
>     Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non-
>     spoofable (ID-5), and identify a registry where the ID is listed (ID-
>     2); all within a 19-character identifier (ID-1).
>
>     This DRIP foundational document (i.e., all else in DRIP enables or
>     uses it) describes (per Section 3 of [drip-architecture]) the use of
>     Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting
>     IPv6 addresses and thereby a trustable identifier for use as the UAS
>     Remote ID.
> -->

Yes, this document.  Not 9153.

I am not finding any changes to lessen the confusion.  Perhaps:

This document, foundational to DRIP as all other documents will enable or
    uses it, describes (per Section 3 of [drip-architecture]) the use of

I don't know if this helps.

> 3) <!-- [rfced] May we update this text as follows?  Otherwise, please
> clarify.
>
> Original:
>     HHIT will be used when
>     covering the technology, and DET for their context within UAS RID.
>
> Perhaps:
>     HHIT will be used when
>     covering the technology, and DET will be used in the context of UAS RID.
> -->

Yes.  good change.

> 4) <!-- [rfced] May we replace instances of "Hierarchical HITs" with
> "HHITs" throughout once the abbreviated form has been introduced?
> For example:
>
>     Hierarchical HITs provide ...
>
>     Hierarchical HITs are valid, ...
>
>
>     Hierarchy ID (HID) ...
> -->

Yes please, sloppy of me not to consistently just use HHIT (and HID).


> 5) <!-- [rfced] The closing parentheis is missing.  Please confirm the
> placement of the closing parenthesis.
>
> Original:
>     This contrasts with using general identifiers (e.g., a Universally
>     Unique IDentifiers (UUID) [RFC4122] or device serial numbers as the
>     subject in an X.509 [RFC5280] certificate.  In either case, there can
>     be no unique proof of ownership/registration.
>
> Current:
>     This contrasts with using general identifiers (e.g., a Universally
>     Unique IDentifiers (UUID) [RFC4122]) or device serial numbers as the
>     subject in an X.509 [RFC5280] certificate.  In either case, there can
>     be no unique proof of ownership/registration.
> -->

Ending paren after "serial numbers".

    Unique IDentifiers (UUID) [RFC4122] or device serial numbers) as the


> 6) <!-- [rfced] For readability, we recommend the following update.
>
> Original:
>     The document includes a set of algorithms with a guidance on the ones
>     that are recommended to be supported by implementations.
>
> Suggested:
>     The document includes a set of algorithms and recommends the ones
>     that should be supported by implementations.
> -->

Yes, please change.

> 7) <!-- [rfced] The XML file includes author comments.  We have added
> [author] to these comments to clearly differentiate them from questions
> inserted by the RFC Production Center.  Please review and let us know if
> any updates are needed; otherwise, these will be deleted.
> -->

All these [author] comments were left in as placeholders for content 
moved elsewhere.  They can all be deleted now.

> 8) <!-- [rfced] Does this text mean the protocol upon which HI, HIT and
> HHIT are based?  If this is correct, perhpas the reference should appear
> after "Host Identity Protocol (HIP)"?
>
> Original:
>     HIP (Host Identity Protocol)
>        The origin [RFC7401] of HI, HIT, and HHIT.
>
> Perhaps:
>    Host Identity Protocol (HIP) [RFC7401]:
>       The origin of HI, HIT, and HHIT.
> -->

Yes.  better.

> 9) <!-- [rfced] Please review instances of <artwork> in the XML and let us
> know if any should instead be <sourcecode>.  If <sourcecode, please
> consider wheter the "type" attribute should be set (see https://www.rfc-editor.org/materials/sourcecode-types.txt).
> If the list does not contain an applicable type, then feel free to let us
> know. Also, it is acceptable to leave the "type" attribute not
> set.
> -->

there is no sourcecode in the document.  It is acceptable to not set the 
"type" attribute.


> 10) <!-- [rfced] For clarity, we suggest not using "4/8-bit". Does this
> mean, "4 and 8 bit"?  May we update this text as follows?
>
> Original:
>     These are a
>     superset of the 4/8-bit HIT Suite ID as defined in Section 5.2.10 of
>     [RFC7401].
>
> Perhaps:
>     These are a
>     superset of the 4-bit and 8-bit HIT Suite IDs as defined in Section
>     5.2.10 of [RFC7401].
> -->

Yes.  That was the intent.

> 11) <!-- [rfced] For readability, please consider whether this update
> correctly conveys the intended meaning.
>
> Original:
>     The rationale for the 14/14 HID split is described in Appendix B.
>
> Perhaps:
>     The rationale for splitting the HID into two 14-bit domains is
>     described in Appendix B.
> -->

good change.  thanks.

> 12) <!-- [rfced] Will "zone tree" be clear for the reader?  In addition,
> is "in the actual zone tree" correct (as opposed to, for example,
> "regarding the actual zone tree" )?
>
> Original:
>     Thus
>     further thought will be needed in the actual zone tree and
>     registration process [drip-registries].
> -->

I think if we can improve clarity by saying:

actual DNS zone tree

> 13) <!-- [rfced] May we update this to specify that the EdDSA HI uses the
> value assigned per [ipseckey-eddsa] for IPSECKEY RR encoding?
>
> Original:
>     The new EdDSA HI uses [ipseckey-eddsa] for the IPSECKEY RR encoding.
>
> Suggested:
>     The new EdDSA HI uses value assigned per [ipseckey-eddsa] for IPSECKEY
>     RR encoding.
> -->

It is more than the value.  It is also how the public key is encoded.  
Perhaps

The 'Algorithm Type' value and EdDSA HI encoding are assigned per 
[ipseckey-eddsa].

> 14) <!-- [rfced] Is NIST SP 800-185 the reference for cSHAKE?  May we
> update text as follows?
>
> Original:
>     *  Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing
>        function.
>
> Perhaps:
>     *  the use of cSHAKE [NIST.SP.800-185] for the hashing
>        function.
> -->

Yes, cSHAKE is defined in 800-185.  Much easier read.  thanks.

> 15) <!-- [rfced] We have updated [TBC_DRIP_REGISTRY] to point to the
> "Hierarchical HIT (HHIT) Suite ID" registry <https://www.iana.org/assignments/drip> and added an informative reference.  Please review and
> let us know if any updates are needed.
>
> Original:
>                       ...  When used for HHIT generation this is
>                       the HHIT Suite ID [TBC_DRIP_REGISTRY].
>
>             Note to the RFC Editor: Please replace [TBC_DRIP_REGISTRY]
>                 with the pointer to the IANA registry created in
>                 Section 8.2.
>
> -->

thank you.

> 16) <!-- [rfced] In section 3.5.1, is this formatting update correct?
> Is this line intended to appear as part of the definition list?  We have
> currently formatted it as a separate item (i.e., not part of the list).
> Please review.
>
> Original:
>     Sizeof(p + n + o + m) 128 bits
> -->

The formatting change of the definition list is fine.  The Sizeof 
function is not part of the list.  In fact it looks like = is missing:

Sizeof(p + n + o + m) = 128 bits

> 17) <!-- [rfced] It is not clear to us what "call for this update" means.
> Please review.  follows?
>
> Original:
>     The cSHAKE function call for this update is:
>
> Perhaps:
>     The update for this cSHAKE function is as follows:
> -->

Change is not correct understanding.  "update" refers to the beginning 
"update" in this section.

Perhaps

The cSHAKE function call is:

> 18) <!-- [rfced] Please confirm that 'UAS ID type 4, "Specific Session ID
> (SSI)"' is not an IANA-registered value.  In addition, we are unable to
> verify SSI 1 and SSI 2.  We do not see  related actions in the IANA
> Considerations section, and we are unable to access [F3411-22a]
> (https://www.astm.org/f3411-22a.html)?  Please review and let us know if
> any updates are needed.
>
> Original:
>     The ASTM Standard Specification for Remote ID and Tracking
>     [F3411-22a] adds support for DETs.  This is only available via the
>     new UAS ID type 4, "Specific Session ID (SSI)".
>
>     ...
>
>     SSI 1  IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.
>
>     SSI 2  3GPP - IEEE 1609.2-2016 HashedID8
> -->

The intention is that SSI is maintained outside of IETF.  It is part of 
the ASTM F3411-22a document and negotiations are in place for the ICAO 
to manage this registry along with the CTA manufacturer registry also 
used in F3411-22a.

This registry is still not in place.  So we are including the values 
here that are currently defined for clarification.

> 19) <!-- [rfced] Note that we updated the link for Section 5 to go
> directly to this line of <artwork>.  Please let us know if any corrections
> are needed.
>
> Section 5:
>     2001:30:280:1405:a3ad:1952:ad0:a69e
>
> Section 4.2:
> Original:
>     Using the sample DET from Section 5 that is for HDA=20 under RAA=10
>     and having the ICAO CTA MFR Code of 8653, the 20-character CTA 2063-A
>     Serial Number would be:
>
>         8653F02T7B8RA85D19LX
> -->

I only see this link in the html, but not in the txt.  Should it also 
show in the txt ver?

Otherwise, thanks for linking.

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

> 21) <!-- [rfced] Please review the questions below regarding this text:
>
> Original:
>     There are two approaches for storing and retrieving DETs using DNS.
>     The following are examples of how this may be done.  This will serve
>     as guidance to the actual deployment of DETs in DNS.  However, this
>     document does not provide a recommendation.  Further DNS-related
>     considerations are covered in [drip-registries].
>
>     *  As FQDNs, for example, "20010030.hhit.arpa.".
>
>     *  Reverse DNS lookups as IPv6 addresses per [RFC8005].
>
> a) Please confirm that these are examples, and not the two approaches.
>
> b) For clarity, may we update the text to read:
>
>     However, this document does not provide a recommendation about which
>     approach to use.
> -->

These are examples.  Final form will be in drip-registries or 
appropriate document.

Yes, the added text really helps here.


> 22) <!-- [rfced] Is the HDA providing HHIT with a detailed response or
> should this read "the detailed HHIT response"?  Please review.
>
> Original:
>     The HDA SHOULD provide DNS service for its zone and provide the HHIT
>     detail response.
> -->

the HDA is an entity as well as a field.  Or rather, the HDA field is 
the tag to reference the HDA entity.  See definition of HDA in sec 2.3.  
Maybe in this usage it should not be abbreviated?

The HHIT Domain Authority (HDA) SHOULD provide DNS service

> 23) <!-- [rfced] Does "could be to" mean "result in"?  Are the two periods
> intentional?
>
>     A DET reverse lookup could be to:
>
>         a69e.0ad0.1952.a3ad.1405.0280.20.10.20010030.hhit.arpa..
> -->

Just remove "to"

A DET reverse lookup could be:

Also it looks like there is an extra period at the end of that FQDN.  
Just .arpa.

> 24) <!-- [rfced] Section 8.1: Please note that we updated the registration
> entry to match what appears in the IANA registry.  Please let us know if
> any updates are needed.
> -->

Yes, that came up during the IANA review, but we did not update the 
draft to reflect those corrections.

Should 8.1 have a reference to

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

?

Looks like I left that out whereas 8.2, 8.3, and 8.4 do have references 
to the proper IANA url.

> 25) <!-- [rfced] Section 8.2 seems to create the "Drone Remote ID Protocol"
> group of registries, which contains the "Hierarchical HIT (HHIT) Prefixes"
> and "Hierarchical HIT (HHIT) Suite ID" registries.  Is it correct that the text about expert review only applies to "Hierarchical HIT (HHIT)
> Prefixes", as the registration procedure for "Hierarchical HIT (HHIT) Suite
> ID" is IETF Review?
>
> If this is correct, may we move the text describing criteria for the
> designated expert to appear after the table 8, to make it more clear that
> it applies to the "Hierarchical HIT (HHIT) Prefixes" registry?  Would it be
> helpful to divide 8.2 into the following sections:
>
> 8.2.1.  Hierarchical HIT (HHIT) Prefixes
> 8.2.2.  Hierarchical HIT (HHIT) Suite IDs
>
> Note that we have removed this sentence entirely, as we believe it is
> common practice for IANA to have at least two experts for a given registry.
> Please let us know if you prefer otherwise.
>
> Original:
>          It is suggested that multiple
> 	designated experts be appointed for registry change requests.
> -->

Yes, expert review applies to the prefixes only.  Lots of discussions 
about that.  And SuiteIDs will follow standard IETF review.  Thus the 
change you recommend for 8.2.1 and 8.2.2 is is good.  And can drop "two 
experts" sentence.  That text was a copy/paste.

> 26) <!-- [rfced] Section 8.2: Should the title for "Hierarchical HIT (HHIT)
> Suite ID" be plural (i.e., "Hierarchical a HIT (HHIT) Suite IDs")?
> -->

Yes.

> 27) <!-- [rfced] Section 8.2: <https://www.iana.org/assignments/drip> lists
> this document as the refernece for value 0 (Reserved).  We have updated the
> table to match.  We note that the "HIT Suite ID" references RFC 7401 for
> value 0 (Reserved), but this seems ok since it is outside of the 1-31
> range.
>
> In addition, please note that the "HIT Suite ID" registry seems to have
> values 1-15, but the text below indicates values 1-31 should match "HIT
> Suite IDs" registrations.
>
> Please review and let usk now if any updates are needed.
>
> Original:
>          HHIT Suite          Value    Reference
>          RESERVED            0
>
>     ...
>
>        The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
>        replicated as HIT Suite IDs (Section 8.4) as is TBD3 here.
>
> Note that similar text appaers in Section 8.4:
>
> Original:
>        The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
>        MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.
>
> -->	

This has to do with the 4-bit/8-bit field for HIT suite ID in 7401. 
After a lot of debate, we worked out this 1-31 compared to 1-15 mess.  
HHIT Suite IDs 16-31 thus have to also be in the 8-bit format of HIT 
Suite IDs.

> 28) <!-- [rfced] Should this document be listed as a reference for the full
> "CGA Extension Type Tags" registry, or just the entry for "0x00B5 A69C 795D
> F5D5 F008 7F56 843F 2C40"?  If both, perhaps:
>
> Original:
>     This document requests that this document be added to the reference
>     field for the "CGA Extension Type Tags" registry [IANA-CGA], where
>     IANA registers the following Context ID:
>
> Perhaps:
>     This document has been added as a reference for the
>     "CGA Extension Type Tags" registry [IANA-CGA].  IANA has registered the
>     following Context ID in this registry:
> -->

This change does seem to reflect the action that IANA needed to take.

> 29) <!-- [rfced] Section 8.3: We converted the registration text into a
> table for clarity and to better align with what appears in the IANA
> registry..  Please let us know this causes any concern.
>
> Original:
>        Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40  [This]
>
> Current:
>           +===========================================+===========+
>           | CGA Type Tag                              | Reference |
>           +===========================================+===========+
>           | 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 | RFC 9374  |
> -->

Thank you, yes.

> 30) <!-- [rfced] We are having trouble parsing "studies of hash size to
> cryptographic hash attacks".  Does this mean "studies of hash size in
> relation to cryptographic hash attacks"?
>
> Original:
>     There are no known (to the
>     authors) studies of hash size to cryptographic hash attacks.
> -->


No.  The crypto reviewers all knew what was meant here, but...

There are no known (to the authors) studies of hash size impact on 
cryptographic hash attacks.

I think that will pass muster with the cryptographers.

> 31) <!-- [rfced] What is being signed - the object or the HHIT?
>
> Original:
>     Another mitigation of HHIT hijacking is if the HI owner (UA) supplies
>     an object containing the HHIT and signed by the HI private key of the
>     HDA such as detailed in [drip-authentication].
>
> Perhaps:
>     Another mitigation of HHIT hijacking is when the HI owner (UA) supplies
>     an object containing the HHIT that is signed by the HI private key of
>     the HDA as detailed in [drip-authentication].
> -->

Better English.  Thanks.

> 32) <!-- [rfced] For readability, please consider whether the suggested
> text correctly conveys the intended meaning.
>
> Original:
>     Collision
>     resistance (more important that it implied second-preimage
>     resistance) makes it statistically challenging to attacks.
>
> Perhaps:
>     Collision
>     resistance (and more importantly, the implied second-preimage
>     resistance) makes attacks statistically challenging.
> -->

Oh boy, good catch; that goes back to ver -08!  I believe the change 
reads better.

> 33) <!-- [rfced] To avoid awkward hyphenation and for clarity, may we
> update this sentence as follows?
>
> Original:
>     HHITs contain the ID for the cryptographic suite used in its
>     creation, a future post quantum computing safe algorithm that fits
>     the Remote ID constraints may readily be added.
>
> Suggested:
>     HHITs contain the ID for the cryptographic suite used in its
>     creation, a future algorithm that is safe for post-quantum computing
>     that fits the Remote ID constraints may readily be added.
> -->

OK.

> 34) <!-- [rfced] May we update this sentence for readability?
>
> Original:
>     The best that
>     might be done within this Basic ID Message is 4 bytes truncated from
>     a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is
>     16).
>
> Suggested:
>     Truncating 4 bytes from a HI signing of the HHIT (the UA ID field is
>     20 bytes and a HHIT is 16) within this Basic ID Message is the best
>     that can be done.
> -->

OK

> 35) <!-- [rfced] We are having trouble parsing this sentence.  Does "the
> observer can see the UA or that information is validated" mean that the
> "observer can see that the UA or the information in question is validated"?
> Please clarify.
>
> Original:
>     Proof of UA transmission comes when the Authentication Message
>     includes proofs for the ASTM Location/Vector Message (Msg Type 0x1)
>     and the observer can see the UA or that information is validated by
>     ground multilateration.
> -->

A UA broadcasts its location.  And the observer can even authenticate 
the message came from a UA with a specific DET.  Is it really at that 
location?  What is the proof?

The observer "sees" a UA at that location.
ground multilateration of the broadcast messages compute the same 
location as the validated location broadcast.

Now how do you say this without a paragraph or two?  Well there is the 
prior para to set the stage.

Proof of a specific UA as the source of a transmission comes when...

> 36) <!-- [rfced] Please confirm that MAC refers to Media Access Control.
> For example:
>
>     Further, the MAC address of the wireless interface used for Remote ID
>     broadcasts are a target for UA operation aggregation that may not be
>     mitigated through MAC address randomization.
> -->

Yes.  The Media Access Control address.

> 37) <!-- [rfced] Is "historically tracking" correct? We wonder if "tracking
> the history of the UA's activity" is meant?
>
> Original:
>     Finally, it is not adequate to simply change the DET and MAC for a UA
>     per operation to defeat historically tracking a UA's activity.
> -->

Yes  better.

> 38) <!-- [rfced] Please consider whether the suggested update improves
> readability and maintains the intended meaning.
>
> Original:
>     UA/GCS binding is complicated with changing MAC addresses;
>     historically UAS design assumed these to be "forever" and made setup
>     a one-time process.
>
> Perhaps:
>     UA/GCS binding is complicated because of the changing MAC addresses;
>     historically, UAS design assumed the ddresses to be static "forever"
>     and made setup a one-time process.
> -->

UA/GCS binding is complicated if the UA MAC address can change;
    historically, UAS design assumed these to be "forever" and made setup
    a one-time process.

> 39) <!-- [rfced] Does "changing the DET" trigger other changes, or it is the beginning of a set of changes?
>
> Original:
>     Simply changing the DET
>     only starts the changes that need to be implemented.
>
> Perhaps:
>     Changing the DET is only the start of
>     the changes that need to be implemented.
> -->

OK.

> 40) <!-- [rfced] Does "(or similar behaving)" mean "(or a similar
> purpose)"?  And, please consider whether "will take years of deployment
> experience" should be "deployment experience will take years".
>
> Original:
>     Perhaps a single RAA providing HDAs for delivery service (or similar
>     behaving) UAS could 'get by' with a 2048 HDA space (11-bits).  ...
>     But as this is speculation, and it will take years
>     of deployment experience, a 14-bit HDA space has been selected.
>
> Perhaps:
>     Perhaps a single RAA providing HDAs for delivery service (or a similar
>     purpose) UAS could 'get by' with a 2048 HDA space (11-bits).  ...
>     However, as this is speculation and deployment experience will take
>     years, a 14-bit HDA space has been selected.
> -->

"similar purpose" is fine and perhaps better generic.
and "deployment experience will take years" is better English.

thanks.

> 41) <!-- [rfced] We are having trouble parsing this sentence.  Please consider whether the suggested update conveys the intended meaning.  Otherwise, please clarify.
>
> Original:
>     The HDA space is large enough that some to use part for
>     government needs as stated above and for small commercial needs.  Or
>     the State may use a separate, consecutive RAA for commercial users.
>
> Perhaps:
>     The HDA space is large enough that a portion may be used for
>     government needs as stated above and small commercial needs.
>     Alternatively, the State may use a separate, consecutive RAA for
>     commercial users.
> -->


I wrote that?  :)
Must have been half-asleep!

Much better wording.

> 42) <!-- [rfced] Will "nibbled fields" be commonly understood by readers?
>
> Original:
>     The DET upper 64 bits appear to be oddly constructed from nibbled
>     fields, when typically seen in 8-bit representations.
> -->

"nibbled fields" is a common enough item in IETF protocol designs. A 
nibble is 4 bits; half a byte!

A reader without protocol design familiarity would google it.


> 43) <!-- [rfced] Does "leaving remaining RAA and HDA combined to" mean
> "which leaves the remaining RAA and HDA to combine to"?
>
> Original:
>     The left most 4 bits of the RAA, all zeros, combine with the prefix
>     to form 2001:0030:, leaving remaining RAA and HDA combined to:
> -->

Yes.

> 44) <!-- [rfced] Does "does not lend to using" mean "is not well suited for
> using"?
>
> Original:
>     The alphabet used in CTA 2063-A Serial Number does not lend to using
>     any published Base32 encoding scheme.
> -->

hmm.  there are no known published Base32 encoding schemes that can work 
with the alphabet used in 2063-A.  Perhaps.

The alphabet used in CTA 2063-A Serial Number does not map to
    any published Base32 encoding scheme.

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

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


> Thank you.
>
> RFC Editor

And thank you!

I assume we will be going another round with these edits.

Bob