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

[Robert Moskowitz <[e-mail]>]

Ignore my response to comment 19.  Your change is fine.  It just does 
not reflect in the .txt which is typically all I read.

On 2/27/23 20:33, Robert Moskowitz wrote:
>
>
> 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
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit