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

["Card, Stu" <[e-mail]>]

Daniel wrote in part --
- draft-card-tmrid-uas-requirements
- draft-card-tmrid-uas-architecture

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 interpret the motivation o fthe BLOCK to be that there is a scope
>
>
>> 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) <[e-mail]>
>> 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.
>>>
>>>
>>>
>>> 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
>>> ”
>>>
>>>
>>>
>> --
>> Tm-rid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tm-rid
>>
>
>
> --
> Daniel Migault
> Ericsson
>