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

[Robert Moskowitz <[e-mail]>]

On 3/17/22 02:36, [e-mail] wrote:
> Standard
>
> Hi Bob,
>
> Thank you.
>
> I suggest to make this change:
>
> ===
>
> OLD :
>
>    *  28-bit Hierarchy ID (HID) which provides the structure to organize
>
>       HITs into administrative domains.  HIDs are further divided into
>
>       two fields:
>
>       -  14-bit Registered Assigning Authority (RAA) (Section 3.3.1)
>
>       -  14-bit Hierarchical HIT Domain Authority (HDA) (Section 3.3.2)
>
> NEW:
>
>    *  28-bit Hierarchy ID (HID) which provides the structure to organize
>
>       HITs into administrative domains.  HIDs are further divided into
>
>       two fields:
>
>       -  14-bit Registered Assigning Authority (RAA) (Section 3.3.1)
>
>       -  14-bit Hierarchical HIT Domain Authority (HDA) (Section 3.3.2)
>
> The rationale for the 14/14 HID split is described in Appendix B.
>
> ===
>

Done. And uploaded to my site.

> The only pending comment is to clean up the text about ICAO in 3.3.1.
>

I don't see me tackling this prior to our session.

> Looking forward seeing that part addressed.
>

Once I have some thoughts on it, we can discuss on the list before edits.

> Cheers,
>
> Med
>
> *De :* Tm-rid <[e-mail]> *De la part de* Robert Moskowitz
> *Envoyé :* mercredi 16 mars 2022 22:06
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>; 
> [e-mail]
> *Objet :* Re: [Drip] missed cutoff time for drip-rid-16 - now -17
>
> Revised ver -17 posted on
>
> http://medon.htt-consult.com/~rgm/ietf/
>
> You are going to have to do diffs yourself with what you previously 
> downloaded...
>
> On 3/16/22 04:00, [e-mail] wrote:
>
>     Hi Bob,
>
>     Please see inline.
>
>     Cheers,
>
>     Med
>
>     *De :* Tm-rid <[e-mail]>
>     <mailto:[e-mail]> *De la part de* Robert Moskowitz
>     *Envoyé :* mercredi 16 mars 2022 01:39
>     *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>     <mailto:[e-mail]>; [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 was leaning this way, but wanted to get other's view.  So it stays out.
>
>
>     *//*
>
>     */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]).
>
>
> Done
>
>
>     *//*
>
>     */(3) We may indicate that entries with network-specific prefixes
>     may be present in the registry./*
>
>     *//*
>
>
> I was thinking about this and how I would say it.  Check out what I 
> added to 9.1
>
>
>     */(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)
>
>
> Done
>
>
>     *//*
>
>           *   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./*
>
>
> I need to regear up with ICAO on GRAIN items which may turn this from 
> an example to actual implementation.  TBD.  Note that ICAO already 
> manages the CTA MFR Code space, but that is not something like DNS.  
> It IS something like needed for RAAs.
>
>
>     *//*
>
>     */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].
>
>
> Done
>
>
>
>
>
>         *   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.
>
>
>
> -- 
> 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
>
> _________________________________________________________________________________________________________________________
>
> 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