Subject: [Drip] AD review for draft-ietf-drip-arch-20

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 1 Feb 2022 16:29:58 +0000

Happy to read that this important document as reached the publication requested status. Congratulations to the authors and the DRIP WG !

As usual, once the publication is requested for a document, I am doing my AD review before continuing the publication process.

I have one major issue with content and flow of this I-D: section 1 is really informative and about the generic architecture, sections 4 and others use a normative vocabulary and are not really about architecture but more about RID. This is really weird: was that the intent of the DRIP WG? Can it be fixed ? In the same vein, I suggest to improve the flow/structure see below.

NB: I obviously know the background of the authors and can easily spot who wrote what ;-)

The comments are direct for sake of time but except when noted do not always need to be acted upon, I will welcome an explanation why this comment was ignored though :-)

Abstract: try to add RFC 9153 after the "requirements document" else put I-D.ietf-drip-reqs

Sec 1: s/Unmanned Aircraft System Remote Identification and tracking (UAS RID)/ Unmanned Aircraft System (UAS) Remote Identification (RID)/ to be consistent with the title of section 1.1

Sec 1.1: use "UAS" rather than " Unmanned Aircraft Systems"

Sec 1.1: prefix "FAA" with "USA-based" ?

Sec 1.1: the use of "commercial" is usually understand as for consumer (i.e., recreative use) while I afraid that here it is more for commercial aviation activities as opposed to recreative ones. Worth clarifying or using a different word than commercial.

I would promote section 1.1, 1.2, 1.3, ... to full sections as they are not really parts of "introduction".

Sec 1.2.1 is it " received UAS ID" or " received UAS RID" ? If "ID", is it worth explaining why "ID" is used here?

Sec 1.2.1 please expand LOS at first use in " RF LOS" (perhaps also expand "RF") at the expanse of readability

Sec 1.2.1 " link based ID" same question about "ID" vs. "RID" (there should also be a '-' as in "link-based")

Sec 1.2.2 " GNSS" expand at first use

Sec 1.2.2 add a note somewhere about the "4-D airspace" as not everyone is aware of the change of rules based on time of the day

Sec 1.2.2 increment the year in " currently (in the year of 2021)"

Section 1.2: this section appears as FAA-only. While this is not too good for the IETF, this could be OK but the document must be clear that section 1.2 is the US FAA position, not a global one.

Sec 3: I would move this section as a sub-section of 1.2.2

Sec 1.4 is " general UAS RID usage scenario" really general ? I.e., is it applicable outside of US FAA/CA CAA ?

Sec 1.4: please expand V2I, V2V, and DAA

Sec 3.1: why only crypto abbreviations ? There are so many aeronautical acronyms that they should be there as well and this § 3.1 should be moved ahead just after §1 (assuming that §1.1 and others become top-level sections)

Sec 3.2 add reference to HIP

Sec 4: please specify that this section is only applicable to US FAA (if so)

Sec 4 at multiple places, the text is rather dense and dry, could there be some figures to help understanding ?

Sec 4.1: the last paragraph is a single sentence of 7 lines...Please consider rewriting in an easier to read paragraph.

Sec 4.2: what is the difference between "RID" "Remote ID" and "ID" ? please try to use a consistent vocabulary. Same later for " cryptographic ID"

Sec 4.2: unsure whether "HI" was defined before

Sec 4.2: I cannot parse " This is in contrast to general IDs (...) as the subject in an X.509 certificate."

Sec 4.2: unsure whether "UA" can be used, isn't it always "UAS" ? Or is "UA" a different concept ?

Sec 4.2: " by avoiding an explicit encoding technology like ASN.1 or CBOR", so what encoding should be used ?

Sec 4.4: what is the meaning of " extant" ?

Sec 4.4: s/ IP address compatible identifiers/IP address/ ?

Sec 5: what are " public and private UAS information" ? The different types of info were not defined earlier in the document or provide a forward reference to sec 5.1 & 5.2

Sec 5.1.1 s/ public registry/ public information registry/

Sec 5.1.1 should "opaque" be used rather than "silent" in " they may be silent to the Observer" ?

Sec 5.1.2 please add a reference to DoT

Sec 5.1.2 after reading this §, it is still unclear to me what are the private information...

Sec 6: I was unable to find a definition of "trustworthiness" in [I-D.ietf-drip-reqs]

Sec 6: " DET (DRIP Entity Tag which is an HHIT-based UA ID)" should be at least written as "DRIP Entity Tag (DET), which is an HHIT-based UAS RID." And it probably deserves a definition / introduction on its own (perhaps in § 3.1)

Sec 7 " One obvious opportunity is to enhance the architecture with gateways from Broadcast RID to Network RID.", while I do not disagree, this section is not the right place to open the discussion. This should be in the § 1 (with perhaps a forward reference to § 7)

Sec 7 " crowd-sourced" indeed many ADS-B receivers are run by amateurs (like my own) for flightradar24, flightaware, ... perhaps add a reference ?

Sec 7 " it adds two more entity types." Which ones ?

Sec 7.1 this should really be part of the overall architecture of section 1

Sec 7.2 " multilateration" should briefly be described, perhaps in the terminology section

Sec 8 "DRIP contact" is nice indeed but same comment as for the CS-RID: this should really be part of the global architecture description and not pushed at the end

Sec 8: should be less descriptive and perhaps not even mention HIP & BEET

Sec 10 is very light and mainly focus on the private keys except for the false flag issue (which deserves its own paragraph). Nothing is said about privacy

Finally, some nits:

  *   several missing '-' as in "web-based methods" or "access-controlled DNS"
  *   "i.e." and "e.g." should be followed by ","
  *   Oxford coma ;-)

Hope this helps

-éric

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 1 Feb 2022 22:36:35 -0500

Thanks Eric!

I agree with 90% of what you have written, and thanks for catching not 
only several nits but also several areas where we were unclear.

It won't surprise you that I'll offer friendly rebuttal on a few points 
as well as answers to a few questions.

;-)

interspersed...

On 2/1/2022 11:29 AM, Eric Vyncke (evyncke) wrote:
> ...
> Sec 1: s/Unmanned Aircraft System Remote Identification and tracking 
> (UAS RID)/ Unmanned Aircraft System (UAS) Remote Identification (RID)/ 
> to be consistent with the title of section 1.1

The acronym UAS RID really does expand with "and tracking" in most of 
the key documents, including the original Aviation Rulemaking Committee 
final report (on which almost everyone based their subsequent efforts) 
and ASTM F3411.

> ...
> Sec 1.2.1 is it "received UAS ID" or "received UAS RID" ? If "ID", is it 
> worth explaining why "ID" is used here?

RID is the _process_, not the identity, not the identifier. In F3411, 
the identifier is the "UAS ID".

> ...
> Section 1.2: this section appears as FAA-only. While this is not too 
> good for the IETF, this could be OK but the document must be clear that 
> section 1.2 is the US FAA position, not a global one.

It was based on F3411 and intended to be generic. Indeed, FAA does not 
yet permit Network RID as a means of compliance with its RID rule. Is 
there something specific here that conflicts with a European or other 
non-US concept?

> ...
> Sec 1.4 is "general UAS RID usage scenario" really general ? I.e., is it 
> applicable outside of US FAA/CA CAA ?

It is general AFAIK.

> ...
> Sec 3.1: why only crypto abbreviations ? There are so many aeronautical 
> acronyms that they should be there as well and this § 3.1 should be 
> moved ahead just after §1 (assuming that §1.1 and others become 
> top-level sections)

We weren't focusing specifically on crypto, but listed only those 
acronyms that weren't defined in -reqs, which is the DRIP terminology 
reference.

> ...

It is intended to be generic.

> ...
> Sec 4.2: what is the difference between "RID" "Remote ID" and "ID" ? 
> please try to use a consistent vocabulary. Same later for "cryptographic ID"

I'm not sure we were consistent. What we should be doing:
  "RID" never used alone
  "UAS RID" ::= "Unmanned Aircraft System[s] Remote Identification and 
tracking"
  "ID" never used alone
  "UAS ID" ::= "Unmanned Aircraft System Identifier"

> ...

"UA" ::= "Unmanned Aircraft", the part of the UAS that actually flies

> ...
> Sec 4.4: what is the meaning of "extant" ?

"still in existence" which is probably not what we want here. Bob?

> ...
> Sec 4.4: s/IP address compatible identifiers/IP address/ ?

We were trying to emphasize that what we need is an identifier, not a 
locator, even though we desire IP address compatibility.

> ...
> Sec 5: what are "public and private UAS information" ? The different 
> types of info were not defined earlier in the document or provide a 
> forward reference to sec 5.1 & 5.2

We should cite the definition in -reqs PRIV-1 "private information 
(i.e., any and all information designated by neither cognizant authority 
nor the information owner as public, e.g., personal data)."

> ...
> Sec 5.1.1 should "opaque" be used rather than "silent" in "they may be 
> silent to the Observer" ?

What was meant was that an Observer might actually _see_ (with eyes) an 
aircraft, and if it was participating in RID, but Network RID only, not 
Broadcast, the Observer would not _receive_ any RID messages, instead 
would have to query a Net-RID DP for any aircraft in the vicinity.

> ...

You got me. :-) We use the word in -reqs section 12 on page 10, we imply 
generally what we want but we never define it. I use the word frequently 
(not just in the context of UAS RID and DRIP), and I identify several 
dimensions of it (reliability, scalability, security, etc.), but I have 
never actually attempted to define it rigorously. I am afraid to try. 
Perhaps we should reword this so it doesn't imply that we have a formal 
definition?

> ...
> Sec 7 "it adds two more entity types." Which ones ?

We should append ", as defined in the following two subsections."

> ...

The "CS-RID Finder" defined in 7.1 and the "CS-RID SDSP" defined in 7.2 
are _additions_: they are not part of UAS RID as contemplated by anyone 
other than the DRIP WG; they are not even part of basic DRIP, but an 
extension.

> ...
> Sec 8 "DRIP contact" is nice indeed but same comment as for the CS-RID: 
> this should really be part of the global architecture description and 
> not pushed at the end

This is another extension relative to UAS RID but I think fundamental to 
our DRIP approach, so yes we should briefly introduce it earlier, before 
elaborating upon it here.

> Sec 8: should be less descriptive and perhaps not even mention HIP & BEET

This really goes back to what has been a fundamental recurring debate 
since we started DRIP: is it based on HHITs and thus related closely to 
(although not entirely dependent upon) HIP; or is it generic? So far, no 
one has come to the DRIP WG and proposed anything other than the HHIT 
based approach. We are far along with that approach. Given the use of 
that approach, the contact requirement is trivially satisfied by using a 
HIP initiated BEET; there is no need to reinvent any wheels.

Thanks again. I will wait for responses from my co-authors and our 
editor before proposing any more replacement language to clarify these 
points where our meaning did not come through.

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 2 Feb 2022 10:42:33 +0000

Hello Stu, and thanks for your quick reply.

Elided the text where we agree, and comments added with EV>

Regards

-éric

On 02/02/2022, 04:37, "Stuart W. Card" <[email-masked]> wrote:

    Thanks Eric!

EV> it was expected and happy to read them

EV> feel free to keep "and tracking"; my point was rather to introduce UAS and RID acronyms just after their expansion, not globally

EV> fair point, the difference is clear in the -reqs document. Now, I wonder whether the reader would benefit from a repetition of the definitions of ID vs. RID in this document. Perhaps in § 3.3 ?

EV> my concern is about the applicability of an IETF document, which needs to be defined. May I suggest to add some pre-amble in sec 1.2 stating that the following sub-sections are applicable / related to F3411 ? The title of section 1.2 could also include F3411 to be clear about its applicability.

EV> text of sec 3.3 should then be included in this section for consistency

EV> happy if the document is reviewed to ensure that "ID" and "RID" are never used alone.

EV> learned a new word, suggest using simple wording ;-)

EV> indeed, easier for the reader

EV> then indeed 'opaque' is the wrong word but I am not sure that 'silent' is better. No proposal of mine though :(

EV> good idea, simply enumerate (reliability, scalability, ...) rather than using "as specified in " ;-)

EV> yes, please introduce those parts (CS-RID & contact) earlier in the document.

EV> As F3411 is the basis this I-D, should those extensions be clearly identified as not included in F3411 ?

EV> I also like the HHIT approach and the extension of DRIP contact. But I believe that mentioning HIP & BEET is venturing too much in a detailed solution especially since there is not even a draft about it. HIP may be mentioned as a potential solution but no more as its mention puts constraints on the work of the DRIP WG. I strongly suggest to remove " An Observer equipped with HIP can... V2X communications (e.g., [MAVLink]), etc" and possibly also the last sentence.

EV> that is the goal of review by a pair of fresh eyes. As soon as a revised I-D is uploaded, then I will initiate the IETF Last Call. We can still hope to get this I-D approved by the IESG before IETF-113 (end of March 2022)

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Feb 2022 15:25:13 -0500

I am only now starting to go through this.  Very bad/sad on performance 
to task again this month.

As it will be a bit of a challenge to catch up with all comments, I will 
go with whatever the other authors agreed on.

I need to get a clean slate and finish and publish the changes I have 
made to rid.

Another lost week....

On 2/1/22 11:29, Eric Vyncke (evyncke) wrote:
>
> Happy to read that this important document as reached the publication 
> requested status. Congratulations to the authors and the DRIP WG !
>
> As usual, once the publication is requested for a document, I am doing 
> my AD review before continuing the publication process.
>
> I have one major issue with content and flow of this I-D: section 1 is 
> really informative and about the generic architecture, sections 4 and 
> others use a normative vocabulary and are not really about 
> architecture but more about RID. This is really weird: was that the 
> intent of the DRIP WG? Can it be fixed ? In the same vein, I suggest 
> to improve the flow/structure see below.
>
> The comments are direct for sake of time but except when noted do not 
> always need to be acted upon, I will welcome an explanation why this 
> comment was ignored though :-)
>
> Sec 1.1: the use of "commercial" is usually understand as for consumer 
> (i.e., recreative use) while I afraid that here it is more for 
> commercial aviation activities as opposed to recreative ones. Worth 
> clarifying or using a different word than commercial.
>
> Sec 1.2.1 is it "received UAS ID" or "received UAS RID" ? If "ID", is 
> it worth explaining why "ID" is used here?
>
> Sec 1.2.1 please expand LOS at first use in "RF LOS" (perhaps also 
> expand "RF") at the expanse of readability
>
> Sec 1.2.1 "link based ID" same question about "ID" vs. "RID" (there 
> should also be a '-' as in "link-based")
>
> Sec 1.2.2 "GNSS" expand at first use
>
> Sec 1.2.2 add a note somewhere about the "4-D airspace" as not 
> everyone is aware of the change of rules based on time of the day
>
> Sec 1.2.2 increment the year in "currently (in the year of 2021)"
>
> good for the IETF, this could be OK but the document must be clear 
> that section 1.2 is the US FAA position, not a global one.
>
> Sec 1.4 is "general UAS RID usage scenario" really general ? I.e., is 
> it applicable outside of US FAA/CA CAA ?
>
> Sec 3.1: why only crypto abbreviations ? There are so many 
> aeronautical acronyms that they should be there as well and this § 3.1 
> should be moved ahead just after §1 (assuming that §1.1 and others 
> become top-level sections)
>
> Sec 4 at multiple places, the text is rather dense and dry, could 
> there be some figures to help understanding ?
>
> Sec 4.1: the last paragraph is a single sentence of 7 lines...Please 
> consider rewriting in an easier to read paragraph.
>
> Sec 4.2: I cannot parse "This is in contrast to general IDs (...) as 
> the subject in an X.509 certificate."
>
> Sec 4.2: "by avoiding an explicit encoding technology like ASN.1 or 
> CBOR", so what encoding should be used ?
>
> Sec 5.1.1 s/public registry/public information registry/
>
> Sec 6: "DET (DRIP Entity Tag which is an HHIT-based UA ID)" should be 
> at least written as "DRIP Entity Tag (DET), which is an HHIT-based UAS 
> RID." And it probably deserves a definition / introduction on its own 
> (perhaps in § 3.1)
>
> Sec 7 "One obvious opportunity is to enhance the architecture with 
> gateways from Broadcast RID to Network RID.", while I do not disagree, 
> this section is not the right place to open the discussion. This 
> should be in the § 1 (with perhaps a forward reference to § 7)
>
> Sec 7 "crowd-sourced" indeed many ADS-B receivers are run by amateurs 
> (like my own) for flightradar24, flightaware, ... perhaps add a 
> reference ?
>
> Sec 7.2 "multilateration" should briefly be described, perhaps in the 
> terminology section
>
> Sec 8 "DRIP contact" is nice indeed but same comment as for the 
> CS-RID: this should really be part of the global architecture 
> description and not pushed at the end
>
> Sec 10 is very light and mainly focus on the private keys except for 
> the false flag issue (which deserves its own paragraph). Nothing is 
> said about privacy
>
> Finally, some nits:
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit