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

[Robert Moskowitz <[e-mail]>]

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

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