Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt

[[e-mail]]

Re-,

Please see inline.

Cheers,
Med

De : Robert Moskowitz <[e-mail]>
Envoyé : vendredi 3 décembre 2021 15:48
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt

Med,

thanks for this.  Much of this is next week.
On 12/3/21 02:33, [e-mail]<mailto:[e-mail]> wrote:

Hi Bob, all,



Thank you for preparing this revised version and integrating most of the comments. Much appreciated.



Please find below some comments about this version:



* The IANA section is still not finalized:

  - RAA assignment guidelines,

I will be talking to ICAO about the RAA assignment guidelines.  There is already much related they are taking on as part of TFSG; it would be great if they ran the RAA assignment and allocation.  (Saulo, another topic for when we meet next week!)
[Med] ACK.



  - follow the template for IPv6 prefix,

What template?
[Med] This one : https://mailarchive.ietf.org/arch/msg/tm-rid/ZMi45WATubihYaJbvOGfdmuZAU8/



  - add explicit links to each registry

Is this the current practice?   Can you point me to an RFC that does this for a model?
[Med] This is part of the Shepherd writeup:

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. *** Confirm that any referenced IANA registries have been clearly identified ***. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).



  - register the context ID at https://www.iana.org/assignments/cga-message-types/cga-message-types.xhtml

Never knew about this one.  7401 and this draft have nothing to do with rfc3972.  7343 is a totally different "CGA" derivation and you could use the same context ID in both and get different answers.  I won't go into the history around CGA; I was rather upset with Ericsson about it at the time.

I look at this as perhaps "common courtesy"; really no technical reason for doing this that I see.
[Med] RFC7343 says the following:

Context ID      : A randomly generated value defining the expected
                   usage context for the particular ORCHID and the
                   hash function to be used for generation of ORCHIDs
                   in this context.  These values are allocated out of
                   the namespace introduced for Cryptographically
                   Generated Addresses (CGA) Type Tags (see RFC 3972<https://datatracker.ietf.org/doc/html/rfc3972> and
                   http://www.iana.org/assignments/cga-message-types).


  - Please consider adding subsections to easily identify each IANA action

  - (very minor) Position the IANA section right after the security considerations section.

* I don't think the document updates RFC8005. The new defined value can be used without requiring any update to 8005. Please fix that.
I can see what you are saying.  Just because you define a new value for a registry, does not mean the base rfc that defines the registry is being updated?  If you are not changing any HOW, only adding more, no update.  OK I will change it.
[Med] Thanks.

  Still need to reference 8005, but it moves to informative?
[Med] I tend to think so, but please check: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/.



* As it is likely that you will have a question about how the document updates 7401 and 7343. I suggest you add a statement in the introduction to explain what is being updated from these specs.

Based on 8005 comment, it is only the HHIT that updates 7401.  All the HIP parameter changes are nothing more than support for the EdDSA algorithm, no logic or format changes.  7343 is getting a major face lift.
[Med] Agree. Please consider adding such text to the introduction and fix the “update” header as appropriate. Also, don’t forget to mention the update(s) in the abstract as well. Thanks.


* "...required for DRIP" under HIP bullet can be misinterpreted as HIP was required for drip, while the intent is HI/HHIT/HID are required in DRIP. I would just delete this mention.

* (minor) There is no mention of "HITv2" in 7401.

No but 7343 updated 4843 and thus the HITs generated were definitely a new version.  This was part of the argument for a different prefix.  So that could be looked as an oversight in 7401 not to name it thusly.  I will look carefully at this.
[Med] Thanks.



* Figure 1 uses RAA/HDA, while these are only introduced in Section 3.3. I would move this introduction text from 3.3 to be positioned right after Figure 1 and consider adding pointers to 3.3.1 (for RAA) and 3.3.2 for (HAD)



==

   The Hierarchy ID (HID) provides the structure to organize HITs into

   administrative domains.  HIDs are further divided into two fields:



   *  16-bit Registered Assigning Authority (RAA)



   *  16-bit Hierarchical HIT Domain Authority (HDA)

==

* The context ID right after Figure 1 is badly linked with the previous text. I suggest to move the following text to, e.g., 3.5.2:



==

   The Context ID for the ORCHID hash is:



       Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40

==



* Some claimed statements should be backed (e.g., 60 - 600M). A reader may ask why this isn't 10-100M or 150-350M?

This was from ICAO GRAIN discussions.  I will have to figure out what and how I can do this.
[Med] Thanks.




* (Sec 6)(nit) Please consider this change:



OLD:

   HHITs might be used within the UTM architecture beyond DET (and USS

   in UA ID registration and authentication).  For example as a GCS HHIT

   ID.

NEW:

   HHITs might be used within the UTM architecture beyond DET (and USS

   in UA ID registration and authentication), e.g., as a GCS HHIT

   ID.

With the RFC editor pulling out so many e.g. from drip-req?   :)
[Med] I’m sure you will get less next time ;-)




* (Sec 9.1)(nit): s/UAD RID (DRIP)/UAS RID (DRIP)

* Please check idnits and fix them when appropriate: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-rid-14.txt

The old ver of idnits was only complaining about Andrei's Swedish uni name.  So I kind of got out of the habit of checking.  My bad, I will look these over for the next ver.
[Med] Thanks.


All, please review this version and share any pending issue you may have.

Got it.  Work for next week.







Cheers,

Med



-----Message d'origine-----

De : Tm-rid <[e-mail]><mailto:[e-mail]> De la part de Robert Moskowitz

Envoyé : jeudi 2 décembre 2021 20:43

À : [e-mail]<mailto:[e-mail]>

Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt



Here is drip-rid-14.  Updated with what I think is most of the comments

from the wglc.



Check out the diff against ver -13.



I added asciii art for the HHIT format.  Thanks Med.



fixed up and clarified that the part of HIP parameters is not really DRIP

related, but rather because DRIP adds a new HI algorithm to 7401, the HIP

parameters affected need to be updated.  And the HIP DNS RR which WILL be

used by DRIP implementations is also updated (updates 8005 and will

require IKE expert review).



IANA section fixes.



And lots of good comments from Med's review.



I fully expect to be putting up a ver -15 before year's end.

Particularly if you all review this one!



thanks.



On 12/2/21 14:33, [e-mail]<mailto:[e-mail]> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts

directories.

This draft is a work item of the Drone Remote ID Protocol WG of the

IETF.



         Title           : DRIP Entity Tag (DET) for Unmanned Aircraft

System Remote Identification (UAS RID)

         Authors         : Robert Moskowitz

                           Stuart W. Card

                           Adam Wiethuechter

                           Andrei Gurtov

    Filename        : draft-ietf-drip-rid-14.txt

    Pages           : 29

    Date            : 2021-12-02



Abstract:

    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).  Within the context of RID,

    HHITs will be called DRIP Entity Tags (DET).  HHITs self-attest to

    the included explicit hierarchy that provides Registrar discovery

for

    3rd-party identifier attestation.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-drip-rid/



There is also an HTML version available at:

https://www.ietf.org/archive/id/draft-ietf-drip-rid-14.html



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-rid-14





Internet-Drafts are also available by rsync at

rsync.ietf.org::internet-drafts







--

Tm-rid mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/tm-rid



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.



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

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.