Subject: [Drip] I-D Action: draft-ietf-drip-reqs-05.txt

From: [email-masked]
Date: Fri, 16 Oct 2020 20:53:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : Drone Remote Identification Protocol (DRIP) Requirements
        Authors         : Stuart W. Card
                          Adam Wiethuechter
                          Robert Moskowitz
                          Andrei Gurtov
	Filename        : draft-ietf-drip-reqs-05.txt
	Pages           : 34
	Date            : 2020-10-16

Abstract:
   This document defines terminology and requirements for Drone Remote
   Identification Protocol (DRIP) Working Group protocols to support
   Unmanned Aircraft System Remote Identification and tracking (UAS RID)
   for security, safety and other purposes.  Complementing external
   technical standards as regulator-accepted means of compliance with
   UAS RID regulations, DRIP will:

      facilitate use of existing Internet resources to support UAS RID
      and to enable enhanced related services;

      enable online and offline verification that UAS RID information is
      trustworthy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-reqs-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Stuart W. Card" <[email-masked]>
Date: Sat, 17 Oct 2020 00:29:00 -0400

> 	Filename        : draft-ietf-drip-reqs-05.txt
I thank my co-authors, our co-chairs, our AD, and all the reviewers,
especially Alexandre P., Amelia A., Fanny P., Michael R. and Shuai Z.,
all of whom helped improve this draft greatly over the past few revs.

Fanny P's review was most recent, so she, I and the WG have not yet
necessarily reached consensus on all the points she raised. I have
attempted to address each: some w/draft edits; some w/rebuttals. Her
points and my responses comprise the last portion of this email. First,
3 shorter lists of what edits I did or did not make in this latest rev.

(1) updates made per reviewer inputs

Made all changes listed on my slides in previous interim
Massively restructured sections 1 (intro inc. concerns & constraints) &
3 (problem space)
Added “defines terminology” to abstract (but not title)
Normalized citations of terminology sources
Cited ICAO Circular 328 for terminology
Cited SESAR Joint Undertaking architectural principles for U-space
Replaced “potential follow-on goals” w/ “timely trustworthy ID data is
prerequisite to ID-oriented networking”
Inserted ASCII art of general scenario, Network & Broadcast RID data flows
Clarified at which layers DRIP applies therein
Listed performance & reliability under QoS
Cited ASTM specific performance requirements
Expanded regulatory “requirement could be met”; moved it out of
definitions section
Clarified ID-2 vs ID-3
Clarified ID-4 scope; gave examples of deregistration causes & times
Clarified DRIP will address multiple related registries TBD by
regulators; deferred registry information model; specified only registry
functions & information linkage by UAS ID
Clarified private registry access should be restricted by role of party
submitting query
Added minor clarifications & more UAS context
Checked spelling, punctuation, grammar, etc.

To satisfy some reviewers’ desire for more context or explanations,
especially of several numbered requirements, text has been added; but
other reviewers thought there were too many such notes already.

(2) reviewer suggested updates not made due to lack of WG consensus

Rename document to something other than Requirements
Remove definitions of terms unused in –reqs but likely to be used in
other DRIP docs
Delete or weaken any privacy requirements

(3) reviewer suggested updates not made due to my not knowing how

Clarify DRIP scope
Clarify GEN-10 requirement for multicast
Redefine AAA (Googling any 3 of the 7 terms in the broad definition
returned from 472k hits on {"attestation","access control","audit"} to
53.8M on  {"accounting","attribution","audit"})
Define authentication or other AAA elements
Define “RID service”

(4) [email-masked] review of draft-ietf-drip-reqs-04
FP comments, RGM interjections & SWC responses (draft edit or rebuttal)

FP: The scope of DRIP should be clarified.
SWC: I don't know how to do so any further; WG must direct me.

FP: The descriptions for BRID and NRID are somehow unclear and seem not
fully consistent throughout the document. Figures of their general
architecture should be provided, e.g. in the section "overall context".
SWC: Attempted in -05.

FP: Reading the document, it seems that NRID and BRID share the same
technical requirements / constraints (regarding security, privacy or
types of attack) and that one can be derived from the other. Given that
they are based on fundamentally different network architectures, this
should be clarified. Their common features and differences should be
highlighted, as well as the layer at which DRIP applies. In particular,
this would help derivate the requirements needed at lower layers.
RGM: ...what is done for broadcast DOES work for network but not the
other way. The commonality is the same data needs to be provided from
the UAS. What differs is how and to whom.  Broadcast is to any observer
within radio range... The lower layers for broadcast are already
provided...  Network will be over the Internet.
SWC: Clarification of ASTM F3411 NRID & BRID commonalities & differences
attempted in -05.

FP: It is quite hard to make a link between the technical description of
DRIP and the sections describing the overall context, scope and RID
solutions. For example, DRIP is about registries, but which registries?
The requirements of Section 4 should be included within the UTM /
U-space architecture.
RGM: DRIP is not about registries.  It needs them in some contexts, but
they are not in the 'driver's seat'.  Which registries? That is one of
the requirements!
SWC: As regulatory requirements for different registries and their
information content, as well as business models for meeting those
requirements, evolve, essential registry functional requirements should
remain the same, so only these are specified for DRIP. Clarification
attempted in -05.

FP: Many terms seem to be used with an aviation perspective and sound
quite strange from the radio / network perspective. This should be
clarified. Ex: coverage, latency, data dictionary, link outage,
instantaneous.
SWC: Clarification of any terms with different meanings to UAS and IETF
community members attempted in -05.

FP: The document is essentially based on [F3411-19], however how to link
it with other national / international regulations, in particular FAA
and EASA?
SWC: ASTM has attempted to satisfy requirements of both EASA (widely
expected to cite ASTM) & FAA (has already explicitly cited ASTM in
NPRM). Additional citations, to clarify what came from ASTM vs what came
from regulators, inserted in -05.

FP: Remote ID does not have the same functions as C2. The scope of DRIP
should be clarified.
RGM: C2 is not in scope, but secure C2 'naturally' falls out as a
function DRIP can help with.
SWC: DRIP requirements are specified not for uses of the identifier
(e.g. C2), but for how to ensure the identifier is immediately useful
(trustworthy and e.g. enabling ID-oriented IP applications that might
include C2).

FP quoting -reqs: "An Observer who classifies an UAS: as Taskable, can
ask it to do something useful; as Low Concern, can reasonably assume it
is not malicious, and would cooperate with requests to modify its flight
plans for safety reasons; as High Concern or Unidentified, is worth
focused surveillance." A reference should be provided: is this
classification commonly used? how to define useful, malicious,
reasonably...? In addition, this classification is not further used in
the document.
SWC: This classification is nonstandard, used only as illustrative
motivation; this is clarified in -05.

FP quoting -reqs: "Standard Specification for Remote ID and Tracking
(early drafts are freely available as [OpenDroneID] specifications)."
Other solutions for Remote ID could be given as examples.
SWC: I am aware of other RID related work, especially in 3GPP and
related organizations, but nothing that purports to be a full system
"solution" likely to be cited by regulators as an "accepted means of
compliance." If anyone in the WG points me to any, I will cite them.

FP quoting -reqs: "Network RID defines a set of information for UAS to
make available globally indirectly via the Internet, through servers
that can be queried by Observers. Broadcast RID defines a set of
messages for UA to transmit locally directly one-way over Bluetooth or
Wi-Fi, to be received in real time by local Observers." Reference? To my
understanding, NRID and BRID are firstly methods to transmit the UAS ID,
before being sets of information. What does "globally
indirectly"mean? Why "message" in BRID and "information" in NRID?
Terms should be made consistent. As examples are given for BRID, why not
talking about cellular and satellite as examples for NRID?
SWC: F3411. NRID and BRID are means to transmit the information, but:
for NRID the methods are only partially specified (the Internet, thus
"globally", and via several specified intermediate nodes, thus
"indirectly"), whereas the information to be transmitted is fully
specified; for BRID, the methods are specified in detail, and the
information is the same as for NRID. Thus "information" for NRID and
"messages" for BRID. Bluetooth and WiFi are not examples; they are the
only data links specified in F3411-19 (although other links could be
added in future revisions). Further clarification of all the foregoing
attempted in -05.

FP quoting -reqs: "The same information must be provided via both
means."Reference for this "must"? NRID provides a bidirectional link
and has a different security & privacy constraints, such that the
transmitted info may differ (This may also change from one country to
another.) Shouldn't it be about a common "minimal set of information",
with extra information depending on the considered RID solution (NRID or
BRID)?
SWC: F3411 & FAA NPRM. Yes, the transmitted bit streams will differ, but
the application layer payload information must not. The common "minimal
set of information" is what is in the data dictionary, whether carried
in the specified BRID message formats or unspecified NRID structures.
Clarification attempted in -05.

FP quoting -reqs: "The presentation may differ, as Network RID defines a
data dictionary, whereas Broadcast RID defines message formats (which
carry items from that same data dictionary)." Same as above: Reference?
NRID and BRID are more about a method to transmit the UAS ID. What is a
dictionary? Quite unclear.
SWC: F3411. https://en.wikipedia.org/wiki/Data_dictionary

FP quoting -reqs: "The frequency with which it is sent may differ, as
Network RID can accommodate Observer queries asynchronous to UAS updates
(which generally need be sent only when information, such as GCS
location, changes) whereas Broadcast RID depends upon Observers
receiving UA messages at the time they are transmitted." Meaning of
Frequency? If this is about spectrum, this depends on the chosen
technology. Or maybe this is the transmission rate? As far as I know,
FAA proposed one message every second, for both NRID and BRID.
SWC: F3411 proposes sending dynamic data at least once per second and
static data at least once per 3 seconds. FAA NPRM proposes sending all
data at least once per second. Term "frequency" replaced with "interval
(or rate)" and its values updated in -05.

FP: Most importantly, it seems that there is a little confusion
regarding NRID. In this case, the Observer does not query the UAS
directly, it queries the UTM service provider or some CAA server.
Consequently, even if the Observer's requests are asynchronous, the UAS
transmissions may remain synchronous. I suggest to clearly illustrate
the considered architecture for NRID and BRID and to specify on this
architecture where DRIP applies, this would help answer this comment.
SWC: Clarification attempted in -05.

FP quoting -reqs: "Network RID depends upon Internet connectivity in
several segments from the UAS to each Observer. Broadcast RID should
need Internet (or other Wide Area Network) connectivity only for UAS
registry information lookup using the directly locally received UAS
Identifier (UAS ID) as a key. Broadcast RID does not assume IP
connectivity of UAS; messages are encapsulated by the UA without IP,
directly in Bluetooth or WiFi link layer frames." What does this mean?
Where does this come from? Why BRID needs internet?
SWC: F3411. "for UAS registry information lookup".

FP quoting -reqs: "The EU allows only Type 1. The US allows Types 1 and
3, but requires Type 3 IDs (if used) each to be used only once (for a
single UAS flight, which in the context of UTM is called an
"operation"). The EU also requires an operator registration number (an
additional identifier distinct from the UAS ID) that can be carried in
an [F3411-19] optional Operator ID message. As yet apparently there are
no CAA proposals to use Type 2." Reference? Even in Europe, drones are
registered, pilots too, and commercial drones must be assigned another
ID at each novel mission. A link should be made with Section 4.
SWC: F3411, FAA NPRM, EU Delegated Regulation 2019/945 cited in -05.
What is the reference for assigning "another ID at each novel mission"?

FP quoting -reqs: "[F3411-19] Broadcast RID transmits all information as
cleartext (ASCII or binary), so static IDs enable trivial correlation of
patterns of use, unacceptable in many applications, e.g., package
delivery routes of competitors." This may evolve soon, isn't it?
SWC: I have seen no specific proposals to mitigate this, outside DRIP.

FP quoting -reqs: "Security oriented UAS RID regulations essentially
have two goals: enable the general public to obtain and record an opaque
ID for any observed UA, which they can then report to authorities;
enable authorities, from such an ID, to look up information about the
UAS and its operator, especially location." "enable the general public
to obtain and record an opaque ID for any observed UA"should not be
stated as the first goal.
SWC: The current text reflects my understanding, based on reading many
long documents, attending many long meetings, etc. What should be stated
as the first goal?

FP quoting -reqs: "Using UAS RID to facilitate vehicular (V2X)
communications and applications such as Detect And Avoid (DAA), which
would impose tighter latency bounds than RID itself." Remote ID can be a
support for DAA solutions, but technical challenges are different and
imposing tighter latency does not solve everything. Indeed, the Remote
ID system does not include non-cooperative UAS (which are not
transmitting any ID but need to be avoided too), nor other types of
flying objects (manned aircraft), nor other types of obstacles
(buildings, birds). DAA are generally based on different technologies.
As the solution proposed in the document is not primarily for DAA, this
topic could be removed. In addition, Remote ID will probably not
intrinsically facilitate V2X communications. This will depend on the
underlying technology and implementation.
SWC: The FAA ARC & NPRM both explicitly contemplate this usage;
"facilitate" != "completely solve on its own."

FP quoting -reqs: "a 'fair witness' functionality (inspired by
[Stranger]) is desirable." This is not clear if the proposed
functionality (as well as the whole paragraph) should apply for both
BRID and NRID. And If so, how? This should be clarified (cf major comment)
SWC: Clarification attempted in -05.

FP quoting -reqs: "By 'immediately actionable' is meant information of
sufficient precision, accuracy, timeliness, etc. for an Observer to use
it as the basis for immediate decisive action, whether that be to
trigger a defensive counter-UAS system, to attempt to initiate
communications with the UAS operator, to accept the presence of the UAS
in the airspace where/when observed as not requiring further action, or
whatever, with potentially severe consequences of any action or inaction
chosen based on that information." The UCs for "immediate decisive
action", given as examples, show very different requirements in terms of
precision, accuracy, latency or timelines, implying that the
architecture behind could be quite different to meet these requirements.
Therefore, should the proposed solution for RID meet the requirements of
the most constrained UC? In addition, do we already know the actual
values for the required accuracy, latency, etc.? I suggest to moderate
the definition of "immediate decisive action" or to further specify it.
SWC: The examples given were not different Use Cases (UCs), but
different Courses Of Action (COAs). Different UCs may apply to Observers
with different roles (e.g. air defense, fire protection, law
enforcement). Indeed such different UCs will have different specific
performance parameters. Our inability to specifically quantify them for
each UC does not make it useless to point out that F3411 does not even
approach "immediately actionable", whereas a trustworthy identifier that
can be used to dynamically establish Observer to Pilot communications,
in many cases, would.

FP: Actually, I'm not sure the EASA can really be considered as a CAA,
as Europe is not a state. To avoid such ambiguity, why not giving DGAC
(Direction General de l'Aviation Civile, in France) as second example?
SWC: Given the confusing European situation, removed EASA, and replaced,
not with DGAC, but Japan Civil Aviation Bureau (clearly a CAA).

FP quoting -reqs: "First the UAS operator pushes an operation plan to
the USS that will serve that UAS for that operation" Isn't about
registration? This is done whether the UA uses NRID or BRID or... no
RID, as it is the case today.
SWC: Today, none of this happens, except perhaps partly with LAANC.

FP quoting -reqs: "If users of any other USS (whether they be other UAS
operators or Observers) develop an interest in any 4-D airspace volume
containing that UAS operation, their USS learns, via the UTM Discovery
and Synchronization Service (DSS)" Same as above, this is a challenge
different from NRID and BRID. DSS is performed for both.
SWC: Yes, DSS supports both UTM (primarily for deconfliction) and UAS
RID. This section describes how Network RID is expected to work. Such a
description is impossible without discussing UTM operation filing and DSS.

FP quoting -reqs: "The Net-RID SP (USS#1) will then publish updates of
the UAS position/status to all subscribed Net-RID DP via unspecified
(but expected to be web browser based) means." Has this already been
standardized? Other systems could be possible.
SWC: F3411

FP quoting -reqs: "Network RID has several variants. The UA may have
persistent onboard Internet connectivity, in which case it can
consistently source RID information directly over the Internet. The UA
may have intermittent onboard Internet connectivity, in which case the
GCS must source RID information whenever the UA itself is offline." NRID
can be direct or relayed by the GCS, but so far, this has not been
further discussed among the different working groups and regulation
entities. Proposing a hybrid solution sounds quite complex from a
technical perspective (just thinking about radio) and calls for evolved
implementation and architecture. Does this really fall under the scope
of DRIP?
SWC: The different scenarios listed are contemplated in the FAA NPRM, at
least, which explicitly specifies that Broadcast RID must be from the UA
itself, whereas Network RID can be from any part of the UAS (UA or GCS).
DRIP is not proposing to provide the connectivity, but to use it.

FP quoting -reqs: "which to perform its function must know where the UA
is, although C2 link outages do occur" Not clear. Remote ID is not C2,
they don't have the same functions. And how to control a drone via a
one-direction BRID system?
SWC: Understood, RID != C2; however, a GCS can feed Network RID with
location, velocity and status information obtained from its UA via the
C2 link. DRIP is not proposing to control an UA via a one-way link:
indeed, DRIP is not proposing how to control an UA at all; DRIP is
proposing that the cryptographic mechanisms required to make RID
trustworthy and respectful of privacy can be re-used for C2.

FP quoting -reqs: "An UAS as the ultimate source of Network RID
information" Meaning of "ultimate"?
SWC: Original, not "proximate" where information is relayed UAS ->
NetRID-SP -> NetRID-DP -> Observer.

FP quoting -reqs: "accessible via typical means such as web
APIs/browsers." Prefer API. As far as I know, it has not been decided
yet if this will be a Web API.
SWC: F3411 does not specify the NetRID-DP -> Observer segment of the
data flow, but almost everything in UTM is web based. DRIP is not
attempting to standardize this either.

FP quoting -reqs: "Network RID is the more flexible and less constrained
of the defined UAS RID means" This depends on the drone UC. Over a
limited airspace volume, BRID may be easier and cheaper to implement.
SWC: I can't see how anything can be easier or cheaper to implement than
an app on the UAS operator's smartphone (considered as a subsystem of
the GCS), which is all that is needed by the UAS operator for Network
RID (at least, under FAA NPRM Limited RID rules). Admittedly, NetRID-SP
and NetRID-DP services are also needed for Network RID, but those costs
can only be avoided if Network RID is not allowed in an entire jurisdiction.

FP quoting -reqs: "It is presumed that IETF efforts supporting Broadcast
RID (see next section) can be easily generalized for Network RID." Given
that NRID and BRID are based on different architectures, with different
constraints and requirements (e.g. security and privacy), how a solution
for BRID can be generalized to NRID? This should be clarified.
SWC: The constraints are different, the functional requirements are
almost identical. BRID is the more severely constrained, therefore what
can be done there, can easily be done in Network RID.

FP quoting -reqs: "After nominal overheads, this limits the UAS ID
string to a maximum length of 20 bytes, and precludes the same frame
carrying position, velocity and other information" Reference? Also, the
situation may be different in USA and in Europe.
SWC: F3411. It can be different only if Europe does not accept F3411 as
a means of compliance.

FP quoting -reqs: "by enabling verification that an UAS is registered"
Registered at CAA level? Isn't it out of the scope of DRIP?
SWC: Registered in the UAS RID system (e.g. U-space/UTM). Clarification
attempted in -05.

FP quoting -reqs: "by enabling instant establishment, by authorized
parties, of secure communications with the remote pilot." Meaning of
"instant"? of "secure"? of "establish communication"? In addition,
establishing a secure C2 link (or "communication with the remote pilot")
is not the primary objective of Remote ID.
SWC: Instant: "happening or coming immediately" (Google Dictionary),
i.e. immediately upon obtaining the ID. Secure: admittedly a vague term,
but here used to mean that at least some attempt has been made to meet
typical security goals, inc. confidentiality, integrity, authentication
of endpoints and traffic, etc. Establish communication: means
unspecified at the requirements level, but at the solution level, we
will propose dynamically setting up IPsec ESP tunnels that can carry
arbitrary traffic. C2 link != O2P comms: neither is the primary
objective of UAS RID, but both are secondary objectives of DRIP, which
aims not just to deliver an identifier, but to make that identifier
immediately useful.

FP quoting -reqs: "Further, [F3411-19] provides very limited choices for
an observer to communicate with the pilot, e.g., to request further
information on the UAS operation or exit from an airspace volume in an
emergency." How is this possible with BRID, where there is only a
one-direction link?
SWC: It is not possible _over that link_; further, that link is from the
UA, not to/from the pilot. An appropriate choice of identifier can
facilitate the observer communicating with the pilot, assuming that some
form of connectivity between them is available: specifying that this
should be possible goes in DRIP requirements; one means for achieving
it, use of a HHIT as an UAS ID, will be proposed in DRIP solution space
documents.

FP quoting -reqs: "An observer with Internet connectivity could look up
operator PII in a registry" This assumes that the registry access is
open to all.
SWC: It assumes that registry access is open to at least some observers.
The point is that this is a poor approach to enabling an observer to
contact a pilot to assess intentions or request/command a change in
operational plan e.g. due to an emergency.

FP quoting -reqs: "Thus complementing [F3411-19] with protocols enabling
strong authentication, preserving operator privacy while enabling
immediate use of information by authorized parties, is critical to
achieve widespread adoption of a RID system supporting safe and secure
operation of UAS." This requirement sounds less challenging for NRID.
SWC: I agree.

FP quoting -reqs: "Basic ID message"
This term has not been contextualized in previous sections and it is
hard to get where it comes from.
SWC: The Basic ID message (Message Type 0) is the most fundamental of
the static data messages defined in F3411.

FP quoting -reqs: "Provable Registration: DRIP MUST enable verification
that the UAS ID is in a registry" Which registry? of some airspace
regulation entity ? of FIMS / CIS ? of some SDSP ? of some USS ? of some
UAS operator ?... This should be clarified.
SWC: In any registry of UAS IDs that can be sent via UAS RID. DRIP does
not get to specify this, regulators do, and they haven't yet converged.

FP quoting -reqs: "Broadcast RID -> Network RID application layer
gateways" How should this be understood?
SWC: 2-port application layer gateways with Broadcast RID receivers and
Internet connectivity, that do as described in the requirement.

FP quoting -reqs: "support optional SDSP services such as
multilateration (to complement UAS position self reports with
independent measurements)" What is meant by independent measurements? At
which layer? Radio or upper layers?
SWC: Either. The most basic is simply to receive Broadcast RID messages
and mark them up with the time of reception and the receiver's location
at that time. As Broadcast RID has very limited range, messages that
claim a UA location further than that range from the receiver should be
suspect.

FP quoting -reqs "QoS: DRIP MUST enable policy based specification of
performance and reliability parameters, such as maximum message
transmission intervals and delivery latencies." Can this be understood
as SLA? SLA with Bluetooth and WiFi?
SWC: DRIP must support specification of these parameters, to the extent
that a DRIP system is taken to include the software implementing RID on
a given UAS (UA and/or GCS), so it can be configured appropriately per a
CAA's rules. There is no implication that DRIP can guarantee the QoS
specification will be met. DRIP should also be able to detect and alert
when the QoS specification is not met (see Management requirement), as
this may lead to unsafe operations.

FP: I recall a previous sentence "By 'immediately actionable' is meant
information of sufficient precision, accuracy, timeliness, etc. for an
Observer to use it as the basis for immediate decisive action, whether
that be to trigger a defensive counter-UAS system" What if this latency
is set to 5ms?
SWC: Although local air defense sensor networks with latency of that
order exist, it is difficult to imagine general purpose commercial data
links (Bluetooth, WiFi) or the Internet meeting such a bound: so it
would be pointless for an administrator to configure the bound that low;
and if someone did, this should (see Management requirement) immediately
trigger alerts that the bound was being exceeded.

FP quoting -reqs: "Management: DRIP SHOULD support monitoring of the
health and coverage of Broadcast and Network RID services." To which
extent? How can DRIP see what is happening at lower layers? How to
monitor coverage for BRID?
SWC: This is a requirements document, not a solution space document.
However, any solution meeting the requirement of Broadcast RID to
Network RID gateways would also enable monitoring coverage for BRID.

I suggest that anyone wishing to address any of these points launch a
thread specific to the point. Thank you all and good night!

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Oct 2020 13:11:56 -0400

Here are some comments on this ver:

Intro -

"Unmanned Aircraft (UA) may be fixed wing Short Take-Of"

I think there is a missing comma after wing

"Unmanned Aircraft (UA) may be fixed wing, Short Take-Of"

Figure 1: "General UAS RID Scenario"

This needs a couple direct lines from the Pilot operator to UA to show 
the C2 connection.

Otherwise it might seem that all the UA are autonomous?  I know it says:

"This is because UAS RID and other connectivity involving the UA varies 
as described below."

But I am not finding this.  Or you can say that UA C2 is not covered in 
RID requirements?

Concerns and Constraints -

"As the origin of all information in UAS RID is self-reports from operators"

 From operators?  I would think "UAS", as both UA and GCS may supply 
information.

I don't like the C2 definition.  First it seems that C2 is only 
available in RF-LOS, excluding use of Internet for C2 transport. But 
more, C2 is a set of messages between the UA and GCS to control the UA 
and report on its activities.  Its transport is secondary to the actual 
messages.  Note that MAVLINK can be transported over UTP.

Network RID -

Fig 3 lacks direct link from UA to Internet as an option.  It is limited 
to RF-LOS operations.

"In the typical UTM context..."

Why the ellipse?

I might recommend changing this to a colon then have each step as an 
indented clause.

"Network RID has several variants.  The UA may have persistent onboard 
Internet connectivity, in which case it can consistently source RID 
information directly over the Internet."

Fig 3 needs to show this.

Broadcast RID -

Fig 4:  (no IP)

Should be (no IP or transport)  or  (app layer only)

Important for the layers wonks (like me!) here that would be thinking 
gateways as in many IoT contexts.

IEEE 802.15.4-2016 and Zigbee 1.0 were a single application interface to 
the MAC.  Created quite a problem, and not for discussion here, but 
constrained comm links squeezing everything between the MAC and Session 
Layer (whatever that is, talk to Vint some time about it) are part of 
the territory.

And you do say this in the text.

A number of places you have "an UA" which is how one might think it 
should be, but I believe the proper syntax in this case is "a UA" that 
you also use.  So one or the other.

Also "an UAS".  Try saying it out loud...

replace "specs" with "specifications".

Replace "WIMAX" with IEEE 802.16 or have this parenthetical.  There is 
work on a new addendum to the PHYs of 802.16 that could greatly increase 
802.16 applicability.

And thank you for putting all of our earlier comments together!

Bob

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 26 Oct 2020 20:13:53 -0400

interspersed

> Here are some comments on this ver:

Thanks Bob! I was afraid this stone had disappeared into the pond 
without a ripple.

> "Unmanned Aircraft (UA) may be fixed wing, Short Take-Of"

No, I meant to write fixed wing STOL, as one typical UA type. Fixed wing 
non-STOL may exist, but are not common today, and presumably would be 
very large aircraft, running ADS-B, not UAS RID.

> But I am not finding this.  Or you can say that UA C2 is not covered in 

Indeed, UAS C2 is out of scope for DRIP _requirements_, per our charter, 
but as you have explained previously, it comes essentially for free once 
we meet our RID-centric requirements. I really hesitate to show _any_ 
comms in Figure 1, as then people will want to know why I didn't show 
comm scenarios A, B, C...

>  From operators?  I would think "UAS", as both UA and GCS may supply 

True, the origin of specific data in UAS RID may be the UA or the GCS, 
without explicit involvement of the operator, but the GCS and UA are (or 
should be) under the control of the operator, so the operator is the 
ultimate source, if not of specific data, at least of the manner in 
which data is generated and reported. The point is that operators can 
lie, or more precisely, configure their UAS to lie. More broadly, in UTM 
(vs UAS RID), as I recall, the governing documents explicitly identify 
operators as the source of information used by USS to track UA.

> messages.  Note that MAVLINK can be transported over UTP.

I don't like it either. The longer definition, while more comprehensive, 
was by no means standard either. I wrote "In the UAS context, typically 
refers" because that is the common usage here. I did not mean that the 
RF data link had to be direct from the GCS to the UA: C2 is from the GCS 
to the UA; the first hop from the GCS is typically wireless; the last 
hop to the UA _must_ be wireless (at least while in flight); those hops 
are often but not always identical. If we rev -reqs again, I would be 
glad to clarify that C2 is really a function over arbitrary transport, 
despite common usage in the small UAS community.

> Network RID -
> 
> Fig 3 lacks direct link from UA to Internet as an option.

Good catch! Figure 3 is not properly generic to ASTM Network RID, but 
specific to ASTM Network RID  under FAA NPRM Limited RID rules. :-(

> It is limited to RF-LOS operations.

Another good catch. At my request, Andrei created ASCII art that 
reflects what we (and presumably the FAA NPRM writers) were thinking, 
but it is not the only possibility allowed by F3411 (or even the NPRM). 
I don't know whether we want to try to show all the possibilities, or 
just label the current figure more precisely?

> I might recommend changing this to a colon then have each step as an 

Ellipsis was because a multi-sentence description followed. Changing it 
as you describe might make it easier to follow.

> Fig 3 needs to show this.

I don't know whether we want to revise Figure 3, label it more 
precisely, or both label it more precisely and insert more figures 
showing the other variants?

> And you do say this in the text.

True. "(no IP)" was intended to drive the point home, but perhaps it 
obscures it instead. So many times, reviewers and mailing list posters 
have insisted that there must be IP there, but there isn't.

> Also "an UAS".  Try saying it out loud...

I tried to follow the old standard, where "a" vs "an" was based on 
expansion of the acronym into the word phrase. There is also a new 
standard, based on pronouncing the acronym as a sequence of letters. 
Apparently I failed to be consistent. Does IETF have a position on the 
new vs old standard for this?

> replace "specs" with "specifications".

All right. Grumble.

> work on a new addendum to the PHYs of 802.16 that could greatly increase 

OK.

> And thank you for putting all of our earlier comments together!

That was most of the work. Editing is easy; figuring out what edits to 
make, based on reconciling diverse comments from all reviewers, is hard. :-)

Do we rev -reqs again, or call it adequate given the calendar?

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Oct 2020 21:25:08 -0400

> Thanks Bob! I was afraid this stone had disappeared into the pond 

Tell me about it....

> No, I meant to write fixed wing STOL, as one typical UA type. Fixed 
> wing non-STOL may exist, but are not common today, and presumably 
> would be very large aircraft, running ADS-B, not UAS RID.

Like Zipline?  Good article a while back in IEEE Spectrum.  They really 
rely on gov subsidies in Rwanda.

>> This needs a couple direct lines from the Pilot operator to UA to 
>> show the C2 connection.
>>
>> "This is because UAS RID and other connectivity involving the UA 
>> varies as described below."
>>
>> But I am not finding this.  Or you can say that UA C2 is not covered 
>> in RID requirements?
>
> Indeed, UAS C2 is out of scope for DRIP _requirements_, per our 
> charter, but as you have explained previously, it comes essentially 
> for free once we meet our RID-centric requirements. I really hesitate 
> to show _any_ comms in Figure 1, as then people will want to know why 
> I didn't show comm scenarios A, B, C...

OK.

> without explicit involvement of the operator, but the GCS and UA are 
> (or should be) under the control of the operator, so the operator is 
> the ultimate source, if not of specific data, at least of the manner 
> in which data is generated and reported. The point is that operators 
> can lie, or more precisely, configure their UAS to lie. More broadly, 
> in UTM (vs UAS RID), as I recall, the governing documents explicitly 
> identify operators as the source of information used by USS to track UA.

Somehow you need to catch this nuance or it will come up again and again 
and...

>> more, C2 is a set of messages between the UA and GCS to control the 
>> UA and report on its activities.  Its transport is secondary to the 
>> actual messages. Note that MAVLINK can be transported over UTP.
>
> I don't like it either. The longer definition, while more 
> comprehensive, was by no means standard either. I wrote "In the UAS 
> context, typically refers" because that is the common usage here. I 
> did not mean that the RF data link had to be direct from the GCS to 
> the UA: C2 is from the GCS to the UA; the first hop from the GCS is 
> typically wireless; the last hop to the UA _must_ be wireless (at 
> least while in flight); those hops are often but not always identical. 
> If we rev -reqs again, I would be glad to clarify that C2 is really a 
> function over arbitrary transport, despite common usage in the small 
> UAS community.

Well there is that tethered UA that is popular with Firefighters! Power 
and C2 on a 100M cable.  Great for long time monitoring a fire with its 
IR cameras.

Always those special cases.

But this is why I like C2 to be either a set of control messages between 
UA and GCS, or a protocol between them and leave out the how for the 
connection.

> but it is not the only possibility allowed by F3411 (or even the 
> NPRM). I don't know whether we want to try to show all the 
> possibilities, or just label the current figure more precisely?

Delivery services will be beyond RF-LOS.  So I think it is needed.

> Ellipsis was because a multi-sentence description followed. Changing 
> it as you describe might make it easier to follow.

It took me a bit of reading to follow.  I like indented steps.

>
>> "Network RID has several variants.  The UA may have persistent 
>> onboard Internet connectivity, in which case it can consistently 
>> source RID information directly over the Internet."
>>
>>

Probably punt for this week.

>> IEEE 802.15.4-2016 and Zigbee 1.0 were a single application interface 
>> to the MAC.  Created quite a problem, and not for discussion here, 
>> but constrained comm links squeezing everything between the MAC and 
>> Session Layer (whatever that is, talk to Vint some time about it) are 
>> part of the territory.
>>

Some of the header compression work in 6lo reduces the IPv6 header to 
zero bytes and the gateway then fixes this.  The transport headers still 
tend to be there.  That is why I recommend (app layer only).

>> should be, but I believe the proper syntax in this case is "a UA" 
>> that you also use.  So one or the other.
>>

Need to ask the RFC Editors...

>> replace "specs" with "specifications".

I am guilty of this often.

>
>> Replace "WIMAX" with IEEE 802.16 or have this parenthetical.  There 
>> is work on a new addendum to the PHYs of 802.16 that could greatly 
>> increase 802.16 applicability.
>
> OK.
>

Really your call.  Your slides for the session can just point to these 
comments needing a 'quick' rev if nothing else comes in soon.