Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

["Eric Voit (evoit)" <[e-mail]>]

Hi Michael,

This thread reminds me of some of the EAT draft adoption discussions from May of 2019.   Some of the threads I remember from the discussion include:

https://mailarchive.ietf.org/arch/msg/rats/7Uzkd84plkQ_LJ6oUYTQ3iwkmws/
https://mailarchive.ietf.org/arch/msg/rats/KPU6WgiCGkT6mUTbf5Ga41KwSNc/
https://mailarchive.ietf.org/arch/msg/rats/jBCYPK2hly554HGYTXZXa2t_AGw/

At the time, there was general agreement that where object definitions existed, it would be good to re-use them.  That would reduce the mapping needed between IANA maintained object definitions between technology spaces.  

Below in your email you point to a list of YANG specifications named within draft-ietf-core-sid, section 7.5.3.  I think you are doing this for as a starting point for some object definition contents.  Am I interpreting this correctly?   If yes, this is exactly what I was hoping might happen.

Eric


> From: Michael Richardson, November 29, 2020 3:18 PM
> To: Giri Mandyam <[e-mail]>; [e-mail]
> Subject: [Rats] challenges of building dependant specifications against Internet-
> Drafts -- a way forward for EAT
> 
> 
> Hi, sorry that I missed the RATS IETF109 meeting: I was engaged as co-chair
> of ASDF at the same time.   I watched the video.
> 
> I think that the many EAT concerns are now at the point where more
> conversation probably will make it worse rather than better.
> It's time to move on with the EAT framework: many of the issues discussed will
> become much clearer when it is used.
> That's why we have "PS" vs "Internet Standard".
> 
> I found Giri's presentation interesting: I scanned through the FIDO IoT
> Onboarding document, and I have no idea why FIDO needs to re-invent
> (Constrained) BRSKI.   But, I'm excited about it!
> 
> The more the manufacturers understand the need for device identities, and for a
> "home base" (A Registrar), the better our whole industry will be.
> When MS tried to do this with the XBOX-1 a decade ago, people cried foul, but
> maybe they weren't ready for this in the home yet.  We certainly need it to be
> standards based, and free of stupid IPR stuff.  What will CHIP do, I wonder.
> 
> The single reference to RFC8366 did not explain why that document did not
> adopt a semantically compatible voucher format.
> 
> draft-ietf-anima-constrained-voucher explains how to serialize the YANG to
> CBOR using draft-ietf-core-yang-cbor and draft-ietf-core-sid.
> This is then signed with COSE.
> {Or CMS, but that option is going away}
> 
> The result is almost *syntactically* identical to an EAT (a map of stuff signed by
> COSE)!
> But the semantics are a fair bit different.
> Vouchers contain many things which I would not call claims, but embody
> essentially a single claim concerning ownership.
> 
> draft-ietf-core-sid establishes a registry for SID values, which as essentially map
> keys for CBOR.  It has been difficult to get the document to advance, and until it
> did, we couldn't figure out how we'd be able to do the IANA allocation process:
> hard to get an early allocation against a registry which does not yet exist.
> 
> What we did, and what Giri could ask the EAT authors and WG to do is to
> allocate some claims in the initial IANA Considerations section.
> That is, until such time as the document progresses through the IESG, the WG
> and the document authors essentially act as IANA.
> 
> Here is what it looks like from draft-ietf-core-sid:
> 
> section 7.5.3 (of sid-14):
> 
>    Initial entries in this registry are as follows:
> 
>    +-------+------+---------------------------+------------------------+
>    | Entry | Size | Module name               | Document reference     |
>    | Point |      |                           |                        |
>    +-------+------+---------------------------+------------------------+
>    |  1000 |  100 | ietf-coreconf             | [I-D.ietf-core-comi]   |
>    |  1100 |   50 | ietf-yang-types           | [RFC6991]              |
>    |  1150 |   50 | ietf-inet-types           | [RFC6991]              |
>    |  1200 |   50 | iana-crypt-hash           | [RFC7317]              |
>    |  1250 |   50 | ietf-netconf-acm          | [RFC8341]              |
>    |  1300 |   50 | ietf-sid-file             | RFCXXXX                |
>    |  1500 |  100 | ietf-interfaces           | [RFC8343]              |
>    |  1600 |  100 | ietf-ip                   | [RFC8344]              |
>    |  1700 |  100 | ietf-system               | [RFC7317]              |
>    |  1800 |  400 | iana-if-type              | [RFC7224]              |
>    |  2400 |   50 | ietf-voucher              | [RFC8366]              |
>    |  2450 |   50 | ietf-constrained-voucher  | [I-D.ietf-anima-constr |
>    |       |      |                           | ained-voucher]         |
>    |  2500 |   50 | ietf-constrained-voucher- | [I-D.ietf-anima-constr |
>    |       |      | request                   | ained-voucher]         |
>    +-------+------+---------------------------+------------------------+
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>