Subject: Re: tcp-expansion issues

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Oct 2006 10:04:58 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> On Friday, September 29, 2006 04:37:45 PM -0400 Sam Hartman
> <[email-masked]> wrote:
>
>>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>>
>>
>>     Jeffrey> Right; I seem to recall the discussion about using a
>>     Jeffrey> bitmask rather than numbered extensions, and agreement
>>     Jeffrey> that supporting a very large number of extensions would
>>     Jeffrey> not be required.  My (1c) was intended to be taken in the
>>     Jeffrey> context of larger changes that I thought would be
>>     Jeffrey> necessary to resolve the problems described in (1a) and
>>     Jeffrey> (2); in that context, I expected (1c) to make things
>>     Jeffrey> somewhat simpler.  Without the larger changes, (1c)
>>     Jeffrey> clearly adds complexity rather than removing it.
>>
>>
>> I didn't follow that discussion , so feel free to ignore these
>> comments.
>>
>> I agree that there is not a lot of need for a huge number of
>> extensions.  I am however concerned that we're adding a lot of
>> complexity to deal with multiple extensions at the same time and I
>> wonder whether that is beneficial.
>
> I don't think we are.  We agreed to essentially treat a combination of
> extensions as a distinct extension with distinct semantics that must
> be specified (presumably by one or more of the specifications for the
> extensions involved) in order to be valid.  In fact, you can
> effectively treat the extension bitmask as an extension number, with
> only one extension in use at a time -- if you don't understand the
> value you see, then treat it as unsupported.  It's only necessary to
> treat it as a bitmask for the purpose of indicating what extensions
> the KDC supports.

I think the complexity in this part is small.

More importantly, I think this is a complexity in the specification(s)
and not in implementations.  The extension specifications need to
discuss how extensions interact, and handle the complexity.  The
framework handle unsupported multi-bit extensions the same way as
unsupported single-bit extensions.

The implementation complexity will thus mostly be in the
extension-specific part of any implementation, instead of in the
implementation of the general framework.

However, I wouldn't object to drop multi-bit extensions.  It felt like
a useful thing when it was added.  I would agree that sometimes adding
"useful things" end up being a bad idea, and maybe this is one such
situation, although it feels pretty non-critical to me.

/Simon