Re: [Mimi] Gatekeeper comparison Re: Recap of June 7 virtual interim

[Alissa Cooper <[e-mail]>]

Hi Mallory,

> On Oct 25, 2023, at 7:55 PM, Mallory Knodel <[e-mail]> wrote:
> 

<snip>

>>>> 
>>> The point is to approximate the status quo-- right now closed systems have control over client integrity. Interop of any degree reduces that control. So no, I wouldn't think those cases would be central to the document. Probably a security considerations section mention that this specification doesn't cover that case or other active attacks (future work?).
>> 
>> I’m not quite following this. Since the WG is specifying server-to-server protocols, what protocol work do you view as being in scope related to clients and their integrity?
> 
> The design team is doing server to server protocols, of course. But MIMI is about end-to-end, so clients matter. 
> 
> But just to be sure, I checked the charter and among a bunch of other things there is “The working group will specify a solution to the introduction problem, together with best practice recommendations for functionality, configuration options, and other aspects.” Those other aspects probably have a thing or two to do with clients, not to mention the various other in-scope items in the charter that go beyond protocol. 
> 
> MLS has client aspects and MIMI is based on clients.
> 
> It’s certainly an important problem to be solved.

I’m trying to understand what you mean by “it.” What functionality related to clients and their integrity are you interested in standardizing?

Thanks,
Alissa

> Does MIMI want to work on it or should we leave it to the gatekeepers to write up their solution in individual white papers?
> 
> -Mallory
> 
>>>>  
>>>>>> 
>>>>>> On the end point problem, this is mostly very contentious territory but I would gently suggest it be worth wading in if not to keep intermediary interops (think of a 3p service that is not messaging but that provides automation or feature integration or ads!) from being within scope for interoperability. So, in MIMI do we consider only end points that are individual people with accounts or do you also allow the protocol to work for bots and such? How does that get defined?
>>>>>> 
>>>>>> I think the latter might stir some imagination around 3p-client-to-host protocol specifications (and what does a minimum set of features entail), but I'm not proposing that as work given the group has made the decision not to do that.
>>>>>> 
>>>>>> -Mallory
>>>>>>  
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> -Ekr
>>>>>>> 
>>>>>>>>>> I wonder if anyone else finds these two areas of work interesting? What's nice is that this work can happen totally in parallel to the design team as well as potentially have some real shape before the upcoming May deadline for gatekeepers for 1-1, where MIMI's DT deliverables are aiming for the following year. It might be useful to engage with policy makers before then with some concrete deliverable-- or at least informed discussion.
>>>>>>>>>> 
>>>>>>>>>> Since it's focussed on nudging gatekeeper status quo, another place this work would support ongoing efforts is filling in Alissa's draft on transport service requirements: https://github.com/coopdanger/ietf-wg-mimi/blob/main/mimi-transport-requirements.md.
>>>>>>>>>> 
>>>>>>>>> There have been additional discussions about architecture questions in interims and the DT. That particular document doesn’t reflect the current state anymore.
>>>>>>>>>> 
>>>>>>>>>> I'd be happy to share more about why I think these are gaps in gatekeeper compliance-- I've even got a slide deck. But I'm keen to hear others' thoughts about these parallel directions.
>>>>>>>>>> 
>>>>>>>>> I'd say this is something for an interim. Some coordination ahead of time would be good in order to make sure you are up to speed with the current status of discussion and there’s no overlap.
>>>>>>>> 
>>>>>>>> On the process:
>>>>>>>> 
>>>>>>>> I’d say the MIMI WG folks who are not in the DT all need to be caught up to speed as a general matter. 
>>>>>>>> 
>>>>>>>> But the point of this work would be that it shouldn’t matter so much on the DT work. They would run in parallel. 
>>>>>>>> 
>>>>>>>> Since it would be new-ish work, and in-person meetings tend to cast a wider net than interims, it might be strategic to talk about this in Prague so contributors might get engaged enough to make some progress as a WG?
>>>>>>>> 
>>>>>>>> -M
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Raphael
>>>>>>>>>> 
>>>>>>>>>> -Mallory
>>>>>>>>>> 
>>>>>>>>>> On 6/8/23 11:00 AM, Alissa Cooper wrote:
>>>>>>>>>>> Recording: https://www.youtube.com/watch?v=FE0Zr-82XAU
>>>>>>>>>>> 
>>>>>>>>>>> Raw notes: https://notes.ietf.org/notes-ietf-interim-2023-mimi-05-mimi#
>>>>>>>>>>> 
>>>>>>>>>>> DMA gatekeeper comparison shared by Matthew/Element: https://docs.google.com/spreadsheets/d/1FiR4yhU5BpLtoeFFda5ORr86qwT33fYZowY_bWDlPas/edit#gid=1722388534
>>>>>>>>>>> 
>>>>>>>>>>> Homework assignments for the WG:
>>>>>>>>>>> Review latest linearized Matrix I-D and have discussion on the list <https://www.ietf.org/archive/id/draft-ralston-mimi-linearized-matrix-01.html> <https://www.ietf.org/archive/id/draft-ralston-mimi-linearized-matrix-01.html>
>>>>>>>>>>> Review gatekeeper comparison and raise questions/comments on the list
>>>>>>>>>>> Get interop testing doing for LM, for those interested
>>>>>>>>>>> Alissa to take an initial stab at synthesizing requirements discussed from IETF 116 going forward
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alissa
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> Mallory Knodel
>>>>>>>>>> CTO :: Center for Democracy and Technology
>>>>>>>>>> newsletter :: https://internet.exchangepoint.tech <https://internet.exchangepoint.tech/>-- 
>>>>>>>>>> Mimi mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mimi
>>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Mimi mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mimi
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Mallory Knodel
>>>>>> CTO, Center for Democracy and Technology
>>>>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Mallory Knodel
>>>>> CTO, Center for Democracy and Technology
>>>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>>> 
>>> 
>>> 
>>> --
>>> Mallory Knodel
>>> CTO, Center for Democracy and Technology
>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>> 
>>