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

[Schönwälder, Jürgen <[e-mail]>]

On Wed, Nov 13, 2019 at 07:24:10PM +0800, Michael Richardson wrote:
> 
> 
> On 2019-11-13 7:14 p.m., Schönwälder, Jürgen wrote:
> > On Wed, Nov 13, 2019 at 07:04:40PM +0800, Michael Richardson wrote:
> >>
> >> On 2019-11-13 1:56 a.m., Laurence Lundblade wrote:
> >>> Got that one totally wrong. I even knew everything you describe about YANG.
> >>>
> >>> I still think it is better if we just stick to EAT / CWT / JWT claims described with CDDL as the way we define claims in RATS, except for a few TPM-specific claims. 
> >> Nothing I've said is opposed to that.
> >> I rather agree.  I don't think that EAT is complex enough to require a
> >> definition in YANG.
> >>
> >> But, that also has nothing to do with whether we'd need a YANG signing
> >> standard if we defined them in YANG.
> >> We wouldn't, because we'd be signing JSON, CBOR (or XML if someone
> >> insisted) using JSOE and COSE.
> >>
> > I am still confused but so far for me it may make sense to have the
> > following:
> >
> > - A YANG defined transport for "tokens" which likely treats tokens as
> >   opaque objects.
> 
> okay, and we need this in the same document (the same model?) as the TPM
> stuff?

Likely not.
 
> I think that the process works okay for TPM, because we don't really
> expect the system that hosts the RESTCONF interface to actually use the
> RESTCONF interface to talk to the TPM.  We are just providing a gateway
> to it.

So which applications are using this RESTCONF interface? Can I somehow
relate this back to the architecture models? Henk's doc seems to be
telling me that the idea is that $something likes to retrieve
"evidence" by invoking YANG RPCs. So what is $something and why is
the evidence TPM specific?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>