Subject: [Drip] Fwd: [Internet]RE: upcoming DRIP session (multi sub-topics, was : IETF#112: Note Taker)

From: "Card, Stu" <[email-masked]>
Date: Wed, 10 Nov 2021 09:13:53 -0500

all --

Please find below a forward of a message I sent late last night to the
authors of draft-ietf-drip-arch and to the DRIP Working Group chairs, which
I should have sent to the entire WG.
It contains my specific suggested text blurbs to address my remaining
concerns with our Architecture draft and to clean it up preparatory to our
sending to IESG for review.
It suggests _inter alia_ discussion tomorrow of two of the figures (items 5
and 7) and leaves as to-do-ASAP a few final textual reviews/cleanups.
Please check this over before tomorrow's session if at all possible.
Thanks!

---------- Forwarded message ---------
From: Card, Stu <[email-masked]>
Date: Wed, Nov 10, 2021 at 12:47 AM
Subject: Re: [Internet]RE: upcoming DRIP session (multi sub-topics, was :
IETF#112: Note Taker)
To: shuaiizhao(Shuai Zhao) <[email-masked]>
Cc: [email-masked] <[email-masked]>, Daniel
Migault <[email-masked]>, Robert Moskowitz <
[email-masked]>, Robert Moskowitz <[email-masked]>,
[email-masked] <[email-masked]>

Responses with specific suggested replacement text are interleaved below.

On Tue, Nov 9, 2021 at 1:18 PM shuaiizhao(Shuai Zhao) <
[email-masked]> wrote:

> Hi All,
>
> Since revision -16, I have received 3 emails from Stu and Bob for reviews.
>
> Comments and replies are getting messy, to avoid missing any of your
> previous comments, I am listing things below which still need Stu's
> feedback.
>
> I saw Stu provides another comment but not related to the things we are
> desperately need for publication.
>
> I suggest we fix them one by one, either confirm or propose text.
>
> 1.
> -------------
> > FAA paragraph:
> > - "whereafter" -> "thereafter"
> > - Sentence 2 could be deleted if Sentence 1 had appended to it "imposing
> > requirements on UAS manufacturers and operators".
> >
> > Shuai/ Not sure what do you mean here. Some ppl liked and insisted on
> > referring to ADS-B in arch-.
>

I was not objecting to retaining a brief statement about the CAAs saying no
to ADS-B.
I was merely proposing clearer and more succinct language than I found in
earlier drafts.
What is in -arch-16 is not bad, but if you wish to update it, I propose the
following.

"The FAA published a Notice of Proposed Rule Making [NPRM] in 2019
and thereafter published a "Final Rule" in 2021 [FAA_RID],
imposing requirements on UAS manufacturers and operators,
both commercial and recreational. The rule clearly states that
Automatic Dependent Surveillance Broadcast (ADS-B) Out
and transponders cannot be used to satisfy the RID requirements
on UAS to which the rule applies (see Appendix B)."

> 2.
> ------------
> > p. 4 EASA paragraphs:
> > -[Delegated] and [Implementing] don't make sense without the word
> > "Regulations" after each of them.
> >
> > Shuai/ I don’t see why we have to a add “regulation” after each word
> > since the context here said they are “regulations”. Adding the
> > “Regulations” after each word also does not make sense.  See below:
> >
> >>The EASA has published the {{Delegated}}regulationsin 2019 to provide
> > regulations for unmanned aircraft systems and on third-country operators
> > of unmanned aircraft systems and followed with implementation regulation
> > on the rules and procedures for the operation of unmanned aircraft
> > Regulations {{Implementing}} regulations.
>

This paragraph remains garbled. I propose the following text.

"The EASA published a [Delegated] regulation in 2019 imposing
requirements on UAS manufacturers and third-country operators,
including but not limited to RID requirements. The EASA also published
in 2019 an [Implementing] regulation laying down detailed rules and
procedures for UAS operations and operating personnel."

> 3.
> ------------
> > p. 5 Section 1.2.1:
> > - Figure 1 still uses stick figures and aircraft silhouettes, which were
> > replaced with boxes in the Requirements document, based on comments
> > received, I suggest replacing w/Requirements Figure 4
> >
> >
> > - last sentence in section: move 1st parenthetical notation "(see
> > Section 7)" to replace 2nd "(e.g., an entire military base or a national
> > forest)"
> >
> > Shuai/ If I understood you right, you want to cut (e.g. around airports,
> > public  gatherings, and other sensitive areas) from Section 7 and
> > replace "(e.g., an entire military base or a national forest)” in
> > Section 2, right?
>

I propose the following specific replacement text.

"Broadcast RID provides information only about unmanned aircraft
(UA) within direct RF LOS, typically similar to visual Light-Of-Sight
(LOS), with a range up to approximately 1 km.  This information
may be 'harvested' from received broadcasts and made available
via the Internet, enabling surveillance of areas too large for
local direct visual observation or direct RF link based ID
(see Section 7)."

> 4.
> ------------
> >
> > p. 5 Section 1.2.2
> > - After spelling out "Network Remote ID" once, further instances can all
> > be shortened to "Network RID" or even "Net-RID".
> > - "A RID data dictionary and data flow for Network RID are defined in
> > [F3411-19]" -> "[F3411-19] defines a RID data dictionary and data flow
> > for Internet based information delivery"
> > - "Observer" is our own DRIP term; F3411 calls the consumer of Network
> > RID information the "client", which word previously appeared here; we
> > could say "Observer's Network RID client device".
> > - A definition of UAS does not belong here. If one must be placed in
> > this document, singular and plural forms need to agree.
> >
> > Shuai/ Stu,  I recall we had this conversation long time ago, not sure
> > why we are going down this path again. Please choose one then we stick
> > to it.
>

I propose the following specific replacement text.

"[F3411-19], using the same data dictionary that is the basis of
Broadcast RID messages, defines a Network Remote Identification
(Net-RID) data flow as follows.

* The information to be reported via RID is generated by the UAS
(typically some by the UA and some by the GCS, e.g. their respective
GNSS derived locations).

* The information is sent by the UAS (UA or GCS) via unspecified means
to the cognizant Network Remote Identification Service Provider (Net-RID
SP),
typically the USS under which the UAS is operating if participating in UTM.

* The Net-RID SP publishes via the Discovery and Synchronization Service
(DSS) over the Internet that it has operations in various 4-D airspace
volumes,
describing the volumes but not the operations.

* An Observer's device, expected typically but not specified to be web
based,
queries a Network Remote Identification Display Provider (Net-RID DP),
typically also a USS, about any operations in a specific 4-D airspace
volume.

* Using fully specified web based methods over the Internet, the Net-RID DP
queries all Net-RID SP that have operations in volumes intersecting that
of the Observer's query for details on all such operations.

* The Net-RID DP aggregates information received from all such Net-RID SP
and responds to the Observer's query."

> 5.
> ------------
> > - Figure 3 is confusing:
> >   = the Observer _sees_ (or hears, or otherwise senses) UAS but does not
> > _connect_ to them;
> >   = the Observer can connect via the Internet to another USS (and thence
> > via the DSS) for queries re: the UAS.
> >
> > Shuai/ This require a little more drawing. I am thinking postponing to
> > another revision once we have agreed on the final drawing.
>

I agree we need a revised drawing but will not attempt to draw it tonight.

> 6
> ------------
> > p. 8 Section 1.4:
> > - Most of the 1st paragraph (all but reference to Figure 4) belongs
> > earlier in Section 1, certainly before Sections 1.2 & 1.3
> >
> > Shuai/ Is that necessary to remove this at all? Can we live with it?
>

The 1st paragraph of 1.4 provides an introduction,
1.2 and 1.3 provide details, generally it is preferable
to put introductions before details.

> 7
> ------------
> > - In our debates over figures this past summer, I think we agreed to
> > replace this Figure 4 with the attached figure, which was deemed too
> > detailed for the Requirements doc.
> >
> > Shuai/ I recall chair prefer not to change the figure. There are many
> > terms are not used/explained such as GPOD, PSOD…
>

My understanding of Med's comment this past summer remains
that he did not like putting this figure in Requirements
but felt it was appropriate for Architecture.
Let's get the WG consensus this Thursday.

> 8
> ------------
> > p. 9 Section 1.4:
> > - "This document outlines the UAS RID architecture" -> "This document
> > outlines the DRIP architecture in the context of the UAS RID
> architecture"
> > - ("including DNS:" -> "(DNS)"
> > - need a line about authentication formats/protocols (after DNS etc.,
> > before "Harvesting")
> > - need a line about Observer to Pilot (O2P) comms (after "Harvesting",
> > before "Privacy")
> >
> > Shuai/ in order to reduce debate on the wording, please provide the
> > sentence you would like to see for both of above bullet points.
>

Still need to replace "DNS:" with simply "DNS" (no trailing colon).

I suggest the following replacement text for the first bullet.

" - Design of trustworthy remote identifiers (Section 4)."

I suggest the following additional bullet texts.

"- Specific authentication methods and message payload formats
to enable verification that Broadcast RID messages were sent
by the claimed sender (Section 6) and that sender is in the
claimed registry (Sections 5 and 6)."

"- Methods for instantly establishing secure communications
between an Observer and the pilot of an observed UAS (Section 8)."

Section 2 let’s define only acronyms, terms, etc. not defined in the
Requirements document.

> 9
> ------------
> > p. 13 Section 4.2:
> > - "the HHIT RID" -> "a HHIT used as a UAS ID" because "RID" is neither
> > "Remote Identity" nor "Remote Identifier" but "Remote Identification" so
> > "RID" should never be used this way, instead use "UAS ID"
> > - last paragraph of this section is suspect, we need both Adam and Bob
> > to review it carefully
> >
> > Shuai/ Bob and Adam, please review as Stu pointed out.

It is really only the 1st sentence of the last paragraph that I find
suspect.
Bob? Adam?

Section 4.3 I previously gave you text with a typo that Bob caught,
“second pre-image attach” should be “second pre-image attack”.

Section 5 needs to cite the corresponding numbered requirement[s] that it
supports.
Section 6 doesn’t use the word “authentication” in the section title, is
there a reason to avoid it?

Section 7 needs to cite the corresponding numbered requirement[s] that it
supports.

Section 7.2 I suggest reversing the order of the 2 sentences as follows.
"A CS-RID SDSP aggregates and processes (e.g., estimates UA location using)
information collected by CS-RID Finders. A CS-RID SDSP should appear
(i.e. present the same interface) to a Net-RID SP as a Net-RID DP."

> 10
> ------------
> > pp. 17ff All references should be checked for accurate titles, live
> > links, citation style, etc.
> >
> > Shuai/ Left for another revision
>

Acknowledged.

> 11
> ------------
> > pp. 20ff Section A needs some tweaking to be standard English grammar,
> > punctuation and style.
> >
> > Shuai/ Left for another revision

Acknowledged.

> 12
> ------------
> > p. 21 Section A.2:
> >   - TFR is Temporary Flight Restriction (not Rule);
> >   - "fly rules" is non-standard terminology; see also next comment.
> > p. 22 Section A.3: "UAS fly map" appears only in this document and one
> > 3GPP document; is there a standard term?
> >
> > Shuai/ it is referent to
> > https://www.faa.gov/uas/commercial_operators/uas_facility_maps/
> > <https://www.faa.gov/uas/commercial_operators/uas_facility_maps/>, The
> > FAA Facility Map. Changed to “UAS Facility map”
>

Thank you for changing "fly map" to "UAS Facility Map".
Can we also change "fly rules" to "flight rules" or "operating rules"?
Unless there is some other standard term?

> 13.
> ------------
> > p. 23 Acknowledgements should be updated to include everyone who has
> > helped, other than authors.
> >
> > Shuai/ Please provide a list and text.

I suggest adding everyone who has participated in mailing list discussion
of -arch
and topics addressed therein (including even ADS-B). This would include:
Alexandre Petrescu, Stephan Wenger, Daniel Migault, Eric Vyncke.

The Acknowledgements section of -reqs reads as follows.

"The work of the FAA's UAS Identification and Tracking (UAS ID)
   Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
   [F3411-19] and IETF DRIP efforts.  The work of Gabriel Cox, Intel
   Corp., and their Open Drone ID collaborators opened UAS RID to a
   wider community.  The work of ASTM F38.02 in balancing the interests
   of diverse stakeholders is essential to the necessary rapid and
   widespread deployment of UAS RID.  IETF volunteers who have
   extensively reviewed or otherwise contributed to this document
   include Amelia Andersdotter, Carsten Bormann, Toerless Eckert, Susan
   Hares, Mika Jarvenpaa, Alexandre Petrescu, Saulo Da Silva and Shuai
   Zhao.  Thanks to Linda Dunbar for the Secdir review, Nagendra Nainar
   for the Opsdir review and Suresh Krishnan for the Gen-ART review.
   Thanks to IESG members Roman Danyliw, Erik Kline, Murray Kucherawy
   and Robert Wilton for helpful and positive comments.  Thanks to
   chairs Daniel Migault and Mohamed Boucadair for direction of our team
   of authors and editor, some of whom are newcomers to writing IETF
   documents.  Thanks especially to Internet Area Director Eric Vyncke
   for guidance and support."

> On 11/8/21, 10:50 PM, "[email-masked]" <
> [email-masked]> wrote:
>
>     Hi Stu, all,
>
>     Thank you for accepting to take minutes. Much appreciated, as usual.
>
>     Agree with your both points on the arch draft. The figure fits the
> arch to illustrate a usage scenario. However, we need to make sure that:
>     * all the acronyms/interfaces should be called out in the text.
>     * make it clear that some interfaces are not within the scope of drip
> (DAA/V2V, for example).
>
>     BTW, may I remind us all that the plan for the arch I-D was as
> follows:
>
>     ==
>     In order to help Shuai digest and integrate any pending proposed
> change, I suggest the following plan:
>
>     .   Any listed author (including the editor) to reply before November
> 3rd whether you are OK with the latest version or raise any issue you
> have.
>     .   If an issue is raised, please make sure a text change is proposed.
>     .   Shuai to prepare a revised version to be submitted in the IETF
> week.
>
>     Please note that we are not seeking for a perfect I-D :-)
>     ==
>
>     Thank you.
>
>     Cheers,
>     Med
>
>     > -----Message d'origine-----
>     > De : Daniel Migault <[email-masked]>
>     > Envoyé : lundi 8 novembre 2021 20:37
>     > À : Stuart W. Card <[email-masked]>; BOUCADAIR Mohamed
>     > INNOV/NET <[email-masked]>; shuaiizhao(Shuai Zhao)
>     > ([email-masked]) <[email-masked]>
>     > Cc : [email-masked]
>     > Objet : Re: upcoming DRIP session (multi sub-topics, was : IETF#112:
> Note
>     > Taker)
>     >
>     >
>     >
>     > ________________________________________
>     > From: Stuart W. Card <[email-masked]>
>     > Sent: Monday, November 8, 2021 1:01 PM
>     > To: [email-masked]; shuaiizhao(Shuai Zhao)
>     > ([email-masked])
>     > Cc: [email-masked]
>     > Subject: upcoming DRIP session (multi sub-topics, was : IETF#112:
> Note
>     > Taker)
>     >
>     > Med, Shuai, et al --
>     >
>     > As Shuai is presenting and I am not, I can more easily take notes.
>     >
>     >
>     > mglt: great thanks!
>     >
>     > I would not mind being allocated 1 minute during the introduction to
> give
>     > a quick oral (no slides unless you want me to make 1-2) update:
>     >
>     > mglt: during the status, that should be ok, please add yourself on
> the
>     > agenda on the etherpad, so we are sure we donot forget you.
>     >
>     > - Currently proposed (consensus of the ASTM working group but not yet
>     > balloted upon) changes in ASTM F3411 enable and recognize our DRIP
>     > extensions thereto.
>     >
>     > - Multiple US Federal agencies now recognize the need to instantly
>     > establish Observer to Pilot (O2P) private communications based on
> RID.
>     >
>     > Perhaps Bob should use 1 minute to update everyone on his
> interactions in
>     > the ICAO Trust Framework Study Group?
>     >
>     > Perhaps Adam should use 1 minute to update everyone on his prototype
>     > implementation of much of DRIP (including solution space designs
> that are
>     > still individual rather than working group drafts)?
>     >
>     > I am going to send today my review of Shuai's latest -arch. There is
>     > confusion on some points, including:
>     >
>     >
>     > - Do we really want to redundantly define in -arch a subset of the
> terms
>     > defined in -reqs despite having declared that -reqs would serve as
> the
>     > common glossary for DRIP?
>     >
>     > mglt: that is good. no, just mention the one not defined in reqs.
>     >
>     > - The attached figure that I proposed several months ago to show the
> big
>     > picture, which I believe you said did not belong in -reqs but did
> belong
>     > in -arch, Shuai has the impression you don't want in -arch either?
> Note
>     > that GPOD and PSOD are not terms we intend to use anywhere else, just
>     > abbreviations to keep the figure compact, which we define as such in
> the
>     > legend below the figure. The figure requires a disclaimer that it
> does not
>     > show one way Broadcast RID wireless links from each UA to all
> receivers in
>     > range (which would clutter the figure confusingly).
>     >
>     > mglt: my last recollection of the draft is very very old. do
> whatever you
>     > think is best and will speed up the draft to be in a state ready to
> be
>     > published. ;-)
>     >
>     > After resolving a few such content issues and cleaning up a few
> remaining
>     > mundane editorial issues, -arch should move forward.
>     >
>     > mglt: I hope so.
>     >
>     > Thanks.
>     >
>     > -- Stu
>     >
>     > On 11/8/2021 9:35 AM, [email-masked] wrote:
>     > > Hi Stu, Shuai,
>     > >
>     > > Would you be willing to take minutes for the forthcoming drip
> session?
>     > >
>     > > Thank you in advance.
>     > >
>     > > Cheers,
>     > > Med
>     > --
>     > -----------------------------------------
>     > Stuart W. Card, PhD, Principal Engineer
>     > AX Enterprize, LLC  https://protect2.fireeye.com/v1/url?k=4771b1b2-
>     >
> 18ea889f-4771f129-8692dc8284cb-6d846366b7baec10&q=1&e=7a467ce1-a2d6-4239-
>     > 9406-d65e113e0df7&u=http%3A%2F%2Fwww.axenterprize.com%2F
>     > 4947 Commercial Drive, Yorkville NY 13495
>
>
> _________________________________________________________________________________________________________________________
>
>     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.
>
>
>
>
>