Re: [nfsv4] feedback on draft-ietf-nfsv4-versioning-06

[David Noveck <[e-mail]>]

Thanks.

> Section 4.4.2: I'd like this section to re-emphasize that the
> requester should try early on to establish knowledge about what
> the other node supports.  Perhaps add this text to the last
> paragraph in the section:
>
>    This should normally be done as part of a negotiation phase, prior
>    to acting on user requests.

Given the way this paragraph is written, the referent of "this" would be
unclear.  I propose adding the following new final paragraph to section
4.4.2:

It is best if client implementations make the determination as to the
support provided by the server before acting on user requests.  This
includes the determination of the common protocol variant and the level of
support for OPTIONAL protocol elements.

> * Section 4.4.3: I'd like to see more text related to the handling
> of multiple bits in the same request.

I intend to add the following:

Note that in the case of attribute or flag bits, use of a request that refers
to 2 or more bits of undetermined status (known versus unknown) may return
results which are not particularly helpful.  In such cases, when the
response is NFS4ERR_INVAL, the requester can only conclude that at least
one of  the bits is unknown.

> * Section 9.1, corrections to required features: the approach here
> makes sense, but it seems to conflict with wording elsewhere in the
> spec,

Good point :-(

> 1. end of page 5, top of page 6:

I intend to replace the last sentence of the penultimate paragraph of the
section by:

For example, one may refer to the set of REQUIRED features in a given minor
version that has not had a protocol correction since it is the same for all
variants within the minor version.  See section 9 for a discussion of
correcting an existing minor version.

  > 2. page 10:

What I intend to do here is replace the lead-in paragraph for the bulleted
list by the following:

Which of these are validly returned by the responder depends on the status
of the protocol element in the minor version specified in the COMPOUND or
CB_COMPOUND.  The possibilities which can exist when dealing with  minor
versions that have not been corrected are listed below.  See section 9.1
for a discussion of the effects of protocol correction.

The text in section 9.1 is TBD.



On Mon, Oct 17, 2016 at 6:37 PM, Mike Kupfer <[e-mail]> wrote:

> I think we're converging, but there are still a couple issues I'd like
> to see addressed.
>
> * Section 4.4.2: I'd like this section to re-emphasize that the
>   requester should try early on to establish knowledge about what the
>   other node supports.  Perhaps add this text to the last paragraph in
>   the section:
>
>     This should normally be done as part of a negotiation phase, prior
>     to acting on user requests.
>
> * Section 4.4.3: I'd like to see more text related to the handling
>   of multiple bits in the same request.  Perhaps before the bullet list,
>   add something like
>
>     Note that in the case of attribute or flag bits, a request that
>     refers to 2 or more bits of undetermined status (known versus
>     unknown) may return ambiguous results.  If the response is
>     NFS4ERR_INVAL, the requester can only conclude that at least one of
>     the bits is unknown.
>
> * Section 9.1, corrections to required features: the approach here makes
>   sense, but it seems to conflict with wording elsewhere in the spec,
>   specifically
>
>   1. end of page 5, top of page 6:
>
>       For example, one may refer to the set of REQUIRED features in a
>       given minor version since it is the same for all variants within the
>       minor version.
>
>   2. page 10:
>
>       The protocol element is defined as a REQUIRED part of the base minor
>       version.  In this case, the requester can expect the protocol
>       element to be both known and supported by the responder.
>
>   Maybe ", barring protocol corrections, " should be added at appropriate
>   places in these two sections?
>
> regards,
> mike
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>