Re: problem with RPCSEC_GSS specification

[John Linn <[e-mail]>]

CAT and ONCRPC-ers:

For the benefit of oncrpc-wg subscribers who don't read cat-ietf, the latter
list has recently been discussing a compilation of errata against rfc-2078,
clarifying/correcting rfc-2078 largely for purposes of alignment with 
subsequent work on the C bindings.  It seems reasonable to me to propose,
as an addition to that compilation, replicating the numeric values from
draft-ietf-cat-gssv2-cbind-04, Table 5-2 (Routine Errors), and Table 5-3
(Supplementary Status Bits) when the successor to rfc-2078 is next advanced.
In conjunction, some reworking would be required in rfc-2078 to make 
more explicit the separate treatment (as evolved in the C bindings) of 
supplementary major stati CONTINUE_NEEDED, DUPLICATE_TOKEN, OLD_TOKEN, 
UNSEQ_TOKEN, and GAP_TOKEN, which are represented in a separate element
within a structured status result and can, in some cases, be indicated in 
conjunction with a non-zero Routine Error.

--jl

> [e-mail] (Mike Eisler) writes:
> 
> >> 
> >> > Date: Tue, 6 May 1997 17:52:15 -0700
> >> > From: mre@jurassic (Mike Eisler)
> >> > To: oncrpc-wg@sunroof
> >> > Subject: problem with RPCSEC_GSS specification
> >> > 
> >> > ONC RPC'ers:
> >> > 
> >> > While debugging a problem, I noticed that RFC2078, the GSS-API
> >> > specification, does not define the numerical values for GSS-API major
> >> > status codes. (Please correct me if I'm wrong). The RPCSEC_GSS
> >> 			^^^^^^^^^^^^^^^^^^^^^^^
> >> 
> >> That took less than a half hour. :-) Roland Schemers points out that
> >> the C-bindings GSS-API spec (RFC1509 and
> >> draft-ietf-cat-gssv2-cbind-04.txt) have defined values. So instead, I
> >> propose just referencing draft-ietf-cat-gssv2-cbind-04.txt. 
> 
> The right answer is to define them in rfc2078.  Although these values
> never appear on the wire, rfc2078 defines numeric values for other
> arguments already.
> 
> 		Marc
>