Mechanism extensions and the GSSAPI

Nicolas Williams Nicolas.Williams at
Mon May 3 17:35:57 EDT 2004

On Mon, May 03, 2004 at 05:10:57PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at> writes:
>     Nicolas> On Mon, May 03, 2004 at 04:29:11PM -0400, Sam Hartman
>     Nicolas> wrote:
>     >> ALso, it means you need to specify a stable, extensible
>     >> protocol between the shim and the mechanism.  That's
>     >> significant work that you avoid by making the ioctl
>     >> specification a mechanism implementation matter.
>     Nicolas> You're still missing the open SPI + pseudo-mechanism
>     Nicolas> aspect of this.  I think we'll have to specify the ioctl
>     Nicolas> part of interface.
> No, I'm failing to understand why that matters in practice.  Just
> because a feature is desirable does not mean it is worthwhile.  I've
> explained why specifying the ioctls has significant cost.  Since you
> haven't disagreed with that statement I'm assuming you understand it
> and agree.
> You now need to justify a benefit of the feature request of specifying
> the ioctls that justifies the cost.

Given your statement about your time constraints versus mine I think
this hardly matters now, plus the ioctl part can always be specified


More information about the krbdev mailing list