Subject: [Drip] AD review of draft-ietf-drip-reqs-09

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Mar 2021 13:44:44 +0000

As usual when a WG requests the publication of a draft, I do my own AD review before proceeding.

First of all, thank you to the authors and the WG for the text that has been developed in 18 months or so (draft-card-tmrid-uas-00 is dated Nov 2019), a record !

Except when noted, a reply or a revised I-D should address the review comments below. The amount of points below is not about the quality of the document itself but more about my interest in this one :-)

The section 1-3 (esp. "problem space") are not really related to the topic of this document, which is about 'requirements'. They would better fit in the architecture document IMHO but we already discussed about this issue over the mailing list.

--- Abstract ---

Can be ignored by the authors but in “security, safety, and other purposes", the "other purposes" is rather vague...

-- Section 1.1 --

Can be ignored but "they can quickly close (500 meters in under 17 seconds at 60 knots);" may be cryptic with the use of "close" and "knots". For the latter, use km/h or mph ?

Unsure whether the paragraph starting with "Diverse other applications can be enabled or facilitated by RID." Has any added value. Consider removing it.

Please expand "Wi-Fi NAN"

The paragraphs with all the long reference is pretty heavy and dry and I am afraid that the actual information in those paragraphs could be lost by the reader. Unsure how to fix the issue though (perhaps repeating in a summary all those references ?).

A terminology section could also help if placed at the beginning.

"The data will be sent in plain text and the UAS operator registration

   number will be represented as a 16-byte string including the state

   code.  The private id part will contain 3 characters which are not

   broadcast but used by authorities to access regional registration

   databases for verification."

Unsure what the 'state' is in the above... Is a status ? a US state ? If a status, then how can it be included in a registration number? If a US state, then what about non-US countries ?

There is also an ambiguity between 'not broadcast' in the list of 'will broadcast locally' ;-)

" it is not addressed in any of the subsequent  regulations or technical specifications." Specifications from whom ?

Where is the difference between safety/security oriented RID defined ?

-- Section 1.2 --

The concept of 'Ground Control Station' should be introduced (possibly earlier in the document).

"by a software process on the GCS" as everything is in SW, what about adding 'transparent and automated' or something in the same vein ?

"dead reckoning" as a private pilot I understand but what about the 'normal' reader ? better to remove those 2 words or add ',i.e.,' after them ?

In " error in but also of intentional falsification of this data", I wonder about the usefulness of the commas.

A key sentence "Broadcast RID uses one-way data links" is lost is in the middle of a long paragraph.

-- Section 1.3 --

Thank you for repeating the DRIP WG charter. You may want to replace 'goal' by 'charter' in the 1st paragraph

Suggest to remove the old name TM-RID

-- Section 1.4 --

Is there a need for the Oxford comma in "privacy and  Transparency" ?

s/Internet based approach/Internet-based approach/ ?

-- Terminology section 2.2 --

This section comes a little late (after the critical section 1) for such a 'unusual' domain, it is probably very useful to have a single place where many concepts/terms are defined BEFORE the section 1.

"community's norms are respected herein" but in IETF documents, the custom is to use IETF wording/vocabulary/conventions. I do not mind too much but we may expect some pushbacks on this.

The 400 ft  in LAANC, isn't it US specific ?

Should "Net-RID" also be defined ? Some other places use "network RID", is it the same concept ?

'PII' is mainly a US concept, how is it related to the EU GDPR ? (and of course other countries similar definitions)

I wonder whether the different messages should be in this section as they are described later (I guess) or should be grouped together ?

"Although called "UAS ID", unique to the UA," I wonder whether the first comma is sensible.

For UTM, is it 'that' or 'which' in "management which manages UAS operations safely" ?

-- Section 3 --

CAA was already expanded, no need to expand it again ;-)

Unsure whether " (or other Wide Area Network)" is useful here... Or do you mean IP connectivity ?

"UAS Identifier  (UAS ID) as a key.", suggest to use a different word than 'key' (which could mean encryption key), e.g., identifier ?

The expansion " Neighbor Awareness Networking" comes a little late in the document ;-)

"specifies three UAS ID types" is it 'ID' or 'RID' or 'identification'  ?

-- Section 3.1 --

"There must be some information flow path (direct

   or indirect) between the GCS and the UA, for the former to exercise

   C2 over the latter."

Is a little too complex for my personal taste, what about "... to control the UA" ?

Figure 3 uses "_" while text uses "-"

" (and other middle layer protocols)" what is this 'middle layer' ? Is it an application-layer protocol ?

" publish-subscribe-query" looks like an oxymoron to me what about " publish-subscribe system" ?

Bullet 2 " Network RID Service Provider (Net-RID SP)" as the term has already been defined, no need for expansion anymore.

s/ via unspecified (generally presumed to be web  browser based) means/via means that are out of scope of this document/ ?

Suggest to use bullet points for " Network RID has several variants."

Humm " this could be the pilot" pilot or operator ?

Consider removing " Long Term Evolution (LTE)" as it brings little value

Later "feeds a Network RID Service Provider (Net-RID SP," is again explained while it was defined before ;-)

-- section 3.2 --

Figure 4, suggest to add the operator (even if doing nothing in this case) to be consistent with figure 3.

" other middle layer protocols" is also unclear

s/ web based verifier/ web-based verifier/

" Neighbor Awareness Networking" has been expanded before, no need to redo it

API has already been expanded and this is a well-known term, hence, not even a need to expand it. See also https://www.rfc-editor.org/materials/abbrev.expansion.txt

s/ within the 25 byte limit/ within the 25-octet limit/. I.e., do not use ambiguous 'byte' but rather use 'octet'

Some explanations may be required about <("paging")> (either in this section or in the terminology section ?)

" on the basis of MAC address" just beware that IEEE 802.11ag/ah (if not mistaken) starts to randomize MAC addresses...

" see  Message Pack below", "below" is rather vague, can you point to a section or a table ?

s/ 4 bit message type field/ 4-bit  message type field/

in " To satisfy EASA and FAA rules, all types are needed" is it 'needed' or 'mandatory' ?

Table 1, is 'message pack' mandatory or optional ?

" far too short for conventional certificates" while I am unsure what is a 'conventional' certificate, could the cert be fetch off-line ?

-- Section 4.1 --

GEN-4: 'readability' is rather vague... is it about clear text vs. cipher text ? is about structure/format ?

GEN-6: should the communications also be authenticated ?

GEN-7: unsure whether the message frequency is really about QoS (suggest to find an alternative to QoS)

GEN-8: what is meant by mobility ? Geographic move ? or change of IP connectivity ? (switching cellular providers)

The last two § would gain of having either a bullet list format or one § per requirement (and also grouped in a sub-section 'rationale')

-- Section 4.2 --

ID-4: isn't uniqueness implicit for an ID ?

ID-5: I wonder whether 'non-spoofable' is an ID property or an authentication property... So, moving ID-5 to another requirements section

ID-6: isn't it more about 'privacy' than 'identifier' ?

Add references to HIP & DTLS ?

-- Section 4.3 --

PRIV-2: is the crypto disabling total or only for partial data ?

-- Section 4.4 --

REG-4: are those policies machine or human readable ?

-- Section 6 --

On this International Women Day,  some will suggest to replace ' Man In The Middle' by 'on path attacker' 😉

-- Appendix A --

Should a reference to " OpenSky and Flightradar" be added ? BTW, I believe you meant 'FlightAware' and not "FlightRadar' BTW2 my own raspeberry PI is part of those community ;-)

" It transmits a four-digit squawk code" should be qualified as four octal digits.

The I-D does not discuss the 24-bit ICAO identifier in mode-S transponder. For sake of completeness, please mention it.

Please make a separate § for CPLDC

It is not "LORA" but "LoraWAN" AFAIK

Hope this helps

-éric

---

From: <[email-masked]>
Date: Mon, 8 Mar 2021 14:20:29 +0000

Hi Eric,

Thank you for the review. I trust the authors will do the right thing.

As a shepherded, please see below two points.

Cheers,
Med

De : Tm-rid [mailto:[email-masked]] De la part de Eric Vyncke (evyncke)
Envoyé : lundi 8 mars 2021 14:45
À : [email-masked]
Objet : [Drip] AD review of draft-ietf-drip-reqs-09

[Med] Agree. This is section is maintained on purpose.

--- Abstract ---

-- Section 1.1 --

-- Section 1.2 --

-- Section 1.3 --

-- Section 1.4 --

[Med] A pointer to https://tools.ietf.org/html/rfc8576#section-5.9 may be sufficient here.

-- Section 3 --

-- Section 3.1 --

   C2 over the latter."

-- section 3.2 --

-- Section 4.1 --

-- Section 4.2 --

-- Section 4.3 --

-- Section 4.4 --

-- Section 6 --

-- Appendix A --

Hope this helps

-éric

_________________________________________________________________________________________________________________________

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: "Card, Stu" <[email-masked]>
Date: Mon, 8 Mar 2021 09:42:10 -0500

Thanks Eric!

Yes, as Med says, we will try to do the right thing, right after IETF 110,
but will need some back and forth on a few points, as I am not sure how to
address them.

On Mon, Mar 8, 2021 at 9:20 AM <[email-masked]> wrote:

> *De :* Tm-rid [mailto:[email-masked]] *De la part de* Eric
> Vyncke (evyncke)
> *Envoyé :* lundi 8 mars 2021 14:45
> *À :* [email-masked]
> *Objet :* [Drip] AD review of draft-ietf-drip-reqs-09
>
>
>
> First of all, thank you to the authors and the WG for the text that has
> been developed in 18 months or so (draft-card-tmrid-uas-00 is dated Nov
> 2019), a record !
>
>
>
> Except when noted, a reply or a revised I-D should address the review comments
> below. The amount of points below is not about the quality of the
> document itself but more about my interest in this one :-)
>
>
>
> The section 1-3 (esp. "problem space") are not really related to the topic
> of this document, which is about 'requirements'. They would better fit in
> the architecture document IMHO but we already discussed about this issue
> over the mailing list.
>
>
>
> Can be ignored but "they can quickly close (500 meters in under 17 seconds
> at 60 knots);" may be cryptic with the use of "close" and "knots". For the
> latter, use km/h or mph ?
>
>
>
> Unsure whether the paragraph starting with "Diverse other applications can
> be enabled or facilitated by RID." Has any added value. Consider removing
> it.
>
>
>
> The paragraphs with all the long reference is pretty heavy and dry and I
> am afraid that the actual information in those paragraphs could be lost by
> the reader. Unsure how to fix the issue though (perhaps repeating in a
> summary all those references ?).
>
>
>
> Unsure what the 'state' is in the above... Is a status ? a US state ? If a
> status, then how can it be included in a registration number? If a US
> state, then what about non-US countries ?
>
> " it is not addressed in any of the subsequent  regulations or technical
> specifications." Specifications from whom ?
>
>
>
> "by a software process on the GCS" as everything is in SW, what about
> adding 'transparent and automated' or something in the same vein ?
>
>
>
> "dead reckoning" as a private pilot I understand but what about the
> 'normal' reader ? better to remove those 2 words or add ',i.e.,' after them
> ?
>
>
>
> In " error in but also of intentional falsification of this data", I
> wonder about the usefulness of the commas.
>
>
>
> This section comes a little late (after the critical section 1) for such a
> 'unusual' domain, it is probably very useful to have a single place where
> many concepts/terms are defined BEFORE the section 1.
>
>
>
> "community's norms are respected herein" but in IETF documents, the custom
> is to use IETF wording/vocabulary/conventions. I do not mind too much but
> we may expect some pushbacks on this.
>
>
>
> 'PII' is mainly a US concept, how is it related to the EU GDPR ? (and of
> course other countries similar definitions)
>
> I wonder whether the different messages should be in this section as they
> are described later (I guess) or should be grouped together ?
>
>
>
> "UAS Identifier  (UAS ID) as a key.", suggest to use a different word than
> 'key' (which could mean encryption key), e.g., identifier ?
>
>
>
> Bullet 2 " Network RID Service Provider (Net-RID SP)" as the term has
> already been defined, no need for expansion anymore.
>
>
>
> s/ via unspecified (generally presumed to be web  browser based) means/via
> means that are out of scope of this document/ ?
>
>
>
> Later "feeds a Network RID Service Provider (Net-RID SP," is again
> explained while it was defined before ;-)
>
>
>
> -- section 3.2 --
>
>
>
> API has already been expanded and this is a well-known term, hence, not
> even a need to expand it. See also
> https://www.rfc-editor.org/materials/abbrev.expansion.txt
>
>
>
> " on the basis of MAC address" just beware that IEEE 802.11ag/ah (if not
> mistaken) starts to randomize MAC addresses...
>
>
>
> " far too short for conventional certificates" while I am unsure what is a
> 'conventional' certificate, could the cert be fetch off-line ?
>
>
>
> -- Section 4.1 --
>
>
>
> GEN-8: what is meant by mobility ? Geographic move ? or change of IP
> connectivity ? (switching cellular providers)
>
>
>
> The last two § would gain of having either a bullet list format or one §
> per requirement (and also grouped in a sub-section 'rationale')
>
>
>
> -- Section 4.2 --
>
>
>
> ID-5: I wonder whether 'non-spoofable' is an ID property or an
> authentication property... So, moving ID-5 to another requirements section
>
>
>
> Should a reference to " OpenSky and Flightradar" be added ? BTW, I believe
> you meant 'FlightAware' and not "FlightRadar' BTW2 my own raspeberry PI is
> part of those community ;-)
>
>
>
> The I-D does not discuss the 24-bit ICAO identifier in mode-S transponder.
> For sake of completeness, please mention it.
>
>
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>