Re: [Rats] Call for adoption (after draft rename) for Yang module draft

[Henk Birkholz <[e-mail]>]

Hi Jürgen,

I think this is very useful input.

On the list, Laurence and I already started to discuss Claims for "YANG 
modeled data" and Claims for "TPM modled data" (referred to as tpm 
tokens recently).

The remaining questions are about: What do you think is the upcoming/TBD 
impact on the current YANG module for challenge-response RATS?

Leveraging YANG modeled data comes up again and again. Maybe there is 
good approach here.

The TPM Interface based YANG Module does not simply convey native TPM 
structure, but decomposes them down the values that are useful and 
common on the management plane because the building blocks themselves 
have well defined semantics (always ensuring canonical re-composition).

Viele Grüße,

Henk

On 14.11.19 15:06, Schönwälder, Jürgen wrote:
> On Wed, Nov 13, 2019 at 10:07:02AM -0800, Laurence Lundblade wrote:
>>
>> I see EAT as applicable to all these worlds, where the YANG module is just for the smallish router world. So I mostly agree with Dave about proportions, however this is the IETF where YANG modules are created.  (Maybe I should go join the W3C world and work on attestations APIs for browsers after RATS is done).
>>
> 
> If EAT is the common format for "token", then it does not make sense
> to me to define a YANG version of it. It may make sense to carry EAT
> token over protocols such as NETCONF or RESTCONF and to have a YANG
> module defining this may make sense for the networking device world.
> This is then a definition of an interaction protocol, but not the
> token format itself.
> 
> If EAT is the common format for "token", then it may make sense to be
> able to include "claims" that are YANG defined data. That may be an
> extension of the core EAT definition (but EAT would have to allow for
> such an extension to work). There is a lot of formally defined data in
> YANG modules that would be convenient to reuse as claims in a
> networking world.
> 
> /js
>