Re: [Model-t] Next steps from Tuesday's breakfast meeting

Jari Arkko <jari.arkko@piuha.net> Fri, 22 November 2019 04:09 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: model-t@ietfa.amsl.com
Delivered-To: model-t@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E42412004A for <model-t@ietfa.amsl.com>; Thu, 21 Nov 2019 20:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 ED7nwo-GutVs for <model-t@ietfa.amsl.com>; Thu, 21 Nov 2019 20:09:12 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48F12003F for <model-t@iab.org>; Thu, 21 Nov 2019 20:09:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6713D6601E4; Fri, 22 Nov 2019 06:09:10 +0200 (EET)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBgUVOqjCqGI; Fri, 22 Nov 2019 06:09:09 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 9CC5E6600C0; Fri, 22 Nov 2019 06:09:08 +0200 (EET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <b46fcb4d-45a6-3efd-a93e-357571bde679@nomountain.net>
Date: Fri, 22 Nov 2019 12:09:06 +0800
Cc: model-t@iab.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B51AC31-F1E5-4A26-BA9E-F2C5A467059F@piuha.net>
References: <A35A9A80-80A4-41A4-8C9B-4A964D565854@isoc.org> <b46fcb4d-45a6-3efd-a93e-357571bde679@nomountain.net>
To: Melinda Shore <melinda.shore@nomountain.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/fZCljW5_edtI9pZu7_kj4EppH1s>
Subject: Re: [Model-t] Next steps from Tuesday's breakfast meeting
X-BeenThere: model-t@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model <model-t.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/model-t>, <mailto:model-t-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/model-t/>
List-Post: <mailto:model-t@iab.org>
List-Help: <mailto:model-t-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/model-t>, <mailto:model-t-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 04:09:14 -0000

Thanks Robin and all.

On Melinda’s question — the following is my personal opinion:

First off, I think we need to produce IETF outputs. It is great that the IAB has kicked off work and is hosting the mailing list, but I ultimately this is primarily IETF results. Definitely the 3552 change needs to be.

Secondly, as Stephen says we’ll benefit from some parallel and independent works at the moment. That being said, I think there’s some value in brainstorming a bit even in the short term about where the different pieces of work might develop into. I’ve also chatted with some of you about this. From the document that me and Stephen have, we’re going to do one round of introducing additional materials, already in ÷  on our editor’s version but not yet published. Things like taking into account points made in our meeting this week and at the SAAG meeting last time. But moving forward, I think I see our document evolving/split into different parts:

* Analysis of why things have changed & architectural considerations (the bulk of our current doc)
* Suggested edits to 3552 (we have some of that now, but I suspect at some point someone is going to write a cleaner and better standalone document about it)
* Guidelines for designers on what to do avoid some of the issues (we have some of that, but again might be better as standalone document, or perhaps with competing proposals)

But in addition to this, there are many other parts that might benefit from having independent documents. E.g., a discussion of attacks and issues that we’ve seen that support the case for more careful consideration of these issues (Dominique or Ali perhaps). Or, a document on trust and where that comes from and plays with architecture (Melinda or Ted/Martin perhaps). A vulnerability analysis (Robin, perhaps). And I don’t mean to say we should avoid competing documents, those are very welcome at this point as well. But it is still worthwhile to think about the different aspects that one might want to write about, and focus a particular piece on a chosen angle.

Jari