Ira McDonald (Musician / Software Architect)

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