Re: [Drip] my (Stu) review of -drip-arch-16

[shuai zhao <[e-mail]>]

Hi Stu and All,

Revision -17 reflects the following updates


> On Nov 8, 2021, at 10:42 PM, Stuart W. Card <[e-mail]> wrote:
> 
> Section 1.1 EASA Paragraph is garbled: [Delegated] and [Implementing] don't make sense without the word "Regulations" after them; "unmanned aircraft systems" was previously spelled out so use "UAS".

Shuai/ now implemented in revision -17 as follows: 

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.


> 
> Section 1.2.1 spell out UA on 1st use (currently it is only expanded in parentheses on a later use).

Shuai/ updated to "Broadcast RID provides information only about unmanned aircraft (UA)"
> 
> Section 1.2.1 in last sentence, move 1st parenthetical notation "(see Section 7)" to replace 2nd parenthetical notation (list of examples, as better ones are given in Section 7).

Shuai/ Bob proposed the following 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).

Please let me know if that works for you.


> 
> Section 1.2.2: definition of UAS does not belong here, but if one must be placed in this document, singular and plural forms need to agree; 2nd bullet claims UAS -> USS via a “secure internet connection” but F3411 specifies such a connection only between Net-RID SP & Net-RID DP; capitalize Internet.
> 

Shuai/ 1.2.2.  Network RID

   [F3411], 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.



> Section 1.3 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 regarding the UAS.

Shuai/ add "Editor-note-1: (Stu) re-draw this figure and propose text. Then double check the langauge in Editor-note-8"

> 
> Section 1.4: most of the 1st paragraph belongs earlier in Section 1, before Sections 1.2 & 1.3; in our debates over figures this past summer, I think we agreed to replace this Figure 4 with the larger picture, which was deemed too detailed for Requirements but suitable for Architecture; "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/ updated as follows:
1) 
1.  Introduction

   This document describes an architecture for protocols and services to
   support Unmanned Aircraft System Remote Identification and tracking
   (UAS RID), plus RID-related communications.  The architecture takes
   into account both current (including proposed) regulations and non-
   IETF technical standards.

   The architecture adheres to the requirements listed in the DRIP
   Requirements document [I-D.ietf-drip-reqs].  The requirements
   document provides an extended introduction to the problem space and
   use cases.


1.4.  Overview of DRIP Architecture

   Figure 4 illustrate a brief summary of the general UAS RID usage
   scenarios in DRIP.

2).  
        -  Mechanisms to leverage Domain Name System (DNS [RFC1034]),
         Extensible Provisioning Protocol (EPP [RFC5731]) and
         Registration Data Access Protocol (RDAP) ([RFC7482]) for
         publishing public and private information (see Section 5.1 and
         Section 5.2).

      -  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 (Section 5 and Section 6).

      -  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).

      -  Privacy in RID messages (PII protection) (Section 11).

3) the rest is implemented as suggested.

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


2.2.  Abbreviations

   EdDSA:      Edwards-Curve Digital Signature Algorithm

   HHIT:       Hierarchical HIT

   HIP:        Host Identity Protocol

   HIT:        Host Identity Tag

2.3.  Additional Definitions

> 
> Section 4.3 oops, sorry, my typo, “second pre-image attach” -> “second pre-image attack”

Shuai/ Updated. 

> 
> Section 5 needs to cite the corresponding numbered requirement[s] that it supports.
Shuai/ Added 

   Editor-note-4: Section 5 needs to cite the corresponding numbered
   requirement that it supports.”


> 
> Section 6 doesn’t use the word “authentication” in the section title, is there a reason to avoid it?

Shuai/ Added 

   Editor-note-5: 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.

Shuai/ added


   Editor-note-6: Section 7 needs to cite the corresponding numbered
   requirement that it supports.
"
> 
> Section 7.2 order of sentences should be reversed, to first introduce the purpose of the CS-RID SDSP, then specify its interface.

Shuai/ updated.

A CS-RID SDSP aggregates and processes (e.g., estimates UA location using including using multilateration when possible) 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.  

Editor-note-8: double check above paragraph after Editor-note-1 is resolved. 

> 
> Section A needs some tweaking to be standard English grammar, punctuation and style.

Shuai/ Updated 

> 
> Section A.2 "fly rules" is non-standard terminology.

Shuai/ Updated 

The LAANC program can automate the UAS operational
   intent (flight plan) submission and application for airspace
   authorization in real-time by checking against multiple aeronautical
   databases such as airspace classification and operating rules
   associated with it, FAA UAS facility map, special use airspace,
   Notice to Airmen (NOTAM), and Temporary Flight Restriction (TFR).


> 
> Suggested replacement text blurbs to follow soon.
> 
> -- 
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC  www.axenterprize.com
> 4947 Commercial Drive, Yorkville NY 13495