IETF Logo Mail Archive

Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 30 November 2020 18:11 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAA43A0F2E for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 10:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vqv8jnR228w for <rats@ietfa.amsl.com>; Mon, 30 Nov 2020 10:11:41 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374123A0FE2 for <rats@ietf.org>; Mon, 30 Nov 2020 10:11:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E916E389A1; Mon, 30 Nov 2020 13:13:06 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2qz_vFdNzHSR; Mon, 30 Nov 2020 13:13:06 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 805CE389A0; Mon, 30 Nov 2020 13:13:06 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D3E7A71C; Mon, 30 Nov 2020 13:11:24 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Giri Mandyam <mandyam@qti.qualcomm.com>, "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <BL0PR11MB3122D35683FD909A3C80E4DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <24519.1606681083@localhost> <BL0PR11MB312296BEFD428C6D9CE9A5DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com> <AM0PR08MB371606D3753BED36E71A5754FAF50@AM0PR08MB3716.eurprd08.prod.outlook.com> <BL0PR11MB3122D35683FD909A3C80E4DEA1F50@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 30 Nov 2020 13:11:24 -0500
Message-ID: <3849.1606759884@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/KVMOozh9BdvX1mSJ4wvwF9O4MHc>
Subject: Re: [Rats] challenges of building dependant specifications against Internet-Drafts -- a way forward for EAT
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: Mon, 30 Nov 2020 18:11:43 -0000

Eric Voit (evoit) <evoit@cisco.com> wrote:
    > Yes, we agreed to use the CWT registry.

I didn't feel that this decision was very strong, and I thought that we went
back and forth at least twice on this, with various kinds of sub-registries
proposed.

    > I also recall using YANG objects and a potential definition and range
    > source for any new claims that people wanted to add.  (I.e., if it
    > exists, let's use it.  And then we don't have to worry about
    > cross-domain mapping.)   My reading of Michael's email is that this was
    > the purpose of the table included in the bottom of this thread.

As I understood Giri's issue, he didn't think he could register production
values into the EAT registry until the document was finished.  That's what I
got from watching the video.

If we are using the CWT registry, then he can just go ahead, as the registry
already exists, and at least some of it is FCFS.

If we are not, then my text was an example of what a different WG did to deal
with early adopters.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email