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

From: [email-masked]
Date: Thu, 02 Dec 2021 11:33:34 -0800

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Dec 2021 14:42:54 -0500

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.

---

From: <[email-masked]>
Date: Fri, 3 Dec 2021 07:33:58 +0000

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,
  - follow the template for IPv6 prefix, 
  - add explicit links to each registry 
  - register the context ID at https://www.iana.org/assignments/cga-message-types/cga-message-types.xhtml
  - 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. 
* 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. 
* "...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.
* 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?
* (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.

* (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

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

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid <[email-masked]> De la part de Robert Moskowitz
> Envoyé : jeudi 2 décembre 2021 20:43
> À : [email-masked]
> Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt
> 
> 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.
> 
> --
> Tm-rid mailing list
> [email-masked]
> 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.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Dec 2021 09:48:28 -0500

Med,

thanks for this.  Much of this is next week.

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

>    - follow the template for IPv6 prefix,

What template?

>    - add explicit links to each registry

Is this the current practice?   Can you point me to an RFC that does 
this for a model?

>    - register the context ID athttps://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.

> * 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.  Still need to reference 8005, but it 
moves to informative?

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

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

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

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

With the RFC editor pulling out so many e.g. from drip-req?   :)

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

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

Got it.  Work for next week.

>> De : Tm-rid<[email-masked]>  De la part de Robert Moskowitz
>> À :[email-masked]
>> On 12/2/21 14:33,[email-masked]  wrote:

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

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

---

From: <[email-masked]>
Date: Fri, 3 Dec 2021 15:07:02 +0000

Re-,

Please see inline.

Cheers,
Med

De : Robert Moskowitz <[email-masked]>
Envoyé : vendredi 3 décembre 2021 15:48
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
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, [email-masked]<mailto:[email-masked]> wrote:

Hi Bob, all,

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.

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

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

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

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

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.

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.

==

==

==

==

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

OLD:

   ID.

NEW:

   ID.

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

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.

Cheers,

Med

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

De : Tm-rid <[email-masked]><mailto:[email-masked]> De la part de Robert Moskowitz

À : [email-masked]<mailto:[email-masked]>

from the wglc.

IANA section fixes.

thanks.

On 12/2/21 14:33, [email-masked]<mailto:[email-masked]> 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)

                           Stuart W. Card

                           Adam Wiethuechter

                           Andrei Gurtov

    Pages           : 29

    Date            : 2021-12-02

Abstract:

    the included explicit hierarchy that provides Registrar discovery

for

Internet-Drafts are also available by rsync at

rsync.ietf.org::internet-drafts

--

Tm-rid mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

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

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

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 7 Dec 2021 13:26:58 -0500

Partial response.

On 12/3/21 10:07, [email-masked] wrote:
> Standard
>
> Re-,
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :* Robert Moskowitz <[email-masked]>
> *Envoyé :* vendredi 3 décembre 2021 15:48
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 
> [email-masked]
> *Objet :* Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt
>
> Med,
>
> 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./*
>
> */[Med] This one : 
> /**/https://mailarchive.ietf.org/arch/msg/tm-rid/ZMi45WATubihYaJbvOGfdmuZAU8/ 
> <https://mailarchive.ietf.org/arch/msg/tm-rid/ZMi45WATubihYaJbvOGfdmuZAU8/>/**//*
>

Ok.  working on this.

> */[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).
>

I looked at some recent RFCs and did not see any that had a registry 
URL.  It does seem like my IANA considerations section may follow an old 
style. Can you point me to some recent examples to steal xml from?

>       - register the context ID at
>     https://www.iana.org/assignments/cga-message-types/cga-message-types.xhtml  <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.
>
> */[Med] RFC7343 says the following: /*
>
> *//*
>
>                    Generated Addresses (CGA) Type Tags (see RFC 3972 
> <https://datatracker.ietf.org/doc/html/rfc3972>and
>
> http://www.iana.org/assignments/cga-message-types 
> <http://www.iana.org/assignments/cga-message-types>).
>

My grey matter is greying...  I have fixed this.

>       - Please consider adding subsections to easily identify each

So hanging lists that I did is no longer the recommended style? Seems 
kind of excessive for what little I have in IANA considerations, 
pointing to the main text in appropriate sections. But I can redo.

Time to head for my gate.  I will resume for here this evening.

> update.  OK I will change it.
>
> */[Med] Thanks. /*
>
> *//*
>
> */[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.
>
>
> */[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. /*
>
> 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./*
>
> */[Med] Thanks. /*
> */[Med] I’m sure you will get less next time ;-)/*
>
> */[Med] Thanks. /*
>         De : Tm-rid<[email-masked]>  <mailto:[email-masked]>  De la part de Robert Moskowitz
>
> E: [email-masked]
>

---

From: <[email-masked]>
Date: Wed, 8 Dec 2021 07:21:49 +0000

Hi Bob,

Please see inline.

Cheers,
Med

De : Tm-rid <[email-masked]> De la part de Robert Moskowitz
Envoyé : mardi 7 décembre 2021 19:27
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt

Partial response.
On 12/3/21 10:07, [email-masked]<mailto:[email-masked]> wrote:
Re-,

Please see inline.

Cheers,
Med

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

Med,

Hi Bob, all,

What template?

Ok.  working on this.

[Med] Thanks.

I looked at some recent RFCs and did not see any that had a registry URL.  It does seem like my IANA considerations section may follow an old style. Can you point me to some recent examples to steal xml from?
[Med] See, e.g., rfc9100.html#name-iana-considerations or rfc9132.html#name-well-known-dots-uri.

So hanging lists that I did is no longer the recommended style?  Seems kind of excessive for what little I have in IANA considerations, pointing to the main text in appropriate sections.  But I can redo.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Dec 2021 09:37:13 -0500

Progess...

On 12/8/21 02:21, [email-masked] wrote:
> Standard
>
> Hi Bob,
>
> Please see inline.
>
> Cheers,
>
> Med
>
> *De :* Tm-rid <[email-masked]> *De la part de* Robert Moskowitz
> *Envoyé :* mardi 7 décembre 2021 19:27
>     <mailto:[email-masked]>
>     *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     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./*
>
>       
>
>     <https://mailarchive.ietf.org/arch/msg/tm-rid/ZMi45WATubihYaJbvOGfdmuZAU8/>/*
>
>
> Ok.  working on this.
>
> */[Med] Thanks. /*
>

Done.

>     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).
>
>
> URL.  It does seem like my IANA considerations section may follow an 
> old style. Can you point me to some recent examples to steal xml from?
>
> */[Med] See, e.g., rfc9100.html#name-iana-considerations or 
> rfc9132.html#name-well-known-dots-uri./*
>

Ah,,, I read 9100 yesterday in the Delta club, waiting for my flight and 
did not see the urls.  This time I searched for "http" and see how it is 
done in 9100.  It will take a little bit, but I think I can hack 
something together.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Dec 2021 10:38:01 -0500

Picking up from where I left off.

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

<surprise>  Seems I always had/saw IANA before security. Wonder when 
this changed.

I mean all my xml have it in this order!  But not hard to change.

But this is will probably totally mess up rfcdiff that seems to not 
handle section rearranging well if at all.

Done.

> mention the update(s) in the abstract as well. Thanks. /*

Done.  Well some text added...

> thusly.  I will look carefully at this.

r/HITv2/HIPv2/

> This was from ICAO GRAIN discussions.  I will have to figure out what 

For now I am leaving the DET format unchanged.  I am writing a section 
that RAA registration will be done by ICAO.  Saulo and I are discussing 
how to do this.

> */[Med] I’m sure you will get less next time ;-)/*

I say "for example" rather than "i.e." a lot of times in the draft. I am 
going to leave this unless you really want me to make this change.  I 
would rather get instructions from the RFC Editor what form they want.

> look these over for the next ver.

Done. I think I have it.  We will see when I submit this time.

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

Now to do the RAA registration.  Then run rfcdiff on my working copy...

---

From: <[email-masked]>
Date: Wed, 8 Dec 2021 15:59:44 +0000

Re-,

Please see inline.

Cheers,
Med

De : Robert Moskowitz <[email-masked]>
Envoyé : mercredi 8 décembre 2021 16:38
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [Drip] I-D Action: draft-ietf-drip-rid-14.txt

Please see inline.

Cheers,
Med

<surprise>  Seems I always had/saw IANA before security.  Wonder when this changed.
[Med] :-)

[Med] Thank you.

But this is will probably totally mess up rfcdiff that seems to not handle section rearranging well if at all.
[Med] This is not an issue. This is adequately tracked in both side-by-side and wdiff diff types.

Done.

r/HITv2/HIPv2/
[Med] OK. Please note that there are other occurrences in the draft.

==

==

==

==

For now I am leaving the DET format unchanged.  I am writing a section that RAA registration will be done by ICAO.  Saulo and I are discussing how to do this.
[Med] We need a formal procedure for this to be recorded in the draft. You may consider, for example:

  *   When the IANA-assigned prefix is used, then RAAs are registered within IANA based on an Expert Review. ICAO can make an official request to be delegated blocks of RAAs that it can then assign individually. If you go this path, then you will need to add some guidelines to perform the Design Expert review (e.g., max size of an RAA block that can be assigned). You may also consider whether an FCFS range can be defined.
  *   If a specific prefix is used, RAA assignments are made by the owner of that prefix.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Dec 2021 11:11:22 -0500

On 12/8/21 10:59, [email-masked] wrote:
> *Envoyé :* mercredi 8 décembre 2021 16:38
> */[Med] :-) /*
> */[Med] Thank you. /*
> */[Med] This is not an issue. This is adequately tracked in both 
> side-by-side and wdiff diff types. /*
>
>
>
>
>     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. /*
>
>     *//*
>
>     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. /*
>
>
>     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./*
>
>
> r/HITv2/HIPv2/
>
> */[Med] OK. Please note that there are other occurrences in the draft. /*
>

I changed them all.

> that RAA registration will be done by ICAO.  Saulo and I are 
> discussing how to do this.
>
> */[Med] We need a formal procedure for this to be recorded in the 
> draft. You may consider, for example:/*
>
>   * */When the IANA-assigned prefix is used, then RAAs are registered
>     within IANA based on an Expert Review. ICAO can make an official
>     request to be delegated blocks of RAAs that it can then assign
>     individually. If you go this path, then you will need to add some
>     guidelines to perform the Design Expert review (e.g., max size of
>     an RAA block that can be assigned). You may also consider whether
>     an FCFS range can be defined. /*
>   * */If a specific prefix is used, RAA assignments are made by the
>     owner of that prefix. /*
>

No.  For IANA to take this on, it would be more than they do for 
Enterprise Numbers:

https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

Saulo and I discussed this that part of the registration is creating and 
delegating the RAA DNS zone, something like:

#.raa.uas.icao.int.

And that uas.icao.int. is DNSSEC signed.

The experts will be working with ICAO.

Your point on the address assignment is valid and I have to think about 
that.  That may impact the:

#.det.arpa.

delegation in sec 5, which probably also needs more work.  Who manages 
.arpa. ?  Who would manage this .det.arpa. ?  ICAO again?

I REALLY would like list discussion on the DNS parts of the draft.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 8 Dec 2021 11:28:18 -0500

> side-by-side and wdiff diff types.

I just tried this.  If I switch IANA and Security sections, you loose 
all the change tracking within those sections.  Thus for 'good' review, 
I am not switching them this time around.  Now there are no changes to 
Security, but substantial to IANA and I think seeing the in diff will help.

There will be further changes.  Sigh.  So there will be later chances to 
switch these sections.