Martin, I realize you had a critical role in designing GSSAPI. I
realize that you've been frustrated by many discussions over the past
few years .
I also realize that you have a unique prospective on a class of
application that uses GSSAPI but has not been represented well within
the IETF community. If the KITTEN BOF and working group are to be
successful then your viewpoint needs to be understood within the IETF.
But dealing with you over the past few years since you stopped
attending IETF has been very frustrating and I begin to question
whether it is worth the effort. It sounds like you view yourself as
the only remaining GSSAPI designer still following the mailing
lists--the poor sucker charged with educating us on how GSSAPI works
and how it is to be used.
The fact is that a lot of us did follow CAT. We were not involved in
the beginning and were not particularly outspoken while you were
attending IETF, but we were following the discussions.
Moreover, while you have been dealing with your class of application
outside the IETF, GSSAPI has continued to be used within the IETF.
We've gained application experience with SASL (and thus a lot of the
application area protocols), with NFSV4 and with Kerberos. There is
an active GSSAPI community withing the IETF and it mostly consists of
people you don't know very well.
Right now, we can do one of two things. We can find some way to
actually communicate with each other. That probably means that you
need to stop asserting that you are right, understand why we are
saying the things we are saying, and then if you still think we are
wrong clearly explain why and how we can solve the problem we're
trying to solve. It would probably be critical for you to either
start attending IETF or to talk with the people involved so that we
have shared context. You seem to misse a lot of GSSAPI-related
thought, like discussion of CCM in the NFSV4 working group, the
channel bindings presentation at the IETF 58 SAAG meeting, etc. You
also probably miss discussions of GSSAPI in the SASL community.
The other option is that we can continue to fail to communicate. I'll
eventually get to a point where I start ignoring you; I suspect others
will follow. You'll probably end up objecting to every last call, but
you'll be one person and the rough consensus will go on without you.
The output of the IETF will end up meeting the IETF's needs, but will
not be particularly suitable for the class of non-IETF applications
you are working with. We'll also probably be more likely to make
mistakes because we will be to a significant extent missing the input
of a valuable contributor--an extra pair of eyes looking for problems
always helps.
I do hope that you are interested in developing communication and
mutual understanding.
--Sam
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [EMAIL PROTECTED]
