Subject: draft-ietf-cat-rfc2078bis-03 enroute, and to WG Last-Call

From: "Linn, John" <[email-masked]>
Date: Thu, 19 Feb 1998 11:11:07 -0500

CAT/2078bis fanciers:

Along with this message, I'm sending another version of the GSS-V2 draft
to the secretariat, to become draft-ietf-cat-rfc2078bis-03, to place the
result into CAT-WG Last-Call to extend until Friday, 13 March.  Please
review and comment as needed on this version's suitability and
sufficiency to be recommended from the WG as a successor Proposed
Standard to RFC-2078. (Note: addition of a "changes from 2078bis"
section, and/or integration of the post-2078bis change summaries into
the existing "changes from GSS-V1" section, is still needed; I'll
consider this as a follow-on editorial step)

Changes made for 2078bis-03:

Added text to section 1.2.3 about use of DUPLICATE_TOKEN status to
indicate reflected per-message tokens.  

For per-message calls, changed descriptions of NO_CONTEXT returns to
refer to "no context" instead of "no valid context". 

Added, within Sec. 2.2.1 on GSS_Init_sec_context(), commentary about
support for GSS_C_NO_NAME target name type being unlikely within
mechanism specifications predating GSS-V2, Update 1. 

Adjusted descriptions of status codes in sec. 1.2.3 to state that
GSS_S_COMPLETE indicates a fully validated token only if sequencing
errors are not concurrently indicated.  Also in 1.2.3, regarding
determination of service availability, changed reference from input
mech_type parameter to "selected mechanism", to more clearly admit
determination as a result of mechanism negotiation. 

Added, to Sec. 1.2.4 on QOPs, interoperability conditions statement for
mechanisms which permit optional QOP support.  

Added, to Sec. 1.2.8 on implementation robustness, statements
constraining impact of GSS_GetMIC() or GSS_Wrap() failures on context
state information.  Also, generalized existing text about behavior
following processing of a token which wasn't valid for the context
against which it was presented to also include tokens which (though they
might have been applied against the right context) generated fatal
errors in processing. 

Reworded, in sections on GSS_Acquire_cred() and GSS_Add_cred(),
sentences from previous draft discussing time-varying resolution of
default references in order to avoid ambiguity. 

Added, to section 4.1, text about contents of service name element in
host-based service name and a proposed approach for IANA registration
policy. 

--jl

John Linn ([email-masked])
RSA Laboratories East, Bedford, MA, USA