Subject: [Drip] (reminder) RE: call for adoption for draft-ietf-drip-uas-rid

From: <[email-masked]>
Date: Wed, 16 Sep 2020 06:17:25 +0000

Re,

This s a nudge that the call is still open for one week.

Silence does not mean support. So, please consider sharing your thoughts about this draft and whether it should be adopted or not to meet this milestone:

=====
Sep 2020 Solution space documents adopted by the WG
=====

Cheers,
Daniel & Med

De : Tm-rid [mailto:[email-masked]] De la part de Daniel Migault
Envoyé : mercredi 9 septembre 2020 19:04
À : [email-masked]
Objet : [Drip] call for adoption for draft-ietf-drip-uas-rid

Hi,

This email starts a call for adoption for draft-ietf-drip-uas-rid available here:
https://datatracker.ietf.org/doc/draft-ietf-drip-uas-rid/

The call for adoption ends on 2020 September 23.  Please state clearly your opinion whether you think the work should be adopted or not. If you think the work should not be adopted, please state why.

Yours,
Med and Daniel
--
Daniel Migault
Ericsson

_________________________________________________________________________________________________________________________

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.

---

From: Andrei Gurtov <[email-masked]>
Date: Wed, 16 Sep 2020 12:08:26 +0200

+1 for adoption (obviously:). I think there was good support at the last
interim meeting.

Andrei

On 2020-09-16 08:17, [email-masked] wrote:
> Silence does not mean support. So, please consider sharing your
> thoughts about this draft and whether it should be adopted or not to
> meet this milestone:
>
>  
>
> =====
>
> *De :*Tm-rid [mailto:[email-masked]] *De la part de* Daniel
> Migault
> *Envoyé :* mercredi 9 septembre 2020 19:04
> *À :* [email-masked]
> *Objet :* [Drip] call for adoption for draft-ietf-drip-uas-rid
>
>  
>
> Hi, 
>
>  
>
> The call for adoption ends on 2020 September 23.  Please state clearly
> your opinion whether you think the work should be adopted or not. If
> you think the work should not be adopted, please state why. 
>
>  
>
> Yours, 
> Med and Daniel
>
> -- 
>
> Daniel Migault
>
> Ericsson
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Sep 2020 15:35:02 +0200

I dont know how to shar emy thoughts.

You say that we need to comment on the contents, not on the naming.

I could comment on the content if there was the right name.

But the wrong name implies that the comments are not needed.  The name 
is wrong in that it seems to be adopted, so there would be no need of 
comments.

If the name was right, and the document was not adopted, and if there 
was a chance for the document to _not_ be adopted, then I could comment 
on it.  Otherwise, why should I comment on it if it is already adopted?

My comment is around the following:

Is UAS-RID concept decoupled from the use of HIP?  Or does UAS-RID 
mandate the use of HIP?

Because, there are other ways into which to achieve same effects as HIP 
which might be probably more in use in the Internet today.  Or maybe 
there are implementations aspects of HIP that I am not aware of.

These are my comments to a document whose name seems to not need comments.

This is a long email, as the situation is difficult.

Alex

Le 16/09/2020 à 08:17, [email-masked] a écrit :
> Silence does not mean support. So, please consider sharing your thoughts 
> about this draft and whether it should be adopted or not to meet this 
> milestone:
> 
> =====
> 
> *De :*Tm-rid [mailto:[email-masked]] *De la part de* Daniel Migault
> your opinion whether you think the work should be adopted or not. If you 
> think the work should not be adopted, please state why.
> 
> Yours,
> Med and Daniel
> 
> -- 
> 
> Daniel Migault
> 
> Ericsson
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 17 Sep 2020 10:43:03 -0400

> is wrong in that it seems to be adopted, so there would be no need of 

Unmanned Aircraft (Drone) Remote ID is outside the IETF.

This IETF effort is to create a trustworthy Remote ID and Protocols 
around its use within the defined aviation framework of UAS.

We chose "Trustworthy", but we need to make it "Trustworthy" within the 
highly constrained Broadcast Remote ID transmissions defined in ASTM 
F3411-19.  We cannot change the framework; that is given.  We can add 
content in specific data objects.

> was a chance for the document to _not_ be adopted, then I could 
> comment on it.  Otherwise, why should I comment on it if it is already 
> adopted?

Procedurally, moskowitz-drip-uas-rid has not been adopted.  My bad about 
creating a ietf-drip-uas-rid

So far it is the only proposal for a Trustworthy Remote Id that fits 
within the defined constraints.

In My Highly Biased Opinion, it is complete enough to show it meets the 
wg charter, thus the call to adopt.

> Is UAS-RID concept decoupled from the use of HIP?  Or does UAS-RID 

It is decoupled.  Important point.  In fact no way to operate HIP in a 
broadcast media.

HIP MAY be used in follow on DRIP protocols.  In fact there are drafts 
that use it.  But that is for later work. First we need the RID.

>
> Because, there are other ways into which to achieve same effects as 
> HIP which might be probably more in use in the Internet today. Or 
> maybe there are implementations aspects of HIP that I am not aware of.

It is achieving the same effect as HIT as defined in HIP.  Note that RFC 
7250 has a similar identity concept, but it cannot fit within the 
F3411-19 broadcast constraints.  Similar problem with RFC 3972.

> This is a long email, as the situation is difficult.

There is a fair amount of aviation baggage and Identity baggage behind 
this work.  As often the case, the draft is the tip of an iceberg.

>> The call for adoption ends on 2020 September 23.  Please state 
>> clearly your opinion whether you think the work should be adopted or 
>> not. If you think the work should not be adopted, please state why.
>>
>> Yours,
>> Med and Daniel
>>
>> -- 
>>
>> Daniel Migault
>>
>> Ericsson
>>
>> 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,
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law;
>> If you have received this email in error, please notify the sender 
>> and delete this message and its attachments.

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Thu, 17 Sep 2020 20:55:23 -0400

+1 for adoption from me as well.

On Thu, Sep 17, 2020 at 10:43 AM Robert Moskowitz <[email-masked]>
wrote:

> But the wrong name implies that the comments are not needed.  The name is
> wrong in that it seems to be adopted, so there would be no need of
> comments.
>
>
> This IETF effort is to create a trustworthy Remote ID and Protocols around
> its use within the defined aviation framework of UAS.
>
> If the name was right, and the document was not adopted, and if there was
> a chance for the document to _not_ be adopted, then I could comment on it.
> Otherwise, why should I comment on it if it is already adopted?
>
>
> In My Highly Biased Opinion, it is complete enough to show it meets the wg
> charter, thus the call to adopt.
>
>
> Is UAS-RID concept decoupled from the use of HIP?  Or does UAS-RID mandate
> the use of HIP?
>
>
> which might be probably more in use in the Internet today.  Or maybe there
> are implementations aspects of HIP that I am not aware of.
>
>
> 7250 has a similar identity concept, but it cannot fit within the F3411-19
> broadcast constraints.  Similar problem with RFC 3972.
>
> *De :*Tm-rid [mailto:[email-masked] <[email-masked]>]
> *De la part de* Daniel Migault
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: <[email-masked]>
Date: Fri, 18 Sep 2020 06:20:14 +0000

Hi Alex, 

If you check https://datatracker.ietf.org/group/drip/documents/, you will see that the document is ** not listed ** as a WG item. The status is set to "I-D Exists Candidate for WG Adoption".

I reiterate what we already said in the note sent to the WG: If there is no sufficient support for adoption, we will change the state in the data tracker accordingly (e.g., "dead"). 

The adoption call is meant to mainly assess the followings: 

(1) Is the document a good starting point to deliver what the WG promised in the charter?
==
Sep 2020 Solution space documents adopted by the WG
==
(2) is there enough energy to contribute/review the document?
(3) Is the proposed solution broken and issues can't be fixed?

The WG may consider more than one solution document. 

Hope this clarifies your concerns. 

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Alexandre
> Petrescu
> Envoyé : jeudi 17 septembre 2020 15:35
> À : [email-masked]
> Objet : Re: [Drip] (reminder) RE: call for adoption for draft-ietf-
> drip-uas-rid
> 
> But the wrong name implies that the comments are not needed.  The
> name is wrong in that it seems to be adopted, so there would be no
> need of comments.
> 
> If the name was right, and the document was not adopted, and if
> there was a chance for the document to _not_ be adopted, then I
> could comment on it.  Otherwise, why should I comment on it if it is
> already adopted?
> 
> > meet this
> > Migault *Envoyé :* mercredi 9 septembre 2020 19:04 *À :*
> > [email-masked] *Objet :* [Drip] call for adoption for
> > draft-ietf-drip-uas-rid
> >
> > Hi,
> >
> clearly
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > 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.
> >
> > privileged information that may be protected by law; they should
> not be distributed, used or copied without authorisation.
> > As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> > Thank you.
> >
> >
> 
> --
> Tm-rid mailing list
> [email-masked]

---

From: Jeff Ahrenholz <[email-masked]>
Date: Fri, 18 Sep 2020 16:10:22 +0000

+1 for adoption of this draft.

The HHIT elegantly binds a cryptographic ID with a verifiable registration system into a 128-bit value. This works well to combine existing, deployed IETF protocols with new purpose-built infrastructure supporting this standard.

-Jeff

From: Tm-rid <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, September 15, 2020 at 11:17 PM
To: "[email-masked]" <[email-masked]>
Subject: [Drip] (reminder) RE: call for adoption for draft-ietf-drip-uas-rid

Re,

 
=====
 
Cheers,
Daniel & Med

Hi, 

 
Yours, 
Med and Daniel

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Fri, 18 Sep 2020 17:22:18 +0000

+1 for adoption.

Best,
Shuai

From: Tm-rid <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, September 15, 2020 at 23:17
To: "[email-masked]" <[email-masked]>
Subject: [Drip] (reminder) RE: call for adoption for draft-ietf-drip-uas-rid(Internet mail)

Re,

=====

Cheers,
Daniel & Med

Hi,

Yours,
Med and Daniel
--
Daniel Migault
Ericsson

Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2020 01:08:52 -0400

> Silence does not mean support. So, please consider sharing your thoughts 

Actually, RFC7221 and RFC7282 have many things to say about this.

> think the work should not be adopted, please state why.

I have read the document in August, and made a number of comments on it.
I made some comments about alternate ways to do the allocation, but I 
accept the rational for a /28.

I disagree that the zone is too big to be signed with DNSSEC, but this 
is an operational detail that can be decided later.

I believe that HHITs are the way to go for this work.