Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other

Robert Moskowitz <rgm@labs.htt-consult.com> Tue, 07 July 2020 17:27 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 1E1B33A0F43 for <tm-rid@ietfa.amsl.com>; Tue, 7 Jul 2020 10:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Bwm3Y8oeoiHL for <tm-rid@ietfa.amsl.com>; Tue, 7 Jul 2020 10:26:57 -0700 (PDT)
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 6C5DC3A0D70 for <tm-rid@ietf.org>; Tue, 7 Jul 2020 10:26:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 79A5562221; Tue, 7 Jul 2020 13:26:54 -0400 (EDT)
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 BDineavsrS9Z; Tue, 7 Jul 2020 13:26:40 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (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 5B36C621B8; Tue, 7 Jul 2020 13:26:40 -0400 (EDT)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: tm-rid@ietf.org
References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <b88975b0-ecfd-3091-4314-304c36d51e8f@gmail.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com>
Date: Tue, 07 Jul 2020 13:26:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <b88975b0-ecfd-3091-4314-304c36d51e8f@gmail.com>
Content-Type: multipart/alternative; boundary="------------A0E9C20D902C367DCF3FEA3D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/V2Q5yUM0hL3YyUHAvKo4gqRoQ8U>
Subject: Re: [Tm-rid] Review of draft-drip-arch-02 w.r.t. RFC6973, RFC8280 and other
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: Tue, 07 Jul 2020 17:27:02 -0000

Alex,

I had 19 years automotive.  I lived through the 13 - 17 character VIN 
conversion.  This included the year 80 'crisis' (before yr2000, there 
was yr80, going from 1 digit to 2).  At AMC we had to run a number of 
systems in '81 on year 'A' and /only/ 1 in '82 on year 'B'.  I KNOW 
about VIN :)

On 7/7/20 12:03 PM, Alexandre Petrescu wrote:
>
>
> Le 07/07/2020 à 17:15, Robert Moskowitz a écrit :
>>
>>
>> On 7/7/20 10:36 AM, Alexandre Petrescu wrote:
>>>
>>>
>>> Le 06/07/2020 à 20:57, Carsten Bormann a écrit :
>>>> On 2020-07-06, at 20:15, Amelia Andersdotter 
>>>> <amelia.ietf@andersdotter.cc> wrote:
>>>>>
>>>>> - In some European languages, there is no language-inherent ways 
>>>>> to express the difference between safety and security, said the 
>>>>> Scholar. In some Scandinavian languages, for
>>>>> instance, the closest translation of "safety" rather brings the
>>>>> mind to a state of personal comfort. It is easy to get lost in 
>>>>> translation when operating in fields that rely a lot on the 
>>>>> distinction.
>>>>
>>>> Indeed.  E.g., in German, both are called “Sicherheit”. In 
>>>> practice, we help ourselves by simply using the English terms when 
>>>> we need a more selective term.  If we are ever forced to actually 
>>>> speak German, we invent compound terms such as “Angriffssicherheit” 
>>>> (Security) and “Betriebssicherheit” (Safety).
>>>
>>> Platon would have probably said something about Σωτηρία (ancient 
>>> Greek for the name of a goddess of salvation), especially because he 
>>> cared about that, as he found the defenders to be very useful.
>>>
>>> That aside,
>>>
>>> I wonder why the choice of encoding an identifier in one
>>> domainname was made, and not that of set of them?
>>
>> Nothing prevents a UA from having multiple IDs to use where needed. 
>> Just the caveat that the Basic ID Message only has room for one ID 
>> and it is expected that that ID be used for a whole Operation.
>>
>>> There could be two domainnames in an onboard network of a flying 
>>> taxi: one dedicated to the hosts on the onboard safety network and 
>>> one for the hosts on the entertainment network, for the
>>> traveller's smartphone wifi.
>>
>> UAM provides some other interesting considerations.  I suspect that
>> a UAM will still be required to Broadcast Remote ID messages. In 
>> theory it could have 2 radios sending out different set of messages 
>> with different MAC addresses (Note that many Brd-RID messages do NOT 
>> have the Remote ID, the receiver MUST be able to correlate messages 
>> to RID based on MAC).
>
> A querier receiving simply two such unrelated IDs would have difficulty
> distinguishing that being one object or two objects flying in formation.
> ('flightooning', akin to 'platooning' which is a convoy of trucks on 
> road).

Exactly.  I *THINK* there is wording in the FAA NPRM of only one RID for 
a UA during an operation.

>
> A number that is painted would not have such a problem, because the
> paint is glued on one object.

As opposed to auto license plates that 'questionable' people attach with 
electro-magnets to drop the fake plate as needed?  :)


>
>>> When that is so, one would still want one domainname to be 
>>> advertised to the outside, like there is just one text painted on 
>>> the outside.
>>>
>>> This makes me wonder if it would not be easier to just take that 
>>> conventional name painted on the outside frame and encode it in an
>>>  identifier, and why not putting it in an IPv6 address.
>>
>> CAAs REQUIRE a tail number for all commercial and almost all civil 
>> aircraft to be displayed clearly.  For your hobby drone, you are 
>> expected to register it with the FAA (or EASA in EU) and be assigned 
>> a tail number.
>
> Thanks.  I would guess a flying taxi would be more like an evolution of
> an existing flying car, which is itself more of a plane that can also
> drive on the highway, with its wings folded.  As such I would suspect
> the tail numbers apply to flying taxis.

Everything I have seen on UAM (Urban Air Mobility) has strict controls 
over them and this includes proper CAA registration and visible 'tail' 
numbers.

>
>> Thus for 'starters' a UA has THREE IDs: Manufacturer Serial Number, 
>> CAA registration, Remote ID.  Now the ASTM and FAA and EASA
>> proposals offer to use Serial # or Tail # as RID (see text about ASTM
>> RID types currently defined).
>>
>> But each CAA has its own rules on what is a tail number, thus 
>> encoding into an IPv6 address is interesting.  Actually that IS
>> being discussed in IATF GRAIN study group (yet another weekly call).
>
> For automobiles, it is very simple: there is a VIN number (Vehicle
> Identification Number) standardised by SAE and there is the license
> plate standardised by a country regulator.

As I said, I lived this.  Also when we had to put the VIN visible 
through the front window and on the engine block and a plate in the 
driver door frame.  Happy to have that behind me.

>
> It thus seems that the tail number is like a license plate.

That is how many see it.

> I wonder whether there is a number in planes that is similar to the VIN
> number in automobiles.

There is an airframe number that is standardized across the manned 
aircraft industry.  For UAS the proposal currently accepted is ANSI/CTA 
2063-A.  This presents challenges for DIY and researcher UA.


>
>>> If we do so, the privacy question would be easier: the painted
>>> text is there mandatory anyways so anyone can see it with a pair
>>> of binoculars.
>>
>> Yes, but that is not even VLOS as you can't always see where the 
>> number is.  With RID, it is RLOS.
>
> I see.
>
> It sounds like one would expect to query on the Internet the approach of
> a flying object, like I informally look some times at flightradar24.
> The great advantage is that I can query it from anywhere about anywhere.

This is the whole UTM/Observer 'ecosystem'.  I have seen one 
demonstration.  What you can learn is controlled by authentication. 
Perhaps I can find out the RID of all UA over downtown San Fran, but 
with my geoloc in Detroit, even a safety officer SHOULD not be able to 
learn about the Operator of those UA.


> For more formal identifications I would have suspected one would query
> the object in a more direct manner.

No.  Not direct.  Over what link?  This is why there is the whole UTM 
system that Stu has shown in his slides.

But our plan for HHITs for RID does provide for a rather formal 
identification.  By receiving the Authentication Messages (see Adam's 
drafts on the proposed content), an Observer can 'trust' the Remote ID.  
I talk about this in the Security Considerations section of my 
drip-uas-rid draft.

>
> Alex
>
>>
>> Oh, and I have been told there are 'perfect' replica model planes. 
>> For example it LOOKs just like a 737 even with binoculars.  But it
>> is only 1000' feet away, not 30000'.
>>
>> The whole privacy/safety issue is complex.
>>
>> Bob
>>
>>
>>>
>>> Alex
>>>
>>>
>>> The difference is presence or absence
>>>> of the human mind to effect the degradation of freedom from 
>>>> dangers. (Of course, the terms are not used as selectively in 
>>>> practice in English either, e.g., “social security” is mostly about 
>>>> safety.)
>>>>
>>>> Grüße, Carsten
>>>>
>>>
>>
>> -- 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
>

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