Subject: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3-10

From: David Noveck <[email-masked]>
Date: Tue, 23 Dec 2014 11:10:48 -0500

This message is to provide my WGLC review of this document.  Overall, this
document is in good shape.  I have a bunch of almost purely editorial
issues/corrections which you may find helpful (or annoying) and which are
listed below.

In the second sentence of the abstract, I suggest adding "support"  after
"provides"

Section 1, "Introduction and Motivation" is well -written but I would
suggest that two pages is too long for a section like this.  My suggestion
for dealing with this is to rename section 1 as something like
"Preliminaries" and break it into three subsections as follows::

   - An "Introduction" section consisting of the first seven paragraphs.
   - An "Added Functionality" section from there to the paragraph beginning
   "this document".
   - A"XDR Code Extraction" section with the rest.

In the second paragraph, suggest:

   - Replacing "We find that" by "Existing".
   - Ending the second sentence after "shortcoming".
   - Beginning a new third sentence with "However, here it is addressed at"
   - Replace "namely" and the material which follows it by, "i,e. in
   RPCSEC_GSS.

The first bulleted item has a very long line which causes annoyance when
you print the pdf.  In my case, since I print documents 4-up, the result of
this was to cause Adobe reader to decide it should print page 3 in the same
font it would use for 16-up printing, i.e, unreadable.

In the paragraph beginning "We add" suggest dropping the "We add " and
adding "is provided" at the end of the sentence.

Suggest replacing the first paragraph of section 2 by the following two
paragraphs

RPCSEC_GSSv3 is very similar to RPCSEC_GSSv2.  The differences are the
addition of support for

assertions and the fact that channel bindings are supported via a different
mechanism.

The entire RPCSEC_GSSV3 protocol is not presented here.  Only the
differences

between it and RPCSEC_GSSV2 are shown.

Suggest replacing the (old) second paragraph of this section by:

The use of RPCSEC_GSSV3  is structured as follows:

Section 2.1 has my only comment which is not purely editorial.

The issue is that RPCSEC_GSS_BIND_CHANNEL is not "deprecated".  It may be
eliminated,

unsupported, mandatory not to use, or replaced by something else, but if
you want it to be

"deprecated", you have to deprecate it, and that isn't done.

In Section 2.2, I suggest replacing the initial sentence fragment ending in
"following:" and the following "The" by the following
including a new initial sentence.

A new reply verifier is needed for RPCSEC_GSSv3 because of a situation that
arise from the use of the same

GSS context by child and parent handles.  Because the

In the second paragraph, replace everything up to the second instance of
"the verifier" by the following:

This issue is addressed in RPCSEC_GSS version 3 by computing the verifier.

For section 2.4, suggest "XDR Code Preliminaries" as a more appropriate
section title.

Regarding the title of section 2.5, see above,

In the second sentence of section 2.6, suggest deleting "each of".

It wold be nice if section 2.7.1 were modified so that a new page were not
started immediately after the "<CODE BEGINS>".

In section 2.7.1.2, indented item (b), suggest replacing "the community now
agrees" by "there is now general agreement"

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 23 Dec 2014 21:36:56 +0000

Hi Dave

Thanks for the review. I pushed the changes.

—>Andy

> On Dec 23, 2014, at 11:10 AM, David Noveck <[email-masked]> wrote:
> 
> This message is to provide my WGLC review of this document.  Overall, this document is in good shape.  I have a bunch of almost purely editorial issues/corrections which you may find helpful (or annoying) and which are listed below.
> 
> In the second sentence of the abstract, I suggest adding "support"  after "provides"
> 
> Section 1, "Introduction and Motivation" is well -written but I would suggest that two pages is too long for a section like this.  My suggestion for dealing with this is to rename section 1 as something like "Preliminaries" and break it into three subsections as follows::
> 	• An "Introduction" section consisting of the first seven paragraphs.
> 	• An "Added Functionality" section from there to the paragraph beginning "this document".
> 	• A"XDR Code Extraction" section with the rest.
> 	• Replacing "We find that" by "Existing".
> 	• Ending the second sentence after "shortcoming".
> 	• Beginning a new third sentence with "However, here it is addressed at"
> 	• Replace "namely" and the material which follows it by, "i,e. in RPCSEC_GSS.
> The first bulleted item has a very long line which causes annoyance when you print the pdf.  In my case, since I print documents 4-up, the result of this was to cause Adobe reader to decide it should print page 3 in the same font it would use for 16-up printing, i.e, unreadable.
> 
> In the paragraph beginning "We add" suggest dropping the "We add " and adding "is provided" at the end of the sentence.
> 
> Suggest replacing the first paragraph of section 2 by the following two paragraphs
> 
> RPCSEC_GSSv3 is very similar to RPCSEC_GSSv2.  The differences are the addition of support for
> assertions and the fact that channel bindings are supported via a different mechanism.
> 
> The entire RPCSEC_GSSV3 protocol is not presented here.  Only the differences
> The issue is that RPCSEC_GSS_BIND_CHANNEL is not "deprecated".  It may be eliminated,
> unsupported, mandatory not to use, or replaced by something else, but if you want it to be
> In Section 2.2, I suggest replacing the initial sentence fragment ending in "following:" and the following "The" by the following
> A new reply verifier is needed for RPCSEC_GSSv3 because of a situation that arise from the use of the same
> In the second paragraph, replace everything up to the second instance of "the verifier" by the following:
> 
> For section 2.4, suggest "XDR Code Preliminaries" as a more appropriate section title.
> 
> It wold be nice if section 2.7.1 were modified so that a new page were not started immediately after the "<CODE BEGINS>".
> 
> In section 2.7.1.2, indented item (b), suggest replacing "the community now agrees" by "there is now general agreement"
> 
> 
> 
> 
> 
>