Subject: RE: Draft minutes, Adelaide CAT session

From: "Linn, John" <[email-masked]>
Date: Fri, 7 Apr 2000 09:52:14 -0400

Martin writes, excerpting:

> I must admit that we in the CAT WG have not really played by the IETF
> rules regarding the "timely fashion" and "focus" when discussing and
> finalizing most of our documents.  Therefore I can fully 
> understand Jeff's
> position procedurally (wearing his IESG hat).  On the other 
> hand I would
> really miss a single forum with the full scope that CAT had de-facto
> gathered over the last couple of years (that I remember).
> 
> Could we retain this forum with its broad scope as it has been, even
> if we don't carry-on a formal active IETF WG status -- but 
> still remain
> an IETF(-related) activity?  I think it would be ok to spin off actual
> IETF WGs with a clear focus every once in a while when a specific need
> has gained enough momentum and interested parties to get some work
> done in short time -- while reporting WG status and results back to
> the CAT forum in a similar fashion as its currently done with 
> rfc1510bis
> progress.  What worries me: if CAT is no longer a working group,
> the "push" of 3 IETF meetings per year for the progress reports on all
> the individual issues within the current CAT scope may disappear,
> and the forum itself may loose significant value.  While I was going
> to IETF meetings, there was a SAAG slot every time.  And the scope
> of SAAG was even broader than CAT, it was about all of the security
> area in the IETF.  And I really liked the overall wrap-up.  SAAG
> is not an IETF WG, therefore no charter and no timelines either,
> and I still consider it a useful forum within the IETF.

The CAT-WG mailing list will continue, as an appropriate channel for
discussing status and activities related to CAT-produced documents,
excepting the Kerberos work which will proceed in its own new WG.  IETF WG
meeting slots are a limited resource, and need to be applied most
effectively to the tasks of standards generation, where issues on actively
evolving specifications need to be resolved.  In CAT, most of the documents
with current activity and consensus for standards-track advancement are
already Proposed Standards or have been approved for Proposed Standard
publication.  For IETF purposes, CAT's ongoing primary role will be to
support their ongoing advancement as schedules and circumstances permit.  As
such, I believe we've reached a right point for the group to transition to
e-mail operation. 

> 
> Security is complex and takes more time that a simple 
> "feature-du-jour"
> protocol extension in the applications area.  And over the 
> past few years
> I've learned that defining an API and _getting_it_right_ is a 
> difficult
> task; and for a security-related API it is extremely difficult.
> In the past I've built application support for arbitrary gss-api
> mechanisms, and I was really impressed about the quality of the
> abstraction of the API in most areas.  Three years ago I basically
> finalized the GSS-API support within our "portable" application,
> based on the experience with two particular gssapi mechanism,
> Kerberos 5 and a public key based mechanism similar to SPKM.
> In the meantime 5 more gssapi mechanism are being used with our
> application, and I didn't touch my code at all.  And I might add
> that I am using EXACTLY the same code on all of our supported
> platforms: Win32, OS/2, AppleMac, 6 different Unix, AS/400, OS/390.

Thanks for this excellent report.  If your code corresponds to RFCs
2743/2744 (vs. 2078/1509), this could be material input to the cause of
advancing these documents to Draft Standards once the time is right. 
 
--jl
 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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-masked]