Subject: Re: [Drip] Encoding HHITs in CTA-2063-A space(Internet mail)

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Mon, 4 Jan 2021 02:24:19 +0000

This may come out wrong, but I am curiously if it is possible to recognize where a drone is registered from the CTA or broadcast number.   Is that even useful?

The FAA Final rule does allow foreign national registered UA to fly at US.

Best,
Shuai Zhao

From: Tm-rid <[email-masked]> on behalf of "Card, Stu" <[email-masked]>
Date: Thursday, December 31, 2020 at 09:56
To: "[email-masked]" <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>, Michael Palage <[email-masked]>
Subject: Re: [Drip] Encoding HHITs in CTA-2063-A space(Internet mail)

Oops. One typo:

 from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is followed also Type 3 (SN);

should be

  from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is followed also Type 1 (SN);

Sorry. :-(

On Thu, Dec 31, 2020 at 12:52 PM Card, Stu <[email-masked]<mailto:[email-masked]>> wrote:
I worked this out many months ago, not just for ANSI/CTA-2063-A (ASTM UAS ID Type 1), but also for FAA single use SessionID (ASTM UAS ID Type 3, USS/UTM assigned UUID).

See again attached illustration.

However, it was based on the previous HHIT structure, so may need revision.

Also, "maybeHash" vs "maybeDerive" should be decided:

- hashing directly from HIbits to Hash64bits is in the spirit of cSHAKE;

- hashing first to Hash122bits, then deriving Hash64bits, allows the same HI to be used as the basis of a Type 3 (UUID128bits) and a Type 1 (CtaSN20char) with a computable mapping from the Type 3 to the Type 1, which _might_ be useful, e.g. to initialize a chain of registrations of SessionIDs that should be traceable (by authorized parties only) back to the SN.

ANSI/CTI-2063-A designates 0 (zero) vs O (oh) and 1 (one) vs I (eye) as the visually similar cases to be avoided: they drop oh and eye, I also dropped zero and one to get 32 characters; perhaps Bob's idea of dropping Z and S might be more useful (avoiding 2 more cases of ambiguity rather than more strongly avoiding the first 2 cases).

I assume each manufacturer code will correspond to a single HDA (either run by the manufacturer or run by some competent registry operator contracted by the manufacturer), and that this mapping can be resolved by DNS; other schemes for mapping MfrCode4char to MfrReg32bits (RAA, HDA) are possible, but only 21 bits are needed at most, and MFR code allocation is likely sparse.

Rather than fixing the first 2 characters to ZZ, they can encode the OGA ID (HIT Suite) and the last 4 bits of the IANA assigned prefix (in case additional "address" space is needed later); that is assumed in the attached diagram.

Summary (simplified, some caveats apply if OGA ID or IANA prefix vary):

- from HI and MFR code, one can derive HHIT, Type 1 (SN) and/or Type 3 (UUID);

- from Type 3 (UUID), one can derive HHIT, and if maybeDerive path is followed also Type 3 (SN);

- from Type 1 (SN), one can derive HHIT;

- from HHIT, one can derive Type 1 (SN) but _not_ Type 3 (UUID).

This has been my fall-back plan if ASTM declines to allocate a UAS ID Type for DRIP HHITs (although such an allocation is highly preferable).

The FAA Final Rule discussion about assignment of single use Session IDs in the absence of NetRID-SP USS invites our contribution!

On Thu, Dec 31, 2020 at 11:31 AM Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:
this is a serious consideration as part of draft-drip-rid for
manufacturers that assign HHITs at manufacture time and want both HHITs
and 2063 serial numbers:

1st consider a 34 valued character mapped to bits.

If only use 32 values (drop Z and S as too similar to 2 and 5), each
character can map 5 bits.  The 64 bit hash portion of the HHIT can be
encoded in 13 characters (65 bits).  But use a full 15 character length
with the first two being "ZZ".

The 4 character Manufacturer code is a big challenge.  Assume all 34
values possible.  It would take 23 bits for a dense binary encoding
(2^23 > 34^4).  This would take 1/512th of the RAA space to map this
into RAA|HDA.  Ouch.

So rather a registry of MC to Prefix|RAA|HDA (as longgg time for all MC
assigned), leaving what to do with the OGA.  That could replace the 2nd
Z above.

Messy, but maybe worth including?

I will shortly push out an update for drip-rid without this little
twist.  It needs time to ferment.

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 3 Jan 2021 21:31:53 -0500

No.

CTA is the manufacturer's code and some number.  Not where it is registered.

The Media Access Code is either the radio manufacturer's code or a link 
local unique value.

Nothing inherent about UA registration.

On 1/3/21 9:24 PM, shuaiizhao(Shuai Zhao) wrote:
>
> This may come out wrong, but I am curiously if it is possible to 
> recognize where a drone is registered from the CTA or broadcast 
> number.   Is that even useful?
>
> *From: *Tm-rid <[email-masked]> on behalf of "Card, Stu" 
> <[email-masked]>
> *Date: *Thursday, December 31, 2020 at 09:56
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Robert Moskowitz <[email-masked]>, Michael Palage 
> <[email-masked]>
> *Subject: *Re: [Drip] Encoding HHITs in CTA-2063-A space(Internet mail)
>
> Oops. One typo:
>
> On Thu, Dec 31, 2020 at 12:52 PM Card, Stu <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I worked this out many months ago, not just for ANSI/CTA-2063-A
>     (ASTM UAS ID Type 1), but also for FAA single use SessionID (ASTM
>     UAS ID Type 3, USS/UTM assigned UUID).
>
>     - hashing first to Hash122bits, then deriving Hash64bits, allows
>     the same HI to be used as the basis of a Type 3 (UUID128bits) and
>     a Type 1 (CtaSN20char) with a computable mapping from the Type 3
>     to the Type 1, which _might_ be useful, e.g. to initialize a chain
>     of registrations of SessionIDs that should be traceable (by
>     authorized parties only) back to the SN.
>
>     ANSI/CTI-2063-A designates 0 (zero) vs O (oh) and 1 (one) vs I
>     (eye) as the visually similar cases to be avoided: they drop oh
>     and eye, I also dropped zero and one to get 32 characters; perhaps
>     Bob's idea of dropping Z and S might be more useful (avoiding 2
>     more cases of ambiguity rather than more strongly avoiding the
>     first 2 cases).
>
>     I assume each manufacturer code will correspond to a single HDA
>     (either run by the manufacturer or run by some competent registry
>     operator contracted by the manufacturer), and that this mapping
>     can be resolved by DNS; other schemes for mapping MfrCode4char to
>     MfrReg32bits (RAA, HDA) are possible, but only 21 bits are needed
>     at most, and MFR code allocation is likely sparse.
>
>     Rather than fixing the first 2 characters to ZZ, they can encode
>     the OGA ID (HIT Suite) and the last 4 bits of the IANA assigned
>     prefix (in case additional "address" space is needed later); that
>     is assumed in the attached diagram.
>
>     This has been my fall-back plan if ASTM declines to allocate a UAS
>     ID Type for DRIP HHITs (although such an allocation is highly
>     preferable).
>
>     The FAA Final Rule discussion about assignment of single use
>     Session IDs in the absence of NetRID-SP USS invites our contribution!
>
>     On Thu, Dec 31, 2020 at 11:31 AM Robert Moskowitz
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>

-- 
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: "Stuart W. Card" <[email-masked]>
Date: Mon, 4 Jan 2021 07:54:10 -0500

Although one could imagine manufacturers using different CTA SN MFR 
Codes and/or registering for multiple MAC OUIs for the different 
countries into which they sell, that would still run afoul of subsequent 
re-registrations in other countries (e.g. UAS re-sale, lease, etc.).

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 4 Jan 2021 08:18:47 -0500

Manufacturers would have to make more per-determination in the country 
of sale during the build process.  Not likely.

MAC OUIs are already being recycled.  These are not free.  This, in 
part, is why many IoT boards just have not bothered with one, but use a 
random local scope MAC.

For example the Allwinner ARM boards that I have a lot of.

On 1/4/21 7:54 AM, Stuart W. Card wrote:
> countries into which they sell, that would still run afoul of 
> subsequent re-registrations in other countries (e.g. UAS re-sale, 
> lease, etc.).
>
>> The Media Access Code is either the radio manufacturer's code or a 
>> link local unique value.
>>
>>> On Thu, Dec 31, 2020 at 12:52 PM Card, Stu 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         --         Tm-rid mailing list