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

+1 for adoption from me as well.

On Thu, Sep 17, 2020 at 10:43 AM Robert Moskowitz <rgm@labs.htt-consult.com>
wrote:

>
>
> 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, mohamed.boucadair@orange.com 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:tm-rid-bounces@ietf.org <tm-rid-bounces@ietf.org>]
> *De la part de* Daniel Migault
> *Envoyé :* mercredi 9 septembre 2020 19:04
> *À :* tm-rid@ietf.org
> *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.
>
>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      rgm@labs.htt-consult.com
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid
>

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