[AFS3-std] Finishing the core rxgk document

[Nico Williams]

On Fri, Oct 18, 2013 at 02:46:34PM -0400, Jeffrey Hutzelman wrote:
> On Thu, 2013-10-17 at 23:08 -0400, Benjamin Kaduk wrote:
> > > - Section 6.2, structure of loop.  I think this is a bit odd and
> > >   redundant.  The structure of the loop is quite standard; repeating it
> > >   is useful when the reader doesn't know anything about the GSS-API,
> > >   but otherwise it could be a source of bugs and confusion.
> 
> Unfortunately, while the structure of the loop _should_ be quite
> standard, there is no standards-track GSS-API document which describes

RFC2744 has sample C code.  What's wrong with it, besides being C and
depending on the API in RFC2744?

> it in sufficient detail.  Nico is correct that information about what
> the flags need to be (and other inputs and checks on the outputs) can be
> abstracted out -- the inputs (except the token) are the same for every
> call, and the outputs (except the status and output token) normally only
> need to be checked at the end.  However, the handling of the loop itself
> has a number of edge cases that I don't think are sufficiently
> well-documented in anything we can refer to.

Well, there may be subtle details, but they are all generic, and don't
really belong here.

Keep the text, rewrite it, or remove it.  I don't care -- it's only an
informational RFC.  KITTEN WG should publish a nice guide RFC sometime
though.  The problem is that the text as written may have subtle bugs.
For *me* it's much easier to assume all the generic GSS usage
information I know and apply only the bits that are specific to rxgk.
For others this might not be so.

If you'll keep text then I'll need to re-review.  I mostly punted when
the redundancy annyed me :(

> There's a reason we described the negotiation in this level of detail in
> RFC4462.

Other RFCs for app protocols using GSS also do this.  It's kind of
annoying...

> > >   For example, I think there's no need to discuss non-sensical GSS
> > >   results, like GSS_S_CONTINUE_NEEDED w/ no output sec context token.
> 
> I disagree.  An implementation has to do _something_ if the library does
> that, and "something" should be to fail, not to assume everything is OK.

There's no need to do that *here*.  That belongs in RFC2743 or similar.

> > doing here and that if an implementor knows how to do a GSS negotiation 
> > loop in general, they should be fine implementing rxgk.  The question (to 
> > me) is more of whether we want to assume that level of expertise on the 
> > reader
> 
> I don't think we should.  I'd be fine with referring to another document
> for this, if one existed.  I'd be fine with someone writing one!  But I
> don't think we should assume _anyone_ knows how to do this right without
> being told, no matter how familiar they are with GSS-API.

:)

> I agree this is really KITTEN's problem more than ours, but here we are.

Considering the purpose of this I-D, I think you can go more
light-weight.

Nico
--