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

[Robert Moskowitz <[e-mail]>]

On 9/17/20 9:35 AM, Alexandre Petrescu wrote:
> 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.

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.

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

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.

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

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.

> These are my comments to a document whose name seems to not need 
> comments.
>
> 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.

>
> Alex
>
> Le 16/09/2020 à 08:17, [e-mail] a écrit :
>> 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:[e-mail]] *De la part de* Daniel 
>> Migault
>> *Envoyé :* mercredi 9 septembre 2020 19:04
>> *À :* [e-mail]
>> *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.
>>
>>
>

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