Re: [Rats] New RATS Architecture document

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 07 October 2019 23:21 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 DFEB3120044 for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 16:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE3d41lzxUgu for <rats@ietfa.amsl.com>; Mon, 7 Oct 2019 16:21:43 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 640C1120019 for <rats@ietf.org>; Mon, 7 Oct 2019 16:21:42 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id x97NLdo2028231 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 8 Oct 2019 01:21:40 +0200
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 8 Oct 2019 01:21:34 +0200
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
CC: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "rats@ietf.org" <rats@ietf.org>
References: <471c785f-1cd8-62ff-431a-075ce9c35058@sit.fraunhofer.de> <fe9e3870aaa6419697db4536e1f0718c@NASANEXM01C.na.qualcomm.com> <6619cceb1f3b400dbd9dbbce51c6fcfb@NASANEXM01C.na.qualcomm.com> <202c09a4-b385-6b7c-cd1d-25562f99850c@sit.fraunhofer.de> <083dbb8a7ad748f399453566af2eb541@NASANEXM01C.na.qualcomm.com> <9fa3ff77-04a5-3d58-b977-5febc8229967@sit.fraunhofer.de> <20191007231030.wugplutyaqiioeb3@anna.jacobs.jacobs-university.de>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <deb4b0d5-1061-2331-1ff1-b75deee9fe4b@sit.fraunhofer.de>
Date: Tue, 08 Oct 2019 01:21:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20191007231030.wugplutyaqiioeb3@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qOcJbLFqipyp-9PvCm2T7NmvyeE>
Subject: Re: [Rats] New RATS Architecture document
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, 07 Oct 2019 23:21:46 -0000

Hm.. if I use requirement notation and not include the BCP14 
boilerplate, that is an idnit, because you have to include the 
boilerplate then. And BCP14 is referring to standards track documents 
and not informational documents.

I've never questioned that line of thought before, tbh. There are maybe 
some individuals subscribed that can clarify this easily?

On 08.10.19 01:10, Schönwälder, Jürgen wrote:
> On Tue, Oct 08, 2019 at 12:41:40AM +0200, Henk Birkholz wrote:
>>
>> A document that uses normative requirements terminology is standards track.
>>
> 
> I just searched backwards for the most recent informational document
> and I found RFC (8649) and it violates this rule. RFC 7921 is
> informational and has "Architecture" in its title and uses RFC 2119
> language as well. So if this rule exists, the IETF is doing pretty
> bad following it. So where is the the rule defined?
> 
> The question whether a document is standards-track should follow from
> its content (is there material that is normative for creating
> interoperable implementations?) and not from specific keywords used to
> write this content down (or other formal aspects).
> 
> /js
>