The value zero is special for (byte)lifetime

Mention this in the server reply section, and change the comparison
text to be correct in the face of it.  While here, use RFC 2119
language for this normative specification.  This language (or some
very close to it) was proffered by Tom Keiser with objection from
Andrew Deason during their conference call with Mike Meffie and
Mark Vitale.
The token need not be an encrypted blob

We explicitly say so, but then go on to write lots of text that assumes
it is, e.g., "this new token contains the derived key", "the new token
is encrypted with the server's private key", etc..
Rather than changing all such occurrences, just make this assumption
clear when the token is first described.
Add internal cross-references

Instead of "see below", "as detailed earlier", etc..
Mostly suggested by Tom Keiser's notes from his conference call
with Andrew Deason, Mike Meffie, and Mark Vitale.
Use RXGK_Levels more appropriately

Use the enum name to refer to the different levels instead of
an informal description.
Mention that the implementation is presented in reverse order
from the declaration.
Also note a case where the security level is irrelevant.
Add a couple more references

Cite the RX spec for the challenge/response negotiation, as requested
by Dave Botsch.
Add RFC 2744 for gss_get_mic() (as distinct from the RFC 3961 get_mic
used elsewhere in the document), as requested by Steven Jenkins.
Catch up to ticket->token rename

Missed in the key usage value RXGK_SERVER_ENC_TICKET.
That key usage was not referenced in the document, so add a reference
when we mention the possibility to generate the token as an encrypted
blob.
Add a bit more about 'clear' vs. 'integrity'

The descriptions for the two levels are very similar, and some extra
clarification could be useful, as noted in Tom Kaiser's notes
from his conference call with Andrew Deason, Mike Meffie, and Mark Vitale.
The suggested text is tweaked slightly, and this commit adds such content
in two places, which may be overkill.
RXGK_StartParams is not made of lists

Only two of the five elements of this structure are lists that should
be ordered by preference.  Reword slightly to say that the whole
structure represents the client's preferences, and that the two list
values are the supported values, ranked best to worst.  Use RFC 2119
language because this formatting is normative.

This was mentioned in Tom Keiser's notes from his conference call with
Andrew Deason, Mike Meffie, and Mark Vitale.
An empty token is zero-length, not NULL

Since it is encoded as an XDR array.
From Tom Keiser's notes on his conference call with Andrew Deason,
Mike Meffie, and Mark Vitale.
Describe the GSSNegotiate errorcode field

Rather than standardize errors, make them application-specific.
Give examples of possible policy errors for some applications.

This issue was mentioned in the conference-call notes from Tom Keiser
with Andrew Deason, Mike Meffie, and Mark Vitale, but there was not
a resolution to the question.  Proposed text is mine.
Other options include to allocate a registry in some other document
(such as wilkinson-afs3-rxgk-afs, which is not inconsistent with
the error codes being application-specific).
Clarify token expiry

We say that the server response from GSSNegotiate() contains an
expiration time, but not any indication as to how the server should
select this time.  Suggest that the underlying GSSAPI credential may
be a source for this time, but allow other options.
Remind that gss_pseudo_random is deterministic

So the client and server produce the same key.
Suggested in Tom Kaiser's notes from his conference call with
Andrew Deason, Mike Meffie, and Mark Vitale.

While here, document the gssapi_context parameter that is not referenced
elsewhere in the document.
Clarify CombineTokens' least-permissiveness

We talk about "numerical fields"; list them for clarity.
Also mention again that 0 is special for lifetimes and so the
"minimum of the values" may not be quite the right operation if the
value zero is involved.
Also note that application-specific data in the token should be
combined with a least-permissive combination.

These issues were noted in Tom Keiser's notes from his conference
call with Andrew Deason, Mike Meffie, and Mark Vitale.
Wordsmith

Why say "a number" when there are just two?