Re: Kitten and Kerberos WG Merger - New Charter

Jeffrey Hutzelman <[email protected]> writes:

>> > PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility)
>> > Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries)
>> > Initial and Pass Through Authentication in Kerberos 5
>> > (draft-ietf-krb-wg-iakerb)
>> > Unencrypted Portion of Ticket Extensions
>> > (draft-ietf-krb-wg-ticket-extensions)
>> 
>> No objection.
>
> ... but will you work on any of these items?  Review them?

No, I was merely stating my thoughts on all items in the list.  "Good
idea" didn't fit, and "Bad idea" was a too strong choice for me: I just
don't care about those drafts.  I currently don't plan to spend any
cycles on them.

>> > Define interfaces for better error message reporting.
>> 
>> I'd rather not spend time on that.  Do we have a problem statement to
>> argue why this is important?
>
> The GSS-API's error reporting interfaces are somewhat clunky, to say the
> least.  It is certainly possible to get a complete set of error
> messages, but since there is no connection to a particular context, it
> is unnecessarily complex for the implementation to report contextualized
> errors, especially when multiple threads and/or mechanisms are involved.
> Additionally, there is no mechanism for localization of error message
> text.

All of GSS-API is clunky, to say the least.  I'm not convinced this
particular clunkyness is that important, but like Alexey said, if
someone describe a better error reporting interface, I could change
opinion.  It has to be so much better that it covers the migration
pains, which is a challenge.

/Simon
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg