Subject: [Drip] urgent last minute pre-IETF113 draft deadline input re: AD review for draft-ietf-drip-arch-20

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 6 Mar 2022 15:03:50 -0500

This is my belated brief reply on those points where Shuai has 
specifically asked for my input. To avoid confusion, I am trimming all 
but those points. Sorry I have been unable to do more or sooner.

Shuai, as soon as you have something ready for Laura to proofread, as a 
fresh set of eyes and mistress of standard American English rules ;-) 
please point her to it.

Thanks all!

On 2/23/2022 4:13 PM, shuaiizhao(Shuai Zhao) wrote:
> ...
> Names are called, please response with your feedback.
> ...
> -----Original Message-----
> From: "Eric Vyncke (evyncke)" <[email-masked]>
> ...
>      Elided the text where we agree, and comments added with EV>
> ...
>      On 02/02/2022, 04:37, "Stuart W. Card" <[email-masked]> wrote:
> ...
>          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.
> ...
>          On 2/1/2022 11:29 AM, Eric Vyncke (evyncke) wrote:
> ...
>          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
> 
> SZ/ @Card, Stu, I am looking for input from you about this comment.  "4-D" was defined in RFC9153, should we repeat the definition here? So maybe I did not understand Eric's concern.

Let's not re-define any other term defined in RFC 9153. However, to 
address Eric's concern, we can explain that operations in airspace 
volumes, which would otherwise be 3-D, are of limited time duration, so 
UTM deconfliction and Net-RID reporting are in terms of 4-D volumes.

Extend

> various 4-D airspace volumes

as

"various 4-D airspace volumes (spatial volumes, time delimited to 
reflect the specific operations being conducted therein)"

>  ...
> " It justifies and explains the use of Hierarchical Host Identity Tags  (HHITs) [RFC7401] as self-asserting IPv6 addresses suitable as a UAS ID type  and more generally as trustworthy multipurpose remote identifiers."
> 
>           Sec 4: please specify that this section is only applicable to US FAA (if so)
> 
> SZ/ I don’t have a clear answer for that. I am assuming the design of DRIP RID is for "general" purpose, which is not only for FAA-based RID. @Card, Stu?

We have paid particular attention to EASA and FAA rules where we aware 
of them, but ASTM F3411 and our extensions of it in DRIP are intended 
for global use. Just state that, explicitly, in Section 1.4.

>          > ...
>          > 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.
> 
>      EV> then indeed 'opaque' is the wrong word but I am not sure that 'silent' is better. No proposal of mine though :(
> 
> SZ/ @Card, Stu, what is your final word choice?

If neither "opaque" nor "silent" suffice here, then neither will any 
other single word; an extended explanation of another sentence or two 
will be needed, along the lines of my "What was meant was..." above.

>          > ...
>          > Sec 6: I was unable to find a definition of "trustworthiness" in
>          > [I-D.ietf-drip-reqs]
> 
>          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?
> 
>      EV> good idea, simply enumerate (reliability, scalability, ...) rather than using "as specified in " ;-)
> SZ/ @Card, Stu it seems to me you may have a solution for this comment?

Perhaps the real problem here is the use in -arch of the word 
"specified" in 'While the DRIP entity identifier is self-asserting, it 
alone does not provide the "trustworthiness" specified in 
[I-D.ietf-drip-reqs].' Specified is too strong of a word. -reqs "calls 
for" or "identifies the need for" trustworthiness, which it does not define.

I suggest removing the quotation marks around "trustworthiness" and 
rewriting as

"While the DRIP entity identifier is self-asserting, it alone does not 
provide the trustworthiness (non-repudiability, protection vs spoofing, 
message integrity protection, scalability, etc.) essential to UAS RID, 
as justified in [I-D.ietf-drip-reqs]."

>> ...
>          > Sec 7.1 this should really be part of the overall architecture of section 1
> 
>          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.
> 
>      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 ?
> 
> SZ/ @Card, Stu, I feel like more discussion is needed regarding how to address this section. Please let me know what is your thinking.

The earlier introduction would have to be in section 1.4 "Overview of 
DRIP architecture" which includes:

>       -  Harvesting broadcast RID messages for UTM inclusion
>          (Section 7).
> 
>       -  Methods for instantly establishing secure communications
>          between an Observer and the pilot of an observed UAS
>          (Section 8).

which we could re-write as

"     -  Harvesting broadcast RID messages for UTM inclusion,
	with the optional DRIP extension of Crowd Sourced Remote
	Identification (CS-RID, Section 7), using the DRIP support
	for gateways required by GEN-5 [I-D.ietf-drip-reqs].

       -  Methods for instantly establishing secure communications
         between an Observer and the pilot of an observed UAS
	(Section 8), using the DRIP support for dynamic contact
	required by GEN-4 [I-D.ietf-drip-reqs]."

> ...
>          Sec 7.2 " multilateration" should briefly be described, perhaps in the terminology section
> SZ/ @Card, Stu "multilateration" was not described in req. Should we do it here?

Well, RFC 9153 has already been published, so we have to do it here, but 
only _briefly_: it is not the job of an IETF RFC to provide a tutorial 
on a technology that lies largely outside IETF scope, which we merely 
wish to support with suitable network protocols. We can put this not in 
7.2 but in the introductory part of Section 7, right after this sentence:

> Surveillance SDSPs can use messages with precise date/time/
>    position stamps from the gateways to multilaterate UA location,
>    independent of the locations claimed in the messages, which are
>    entirely operator self-reported in UAS RID and UTM, and thus are
>    subject not only to natural time lag and error but also operator
>    misconfiguration or intentional deception.

"Multilateration technologies use physical layer information, such as 
precise Time Of Arrival (TOA) of transmissions from mobile transmitters 
at receivers with _a priori_ precisely known locations, to estimate the 
locations of the mobile transmitters."

>          > ...
>          > 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.
> 
>      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.
> ...
> SZ/ @Card, Stu should we trim down the details regarding HIP/BEET?

Rewrite

> An Observer equipped with HIP can
>    initiate a Base Exchange (BEX) and establish a Bound End to End
>    Tunnel (BEET) protected by IPsec Encapsulating Security Payload (ESP)
>    encryption to a likewise equipped and identified entity: the UA
>    itself, if operating autonomously; the GCS, if the UA is remotely
>    piloted and the necessary records have been populated in DNS;
>    likewise the USS, etc.  Certain preconditions are necessary: each
>    party to the communication needs a currently usable means (typically
>    DNS) of resolving the other party's DRIP entity identifier to a
>    currently usable locator (IP address); and there must be currently
>    usable bidirectional IP (not necessarily Internet) connectivity
>    between the parties.  Given a BEET, arbitrary standard higher layer
>    protocols can then be used for Observer to Pilot (O2P) communications
>    (e.g., SIP [RFC3261] et seq), V2X communications (e.g., [MAVLink]),
>    etc.  

as

"	A suitably equipped Observer could initiate a cryptographic
	handshake to a likewise equipped and identified entity: the UA
	itself, if operating autonomously; the GCS, if the UA is
	remotely piloted and the necessary records have been populated
	in DNS; likewise the USS, etc. Assuming mutual authentication
	is successful, keys then can be negotiated for an IPsec
	Encapsulating Security Payload (ESP) tunnel, over which
	arbitrary standard higher layer protocols can then be used for
	Observer to Pilot (O2P) communications (e.g., SIP [RFC3261]
	et seq), V2X communications (e.g., [MAVLink]), etc. Certain
	preconditions are necessary: each party needs a currently
	usable means (typically DNS) of resolving the other party's DRIP
	entity identifier to a currently usable locator (IP address);
	and there must be currently usable bidirectional IP (not
	necessarily Internet) connectivity between the parties. One
	method directly supported by the use of HHITs as DRIP entity
	identifiers is initiation of a HIP Base Exchange (BEX) and
	Bound End-to-End Tunnel (BEET).

I hope this suffices. Thanks!

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

---

From: shuai zhao <[email-masked]>
Date: Sun, 6 Mar 2022 16:45:59 -0800

Dear Stu and All,

Please see updated -21, with ALL the changes requested/suggested by Med (on 03/06 and 02/24 ) and Stu’s comment today. 

@Laura, the submission deadline is next Monday,  March 7th, 6:59PM (EST).  Please give me at least one-hour (or more) to address any comments you may have. 

Quick Summary: 
- Abstract update based on Med’s suggestion
- update "I-D.ietf-drip-reqs” with “RFC9153"
- Add a preamble in section 1.2, to expilicit saying that Broadcast RID and network RID are defined in ASTM F3411.
- Explicit stating DRIP Architecture is for global UAS RID operation.
	1.4.  Overview of DRIP Architecture
   	Figure 4 illustrates a global UAS RID usage scenario
- Other minor text updated per comments from Stu

I will provide a detailed summary later tonight for things we may have missed, which not much I think. 

Best,
Shuai

> SZ/ @Card, Stu, I am looking for input from you about this comment.  "4-D" was defined in RFC9153, should we repeat the definition here? So maybe I did not understand Eric's concern.

Let's not re-define any other term defined in RFC 9153. However, to address Eric's concern, we can explain that operations in airspace volumes, which would otherwise be 3-D, are of limited time duration, so UTM deconfliction and Net-RID reporting are in terms of 4-D volumes.

SZ/ Med suggested just to refer Section 2.2 of RFC9153, which I think it is much simpler solution. 

> On Mar 6, 2022, at 12:03 PM, Stuart W. Card <[email-masked]> wrote:
> 
>>         > ...
> If neither "opaque" nor "silent" suffice here, then neither will any other single word; an extended explanation of another sentence or two will be needed, along the lines of my "What was meant was..." above.
> 
>>         > …
SZ/ I suggest just remove this sentence "The Observer may visually "see" these Net-RID UAS, but they may be silent to the Observer.”
We are overstating how Net-RID works, this sentence only makes confusion. 

Best,
Shuai

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 7 Mar 2022 07:43:51 -0500

Thanks Shuai and Laura.

As "Broadcast RID" & "Network RID" are, in that exact form, terms defined
in F3411 and so listed in the RFC 9153 DRIP terminology section, and are
specifically for UAS RID, we should pull "UAS" out of the middle of
"Broadcast UAS RID" and "Network UAS RID", while retaining "UAS" as a
prefix to "RID" anywhere "RID" is not prefixed with "Broadcast" or
"Network".

On Sun, Mar 6, 2022, 22:44 Laura Welch <[email-masked]> wrote:

> I will go through it tomorrow morning and get you my comments by mid-day.
> Best,
> Laura
> ------------------------------
> *From:* shuai zhao <[email-masked]>
> *Sent:* Sunday, March 6, 2022 7:45 PM
> *To:* Stuart W. Card <[email-masked]>; Laura Welch <
> [email-masked]>
> *Cc:* [email-masked] <[email-masked]>; Adam Wiethuechter <
> [email-masked]>; [email-masked] <[email-masked]>;
> Robert Moskowitz <[email-masked]>; Eric Vyncke (evyncke) <
> [email-masked]>; Daniel Migault <[email-masked]>;
> [email-masked] <[email-masked]>
> *Subject:* Re: urgent last minute pre-IETF113 draft deadline input re: AD
> review for draft-ietf-drip-arch-20
>
> Dear Stu and All,
>
> Please see updated -21, with ALL the changes requested/suggested by Med
> (on 03/06 and 02/24 ) and Stu’s comment today.
>
> @Laura, the submission deadline is next Monday,  March 7th, 6:59PM (EST).
> Please give me at least one-hour (or more) to address any comments you may
> have.
>
> Quick Summary:
> - Add a preamble in section 1.2, to expilicit saying that Broadcast RID
> and network RID are defined in ASTM F3411.
>         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
> SZ/ @Card, Stu, I am looking for input from you about this comment.  "4-D"
> was defined in RFC9153, should we repeat the definition here? So maybe I
> did not understand Eric's concern.
>
>
> address Eric's concern, we can explain that operations in airspace volumes,
> which would otherwise be 3-D, are of limited time duration, so UTM
> deconfliction and Net-RID reporting are in terms of 4-D volumes.
>
>     EV> then indeed 'opaque' is the wrong word but I am not sure that
> 'silent' is better. No proposal of mine though :(
> If neither "opaque" nor "silent" suffice here, then neither will any other
> single word; an extended explanation of another sentence or two will be
> needed, along the lines of my "What was meant was..." above.
>
>         > …
>
> SZ/ I suggest just remove this sentence "The Observer may visually "see"
> these Net-RID UAS, but they may be silent to the Observer.”

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 7 Mar 2022 08:43:07 -0500

Sections 2 & 3 should be merged, re-ordered and a lost sentence
re-inserted, as follows --

2.  Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.

To encourage comprehension necessary for adoption of DRIP by the
intended user community, the UAS community's norms are respected
herein.

This document uses abbreviations and terms defined in [RFC9153].

2.1.  Additional Abbreviations

<content from current 2.1, except for current 1st sentence moved out
of sub-section where it is confusing and inserted directly under
section 2 as shown above>

2.2 Additional Definitions

<all content of current 2.2>

---

From: <[email-masked]>
Date: Mon, 7 Mar 2022 15:09:30 +0000

Re-,

Thank you Laura for sharing these edits. Much appreciated!

I trust Shuai will check the edits and make sure that the initial intent is not altered.

Shuai, please add Laura to the ACK section. Thanks.

Cheers,
Med

De : Laura Welch <[email-masked]>
Envoyé : lundi 7 mars 2022 15:58
À : Card, Stu <[email-masked]>; shuai zhao <[email-masked]>
Cc : [email-masked]; Adam Wiethuechter <[email-masked]>; Andrei Gurtov <[email-masked]>; Robert Moskowitz <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; Daniel Migault <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Objet : Re: urgent last minute pre-IETF113 draft deadline input re: AD review for draft-ietf-drip-arch-20

Hello All:

Attached are my edits, excluding Stu's requested changes below. I was conservative about making changes, limiting my edits to grammar corrections/clarifications only when necessary to assure clarity and consistency. At this late hour I did not want to risk changing any technical meanings. I'm also not incredibly fluent in markdown, so I didn't want to risk making major changes, such as the order changes Stu recommends.

I left the version number the same and added my initials for version control.

Laura
________________________________
From: Card, Stu <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 7, 2022 8:43 AM
To: Laura Welch <[email-masked]<mailto:[email-masked]>>; shuai zhao <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Adam Wiethuechter <[email-masked]<mailto:[email-masked]>>; Andrei Gurtov <[email-masked]<mailto:[email-masked]>>; Robert Moskowitz <[email-masked]<mailto:[email-masked]>>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>; Daniel Migault <[email-masked]<mailto:[email-masked]>>; Mohamed Boucadair <[email-masked]<mailto:[email-masked]>>
Subject: Re: urgent last minute pre-IETF113 draft deadline input re: AD review for draft-ietf-drip-arch-20

Sections 2 & 3 should be merged, re-ordered and a lost sentence re-inserted, as follows --

2.  Terms and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.

To encourage comprehension necessary for adoption of DRIP by the intended user community, the UAS community's norms are respected herein.
This document uses abbreviations and terms defined in [RFC9153].

<content from current 2.1, except for current 1st sentence moved out of sub-section where it is confusing and inserted directly under section 2 as shown above>

On Sun, Mar 6, 2022, 22:44 Laura Welch <[email-masked]<mailto:[email-masked]>> wrote:
I will go through it tomorrow morning and get you my comments by mid-day.
Best,
Laura
________________________________
From: shuai zhao <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, March 6, 2022 7:45 PM
To: Stuart W. Card <[email-masked]<mailto:[email-masked]>>; Laura Welch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Adam Wiethuechter <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Moskowitz <[email-masked]<mailto:[email-masked]>>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>; Daniel Migault <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: urgent last minute pre-IETF113 draft deadline input re: AD review for draft-ietf-drip-arch-20

Dear Stu and All,

Please see updated -21, with ALL the changes requested/suggested by Med (on 03/06 and 02/24 ) and Stu's comment today.

Quick Summary:
- Abstract update based on Med's suggestion
- update "I-D.ietf-drip-reqs" with "RFC9153"
- Add a preamble in section 1.2, to expilicit saying that Broadcast RID and network RID are defined in ASTM F3411.
- Explicit stating DRIP Architecture is for global UAS RID operation.
1.4.  Overview of DRIP Architecture
    Figure 4 illustrates a global UAS RID usage scenario
- Other minor text updated per comments from Stu

Best,
Shuai

SZ/ I suggest just remove this sentence "The Observer may visually "see" these Net-RID UAS, but they may be silent to the Observer."
We are overstating how Net-RID works, this sentence only makes confusion.

Best,
Shuai

_________________________________________________________________________________________________________________________

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.