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

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Fri, 15 November 2019 00:48 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9AC33120072 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 16:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JJr5DKAeJWsn for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 16:48:51 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B57120059 for <rats@ietf.org>; Thu, 14 Nov 2019 16:48:50 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 29F0CB4DF98EF3C2A612; Fri, 15 Nov 2019 00:48:49 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com ( by lhreml702-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 15 Nov 2019 00:48:48 +0000
Received: from DGGEMM531-MBS.china.huawei.com ([]) by DGGEMM402-HUB.china.huawei.com ([]) with mapi id 14.03.0439.000; Fri, 15 Nov 2019 08:48:41 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>, Laurence Lundblade <lgl@island-resort.com>
CC: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, "Smith, Ned" <ned.smith@intel.com>, Dave Thaler <dthaler@microsoft.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Call for adoption (after draft rename) for Yang module draft
Date: Fri, 15 Nov 2019 00:48:41 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EA3630F@DGGEMM531-MBS.china.huawei.com>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com> <MWHPR21MB07844F61BEFAE03F9E7DD290A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <6E7D64B4-2049-4D0A-ADC5-CA3F0647779B@island-resort.com> <20191114140600.itrr5mjiysgutsj5@anna.jacobs.jacobs-university.de> <59707a99-8cec-2005-b1ee-72f171234cbe@sit.fraunhofer.de> <DM6PR11MB4154A67956517DF2D9D305ADA1710@DM6PR11MB4154.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB4154A67956517DF2D9D305ADA1710@DM6PR11MB4154.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/PCFcCW0-oQdiNk5oCTDV3_ZXHak>
Subject: [Rats] =?utf-8?b?562U5aSNOiAgQ2FsbCBmb3IgYWRvcHRpb24gKGFmdGVy?= =?utf-8?q?_draft_rename=29_for_Yang_module_draft?=
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2019 00:48:55 -0000

Hi Eric,
You are exactly expressing my mind here~~


发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Eric Voit (evoit)
发送时间: 2019年11月15日 0:02
收件人: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>de>; Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de>de>; Laurence Lundblade <lgl@island-resort.com>
抄送: Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>om>; Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com>om>; Smith, Ned <ned.smith@intel.com>om>; Dave Thaler <dthaler@microsoft.com>om>; rats@ietf.org
主题: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Hi Jürgen,
Hi Henk,

What routers need is exactly what you said.  
 - currently: the retrieval of TPM originated/signed quotes.   
 - in the future: the retrieval EAT Tokens

Knowing when to retrieve these items is a function of the value of specific claims inside those structures.  For example, I might want to use RFC-8641 to make a YANG Subscription to a router so that I will be pushed the latest TPM quote when a specific PCR changes.  For this to work in the router world, we must have the structures of Quotes/Tokens exposed by a YANG model.


> 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
> >
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats