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

"Card, Stu" <stu.card@axenterprize.com> Wed, 05 February 2020 15:40 UTC

Return-Path: <stu.card@axenterprize.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB541200FE for <tm-rid@ietfa.amsl.com>; Wed, 5 Feb 2020 07:40:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=axenterprize.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk3jRSPqHQV7 for <tm-rid@ietfa.amsl.com>; Wed, 5 Feb 2020 07:40:16 -0800 (PST)
Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A6F120052 for <tm-rid@ietf.org>; Wed, 5 Feb 2020 07:40:16 -0800 (PST)
Received: by mail-yw1-xc2e.google.com with SMTP id b186so2797541ywc.1 for <tm-rid@ietf.org>; Wed, 05 Feb 2020 07:40:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axenterprize.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ox0kuTZzzxEqm6I0bXBCiHfC0HskZs/fMCvhC0ecK8=; b=DwXpuYDxEL6+x3PRrJ38VdFRC7vNCGVu9RZAYdLKE7O6lIH77qPy5Ob50CbgFikIvv QD86FBX8TDpAtKanB6m/pK7R41DokNM7M+e0VkT9ZqG2IF01ja5F7pb02yue6yKvzl2y cpToub6dp9UqDwLLfAUX1UiCBF5lGzq4Mqp2g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ox0kuTZzzxEqm6I0bXBCiHfC0HskZs/fMCvhC0ecK8=; b=M8vgRRJrX+Lz/ppkxpH34dAfRL5QjIZ6rWv8TGEbgXGHqBWRjXuBUbRRfNtENkccBq tlu9PJgVy/uEuh3RE7HSpLW5GjOfBgIA0NMjUFGE9QZPQ9J3VKsH+3klfzUlf6aJDMZ+ bovyngm6/XC0K4pZvrNjJaWLvVmyl/b4eBfpNExKSOcDhDVHOYXcme64j7LcvMUDVCud 3iRSMwnoZekiVa6H9Hle6zderOP4InZO7rBmuj+z5h0o2tpco8TwC5lk34GGBUnsgTp4 OJmmbu44aIAfam8CsUOy6CFehU8mcVbxMQG/sdgNElszPy+20M5XzYDy9KekOepIGN/a Fhrg==
X-Gm-Message-State: APjAAAX8/mPvyBnVq39J2yFysOqxO32Mc2uj5t72dFehAX+5bdsGjxVR ngKaSVkHFnaXvKOD6Hqw797RZB9Mi7A9mOcNzLWR3SdDkE8=
X-Google-Smtp-Source: APXvYqznEhzyNm2Zc5muWMaD+dYpcP/0DG+N7yDgk/IOguEMirHGbIq/QYYeT8bNQxqM0dtCK7oHtH93hLrI417rSDg=
X-Received: by 2002:a0d:ca89:: with SMTP id m131mr10612004ywd.509.1580917214726; Wed, 05 Feb 2020 07:40:14 -0800 (PST)
MIME-Version: 1.0
References: <8C7B579D-E33D-4D76-BADB-726C15A214DC@cisco.com>
In-Reply-To: <8C7B579D-E33D-4D76-BADB-726C15A214DC@cisco.com>
From: "Card, Stu" <stu.card@axenterprize.com>
Date: Wed, 05 Feb 2020 10:40:04 -0500
Message-ID: <CAKM0pYNHcNRWQ6SWr6zH-ir2hnWtTTNshUW_UWxjadSkQDb5xw@mail.gmail.com>
To: tm-rid@ietf.org
Cc: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Daniel Migault <daniel.migault@ericsson.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, "Wiethuechter, Adam" <adam.wiethuechter@axenterprize.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000000e281059dd5f981"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/7WnzBsQVJMXvelk3o36T6Z2tNKY>
Subject: Re: [Tm-rid] We need to update the TMRID charter
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Trustworthy Multipurpose RemoteID <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2020 15:40:21 -0000

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) <evyncke@cisco.com>
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
> ”
>
>
>