Re: [Drip] DET Control and interop (was RE: I-D Action: draft-ietf-drip-rid-14.txt)

[[e-mail]]

Hi all,

Thank you all for sharing your inputs.

What I’m hearing from the discussion so far is as follows:

  *   Maintain the request for /28 prefix
  *   Add a provision for the use of other prefixes + Define a new registry to list prefixes used for DET purposes.
  *   The RID structure is the same for all prefixes (Figure 1) but with these changes:
     *   HID to be 28 bits
     *   HSI to be 8 bits
     *   Add an appendix to explain the rationale for 14|14 HID split
  *   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).
  *   Consequently, remove the mentions of ICAO from the draft, especially from:
     *   Section 3.3.1: RAA assignment
     *   Section 5: DNS
  *   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. From an interop standpoint, this is fine as a DET is unambiguously identified by the prefix part.

Unless there are objections, I kindly invite the authors to update the draft accordingly. Thank you.

Cheers,
Med

De : Robert Moskowitz <[e-mail]>
Envoyé : lundi 13 décembre 2021 18:52
À : Card, Stu <[e-mail]>
Cc : [e-mail]; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Objet : Re: [Drip] DET Control and interop (was RE: I-D Action: draft-ietf-drip-rid-14.txt)

My opinion is we request of IANA a /28 prefix for DRIP RID.  We recommend a new prefix.  Leave it to discussions with IANA on the final prefix selection.  Don't pre-decide this one.

Yes, allow in this doc for "other" prefixes for UAS usage that fit into the DRIP RID framework.
On 12/13/21 12:34, Card, Stu wrote:
Clarification to my previous message: we should make an IANA request for a /28 in the special IETF protocol IPv6 address space (probably repurposing the old HIPv2 allocation) for experimental (inc. working examples) and general use, but make clear that we expect other prefixes (and DNS domains) to be used for specific applications (such as ICAO's /[16+4] for IATF inc. UAS RID).

On Mon, Dec 13, 2021 at 11:29 AM Card, Stu <[e-mail]<mailto:[e-mail]>> wrote:
IMO this draft should have _examples_ of HHITs, registries, FQDNs, etc., and the registries draft should have the real things, but even there, IETF should not try to perform (only request) IANA functions.


On Mon, Dec 13, 2021, 09:41 Robert Moskowitz <[e-mail]<mailto:[e-mail]>> wrote:
Med,

Does the RAA registrar even belong in this document?  perhaps, I should only say that one is needed, as I really don't think all the tasks an RAA SHOULD do are germane here and these tasks should impact the registrar work (like that the RAA needs a DNS operation for HDAs and registrar process for said HDAs).

I think this should actually be in drip-registries.  The more I have in drip-rid, the longer it will take until I can turn my attention to registries...

Different prefixes will have slightly different ORCHID processing, but I believe I have made the new ORCHID logic inclusive for such.  It will get more into different DNS trees.  So the DNS part of drip-rid may only be an example and the real work again in drip-registries.  Multiple, fielded, prefixes for UAS can be managed and interoperate in the field.

.aero was put in the draft, as Stu and Adam had gotten uas.aero<http://uas.aero> registered and where testing with that.  With draft -14, I was trying to move beyond PoC, to how we see this actually working.  Knowing what aviation is thinking, in their broader context on move to IPv6, I was able to latch on to a more mainstream (and thus perhaps more acceptable to aviation community) direction with icao.int<http://icao.int>.  Note that ICAO has put in for their own TLD, but that will be some time in coming, as ICANN limits when new TLDs are added.  So even, potentially, icao.int<http://icao.int> is just a stepping stone.

So EVERYONE here, please think about this.  Few of you have the broader aviation context, and I have only been learning this over the past 2+ years.

Should drip-rid include the RAA registration process or punt it, clearly to elsewhere?
Should drip-rid provide the definitive? DNS tree or only provide a set of examples and clearly punt to elsewhere?

That is is drip-rid just about the IETF UAS RID or also the home for services supporting it?

Now I have this 'challenge' on answering the RFC editor on the latest go-around on drip-req.  ARGH!!!

Bob
On 12/9/21 02:59, [e-mail]<mailto:[e-mail]> wrote:
Hi Bob, all,

In general, I’m uncomfortable with including text about an external organization without commitment from that organization.

We need more eyes on this issue, especially:
* 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
* interoperability issues when distinct prefixes are used
* why the draft said in -14 that .aero was an option and then this was changed without recording why isn’t an option anymore
* the use of a special name (RFC6761, RFC3172)

I kindly invite the WG participants (including other co-authors) to share their options on this issue. Thank you.

Given that this is an important aspect that will have practical implications on deployment and protocol maintenance, we will keep this discussion open till end of December 2021.

Cheers,
Med

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


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:

  1.  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.
  2.  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<http://raa.uas.icao.int>.

And that uas.icao.int<http://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.

_________________________________________________________________________________________________________________________



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.



--
Tm-rid mailing list
[e-mail]<mailto:[e-mail]>
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.