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

[Robert Moskowitz <[e-mail]>]

Perhaps today.  I have to work on ASTM as well.

Oops on that copy and paste with '16'.   ;)

On 3/16/22 04:00, [e-mail] wrote:
> Standard
>
> 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] 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 inhttps://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.
>

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