Re: [Tm-rid] Benjamin Kaduk's Block on charter-ietf-tmrid-00-03: (with BLOCK and COMMENT)

Robert Moskowitz <rgm@labs.htt-consult.com> Thu, 06 February 2020 15:14 UTC

Return-Path: <rgm@labs.htt-consult.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 E121B1200B6; Thu, 6 Feb 2020 07:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dCCs6tAbzz8Z; Thu, 6 Feb 2020 07:14:12 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC4512093C; Thu, 6 Feb 2020 07:14:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A0A0E621AA; Thu, 6 Feb 2020 10:14:07 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42KUwawEzdDX; Thu, 6 Feb 2020 10:13:57 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9F1136212E; Thu, 6 Feb 2020 10:13:56 -0500 (EST)
To: "Card, Stu" <stu.card@axenterprize.com>, kaduk@mit.edu
Cc: tm-rid@ietf.org, The IESG <iesg@ietf.org>, tmrid-chairs@ietf.org
References: <158097042097.30642.12144712233440703137.idtracker@ietfa.amsl.com> <0748c414-6056-7202-ca8a-6583b7dffdcb@labs.htt-consult.com> <CAKM0pYMFrg-VvP-oj_KOfw9Mto913uc_psifAd93dTwt_idKzA@mail.gmail.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <c726e30f-569b-304b-cf16-352b402e8f26@labs.htt-consult.com>
Date: Thu, 06 Feb 2020 10:13:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAKM0pYMFrg-VvP-oj_KOfw9Mto913uc_psifAd93dTwt_idKzA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------92259BEB26F24200B8BC5459"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/6kUBxVAj9tROjahQ_l1Np8a0jNs>
Subject: Re: [Tm-rid] Benjamin Kaduk's Block on charter-ietf-tmrid-00-03: (with BLOCK and COMMENT)
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: Thu, 06 Feb 2020 15:14:22 -0000

Doesn't ASTM discuss some of these constraints?  Definitely the radio 
even though they report testing, in noise free, open space BT4 to 300M 
and WiFi to 1KM.  I.E. best case performance.

On 2/6/20 10:05 AM, Card, Stu wrote:
> Ref [2] doesn't use the word "constrained" but talks about some of the 
> issues, esp. around p. 13 & p. 27.
>
> Batteries must support not only RID but also whatever the mission 
> payload is doing, Command & Control of the aircraft, and 
> propulsion/lift (inc. the weight of the battery itself). Every watt of 
> power and joule of energy is precious.
>
> Essentially, the constraints are: low cost, size, weight and power 
> CPUs; small radio antenna, rarely oriented anywhere near optimally for 
> communication with any given peer (due to UA flight maneuvers); the 
> need to support data link types now ubiquitous on deployed observer 
> devices (WiFi, BT5 & worst BT4, as Bob wrote); and usually no 
> professional RF or IT staff to keep things maintained & secure.
>
> We can say this explicitly in our charter rather than relying on ref 
> [2] and general reader knowledge, but were trying to keep charter text 
> to a reasonable length. Ref [2] is essential background on UAS RID, 
> which we should retain, but perhaps we should augment it with another 
> reference that addresses UAS wireless networking constraints more 
> explicitly?
>
>
>
> On Thu, Feb 6, 2020, 06:04 Robert Moskowitz <rgm@labs.htt-consult.com 
> <mailto:rgm@labs.htt-consult.com>> wrote:
>
>     Bluetooth 4 is "highly constrained".  It is extremely challenging
>     to do anything with 21 byte packets in broadcast mode.
>
>     Although the documents do not discuss this, many UAs use very
>     limited cpus, or rather said processing power is dedicated to
>     flight, not communications.  Battery life is another large
>     constraint; additional processing demands for communications take
>     away from flight time.
>
>     So when you look into the UAS environment, "highly constrained".
>
>     Even Bluetooth 5 with 251 bytes in broadcast messages is hard.
>
>     On 2/6/20 1:27 AM, Benjamin Kaduk via Datatracker wrote:
>>     Benjamin Kaduk has entered the following ballot position for
>>     charter-ietf-tmrid-00-03: Block
>>
>>     When responding, please keep the subject line intact and reply to all
>>     email addresses included in the To and CC lines. (Feel free to cut this
>>     introductory paragraph, however.)
>>
>>
>>
>>     The document, along with other ballot positions, can be found here:
>>     https://datatracker.ietf.org/doc/charter-ietf-tmrid/
>>
>>
>>
>>     ----------------------------------------------------------------------
>>     BLOCK:
>>     ----------------------------------------------------------------------
>>
>>     W.r.t "severely constrained UAS environments [2]", I followed the reference for [2] and found
>>     no discussion of constrained environments, so it seems that some discussion of the nature
>>     of the constraints is needed in-band if [2] is intended only as a reference for "UAS environments".
>>
>>
>>     ----------------------------------------------------------------------
>>     COMMENT:
>>     ----------------------------------------------------------------------
>>
>>     "Network RID defines a set of information for UAS to make available globally indirectly
>>     via the Internet" is hard to parse ("globally indirectly"?).
>>
>>     I don't understand what "make RIDs immediately actionable" means (along the lines of
>>     Magnus' Block).
>>
>>     (As a side note, I note that [3] lists as a "minimum requirement" for both standard and limited
>>     remote identification UAS of "Cybersecurity" with fairly vague definition thereof, so we might
>>     have room to supply some more usable definition.)
>>
>>
>
>     -- 
>     Robert Moskowitz
>     Owner
>     HTT Consulting
>     C: 248-219-2059
>     F: 248-968-2824
>     E: rgm@labs.htt-consult.com <mailto:rgm@labs.htt-consult.com>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     Tm-rid@ietf.org <mailto:Tm-rid@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tm-rid
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit