[Model-t] Potential next steps with model-t & meeting

Jari Arkko <jari.arkko@piuha.net> Wed, 23 March 2022 17:39 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 801263A09EB for <model-t@ietfa.amsl.com>; Wed, 23 Mar 2022 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ISAYQum7nzcE for <model-t@ietfa.amsl.com>; Wed, 23 Mar 2022 10:39:36 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9482A3A00AF for <model-t@iab.org>; Wed, 23 Mar 2022 10:39:36 -0700 (PDT)
Received: from smtpclient.apple (dhcp-9af6.meeting.ietf.org [31.133.154.246]) by p130.piuha.net (Postfix) with ESMTPSA id 563FC6600E3 for <model-t@iab.org>; Wed, 23 Mar 2022 19:39:34 +0200 (EET)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52A06C1F-4785-4312-8F06-9A77F4A48AAB"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Message-Id: <E03CFB96-614A-4C7A-9895-FB719D9FB9D1@piuha.net>
Date: Wed, 23 Mar 2022 18:39:33 +0100
To: model-t@iab.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/rBFiDQuIVokvfm34zQ_7TXMNwjw>
Subject: [Model-t] Potential next steps with model-t & 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: Wed, 23 Mar 2022 17:39:42 -0000

Hi,

Since the December meeting we’ve had some amount of discussion on the list, including three drafts posted this year. I think we also have at one other document being worked that could be posted soon. I’m sorry we have not organised a meeting early in the year as promised in December, but I think there is some basis for moving forward.

In the December meeting, we divided potentially useful things we could do in two categories:

1/ documenting specific design principles motivated by evolving situation, to be published as short IAB RFCs
2/ proposing a way forward to document a change in the threat model

I did not actually form a design team of two people for item 1, but Martin and I have both discussed the documents and are trying to move them to a more reasonable state; mine in particular was heavily revised based on Martin’s input, and his draft was already in pretty good shape. My thought for this work item is that whatever we produce should not be an all-encompassing-cover-everything documents, but address specific, narrow issues that we believe are reasonable guidance at present time. The IAB is I think happy to publish documents, particularly when there are member(s) in the IAB that act as drivers for taking the documents through, which I think we have. Given the desire for specific guidance, the effort at least when it came to my document was to distill it more to the essential general principle. In my case the principle is about being careful about what data gets sent out (“only do it on a need-to-know-basis”), and in Martin’s case it is about being careful about the use of intermediaries. These are of course suggested drafts and principles, we can replace them with other ideas or change them if needed.

Mark had formed a design team for item 2, worked on a proposal, and organised a small meeting to talk about it. Mark, could you report on where you think you are?

I’d like to suggest a meeting in the weeks after the IETF. I realise the usual participants are from around many different timezones, so it seems appropriate to have a poll about the potential times for the meeting. The poll is here, please vote: https://doodle.com/meeting/participate/id/DbDg6Eka <https://doodle.com/meeting/participate/id/DbDg6Eka> 

Thoughts and comments on any of this?

For further information, see:

Archive: https://mailarchive.ietf.org/arch/browse/model-t/ <https://mailarchive.ietf.org/arch/browse/model-t/>
Notes from December: https://github.com/intarchboard/program-model-t/blob/master/notes/notes-2021-12-07.md <https://github.com/intarchboard/program-model-t/blob/master/notes/notes-2021-12-07.md>
Potential input drafts for work item 1, principles: https://datatracker.ietf.org/doc/html/draft-thomson-tmi-03 <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-03> and https://datatracker.ietf.org/doc/html/draft-arkko-iab-data-minimization-principle <https://datatracker.ietf.org/doc/html/draft-arkko-iab-data-minimization-principle> 
Other drafts posted to the list: https://datatracker.ietf.org/doc/html/draft-bertola-everything-but-the-user <https://datatracker.ietf.org/doc/html/draft-bertola-everything-but-the-user> 

Jari