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

The trouble is that I think many claims should be in the Standards Action range (-255 to 255).  For example, nonce, ueid, submods section, location, CoSWID and probably a few others should be in the standard space. If I were IANA I would hesitate to register these in the Standards Action range until the EAT document is further along. 

It also seems poor practice to unilaterally pre-assign Standards Action range claims in an EAT draft and then use them in a bunch of implementations. Those numbers could be assigned to some one else before EAT is an RFC.

Here’s one proposal:

We put claim numbers in the EAT document from the private space CWT space (less than -65536). These can be the same as in my in-progress EAT implementation here. Hopefully other implementations do the same. Also, the same as the claims in the ARM PSA token draft <https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-05> where they overlap.

When the EAT draft is standardized, new Standards Action range numbers will get assigned. Implementations can either continue using the old private space CWT numbers or they can move to the new numbers. It is pretty easy for a receiver of a token to accept both the old and new numbers. It is just one extra if statement or case in a case statement. The sender of a token can stick to the old private ones for a long time, until the receivers they care about support the new ones. There is some motivation to move to the new ones because of the size reduction.

Another proposal:

Register them in the Specification Required space (255 to 65535) once and for all. That will result in 3-byte map labels rather than 1-byte map labels, but there’s no transition.

Finally, a third proposal:

Maybe we can convince IANA to pre-register a small clear set in the standard space? Perhaps just nonce and UEID.

LL

> On Nov 30, 2020, at 10:11 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Eric Voit (evoit) <evoit@cisco.com> wrote:
>> Yes, we agreed to use the CWT registry.
> 
> I didn't feel that this decision was very strong, and I thought that we went
> back and forth at least twice on this, with various kinds of sub-registries
> proposed.
> 
>> I also recall using YANG objects and a potential definition and range
>> source for any new claims that people wanted to add.  (I.e., if it
>> exists, let's use it.  And then we don't have to worry about
>> cross-domain mapping.)   My reading of Michael's email is that this was
>> the purpose of the table included in the bottom of this thread.
> 
> As I understood Giri's issue, he didn't think he could register production
> values into the EAT registry until the document was finished.  That's what I
> got from watching the video.
> 
> If we are using the CWT registry, then he can just go ahead, as the registry
> already exists, and at least some of it is FCFS.
> 
> If we are not, then my text was an example of what a different WG did to deal
> with early adopters.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats