Subject: [Drip] reqs review: DRIP scope

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 4 Oct 2020 06:40:47 -0400

[email-masked] review primary issue:

> - The scope of DRIP should be clarified.

generally, and then again specifically

> - Remote ID does not have the same functions as C2. The scope of DRIP should be clarified.

IMO identification is not an end in itself but a means to various ends.
Thus DRIP must not only provide timely trustworthy identification
information, but also ensure that info is immediately and effectively
usable for urgent important applications in UAS, mostly V2X comms based,
including DAA and C2. I have tried to make that point in the draft, but
either have been unclear, or there is not agreement on the point itself?

Our scope is constrained by our charter, so the draft should specify
requirements only for RID not C2. The only 2 requirements that come
close to being C2 driven are Mobility and Multihoming, as those both
greatly benefit C2. However, those also support Network RID: UAS (and
other nodes) should be able to change their points of attachment to the
Internet, and to have more than one point of attachment concurrently,
while using their compactly provable identities in RID messaging.

I solicit specific input on how DRIP scope might be clarified.

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 5 Oct 2020 09:21:06 -0400

> I solicit specific input on how DRIP scope might be clarified.

Network RID is within scope of DRIP.  I have a draft for that.  In 
writing that draft, it was not a stretch to include C2.  In fact our 
proposed design for a trustworthy RID, i.e. Hierarchical HITs, inhances 
C2 authentication and control in a BLOS situation.  Or even LOS with 
necessary communications security.  Please see:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

Note that for NRID, it may be the UA or the GCS that is communicating to 
the USS.  Thus not only do UA need an ID the USS can trust, the GCS also 
needs this.  Given this situation, using these trustable IDs for UA-GCVS 
communication (e.g. C2) just makes sense.

C2 is not in scope, but secure C2 'naturally' falls out as a function 
DRIP can help with.

Bob

---

From: <[email-masked]>
Date: Tue, 6 Oct 2020 08:12:41 +0000

Hi Stu, Fanny, all, 

One additional comment, the draft already includes two sections that touch on this:
* 1.3. DRIP Scope
* 3.3.  DRIP Focus

We may consider merging these two to better articulate the scope. Of course, we don't need to replicate the charter in the draft. 

Cheers,
Med 

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Stuart W.
> Card
> Envoyé : dimanche 4 octobre 2020 12:41
> À : [email-masked]
> Cc : PARZYSZ Fanny TGI/OLN <[email-masked]>
> Objet : [Drip] reqs review: DRIP scope
> 
> information, but also ensure that info is immediately and
> effectively usable for urgent important applications in UAS, mostly
> V2X comms based, including DAA and C2. I have tried to make that
> point in the draft, but either have been unclear, or there is not
> agreement on the point itself?
> 
> greatly benefit C2. However, those also support Network RID: UAS
> (and other nodes) should be able to change their points of
> attachment to the Internet, and to have more than one point of
> attachment concurrently, while using their compactly provable
> identities in RID messaging.
> 
> Tm-rid mailing list
> [email-masked]
> 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.