Re: [Rats] Call for Adoption: EAT draft

So if an EAT is a CWT, then the proposal is to change the IANA registry rules for CWT in the EAT draft. Is that allowed? This is really a change to CWT and even JWT. Seems like it is saying that if a YANG-defined claim exists for a possible CWT or JWT claim, the YANG-based claim MUST be used. 

I think Eric’s thought about harmonizing is a good one. Learn from past efforts. Improve interop.

However, IANA registry rules revising aside, making it a MUST seems too much. I think the YANG-defined claims should be very much seriously considered, just like any other previous data structure definition, but that there be no blanket requirement.

To go a little further and to be clear. When a YANG-defined claim is used the CBOR encoding of it will be used with CWT and the JSON encoding of it will be used with JWT. This hinges on draft-ietf-core-yang-cbor-10 producing satisfying, compact and sensible CBOR encodings (binary data is really CBOR binary, claim keys are small integers…).

LL

> On May 30, 2019, at 12:19 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
> 
> Hi Hannes,
> 
> I do like EAT.  I am hoping that it gets adopted.  
> 
> At the same time, I am trying to avoid unnecessary mapping of claims from a chipmakers domain into system integrator /network operator domains.  I believe much pain can be avoided with a little planning up front.  That is what I am trying to facilitate with this discussion.  
> 
> Specific details/examples in-line...
> 
>> From: Hannes Tschofenig, May 30, 2019 1:18 PM
>> 
>> Hi Giri, Hi Eric,   
>> 
>> (a) some principles/guidance to CWT claims registry people on avoiding the mass registration of lightly-used or unused claims
>> 
>> Why is this a requirement? When a claim is registered then it is most likely done with the anticipation that it will be used. I have not seen other IETF registries that have raised the bar to a similar level, at least the JWT claims registry does not work that way. Furthermore, what is the harm in registering claims that later turn out to be less frequently used? 
> 
> Let me provide a *best* case example.  In the NETMOD WG, there is a draft-ietf-netmod-geo-location.  Both that draft and this have definitions of latitude, longitude, altitude, accuracy, etc.   The *good* news is that both drafts are based on WGS84.  So at least our experts have lucked in to using a consistent resource.  But are these the same objects?  How does a reader know?   In one of the documents the latitude/longitude attributes are "FloatOrNumber", in the other they are "decimal64 {fraction-digits 16}".
> 
> It of course gets harder for other objects.   The velocity objects in draft-mandyam-rats-eat are "heading" and "speed".  And draft-ietf-netmod-geo-location has this information "v-north", " v-east", and " v-up".  Here we have different formats, the first of which cannot be easily upgraded to serve three dimensions.
> 
> And then we get into other harder objects where we will have timestamping, explicit domains of allowed entries, etc.  And is there is no boundaries on what might be claimed as an EAT, in theory we could create a parallel domain of objects without description on how to map between the two, placing the heavy lifting onto the implementer.
> 
> Now I am not trying to solve world hunger in this thread.  I am just trying to have the draft consider minimizing inter-ecosystem friction where we can see it coming.  I believe with a little foresight we can ensure a consistent population and data typing for a subset of claims.   Without foresight, I see that people will create new CWT to avoid some later mapping.  And more/redundant CWT tags will harm interoperability.
> 
>> (b) a requirement to map claims to existing YANG objects, if these YANG objects exist 
>> 
>> I also don’t understand this requirement. Is there some design rational why this would be needed/useful?
> 
> Per above, EAT claim instances need to be integrated with other work/ecosystems in the IETF after the information comes off of a hardware chip.  A claim registry shouldn't create redundant info/formats to other work/ecosystems when it can be avoided, at least without broad discussion and consensus.   (I.e., lets avoid unconscious object definition and object domain overlaps wherever possible.)
> 
> Eric
> 
>> Cia
>> Hannes
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats