Subject: [Drip] WGLC of draft-ietf-drip-reqs-04 (Ends 23/09/2020)

From: <[email-masked]>
Date: Wed, 9 Sep 2020 06:45:00 +0000

Hi all,

This message starts the WGLC for "Drone Remote Identification Protocol (DRIP) Requirements": https://tools.ietf.org/html/draft-ietf-drip-reqs-04

Detailed reviews were shared with the authors in the past, but we do need more reviews to ensure the content is ready to move forward.

Please review this version and share your comments, suggestions, etc.

Feedback supporting publication (i.e., "+1") is also welcome.

Thank you.

Cheers,
Daniel & Med

_________________________________________________________________________________________________________________________

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2020 11:19:17 -0400

<[email-masked]> wrote:
    > This message starts the WGLC for "Drone Remote Identification Protocol
    > (DRIP) Requirements":
    > https://tools.ietf.org/html/draft-ietf-drip-reqs-04

{As a proceedural matter, I think it's better to link to the DT copy of the
draft, because the IETF is trying obsolete tools.ietf.org, which is not
supported by the secretariat}

    > Detailed reviews were shared with the authors in the past, but we do
    > need more reviews to ensure the content is ready to move forward.

    > Feedback supporting publication (i.e., "+1") is also welcome.

The document seems to have dealt with most of my previous comments.
I think that the listed requirements have too many long (comments).
I think that many should just become additional requirements, or
sentences on their own.  But, I can live with the document as it is.

I would suggest that the document title and abstract should include the word
"Terminology" somewhere.

As an aside, perhaps the Architecture document should be retitled
"Architectural Roadmap", and we should agree not to finish/close it until
the protocol documents are ready to go.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: <[email-masked]>
Date: Thu, 10 Sep 2020 05:39:03 +0000

Hi Michael, 

We wanted to include a pointer to this specific -04 version of the document, hence the tools pointer. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Michael
> Richardson
> Envoyé : mercredi 9 septembre 2020 17:19
> À : [email-masked]
> Objet : Re: [Drip] WGLC of draft-ietf-drip-reqs-04 (Ends 23/09/2020)
> 
> {As a proceedural matter, I think it's better to link to the DT copy
> of the draft, because the IETF is trying obsolete tools.ietf.org,
> which is not supported by the secretariat}
>

---

From: <[email-masked]>
Date: Mon, 21 Sep 2020 14:42:12 +0000

Hi all,

Fanny (cced) kindly agreed to review the requirements draft. I'm relaying the review as I received it.

Authors, please consider this review and engage with Fanny to address her concerns and to share with the list the changes that you are planning to make to the draft to address the comments.

Some of the issues may not be specific to this draft. Please call out those. We need to consider adding some text to clarify these ones as well (as I expect will receive similar comments when the draft will progress in the publication process).

In order to ease tracking the issues and keep the discussion focused, please use dedicated threads.

Thank you

========Fanny's Review Start :====
·        Major comments:

-          The scope of DRIP should be clarified.

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

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

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

-          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...
But also:

-          The document is essentially based on [F3411-19], however how to link it with other national / international regulations, in particular FAA and EASA?

-          Remote ID does not have the same functions as C2. The scope of DRIP should be clarified.

·        Section 1.1. Overall Context

"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.
"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.
« 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?
"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)?
" 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...
"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.
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.
« 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?
« 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.
"[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 ?
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...

·        Section 1.2: Intended Use

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.
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)
·        Section 1.3: DRIP Scope

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.

·        Section 2.2: Definitions

CAA
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 Générale de l'Aviation Civile, in France) as second example?

·        Section 3.1:  Network Remote ID

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.
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.
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.
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?
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?
An UAS as the ultimate source of Network RID information
Meaning of "ultimate"?
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".

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.
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.
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.
·        Section 3.3 DRIP scope

by enabling verification that an UAS is registered
Registered at CAA level? Isn't it out of the scope of DRIP ?
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.
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?
An observer with Internet connectivity could look up operator PII in a registry
This assumes that the registry access is open to all...
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.
·        Section 4.1 Requirements - general

"Basic ID message"
This term has not been contextualized in previous sections and it is hard to get where it comes from.
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.
Broadcast RID -> Network RID application layer gateways
How should this be understood?
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?
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?
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?
"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?

Next Sections have not been reviewed yet...

==

De : [email-masked] [mailto:[email-masked]]
Envoyé : mercredi 9 septembre 2020 08:45
À : [email-masked]
Cc : [email-masked]
Objet : WGLC of draft-ietf-drip-reqs-04 (Ends 23/09/2020)

Hi all,

Thank you.

Cheers,
Daniel & Med

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 21 Sep 2020 11:09:04 -0400

On 9/21/20 10:42 AM, [email-masked] wrote:
>
> Hi all,
>
> Fanny (cced) kindly agreed to review the requirements draft. I’m 
> relaying the review as I received it.
>
> Authors, please consider this review and engage with Fanny to address 
> her concerns and to share with the list the changes that you are 
> planning to make to the draft to address the comments.
>
> Some of the issues may not be specific to this draft. Please call out 
> those. We need to consider adding some text to clarify these ones as 
> well (as I expect will receive similar comments when the draft will 
> progress in the publication process).
>
> ========Fanny’s Review Start :====
>
>
>     ·Major comments:
>
> -The scope of DRIP should be clarified.
>
> -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”.
>

Here we get into the what goes into reqs and what into arch.  We pulled 
much of this out of the original reqs to put it into arch.  I personally 
believe that what is NRID and what is BRID belongs in arch.  Being 
consistent IS critical....

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

It is the the lower layers that drive much of the requirements of NRID 
and BRID!  that fact should be made clearer.

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

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!

> -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…
>

there is quite a collision of some of these terms.  How to clarify is 
hard.  How much of outside documents gets directly included vs pointers 
to read this.

> But also:
>
> -The document is essentially based on [F3411-19], however how to link 
> it with other national / international regulations, in particular FAA 
> and EASA?
>

FAA and EASA have called out use of F3411-19.  Definitely in the FAA 
NPRM.  EASA, I am unclear of which of their doc(s) point to F3411-19.

> -Remote ID does not have the same functions as C2. The scope of DRIP 
> should be clarified.
>

That is true, and if this point is raised, more should be said.  Of 
course there IS a draft for securing C2, leveraging RID.

More later after I talk to Stu and Adam.

>     ·Section 1.1. Overall Context
>
> “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.
>
> “Standard Specification for Remote ID and Tracking (early drafts are 
> freely available as [OpenDroneID] specifications).”
>
> « 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.
>
> “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)?
>
> “ 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…
>
> “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.
>
> 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.
>
> « 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. »
>
> « 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.
>
> “[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 ?
>
> 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…
>
>
>     ·Section 1.2: Intended Use
>
> 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.
>
> 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)
>
>
>     ·Section 1.3: DRIP Scope
>
> 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.
>
>
>     ·Section 2.2: Definitions
>
> CAA
>
> 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 Générale de l’Aviation Civile, in France) as second example?
>
>
>     ·Section 3.1:  Network Remote ID
>
> Isn’t about registration? This is done whether the UA uses NRID or 
> BRID or... no RID, as it is the case today.
>
> 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)
>
> 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.
>
> 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?
>
> 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?
>
> Meaning of “ultimate”?
> Prefer “API”. As far as I know, it has not been decided yet if this 
> will be a “Web API”.
>
> 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.
>
> 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
>
>     ·Section 3.3 DRIP scope
> Registered at CAA level? Isn’t it out of the scope of DRIP ?
>
> 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.
>
> 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.
>
> This assumes that the registry access is open to all…
>
> 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.
>
>     ·Section 4.1 Requirements – general
>
> “Basic ID message”
>
> Which registry? of some airspace regulation entity ? of FIMS / CIS ? 
> of some SDSP ? of some USS ? of some UAS operator ?... This should be 
> clarified.
>
> support optional SDSP services such as multilateration (to complement 
> UAS position self reports with independent measurements)
>
> QoS: DRIP MUST enable policy based specification of performance and 
> reliability parameters, such as maximum message transmission intervals 
> and delivery latencies.
>
> 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 …”
>
> “Management: DRIP SHOULD support monitoring of the health and coverage 
> of Broadcast and Network RID services.”
>
> Next Sections have not been reviewed yet…
>
> ==
>
> *De :[email-masked] [mailto:[email-masked]]
> *Envoyé :* mercredi 9 septembre 2020 08:45
> *À :* [email-masked]
> *Cc :* [email-masked]
> *Objet :* WGLC of draft-ietf-drip-reqs-04 (Ends 23/09/2020)
>
> Hi all,
>
> (DRIP) Requirements": https://tools.ietf.org/html/draft-ietf-drip-reqs-04
>

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 21 Sep 2020 11:22:33 -0400

> sentences on their own.  But, I can live with the document as it is.
<mglt>
I provided some comments before the WGLC and I tend to agree with Michael
that the wording could be simplified and be more specific. I would like to
co-author to re-consider my earlier comments in the light of comments that
have been provided during this WGLC
https://mailarchive.ietf.org/arch/msg/tm-rid/MqJPg6E8MszaHlS3Ql8Z7KRKfCI/
</mglt>

> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
Daniel Migault
Ericsson

---

From: <[email-masked]>
Date: Thu, 24 Sep 2020 09:00:01 +0000

Hi all,

This message concludes the WGLC for this draft. A new version is needed to address the comments.

Cheers,
Daniel & Med

Hi all,

Thank you.

Cheers,
Daniel & Med