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

[Ira McDonald <[e-mail]>]

Hi Jari,

Thanks for a good summary of the existing contributions to Model-T.  I hope
most all of this work
will be saved and dispatched to an appropriate IETF or IRTF WG.

FWIW - Thursday 25 November is the US Thanksgiving Day holiday - you're not
likely to get many
US attendees.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Wed, Nov 3, 2021 at 8:19 AM Jari Arkko <[e-mail]> 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 mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>