Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07

[Nico Williams <[e-mail]>]

On Thu, Nov 8, 2012 at 9:36 AM, Leif Johansson <[e-mail]> wrote:
>> The short answer to this is: if we know what the exact guidance is, we
>> wouldn't need to use the Expert Review. So this is by design.
>
> I object to that answer.

Hmm, well, we could certainly spend some time on providing GSS API
design perls of wisdom.

But then, if we proceed with the channel bound thing and async I/O...
well, we'll  be rototilling the whole thing.  That will be great
because the API will get easier to use, but it may also change some of
those perls of wisdom.

> Expert review should absolutely have guidance. I'm fine saying "use your
> good
> judgement" or not even having a guidance section and relying on implicit
> good sense.

"Take API design 101, and preferably 201 too".

> However, the current text claims to provide guidance to reviewers but
> probably
> won't help anyone who doesn't already understand what to do.
>
> I say skip it, but if ppl are really married to it I'm fine with that
> too :-)

I'll provide a handful of perls now:

 - *always* include an OM_uint32 *minor_status argument in the C
bindings of any new GSS functions

 - always specify all major status codes a new function may return,
and if it may return as-yet-undefined errors, then say so (or maybe
that should always be allowed for new functions?)

 - if you add any new opaque types always add a GSS_Duplicate_<type>() function

 - wherever possible use the naming attributes API for extensions

You already have to follow the naming conventions (GSS_S_.*, GSS_C_.*,
...), so no need to go there.

I could add more.  Someone else take a turn first.

Nico
--