Re: [Model-t] Meeting to discuss how (and if) to continue

Jari Arkko <jari.arkko@piuha.net> Thu, 11 November 2021 08:49 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 10EAC3A0E2A for <model-t@ietfa.amsl.com>; Thu, 11 Nov 2021 00:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 dCjHzkqfo3cK for <model-t@ietfa.amsl.com>; Thu, 11 Nov 2021 00:48:56 -0800 (PST)
Received: from p130.piuha.net (unknown [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CA3A0E28 for <model-t@iab.org>; Thu, 11 Nov 2021 00:48:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 441DF6601FE for <model-t@iab.org>; Thu, 11 Nov 2021 10:48:53 +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 6XRSEH_musZI for <model-t@iab.org>; Thu, 11 Nov 2021 10:48:51 +0200 (EET)
Received: from smtpclient.apple (p226.piuha.net [193.234.219.226]) by p130.piuha.net (Postfix) with ESMTPS id 26CD66601E2 for <model-t@iab.org>; Thu, 11 Nov 2021 10:48:51 +0200 (EET)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 11 Nov 2021 10:47:50 +0200
References: <6F924A7E-2119-41EB-A9EE-12881CE94C60@piuha.net>
To: model-t@iab.org
In-Reply-To: <6F924A7E-2119-41EB-A9EE-12881CE94C60@piuha.net>
Message-Id: <D0A26433-975C-4172-9D0B-8C290DEAFB05@piuha.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/iYCeHvuafOu-2wTw0YBR32lawP8>
Subject: Re: [Model-t] Meeting to discuss how (and if) to continue
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: Thu, 11 Nov 2021 08:49:01 -0000

Updating time to avoid Thanksgiving.

Would Thursday Dec 2nd, 22:00 Paris time, for one hour work? This is Thursday Dec 2nd, 13:00 San Francisco and Friday Dec 3rd, 08:00 Melbourne

Jari

> On 3. Nov 2021, at 14.18, Jari Arkko <jari.arkko@piuha.net> wrote:
> 
> Hi,
> 
> We’ve obviously not made much progress. This was discussed in previous IABOPEN session meeting in the summer, the IAB also discussed it subsequently. 
> 
> We could discuss why…. and have to some extent. Long story short, my opinion is that has been due to leadership problem (i.e., me) of not organising the group even to have meeting, despite fairly broad set of contributions. Secondly, in hindsight the original decision to focus on RFC 3552 updates may have been a mistake. IAB activities tend to do well on writing about architectural trends, principles to follow, etc, as we’ve seen with for instance RFCs 8546, 8558 or 8890. Thirdly, IAB activities other than one-time workshops are best done as something where there’s a strong drive and participation from IAB member(s), kind of as an extension of IAB helping to complete something, preferably something very specific.
> 
> But we could also discuss what to do now, if anything. I personally still believe this is an important topic, perhaps one of the most important ones in the Internet, at least from my perspective. The question is perhaps how. The good things are that we do have plenty of contributions, we have interested people, we’ve also heard offers from volunteers to help with leading efforts, and so on. But what’s the best way to organise activities, and what activities make sense to begin with? And what to focus on?
> 
> If we look at the different drafts, they can in my mind be classified into (1) general observations about attacks and trends with them, (2) architectural or security principles, and (3) updates of IETF guidance in RFCs 3552, 7258, etc. All of this is interesting, but have different nature. I think it is difficult for the program to get to a final result for the third category, for instance, simply because we don’t decide that in the end. And maybe the bar for that is too high anyway. The first category is very useful, but is also very dynamic in nature. And it is unclear to me to what extent there’s research in the academic world that would document some of that. Does someone know? I have a feeling that the drafts are more examples than comprehensive surveys, so more work would be needed. 
> 
> But perhaps there is some room for focused progress in the second category, documenting principles. For instance, Martin’s draft (draft-thomson-tmi) is an excellent contribution that addresses “intermediaries” and when/if they need to be involved. And what principles can be applied to ensure the involvement of intermediaries is done in reasonable manner. His concept is broader than middle boxes, by the way, covering even things like routers. I think this might be a potential direction for useful work, documenting principles such as those in Martin’s document. FWIW, I’m not suggesting that we must limit ourselves to that specific document — for instance, I think it would be useful to also discuss the role end-to-end services and how sharing of data with them can be done in a reasonable manner :-) But Martin’s document is certainly the one that in my mind is clearest and furthest ahead in this direction.
> 
> Anyway, if we were to focus on more actionable architectural advice, then maybe it would be easier to see what we could do together. For instance, perhaps we could re-define model-t to work on 1-2 specific pieces of advice expressed as principles to follow. I’d personally be happy to work on that or help guide a document forward.
> 
> But these are just my opinions. What do others think?
> 
> Perhaps it would be useful to discuss this on a call, and also to review documents in light of the above. I’d tentative suggest the following time slot for the meeting: Thursday Nov 25th, 22:00 Paris time, for one hour. This is Thursday Nov 25th, 13:00 San Francisco and Friday Nov 26th, 08:00 Melbourne. Would this be a reasonable time, or do people see major conflicts? If I don’t hear loud objections in the next couple of days, I will set up the call and send a calendar invite.
> 
> See below for a list of drafts related to the model-t discussions and my slide deck about the model-t situation from the summer IAB discussions.
> 
> Jari
> 
> ——
> 
> draft-arkko-arch-internet-threat-model-guidance	
> draft-arkko-arch-internet-threat-model	
> draft-mcfadden-smart-endpoint-taxonomy-for-cless	
> draft-lazanski-smart-users-internet	
> draft-arkko-farrell-arch-model-t	
> draft-lazanski-users-threat-model-t	
> draft-lazanski-protocol-sec-design-model-t	
> draft-mcfadden-smart-threat-changes	
> draft-thomson-tmi	
> draft-arkko-farrell-arch-model-t-7258-additions	
> draft-arkko-farrell-arch-model-t-3552-additions	
> draft-arkko-farrell-arch-model-t-redux	
> draft-arkko-iab-data-minimization-principle
> 
> <model-t-status-2021aug.pdf>-- 
> Model-t mailing list
> Model-t@iab.org
> https://www.iab.org/mailman/listinfo/model-t