RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-06

Boilerplate: This is an IESG comment and should be treated in a similar
fashion to an IETF last call comment from any IETF participant.  This
comment does not prevent advancement of your document through the IETF
process.  However, it may contain suggestions to improve the document,
and it is polite to consider those suggestions.

I support Pasi's Discuss.

Section 3.3, second bullet:

I suggest you also reference the IANA registry "Hash Function Textual Names" to help find new hash functions as they're defined.

General Concern:

A test vector or two would greatly improve this document.  While
I have an adequate understanding of XDR, hash functions, channel
bindings, ASN.1 and Kerberos, I'm skeptical that I would correctly
implement this protocol on the first try.  There are a lot of
important details in prose (such as hashing the channel bindings)
that leave room for implementation errors.  Protocols like this can
gain a bad reputation from implementation errors unless there is a
reference implementation or test vector that implementers can use
for validation to catch errors before they're released in the wild.

The acrnym GSS is never expanded in the document. I suggest to expand it at the first occurence in the Abstract or Introduction section.

Review by Chris Vogt:

This document describes updates to the RPCSEC_GSS protocol that enable
channel binding between the RPCSEC_GSS protocol and secure channels at
lower layers.

The document assumes that the reader is very familiar with
implementation-specific details of the RPCSEC_GSS protocol.  The
document is not understandable to a reader without such detailed
knowledge.  The reason is that the document specifies protocol updates
mostly in terms of pseudo-code fragments.  The pseudo-code fragments
may make sense to an RPCSEC_GSS protocol implementor, but they bear
little information to a reader unfamiliar with the RPCSEC_GSS
protocol's implementation specifics.

Making the document plausible for the average reader would require
major rewriting of this document.  To avoid such rewriting but still
ensure that the document is unambiguous for implementation purposes, I
suggest to have the document reviewed by implementers who have worked
with the RPCSEC_GSS protocol.  Based on such a review, an informed
decision could be made on whether or not to publish this document in
its current form.

There are no reference to XDR in the first occurrence in section 1.

I support Pasi's discuss.  I have no other objections to the document.