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

From: Mike Kupfer <[email-masked]>
Date: Mon, 17 Oct 2016 15:37:49 -0700

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

---

From: David Noveck <[email-masked]>
Date: Tue, 18 Oct 2016 06:54:33 -0400

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:
>

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.

> 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 <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 18 Oct 2016 11:01:54 -0700

On 18-Oct-16 3:54, David Noveck wrote:

>> Section 4.4.2
[...]
> unclear.  I propose adding the following new final paragraph to section
[...]

Looks good.

>> * Section 4.4.3
[...]
> I intend to add the following:
[...]
That's fine, too.

> I intend to replace the last sentence of the penultimate paragraph of
> the section by:
>
>     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.

Editing nits:
- A comma before "since" might make it a little easier to read.
- "section 9" should be capitalized.

Otherwise looks good.

>    > 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.

Editing nit: "section 9.1" should be capitalized.

Otherwise looks good.

> The text in section 9.1 is TBD.

Okay.

thanks,
mike