Re: [Tm-rid] 1st steps - time lines and drafts

[Robert Moskowitz <[e-mail]>]

On 8/1/19 4:55 PM, Michael Richardson wrote:
> Card, Stu <[e-mail]> wrote:
>      > I like the generality & extensibility of CBOR, CDDL, COSE, COID, etc.,
>      > esp.  as an attempt at future-proofing tm-rid.
>
> So, to be clear: CDDL is a documentation tool. It never travels on the wire.
> Some people may be able to generate code from CDDL.  Some people have also
> considered how to encode CDDL in... CDDL, which is a meta-meta situation, and
> double so, not something to worry about.
>
> COSE, COID are implemented on top of CBOR.
> IPv4 and IPv6, DHCP, OSPF, Radius, etc... all include variously (and
> differently) encoded "extensions" usually in the form of Type-Length-Value
> structures.
>
>      > I wonder, though, whether all their self-describing headers are too
>      > much overhead for the severely constrained Bluetooth frames of ASTM's
>      > proposed Broadcast Remote ID format.
>
> My experience with CBOR is that unless you want a flat non-extendable
> C-struct, and you will ALWAYS need *ALL* of the fields,  odds are that CBOR
> is smaller. CBOR probably does better at encoding than many of the TLV
> structures mentioned above, but probably the VLSI guys 20 years ago would
> have been annoyed with it's non-32-bit alignment.
>
>      > IETF, as latecomers to the aviation community's party, should look
>      > closely at what ASTM, FAA, ICAO, et al have already concluded or
>      > proposed, rather than regard this as an entirely clean slate; although
>      > a truly compelling solution might get them to change some of their
>      > thinking, as it has not yet been issued as a standard or implemented by
>      > UAS makers (beyond experimentally).
>
> Sure.  Can you point at the documents?

Start with:  https://github.com/opendroneid/specs

That directly impacts what we are planning here.