RE: Document editors

Given that GSS-API discussion (at least as I've seen) has been largely quiet
for several years, I've been interested, pleased, and somewhat surprised to
see the recent level of interest emerge in evaluating refinements and
extensions.  I'm glad to see this confirmation that the CAT-WG documents
have been, and continue to be, useful bases to provide implementation
experience and to support a range of activities.  I haven't been closely
involved in GSS-related activities in recent years, and am not now in a
position to offer close, ongoing engagement or to undertake document
editorship on an RFC-2743bis if such proves to be needed.  I'd like,
however, to strongly endorse and amplify on one of the points Douglas makes
below: if GSS-API evolution is to take place, it should occur within a
constituency where multiple mechanisms are sufficiently and actively
represented.  I think this represents a central criterion that should be
evaluated if and as the process of chartering a new WG proceeds. 

--jl

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Douglas E.
Engert
Sent: Thursday, March 11, 2004 4:51 PM
To: Sam Hartman
Cc: [email protected]
Subject: Re: Document editors




Sam Hartman wrote:
> 
> Are there any parties who would be willing to edit the base spec and C
> bindings if we do manage to have a WG?
> 
> If we don't have document editors, a lot of the proposed work is not
> possible.

As Nico points out we should have the BOF first, and we need to invite
people who we feel should be interested even if they are not
interested today.  

I thing it would be important to have the WG members and editors who 
have dealt with multiple GSSAPI implementations. The extensions 
need to address the needs of more then just Kerberos.

We need to strive to provide the generic hooks so calls to mech specific
routines can be made via the GSSAPI and not be calling the underlying 
mechanisms routines directly. I believe that this is one of the traps a 
mechanism developer can fall into as they only have to deal with their
own mechanism, and this has lead to applications being tied to
specific mechs or even specific implementations of a mech. 
  

> 
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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]

-- 

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]