Subject: [Tm-rid] We need to update the TMRID charter

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 5 Feb 2020 14:50:53 +0000

Let’s update the TMRID charter to fix the discussions done internally by the IESG and IAB. I have modified the text (see below), but there are still a couple of comments to be fixed. Suggestions are urgently welcome

  *   The “based on HIP” in “primarily leverage solutions based on HIP” seems pre-mature, the WG needs a document/work item to justify the choice of HIP (or possibly a liaison statement ?)
  *   Barry Leiba’s public comments should be acted upon (it is mostly editorial comments)
  *   I have already addressed the in-line expansion of acronyms (my suggestion to use foot notes was not well received by the IESG/IAB)

The above should really be fixed before Thursday 6th of February IESG telechat. **Suggestions are really welcome within 24 hours**

Magnus’ BLOCK is critical to be fixed. Unsure that the WG will manage to fix this part before tomorrow but we can give it a try. For example, on listing the work items for this WG ? This would limit the scope.
Updated charter below:

“CAAs (Civil Aviation Authorities) worldwide have initiated rule making for UAS (Unmanned Aircraft Systems) RID (Remote Identification). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM (formerly the American Society for Testing and Materials) WK65041 [1].  Network RID defines a set of information for UAS to make available globally indirectly via the Internet. Broadcast RID defines a set of messages for UA (Unmanned Aircraft) to send locally directly one-way over Bluetooth or Wi-Fi. WK65041 addresses how to neither populate/query registries, ensure trustworthiness of information nor make it instantly useful.
TMRID’s goal is to make RID immediately actionable, in both Internet and local-only connected scenarios, especially emergencies, in severely constrained UAS environments [2], balancing legitimate (e.g. public safety) authorities’ need to know trustworthy information with UAS operators’ privacy.

The  working group will primarily leverage solutions based on HIP as well as the domain name registration and focused on NPRM (Notice of Proposed Rule-Making) [3] published by US FAA (United States Federal Aviation Administration) as well as European CAA.

List of candidate drafts:
- draft-card-tmrid-uas
- draft-wiethuechter-tmrid-auth
- draft-moskowitz-hip-new-crypto
- draft-moskowitz-orchid-cshake
- draft-moskowitz-hip-hierarchical-hit
- draft-moskowitz-hip-hhit-registries

References:
[1] ASTM International F38 Committee Work Item WK65041 “Standard Specification for UAS Remote ID and Tracking” https://www.astm.org/DATABASE.CART/WORKITEMS/WK65041.htm
[2] UAS Identification and Tracking Aviation Rulemaking Committee Recommendations Final Report 2017 SEP 30 https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf
[3] https://www.federalregister.gov/documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems”

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Feb 2020 10:40:04 -0500

I had been waiting for more comments to come in, assuming we would discuss
them tomorrow in our tmrid conference call (I thought the IESG telechat was
a day later).

Most of the comments are editorial in nature (grammar, clarity, etc.), not
arguments against the substantive content.

I agree that I clumsily worded the "WK65041 addresses how to
neither..." sentence.
In a unicast email to me,  Michael Richardson suggested better text
"WK65041 does not address how to either populate/query registries, nor
ensure trustworthiness of information, nor make it instantly useful", but
Daniel didn't see that before he revised my charter draft version 4 to
create the one Eric uploaded.

WRT domain text, I recommend "leverage Internet domain name registration
business models, infrastructure and standards, including EPP, RDAP and DNS."

The primary substantive issue, IMO, is whether the WG is, in the charter:
(a) committed to a domain name and HIP centric approach;
(b) required to solicit approaches, then evaluate any brought forward, then
select/merge, then pursue an approach; or
(c) allowed to compromise by soliciting alternatives while pursuing a HIP
centric approach in parallel, so that if no alternatives are brought
forward and shown to be able to meet the UAS RID need by the end of the
solicitation and evaluation period, we already will have made some of the
urgently needed progress on the one approach identified so far.

My personal opinion is that (c) is the most prudent course. I could easily
live with (a). The one against which I strongly argue is (b), as we would
almost certainly miss the window within which IETF could make a significant
contribution to solving this important and urgent problem: the EU has
already adopted some regulations that violate operator privacy, but they
are not yet effective, so we can offer a better alternative if we do it
_soon_; the FAA will be making rules in the coming months; both sets of
[proposed] regulations and the ASTM standard fail to make the information
trustworthy or immediately usable; and manufacturers will produce large
numbers of drones to these standards, locking in either a bad or a good
design for at least the lifetime of those aircraft.

I am working on an architecture draft today, based on HIP, DNS, RDAP and
EPP, for consideration by the WG if its formation is approved by the IESG.

On Wed, Feb 5, 2020 at 9:50 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Let’s update the TMRID charter to fix the discussions done internally by
> the IESG and IAB. I have modified the text (see below), but there are still
> a couple of comments to be fixed. Suggestions are urgently welcome
>
>    - The “based on HIP” in “primarily leverage solutions based on HIP”
>    seems pre-mature, the WG needs a document/work item to justify the choice
>    of HIP (or possibly a liaison statement ?)
>    - Barry Leiba’s public comments should be acted upon (it is mostly
>    editorial comments)
>    - I have already addressed the in-line expansion of acronyms (my
>    suggestion to use foot notes was not well received by the IESG/IAB)
>
>
>
> The above should really be fixed before Thursday 6th of February IESG
> telechat. **Suggestions are really welcome within 24 hours**
>
>
>
> Magnus’ BLOCK is critical to be fixed. Unsure that the WG will manage to
> fix this part before tomorrow but we can give it a try. For example, on
> listing the work items for this WG ? This would limit the scope.
>
> Updated charter below:
>
>
>
> “CAAs (Civil Aviation Authorities) worldwide have initiated rule making
> for UAS (Unmanned Aircraft Systems) RID (Remote Identification). CAAs
> currently promulgate performance-based regulations that do not mandate
> specific techniques, but rather cite industry-consensus technical standards
> as acceptable means of compliance. One key standard is ASTM (formerly the
> American Society for Testing and Materials) WK65041 [1].  Network RID
> defines a set of information for UAS to make available globally indirectly
> via the Internet. Broadcast RID defines a set of messages for UA (Unmanned
> Aircraft) to send locally directly one-way over Bluetooth or Wi-Fi. WK65041
> addresses how to neither populate/query registries, ensure trustworthiness
> of information nor make it instantly useful.
>
> TMRID’s goal is to make RID immediately actionable, in both Internet and
> local-only connected scenarios, especially emergencies, in severely
> constrained UAS environments [2], balancing legitimate (e.g. public safety)
> authorities’ need to know trustworthy information with UAS operators’
> privacy.
>
>
>
> The  working group will primarily leverage solutions based on HIP as well
> as the domain name registration and focused on NPRM (Notice of Proposed
> Rule-Making) [3] published by US FAA (United States Federal Aviation
> Administration) as well as European CAA.
>
>
>
> [1] ASTM International F38 Committee Work Item WK65041 “Standard
> Specification for UAS Remote ID and Tracking”
> https://www.astm.org/DATABASE.CART/WORKITEMS/WK65041.htm
>
> [2] UAS Identification and Tracking Aviation Rulemaking Committee
> Recommendations Final Report 2017 SEP 30
> https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf
>
> [3]
> https://www.federalregister.gov/documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems
> ”
>
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Feb 2020 16:51:58 -0500

Going through the charter, I believe the following sentence may have an
issue where the word "neither" is placed.
OLD
"""
 WK65041 addresses how to
neither populate/query registries, ensure trustworthiness of information nor
make it instantly useful.
"""

NEW:
"""
WK65041 addresses how to
neither populate/query registries, ensure trustworthiness of information nor
make it instantly useful.
"""

It is not very clear to me what is the concerned of Magnus for the BLOCK.

One possibility is that the WG is narrowing its scope to HIP. If that is
the case, the reason we narrow down this scope is that this is
currently the only candidate. Charter are also written in order to clearly
put some work out of scope, and I am not sure that is what we really want
so the current charter leaves some place for other solution to be
evaluated. I think that corresponds to option (c) provided by Stu.

Another possibility is that the charter does not provide a high level
description of the work to be accomplished. If that is the case, I think
this could clarify what the WG is expected to do.

The working group will work on the following items:

* Requirements: The WG is expected to provide an information document that
lists the requirements the UAS Remote Identification (UAS RID) - that is
the system for identifying UA during flight by other parties must meet.
Requirements will also includes those associated to the UAS Identifier that
needs to both meet some constraints as well as some specific properties.

* Architecture: The WG will propose a standard document that describes the
architecture that address the requirements and that will re-use protocols
or architectures already standardized at the IETF.

* Protocol design: While the primary purpose of TM-RID WG is to leverage on
existing protocols, the specificities of the UAS environment is likely to
require existing protocols to be extended or new protocols to be designed.
The WG will be focused on standardizing this protocols or extensions.

List of candidate drafts:
- draft-card-tmrid-uas-requirements
- draft-card-tmrid-uas-architecture
- draft-wiethuechter-tmrid-auth
- draft-moskowitz-hip-new-crypto
- draft-moskowitz-orchid-cshake
- draft-moskowitz-hip-hierarchical-hit
- draft-moskowitz-hip-hhit-registries

On Wed, Feb 5, 2020 at 10:40 AM Card, Stu <[email-masked]> wrote:

> I agree that I clumsily worded the "WK65041 addresses how to neither..." sentence.
> (b) required to solicit approaches, then evaluate any brought forward,
> then select/merge, then pursue an approach; or
> I interpret the motivation o fthe BLOCK to be that there is a scope

>> via the Internet.. Broadcast RID defines a set of messages for UA (Unmanned
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
Daniel Migault
Ericsson

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 5 Feb 2020 22:00:52 +0000

Daniel,

<AD hat off>
Your reading of Magnus’ BLOCK is similar to mine, mainly two items:

  *   “One possibility is that the WG is narrowing its scope to HIP. “
  *   “the charter does not provide a high level description of the work to be accomplished “

I like your work items enumeration to address the second item, possibly a document about why HIP is the current best choice could be added. Stu’s c) approach being the most sensible.

<AD hat on>
My statement above should not prevent other proponents to chime in of course !

Regards

-éric

From: Daniel Migault <[email-masked]>
Date: Wednesday, 5 February 2020 at 22:52
To: "Card, Stu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Wiethuechter, Adam" <[email-masked]>, Eric Vyncke <[email-masked]>, Robert Moskowitz <[email-masked]>, Gonzalo Camarillo <[email-masked]>
Subject: Re: [Tm-rid] We need to update the TMRID charter

Going through the charter, I believe the following sentence may have an issue where the word "neither" is placed.
OLD
"""
 WK65041 addresses how to
neither populate/query registries, ensure trustworthiness of information nor
make it instantly useful.
"""

NEW:
"""
WK65041 addresses how to

One possibility is that the WG is narrowing its scope to HIP. If that is the case, the reason we narrow down this scope is that this is currently the only candidate. Charter are also written in order to clearly put some work out of scope, and I am not sure that is what we really want so the current charter leaves some place for other solution to be evaluated. I think that corresponds to option (c) provided by Stu.

Another possibility is that the charter does not provide a high level description of the work to be accomplished. If that is the case, I think this could clarify what the WG is expected to do.

* Requirements: The WG is expected to provide an information document that lists the requirements the UAS Remote Identification (UAS RID) - that is the system for identifying UA during flight by other parties must meet. Requirements will also includes those associated to the UAS Identifier that needs to both meet some constraints as well as some specific properties.

* Architecture: The WG will propose a standard document that describes the architecture that address the requirements and that will re-use protocols or architectures already standardized at the IETF.

* Protocol design: While the primary purpose of TM-RID WG is to leverage on existing protocols, the specificities of the UAS environment is likely to require existing protocols to be extended or new protocols to be designed. The WG will be focused on standardizing this protocols or extensions.

On Wed, Feb 5, 2020 at 10:40 AM Card, Stu <[email-masked]> wrote:
I had been waiting for more comments to come in, assuming we would discuss them tomorrow in our tmrid conference call (I thought the IESG telechat was a day later).

Most of the comments are editorial in nature (grammar, clarity, etc.), not arguments against the substantive content.

I agree that I clumsily worded the "WK65041 addresses how to neither..." sentence. In a unicast email to me,  Michael Richardson suggested better text "WK65041 does not address how to either populate/query registries, nor ensure trustworthiness of information, nor make it instantly useful", but Daniel didn't see that before he revised my charter draft version 4 to create the one Eric uploaded.

WRT domain text, I recommend "leverage Internet domain name registration business models, infrastructure and standards, including EPP, RDAP and DNS."

The primary substantive issue, IMO, is whether the WG is, in the charter:
(a) committed to a domain name and HIP centric approach;
(b) required to solicit approaches, then evaluate any brought forward, then select/merge, then pursue an approach; or
(c) allowed to compromise by soliciting alternatives while pursuing a HIP centric approach in parallel, so that if no alternatives are brought forward and shown to be able to meet the UAS RID need by the end of the solicitation and evaluation period, we already will have made some of the urgently needed progress on the one approach identified so far.

My personal opinion is that (c) is the most prudent course. I could easily live with (a). The one against which I strongly argue is (b), as we would almost certainly miss the window within which IETF could make a significant contribution to solving this important and urgent problem: the EU has already adopted some regulations that violate operator privacy, but they are not yet effective, so we can offer a better alternative if we do it _soon_; the FAA will be making rules in the coming months; both sets of [proposed] regulations and the ASTM standard fail to make the information trustworthy or immediately usable; and manufacturers will produce large numbers of drones to these standards, locking in either a bad or a good design for at least the lifetime of those aircraft.

I am working on an architecture draft today, based on HIP, DNS, RDAP and EPP, for consideration by the WG if its formation is approved by the IESG.

On Wed, Feb 5, 2020 at 9:50 AM Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Let’s update the TMRID charter to fix the discussions done internally by the IESG and IAB. I have modified the text (see below), but there are still a couple of comments to be fixed. Suggestions are urgently welcome
·         The “based on HIP” in “primarily leverage solutions based on HIP” seems pre-mature, the WG needs a document/work item to justify the choice of HIP (or possibly a liaison statement ?)
·         Barry Leiba’s public comments should be acted upon (it is mostly editorial comments)
·         I have already addressed the in-line expansion of acronyms (my suggestion to use foot notes was not well received by the IESG/IAB)

“CAAs (Civil Aviation Authorities) worldwide have initiated rule making for UAS (Unmanned Aircraft Systems) RID (Remote Identification). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM (formerly the American Society for Testing and Materials) WK65041 [1].  Network RID defines a set of information for UAS to make available globally indirectly via the Internet.. Broadcast RID defines a set of messages for UA (Unmanned Aircraft) to send locally directly one-way over Bluetooth or Wi-Fi. WK65041 addresses how to neither populate/query registries, ensure trustworthiness of information nor make it instantly useful.
TMRID’s goal is to make RID immediately actionable, in both Internet and local-only connected scenarios, especially emergencies, in severely constrained UAS environments [2], balancing legitimate (e.g. public safety) authorities’ need to know trustworthy information with UAS operators’ privacy.

References:

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

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Feb 2020 17:13:45 -0500

Hi Eric,

For the first point, It seems to me that it will depend on the architecture
document. If the document is sufficiently high level, we may not have the
rational for using HIP in the document. In that case we may have a another
document that provides a HIP-based architecture with some rationals for
using HIP. It might address the first bullet. So we may add to the
Architecture bullets:

* Architecture: The WG will propose a standard document that describes the
architecture that address the requirements and that will re-use protocols
or architectures already standardized at the IETF. The WG will define how
to implement the propose architecture and select the most appropriated
technology for it. If different technologies are selected, the WG will need
to make then interoperable.

On Wed, Feb 5, 2020 at 5:00 PM Eric Vyncke (evyncke) <[email-masked]>
wrote:

>    - “One possibility is that the WG is narrowing its scope to HIP. “
>    - “the charter does not provide a high level description of the work
>    to be accomplished “
>
>
>
> I like your work items enumeration to address the second item, possibly a
> document about why HIP is the current best choice could be added. Stu’s c)
> approach being the most sensible.
>
>
>
> <AD hat on>
>
> *From: *Daniel Migault <[email-masked]>
> *Date: *Wednesday, 5 February 2020 at 22:52
> *To: *"Card, Stu" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Wiethuechter, Adam" <
> [email-masked]>, Eric Vyncke <[email-masked]>,
> Robert Moskowitz <[email-masked]>, Gonzalo Camarillo <
> [email-masked]>
> *Subject: *Re: [Tm-rid] We need to update the TMRID charter
>
>
>
> Requirements will also includes those associated to the UAS Identifier
> that needs to both meet some constraints as well as some specific
> properties.
>
>
>
> * Protocol design: While the primary purpose of TM-RID WG is to leverage
> on existing protocols, the specificities of the UAS environment is likely
> to require existing protocols to be extended or new protocols to be
> designed. The WG will be focused on standardizing this protocols or
> extensions.
>
>
>
> ·         The “based on HIP” in “primarily leverage solutions based on
> HIP” seems pre-mature, the WG needs a document/work item to justify the
> choice of HIP (or possibly a liaison statement ?)
>
> ·         I have already addressed the in-line expansion of acronyms (my

-- 
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 5 Feb 2020 17:30:37 -0500

Daniel wrote in part --

For brevity of names that are already quite long, I abbreviated them as --
- draft-card-tmrid-uas-reqs
- draft-card-tmrid-uas-arch

They are the result of a fork of the former draft-card-tmrid-uas, which I
don't plan to continue, unless at some point it is decided by the putative
TM-RID WG to re-merge requirements and architecture into a single
Applicability Statement for UAS RID.

-reqs-00 is already uploaded.
-arch-00 I hope to upload late tonight.

Slides corresponding to each are already uploaded to the tmrid interim
meeting materials area.

I look forward to hearing from many of you in the interim meeting Webex
tomorrow!

On Wed, Feb 5, 2020 at 4:52 PM Daniel Migault <[email-masked]> wrote:

> * Requirements: The WG is expected to provide an information document
> that lists the requirements the UAS Remote Identification (UAS RID) -
> that is the system for identifying UA during flight by other parties must
> meet. Requirements will also includes those associated to the UAS
> Identifier that needs to both meet some constraints as well as some
> specific properties.
>
> * Architecture: The WG will propose a standard document that describes
> the architecture that address the requirements and that will re-use
> protocols or architectures already standardized at the IETF.
>
>> I had been waiting for more comments to come in, assuming we would
>> discuss them tomorrow in our tmrid conference call (I thought the IESG
>> telechat was a day later).
>>
>> Most of the comments are editorial in nature (grammar, clarity, etc.),
>> not arguments against the substantive content.
>>
>> My personal opinion is that (c) is the most prudent course. I could
>> easily live with (a). The one against which I strongly argue is (b), as we
>> would almost certainly miss the window within which IETF could make a
>> significant contribution to solving this important and urgent problem: the
>> EU has already adopted some regulations that violate operator privacy, but
>> they are not yet effective, so we can offer a better alternative if we do
>> it _soon_; the FAA will be making rules in the coming months; both sets of
>>> The  working group will primarily leverage solutions based on HIP as
>>> well as the domain name registration and focused on NPRM (Notice of
>>> Proposed Rule-Making) [3] published by US FAA (United States Federal
>>> Aviation Administration) as well as European CAA.
>>>
>>>
>>>