Re: Document editors

>>>>> "Martin" == Martin Rex <[email protected]> writes:

    Martin> 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?

    Martin> Huh?

    Martin> You meant to be asking for a document editor for the
    Martin> extension document(s) ggf, nick's credentials stuff,
    Martin> nick's channel-bindings stuff and your BCP, right?
The BCP for mechanism implementations does require an editor.  Nico's
documents also require an editor, but he has volunteered to do that.

I don't think the GGF proposals have advanced to a stage where we know
what documents are required or whether the IETF can agree to any
particular way of solving those problems.  So while editors will be
needed for those tasks, I do not think we are yet ready to start
working on drafts.


    Martin> "base spec" and "C bindings" sound too much like
    Martin> rfc-2743/2744, but those specs are in perfectly good
    Martin> shape, don't need any fixing and certainly don't need any
    Martin> editing to accomodate any of the extensions above or the
    Martin> BCP document.
I was in fact talking about editors for documents to replace RFC 2743
and RFC 2744.

I do believe those documents have significant clarity problems and do
need to be revised.

Here are some issues I can think of that demonstrate the point:

1) I seem to recall you wanting to depricate or at least add text
   advising against the use of GSS_NT_SRV_HST.  I disagree with this
   proposal, but it has not yet been discussed.


2) Discussion of prot_ready in the Kerberos working group indicated
   significant lack of clarity on what the spec meant.  We ended up
   concluding, and I believe that you agreed with our conclusion, that
   a mechanism may be able to produce prot_ready tokens even if it
   cannot yet consume them.  The spec is not particularly clear on this point.

3) As I mentioned, the discussion of channel bindings is unclear and
    the way it is presented has been problematic for standards track
    documents including draft-ietf-krb-wg-gssapi-cfx and
    draft-ietf-nfsv4-gssapi-ccm.


4)  As mentioned previously, I want to revisit GSSAPI naming.

5)  The documents should be updated to conform to current standards for RFCs.  They should use the new IP notices (very recent), split normative references, that sort of thing.

It does seem reasonable to have at least an initial (and more
complete) list of clarity problems before the BOF.  But my current
assumption is that we will need to rev both of the core documents.  If
we cannot convince the IETF that this assumption is justified then
such revisions should be out of scope for a charter.

--Sam

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