Subject: [Tm-rid] Review of draft-drip-reqs-01

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 6 Jul 2020 08:59:16 +0200

Dear all,

So my thoughts are collected below, referencing RFC6973 and RFC8280 as
appropriate.

1 Introduction

"Civil Aviation Authorities (CAAs) worldwide are mandating Unmanned
Aircraft System Remote Identification and tracking (UAS RID). The
European Union Aviation Safety Agency (EASA) has published [Delegated
<https://www.ietf.org/id/draft-ietf-drip-reqs-01.html#Delegated>] and
[Implementing
<https://www.ietf.org/id/draft-ietf-drip-reqs-01.html#Implementing>]
Regulations"

To me it's strange not to reference the SESAR JU reference architectures
in https://www.sesarju.eu/node/3402 as long as the UTM CONOPS from the
FAA are being referenced.

It's also strange for me to name the FAA CONOPS reference "[CONOPS]"
since CONOPS is a generally accepted industry term for "concept of
operations". Maybe FAACONOPS instead?

"Generally the same information must provided via both means."

This is an awkward formulation to me: either "generally" implies that
it's "should" rather than "must", or the word "generally" should be
dropped. I'm not sure which is the right answer, but either "generally"
or "must" should go.

"The EU allows only Type 1; the US allows Types 1 and 3, but requires
Type 3 IDs (if used) each to be used only once (for a single UAS flight,
which in the context of UTM is called an "operation")."

I have some difficulty with semi-colons. The EU requires Type 1 for
hardware, similarly to IMEI for phones, but does not preclude additional
identifiers (and indeed requires at least one additional identifier by
section 7 in draft-drip-arch-02).

What you could do is lift out parts of section 7 from draft-drip-arch-02
and put it below the [F3411-19] UAS ID types list. Then you can make
assertions about the different IDs required in the different jurisdictions.

"Broadcast RID transmits all information in the clear as plaintext
(ASCII or binary), so static IDs enable trivial correlation of patterns
of use, unacceptable in many applications, e.g., package delivery routes
of competitors."

This looks like a good privacy assessment in line with [RFC6973 7.1c,
7.1f, 7.1e and 7.1a] but it's placed in a way it's difficult to
recognise. Maybe create a subsection of 1 Introduction in the following way:

1. Introduction

1.1 Uses for RID in UAS space

This would contain "An ID is not end end in itself; ..."

"Using UAD RID to facilitate..."

"The need for near-universal adoption of UAS RID..."

1.2 Privacy concerns in UAS space

"Minimal specified info..."

"Broadcast RID transmits all information..."

1.3 Resource constraints in UAS space

"UA onboard RID devices are..."

"To accommodate the most severely constrained cases..."

"Given not only packet payload length..."

And then drop the following paragraphs or move them to section 3:

"Despite work by regulators...", "DRIPs initial goal..." and "DRIP
(originally...")

----

2 Terminology

Why is V-LOS in the definition list? it's used in the definition of
BVLOS (which is not used anywhere else in the document), and in the
definition of Limited RID (which is not defined by this document or any
other DRIP document either).

In fact, LOS is also not used, except in the definition of BLOS (which
is not used anywhere), and in RF-LOS, which is also not used anywhere.

Notably, none of the requirements in 4 seem to actually deal a lot of
transmission specific issues - it's assumed that there will be some form
of internet connectivity available (basically IP traffic, whether over
wifi/bluetooth or mobile networks) - indeed, by section 3.1 and 3.2. By
similar token it's not clear why RF needs to be defined in the
terminology section rather than simply spelled out, if necessary, in the
main text.

GBDAA is not used anywhere in the document.

ABDAA is also not used anywhere in the document.

LAANC is not used anywhere in the document.

GRAIN is not used anywhere in the document.

Standard RID is not used either (except in some other definitions).

Direct RID is also not used (except in some other definitions).

In the definition of "Operator" it's a bit confusing that it says an
operator is typically an organization, while most of the uses of the
word operator connects the operator to PII and privacy concerns or PII
(things which sort of inherently belong to private persons).

Notably, VTOL is used in section 3 but is not in the terminology list.
Neither is STOL

----

4 Requirements

But ok, it seems I'm getting lost in editorials here. On the
requirements section, it might help to cross-reference the requirements
to the privacy checklist contained in RFC6973 section 7:

RFC6973, 7.1 Data minimization

a) Identifiers. Section 4.1 and 4.2 of the draft contain specific lists
of identifiers required and it is clarified in section 1 and 5 that the
range of identifiers and their properties is motivated by regulatory
concerns. ID-6 even specifically mandates that identifiers not allow
correlations of interactions.

b) Data. Various requirements in Section 4 and Section 1 deals with
information which is being exposed, why, and how to protect information.
The information which is not regulatorily mandated to be exposed appears
not to be intended to be exposed (e.g. PRIV-1 and PRIV-2 or REG-2).

c) Observers. See b)

d) Fingerprinting. See a) but also ID-6.

e) Persistence of identifiers. ID-6 makes it a specific requirement with
transient IDs.

f) Correlation. See a), d) and e).

g) Retention. Basically information is retained, in the registry
(section 4.4) and on the identified UAS.

RFC6973, 7.2 User Participation

a) User control. I can't find any requirement that immediately deals
with user control. OTOH, most of the requirements are specifically
motivated by regulations that somehow assume the UAS operator/drone
owner is the antagonist, so that makes sense. Data minimization is a
stronger privacy strategy in these cases, imho.

b) Control over sharing with individual receipients. Arguably in PRIV-1,
PRIV-2, and REG-2.

c) See b).

d. Preference expression. I can't really find any requirement that match
preference expression. If you want to share more information about the
drone, how to create those settings? The GEN-4 requirement could cover
this though, together with the GEN-X requirements and ID-X requirements.
It could be for some other application to enable to management of
preferences with respect to sharing under b) (when not mandated by law
and covered by REG-1 req).

RFC6973, 7.3 Security

a) Surveillance. Well. The entire point of introducing the identifiers
is facilitating better surveillance, and DRIP makes some attempts to be
privacy-friendly in spite of this.

b) Stored data compromise. This goes back to the PRIV-3 requirement
which was already discussed - RFC6973 7.3.b is actually a good reason to
keep PRIV-3 requirement I suppose.

c) Intrusion. PRIV and REG reqs appear to cover this.

d) Misattribution. GEN-1, GEN-2, GEN-3 requirements appear to cover this.

RFC6973 7.4 General

a) Trade-offs. They're covered in the introduction section 1 and
discussion section 5.

b) Defaults. This is not mentioned in the draft. Maybe could be added
suggested defaults on the technology that implements the requirements
eventually?

---

From: <[email-masked]>
Date: Mon, 6 Jul 2020 07:22:50 +0000

Hi Amelia,

Thank you for the review. Much appreciated.

> is not used anywhere), and in RF-LOS, which is also not used anywhere.

Actually, this is OK because we wanted to have one place for DRIP terms. This is why we do have this note in the document:

==
   This section defines a set of terms that are used in DRIP documents.
   This list is meant to be the DRIP terminology reference.  Some of the
   terms listed below are not used in this document.
==

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Amelia
> Andersdotter
> Envoyé : lundi 6 juillet 2020 08:59
> À : [email-masked]
> Objet : [Tm-rid] Review of draft-drip-reqs-01
> 
> Dear all,
> 
> --
> 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.

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 6 Jul 2020 09:32:33 +0200

> Actually, this is OK because we wanted to have one place for DRIP terms. This is why we do have this note in the document:

I sort of requested in the past, so I know. But the [draft-drip-arch-02]
also does not use these terms.

So LOS, for instance, is mentioned in [draft-moskowitz-drip-secure-nrid]
but is then not used in that document.

So it's just a bit confusing. Maybe it's because there's still work to
be done? But LOS and such things would seem to me things they work out
in either IEEE 802 or Bluetooth Consortium or 3GPP RAN groups?

best regards,

Amelia