Re: [MLS] [new-work] WG Review: Messaging Layer Security (mls)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Eric,

On Sat, May 26, 2018 at 5:18 PM Eric Rescorla <[e-mail]> wrote:

> I think even Class 2 devices should be out of scope. If it happens to be
> the case that the protocol works for them, then great, but it shouldn't be
> a design consideration.
>
> More to the point, I don't really understand why this needs to be in the
> charter. Again, the default assumption should be that devices aren't
> constrained; if each charter is going to need to say that, we're going to
> need to revise a lot of WG charters.
>

I agree that charters don't need to include a mention of everything that is
out of scope - not only would we be revising a lot of WG charters, but the
revised chartered would be really long (and for extra credit, we could read
them aloud as children's books, because they would sound a lot like "Green
Eggs and Ham"(*)).

I do think it makes sense to include topics that have come up in chartering
discussions, especially if the resulting answer was "no, we're not gonna do
that", because some working group participants can be really sure that that
thing we decided not to do was really the right thing to do after all, and
being able to point to the charter can make life easier for chairs and ADs.

That's why I commented about this.

Do the right thing, of course ...

Spencer

(*) for those who don't know "Green Eggs and Ham", it's a children's book,
and an excerpt is at
https://genius.com/Dr-seuss-green-eggs-and-ham-excerpt-annotated. The
complete book is much more endless than the excerpt would make you think -
endless enough that my junior senator, the Savior Of IANA IPR Except Not,
read the book aloud to the assembled senate during a filibuster in 2013.
YouTube is at https://www.youtube.com/watch?v=q8-NuwTjtq4.


> -Ekr
>
>
>
> On Sat, May 26, 2018 at 2:46 PM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> FWIW,
>>
>> On Fri, May 25, 2018 at 11:23 AM Peter Saint-Andre <[e-mail]>
>> wrote:
>>
>>> On 5/24/18 8:05 AM, Eric Rescorla wrote:
>>> >
>>> >
>>> > On Mon, May 14, 2018 at 8:55 AM, Peter Saint-Andre <
>>> [e-mail]
>>> > <mailto:[e-mail]>> wrote:
>>> >
>>> >     Two points:
>>> >
>>> >     1. It would be helpful to specify the expected capabilities of
>>> devices
>>> >     on which the resulting protocol might be deployed, such as only
>>> personal
>>> >     devices (e.g., phones and tablets) or also Internet of Things
>>> devices.
>>> >     If IoT devices are in scope (I hope they are!), then citing RFC
>>> 7228
>>> >     would be good:
>>> >
>>> >     https://datatracker.ietf.org/doc/rfc7228/
>>> >     <https://datatracker.ietf.org/doc/rfc7228/>
>>> >
>>> >
>>> > I think the default is we assume reasonably powerful general purpose
>>> > computers,
>>>
>>> Constrained devices are indeed hard to design for (and there are many
>>> dimensions of constraint - code size, memory, storage, battery, etc.). I
>>> wouldn't necessarily argue for supporting Class 0 devices (which
>>> according to RFC 7228 are "very constrained sensor-like motes"), but
>>> Class 2 devices (which are "fundamentally capable of supporting most of
>>> the same protocol stacks as used on notebooks or servers") would be
>>> great. I'm not sure where to draw the line and whether to include Class
>>> 1 devices (which "are quite constrained in code space and processing
>>> capabilities, such that they cannot easily talk to other Internet nodes
>>> employing a full protocol stack such as using HTTP, Transport Layer
>>> Security (TLS), and related security protocols and XML-based data
>>> representations").
>>>
>>> > so if people want IoT to be designed for -- which it
>>> > shouldn't, IMO -- then that would have to be stated in the charter.
>>>
>>> No matter what we decide, it would be good to make that explicit in the
>>> charter.
>>>
>>
>> I'd agree with Peter in general, but especially in this case - it seems
>> unhelpful to the working group to make them figure out whether to include
>> Class 1 devices in their work, after they've been chartered.
>>
>> Spencer
>>
>>
>>>
>>> Peter
>>>
>>>
>>>
>