Re: [Drip] missed cutoff time for drip-rid-16

[[e-mail]]

Hi Bob,

Please see inline.

Cheers,
Med

De : Tm-rid <[e-mail]> De la part de Robert Moskowitz
Envoyé : mercredi 16 mars 2022 01:39
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>; [e-mail]
Objet : Re: [Drip] missed cutoff time for drip-rid-16


On 3/9/22 02:47, [e-mail]<mailto:[e-mail]> wrote:

Hi Bob,



Thank you for preparing and sharing this version. The changes look great.



The following comments are not addressed yet:



  *   Add a provision for the use of other prefixes + Define a new registry to list prefixes used for DET purposes.

Done, I think.  Should this registry include the HIT prefix in rfc7343?
[Med] I don’t think we need to add that prefix to the list.

I suggest to make these changes to your proposed text:

(1)

OLD:
   This document requests IANA to make a new registry for DRIP with
   initially two entries.

NEW:
   This document requests IANA to create a new registry titled
   “Drone Remote Identification Protocol” registry. The following
   two subregistries should be created under that registry.

(2)

OLD:
Future additions to this subregistry MUST be approved by the DRIP protocol expert(s).

NEW:

Future additions to this subregistry are to be made through Expert Review (Section 4.5 of [RFC8126]).

(3) We may indicate that entries with network-specific prefixes may be present in the registry.

(4)



  *   Add an appendix to explain the rationale for the 14|14 HID split

New sec 3.3.3.  I can move it to an appendix...
[Med] Please do so. Thanks. BTW, please make this change in Section 3:

OLD:
      -  16-bit Registered Assigning Authority (RAA) (Section 3.3.1)

      -  16-bit Hierarchical HIT Domain Authority (HDA) (Section 3.3.2)

NEW:
      -  14-bit Registered Assigning Authority (RAA) (Section 3.3.1)

      -  14-bit Hierarchical HIT Domain Authority (HDA) (Section 3.3.2)



  *   Tweak Section 5 so that this is presented as an example + add a mention that further DNS-related considerations will be covered in the registries draft (no normative text, please).

I think I have this done.
[Med] Looks good to me. Even if ICAO is still mentioned there, it is clear that this is just an example, not a recommendation. I suspect that we will be asked to follow RFC6761, but I don’t have an objection to maintain your current text.

Please fix this nit:

OLD:
Further DNS-related considerations will are covered in [drip-registries].

NEW:
Further DNS-related considerations are covered in [drip-registries].



  *   Consequently, remove the mentions of ICAO from the draft, especially from:

     *   Section 3.3.1: RAA assignment

     *   Section 5: DNS

I will leave this for a later iteration.  I actually put more in about ICAO.  I will need to change this somehow to the "organization best suited manage the HID space".  Or some such.
[Med] Looking forward seeing this addressed.



  *   Leave the answer to “whether we want to (1) abandon the control on the RAA assignment bound to the IANA-assigned prefix or (2) keep the full control but have a provision for some delegation” to the registries draft. Add a sentence that basically says that. From an interop standpoint, this is fine as a DET is unambiguously identified by the prefix part.

TBD next iteration.
[Med] ACK.




Also, most of the comments in https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-15-rev%20Med.pdf are not addressed.

[Med] Thanks.

_________________________________________________________________________________________________________________________

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.