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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 22:27:00 -0800

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 6 Feb 2020 05:56:36 -0500

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.

-- 
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: "Card, Stu" <[email-masked]>
Date: Thu, 6 Feb 2020 10:05:27 -0500

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 <[email-masked]>
wrote:

> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/charter-ietf-tmrid/
>
>
>
> Robert Moskowitz
> 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
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 6 Feb 2020 10:13:48 -0500

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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>     E: [email-masked] <mailto:[email-masked]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     [email-masked] <mailto:[email-masked]>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 7 Feb 2020 19:54:01 +0000

As discussed over our IESG telechat of 6th of February, the charter for DRIP (new potential name for TM-RID)  has been updated to take into account all comments received by email or during the telechat.

Ben, Magnus, if you agree with the improved charter, then can you clear your BLOCK so that the charter could proceed to the external review ?

Thank you all

-éric
 
On 06/02/2020, 07:27, "iesg on behalf of Benjamin Kaduk via Datatracker" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Feb 2020 14:37:21 -0800

Hi Éric,

> Ben, Magnus, if you agree with the improved charter, then can you clear your BLOCK so that the charter could proceed to the external review ?

I like the direction this is going; thanks to all who worked on it!

With respect to:

% * Protocol design: while the primary purpose of DRIP WG is to leverage
% existing protocols, the specificities of the UAS environment are likely to
% require existing protocols to be extended or new protocols to be designed.
% The WG will be focused on standardizing these protocols or extensions.

This could be read as saying that DRIP will extend existing protocols,
including ones that already have a WG to maintain the protocol.  Typically
we say that WGs will coordinate with the protocol-maintenance WGs to get
the work done (i.e., focus on the work and not who is doing it).

So perhaps "The WG will focus on getting these protocols or extensions
standardized, coordinating with other WGs relevant for the protocol(s) in
question on the most appropiate home for any given piece of work."?

-Ben

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 7 Feb 2020 23:34:28 +0000

Hello Ben,

Good catch, charter has been updated in the data tracker

Thanks,

-éric

On 07/02/2020, 23:38, "Tm-rid on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Éric,

    
    With respect to:

    
    
    -Ben