[Gen-art] Minor nits in minorversion2-40

[Elwyn Davies <[e-mail]>]

Hi.

As suggested I downloaded your repository and made -40.

I had a quick look through and it is looking good.

Still to do/think about:
- 'we' removal
- structured privilege description expansion as per email.
- [BL73] - not reffed anymore.

I spotted a few items that appeared (or I had missed) - noted below.

Cheers,
Elwyn

Minor nits:
s4.2, para 2: s/intra-sever/intra-server/

s4.2.2, para 1: This sentence is a bit garbled:
> Other operations are OPTIONAL in the context of a particular feature 
> Section 13, but may become REQUIRED depending on server behavior.

s4.9, last para:
I was supposed to be letting you know if some extra explanation of why 
seqid being zero is ambiguous.... so, yes, I do think a bit extra is 
needed. Here goes:

s15.8.3 notes that there can be multiple file copies associated with a 
single file going on at the same time.  This is only implicit up to that 
point I think.  It would be helpful to add a note about this possibility 
and the availability of asynchronous copy in general to the intro of 
section 4.

BTW: removing the s4.1 header would be in keeping with usual style as 
you have already done for other sections.

BTW2:  I just realized that there is no general terminology section in 
this document.  Clearly most of it is taken over from either or both of 
RFC 7530 (s1.5) and RFC 5661 (s1.6).  What triggered this was the point 
that stateid isn't actually defined in this doc.  A reference to one or 
both of these and/or possibly some copies of definitions would be helpful.

In the following I may not have exactly grokked what the copy offload 
stateid represents... if so please adjust the words

Add to intro (was in s4.1, s/b in s4) as new last para:
ADD:
The copy feature allows the server to perform the copying either 
synchronously or asynchronously.  The client can request synchronous 
copying but the server may not be able to honor this request.  If the 
server intends to perform asynchronous copying, it supplies the client 
with a request identifier that  the client can use to monitor the 
progress of the copying and, if appropriate, cancel a request in 
progress.   The request identifier is a stateid representing the 
internal locks held by the server while the copying is performed. 
Multiple asynchronous copies of all or part of a file may be in progress 
in parallel on a server; the stateid request identifier allows 
monitoring and canceling to be applied to the correct request.
END

Then modify the last para of s4.9:
OLD:
    A copy offload stateid's seqid MUST NOT be zero.  In the context of a
    copy offload operation, it is ambiguous to indicate the most recent
    copy offload operation using a stateid with seqid of zero. Therefore
    a copy offload stateid with seqid of zero MUST be considered invalid.
NEW:
    A copy offload stateid's seqid MUST NOT be zero.  In the context of a
    copy offload operation, it is inappropriate to indicate "the most recent
    copy offload operation" using a stateid with seqid of zero (see 
Section 8.2.2
    of [RFC5661] for the meaning of a seqid of zero).  It is inappropriate
    because the stateid refers to internal state in the server and there 
may
    be several asynchronous copy operations being performed in parallel
    on the same file by the server.  Therefore
    a copy offload stateid with seqid of zero MUST be considered invalid.
END

s4.10, last para:
OLD:
    If a server requires the use of RPCSEC_GSSv3 copy_to_auth,
    copy_from_auth, or copy_confirm_auth and it is not used, the server
    will reject the request with NFS4ERR_PARTNER_NO_AUTH.

NEW:
    If a server requires the use of an RPCSEC_GSSv3 copy_to_auth,
    copy_from_auth, or copy_confirm_auth privilege and it is not used, 
the server
    will reject the request with NFS4ERR_PARTNER_NO_AUTH.

s4.10.1.1.1:  I understood you were going to say something about size 
and non-reuse of the random number?

s4.10.1.1.3, bullet 6: s/the COPY will be rejeced/the COPY will be rejected/

s8:  Did you think about 64bit big-endian/little-endian issues?

s9.2, last para: Need to expand LFS on first use. (missed in -39)

s10.5.6, para 2: (Not a change - I missed this in -39)
> Any file's layout obtained from a NFSv4.1 metadata server MUST NOT 
> have NFL42_UFLG_IO_ADVISE_THRU_MDS set.
I don't understand this statement.  If the layout is originated by an 
NFSv4.1 server, then I would interpret having this bit set as a server bug.

s12.1: One of the ADs complained about the weasel words in the Id column 
definition... the slightly less weaselly words from s5.6 of RFC7530 
should cure this.

s19.2:  Need to sort out [BL73].