Re: [sasl] Kitten Recharter

[Jeffrey Hutzelman <[e-mail]>]

--On Thursday, June 17, 2010 06:44:08 PM -0600 Shawn Emery 
<[e-mail]> wrote:

> On 06/11/10 11:40 AM, Alexey Melnikov wrote:
>> Shawn Emery wrote:
>>
>>> Per the recent thead on "MOGGIES Proposed Charter"; I have taken
>>> suggestions by kitten/SASL WG members and created recharter text for
>>> Kitten (whilst closing SASL).  Please let me know if I missed anything.
>>>
>>> Shawn.
>>> Kitten co-chair.
>>
>> Hi Sean,
>> Thanks for the updated version. This looks much better.
>
> Thanks.
>
>> Some additional comments inline.
>>
>>> Kitten (Common Authentication Technology Next Generation)
>>>
>>> <snip>
>>>
>>> * Provide a more programmer friendly interface for application
>>> developers.
>>>
>>>
>> This point is a bit vague. Do we actually need this as an explicit goal?
>
> Do you want more details on how this will be accomplished?  For example:
>
> * Provide a more programmer friendly GSS-API for application developers.
> This could include reducing the number of interface parameters,
> eliminating those whose values' are commonly used.
>
> <snip>
>>> This WG should review proposals for new SASL and GSS-API mechanisms.
>>> The WG
>>> should also review non-mechanism proposals related to SASL and the
>>> GSS-API.
>>>
>> I think this is a bit too open-ended for IESG. I would have asked
>> about that if I were asked to review such charter ;-).
>>
>> To be frank, I would delete these 2 sentences, or say the exactly
>> opposite: other proposals would require rechartering. However chairs
>> always have some flexibility in allowing conversations on related
>> topics, as long as this doesn't compromise progress on major
>> deliverables.
>
> I've read the follow-up thread between you and Hutzelman, and concluded
> that the following clarification should be made:
>
> This WG should review proposals for new SASL and GSS-API mechanisms.  The
> WG should also review non-mechanism proposals related to SASL and the
> GSS-API.  However, work that adds SASL or GSS-API support in application
> protocols should be handled by the application's WG.

To the first sentence, add "but may take on work on such mechanisms only 
through a revision of this charter".  Then I think you'll have captured the 
gist of the discussion.

-- Jeff