Re: [Drip] HHIT field order & draft status

["Card, Stu" <[e-mail]>]

I address here only the one question Bob directed specifically to me.

Yes, ASTM F3411 (cited by EASA & FAA) requires that all mandatory elements
of information in UAS RID be the same whether sent via Broadcast or Network.

The UAS ID itself is the most fundamental of these.

This obviously may have implications for HHIT structure given the different
prefix lengths of generic HIP vs GRAIN etc.

I feel we may be obsessing excessively about hash collisions, as the most
basic function of a HDA should be to reject attempts to register colliding
HHITs.

Adam & I are flight testing for FAA all week, with 1 of 2 major focii being
UAS RID (the other is UTM interoperability of several USS from different
providers).

That is positive for DRIP but means our attention to this email list,
including responses to queries driving editing of drafts, will be limited.

Fortunately, except for the questions I asked over the weekend, some of the
most recent review, & final proofreading, the Requirements draft is done
per inputs received from all prior reviews & meetings. :-)

On Mon, Oct 5, 2020, 8:57 AM Robert Moskowitz <[e-mail]>
wrote:

> This note is going to ask for thoughts on the order of the fields in a
> HHIT.  Either
>
> Prefix | Suite ID | RAA | HDA | HI Hash
>
> or
>
> Prefix | RAA | HDA | Suite ID | HI Hash
>
> =================
>
> In drip-uas-rid, I define the HHIT fields, as I did in
> draft-moskowitz-hip-arch-02 in '01, as follows:
>
>     A HHIT is built from the following fields:
>
>     *  28 bit IANA prefix
>
>     *  4 bit HIT Suite ID
>
>     *  16 bit Registered Assigning Authority (RAA)
>
>     *  16 bit Hierarchical HIT Domain Authority (HDA)
>
>     *  64 bit ORCHID hash
>
>
> But I am proposing a different arrangement in the ICAO/GRAIN IPv6
> scheme.  First a bit about GRAIN.
>
> The GRAIN network is for Commercial-Civil aviation:
>
> "1.2    The network enabling the IATF, the Global Resilient Aviation
> Interoperable Network"
> (GRAIN), is envisioned as an aviation only (dedicated) IPv6 overlay
> network on a series of underlying
> networks and supporting network services."
>
> In some doc that I can't find right now this is limited to
> commercial/civil aviation.  Further we have:
>
> "[Please note that all recreational drone operation within Line Of Sight
> (LOS), Class G airspace are not included in this schema. Recreational
> drones using point-to-point LOS Command and Control (C2) are outside the
> scope]"
>
> So there is a potential and almost for sure bifurcating split in UAS
> networking.  This does not impact Broadcast Remote ID, but it does
> impact Network Remote ID.  The actual Remote ID SHOULD be the same for
> each mode.  (Stu does the reqs say this?)
>
> The regulators are going to have to figure out the demark.  Are
> Police/Fire and Small Business like photographers and realtors in GRAIN
> or out of GRAIN.  It will be interesting, as I suspect it will be a
> higher cost to be in GRAIN, but there are some advantages to participants.
>
> I should provide an aside here that the GRAIN prefix plus "platform
> type" could be /20 so the following reflects this.
>
> I added HHITs into the GRAIN addressing scheme, minimally for
> commercial/civil UAS usage.  It could be used for more than UAS within
> GRAIN.  In doing this I came to thinking two reasons for altering the
> field order.
>
> I put the Suite ID after the HID:
>
> "ICAO DELEGATED NETWORKS /16 FOR PLATFORM TYPE 13 – Hierarchical Host
> Identifier Tags (HHITs)
> /16 IANA Prefix Addressing Scheme
>
> Bit #        Field Length        Purpose
> 1 – 16        16            ICAO IPv6 prefix
> 17 – 20        4            Platform type = 13
> 21 – 36       16            GRAIN HHIT RAA
> 37 – 52       16            GRAIN HHIT HDA
> 53 – 56        4            HHIT Crypto Suite
> 57 – 128      72            HHIT HI Hash
>
> A HHIT Registered Assigning Authority (RAA) will apply for GRAIN
> membership and be allocated a /36 prefix from this type with their RAA
> GRAIN number being used in the 16 bits after the platform type. The RAAs
> will then accept HHIT Hierarchical HIT Domain Authorities (HDA) as
> sub-members and allocate to them /52 prefixes.
>
> These HDAs will accept registration from UAS of HHIT Crypto Suite/HI
> Hash per the IETF DRIP UAS-RID documents using a 72 bit hash. GRAIN HHIT
> addresses may be for the life of the UAS or may be registered for only
> some operational period."
>
> Note, I do NOT envision different Crypto Suites by HDA.  And:
>
> "A .01% hash collision probability occurs after ~1 Billion HHITs
> registered (based on the 72 bit hash size) with an HDA. This increases
> to 1% with ~10 Billion HHITs registered. If an HDA’s business model is
> to provide a per operation HHIT for delivery UA, and supports a
> clientele of 1 Million UA making 10 deliveries per day, then the HDA
> will reach the .01% level in 100 days of operation.  Thus an HDA
> provider in this type of business may request a block of 128 HDAs from
> its RAA."
>
> ========================
>
> The importance here is putting the Crypto Suite and HI Hash together and
> the Prefix and aggregation information at the front.  This is good for
> filtering policy.  It also makes sense in grouping the HIT specific
> parts and the prefix parts.
>
> But does it cause any coding or other challenges.  Adam seems to think
> so and so far he is the only coder active...
>
> I look forward to a lively debate on this!
>
> Bob
>
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>