Re: [T2TRG] [core] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?)

Carsten Bormann <cabo@tzi.org> Mon, 20 December 2021 18:01 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16F3A040B for <t2trg@ietfa.amsl.com>; Mon, 20 Dec 2021 10:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 mzSVIvcQAOSr for <t2trg@ietfa.amsl.com>; Mon, 20 Dec 2021 10:01:38 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6653A03EA for <t2trg@irtf.org>; Mon, 20 Dec 2021 10:01:38 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHnTW1HdDzDCnl; Mon, 20 Dec 2021 19:01:35 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <13383.1640023097@localhost>
Date: Mon, 20 Dec 2021 19:01:34 +0100
Cc: "Apple Inc." <goran.selander@ericsson.com>, "t2trg@irtf.org" <t2trg@irtf.org>, "core@ietf.org" <core@ietf.org>
X-Mao-Original-Outgoing-Id: 661716094.208497-efc730248854ded5eb62fa74b938489c
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F90658A-DD84-47CA-A431-E4F49AA3D3E0@tzi.org>
References: <YYkUABLfpU/SRaxX@hephaistos.amsuess.com> <YYqfI38dg8035RLn@hephaistos.amsuess.com> <YZPGVxFc7AvdYXNB@hephaistos.amsuess.com> <AM4PR0701MB21955D1AB35A1A335B5EFDD0F4669@AM4PR0701MB2195.eurprd07.prod.outlook.com> <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> <AM4PR0701MB2195A52DA79B1E88364BCAD7F47B9@AM4PR0701MB2195.eurprd07.prod.outlook.com> <2420.1640020970@localhost> <EDAA4FFE-3B99-4F13-AB09-EA5E89ECB7A8@tzi.org> <13383.1640023097@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/SH8zuU7zIO_1k24Wsu6c16hlPLI>
Subject: Re: [T2TRG] [core] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?)
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Dec 2021 18:01:43 -0000


> On 2021-12-20, at 18:58, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> Signed PGP part
> 
> Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> applicability statement.
> 
>> That word is taken (Section 3.2 of RFC 2026), so please don’t use it
>> unless you actually do mean this (rather unsuccessful) form of
>> specification.
> 
>> https://datatracker.ietf.org/doc/html/rfc2026#section-3.2
> 
> I think that I really do mean this word in exactly the context given.
> I agree that they have often been unused or ill-applied, but also often do
> work.

As an informational document, sure.  In the RFC 2026 sense, hmm.

Note that the activity discussed in this thread is really trying to organize an activity of the T2TRG, and RGs don’t do standards, so any RFC 2026 ASs would need to be done elsewhere.  But research identifying good (and not so good) combinations does make a lot of sense here.

Grüße, Carsten