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

Henk Birkholz <> Thu, 14 November 2019 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90533120274 for <>; Thu, 14 Nov 2019 07:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HVIFcVFMYKUp for <>; Thu, 14 Nov 2019 07:03:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4241012025D for <>; Thu, 14 Nov 2019 07:03:08 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xAEF2xM6027965 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 14 Nov 2019 16:03:00 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Thu, 14 Nov 2019 16:02:54 +0100
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <>, Laurence Lundblade <>
CC: Dave Thaler <>, "Nancy Cam-Winget (ncamwing)" <>, "Oliver, Ian (Nokia - FI/Espoo)" <>, "Smith, Ned" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Thu, 14 Nov 2019 16:02:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 15:03:12 -0000

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,


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