Subject: Re: [nfsv4] high-level editorial comments, draft-ietf-nfsv4-versioning-03

From: David Noveck <[email-masked]>
Date: Wed, 1 Jun 2016 16:04:16 -0400

> but the remaining items are mostly lower-level editorial
> concerns that probably should wait until the overall document
> organization is settled.

Some of these have interactions with a potential re-organization
but others don't. I'd like to get the latter out of the way by addressing
them in -04, if I can.  Keeping things on a big to-do list  can result in
them being lost.

> * Can a minor version group contain non-contiguous minor versions?

>   The definition on page 9 allows for that, but I'm not sure that's what
>   people would intuitively expect.

Shouldn't be allowed.  Will address in -04.

>  Section 4.4.3 says
>
>    o  When a request is made including an operation with a new flag
>       bit, if the operation returns with the error NFS4ERR_INVAL, then
>       it can be concluded that the responder has no knowledge of the
>       flag bit in question.  Other responses indicate that the
>       responder is aware of the flag bit in question.
>
>  I have 2 concerns with this text.
>
>  First, use of INVAL here precludes using it to mean that the flag bit
>  is known but not valid for some reason.

Good catch, but I don't think that using INVAL here precludes other
reasons for returning INVAL.  I think part of addressing this is being
more careful about the language.

>  Second, what if the request has more than one new flag bit?  It might
>  not be appropriate for the client to retry the request in pieces.

I think the context here is that, in preparation for dealing with the
responder, the
requester is finding out which feature packages the responder knows about.
You seem
to be assuming that the client is going to defer that, and then just try a
mix of new
features and retry when it finds something unknown or unsupported.  I don't
think
people should be doing things that way and the spec needs to make that
clear.

>  I think NFS4ERR_BADXDR would be more appropriate than NFS4ERR_INVAL,
>  though it doesn't handle the multiple-bit concern.

It would be if XDR had bit support in the XDR language,  RIght now, flags
are constant
values in an integer, and XDR has no way to check that a specific bit is
valid in a
specific word.

My understanding is that current implementations report INVAL for invalid
flag bits
and that was my reason for adopting this approach. If anyone knows of
servers that do anything
else, please let me know.

>  The multiple-bit issue could be addressed by introducing a new
>  NFS4ERR_BADFLAGS error which includes a bitmask to identify the
>  unknown flag bits.  But that would require an XDR change.

I don't think it is necessary for this issue but I think that if we ever do
a  new
minor version, that sort of error cleanup should be part of it.  I think
adding
NFS4ERR_BADFLAGS and NFS4ERR_FLAGNOTSUPP would be nice.

>   Perhaps the answer is that the client should use some other extension
>  element to determine whether a given flag bit is known.

That probably is part of the way to address this.  It could be made more
explicit that the client only needs to test a single protocol elements and
is
free to pick one that is easy to test.  Also, that someone defining an
extension
is well-advised to make sure that there is it at least one protocol element
to
test to determine whether the feature package is known.

Will defer addressing most of this until structure decision is made.
Different
parts of this might be in different documents.  I will try to address the
specific
textual corrections regarding INVAL in -04 and propagate those changes to
draft-dnoveck-nfsv4-extension-00 if necessary.

>   Section 7.4 says
>
>    Extensibility of minor versions are governed by the following rules:
>    [...]
>    o No new feature may be added to a minor version once the
>       specification document for a subsequent minor version becomes a
>       working group standards-track document.

>   This is okay as a recommendation, but I think the working group should
>   be free to use its discretion about when it will stop accepting
>   extensions for a given minor version.

I agree with you but will not address this in -04 because this might
interact with the spec structuring issues that need to be decided.

Note that the working group's discretion to add things to an existing
minor version is limited by the IESG's discretion as to when/whether
to approve Proposed Standards for publication.

Thinking back regarding writing this, IIRC, at the time my focus was on
providing a set of version management "rules" to replace the existing
minor versioning rules.  In that context, I might well have turned
reasonable recommendations into rules without sufficient justification.

>  Section 8.3.2 says
>
>    o  Servers supporting a given minor version MUST support any earlier
>       minor version in the same minor version group
>
>  Why MUST?

I'm not sure that this is right but I will answer the "Why" question first.

First of all, a capitalized term is used since this is directed at
implementers, rather
than spec authors and that an RFC2119 term is appropriate since this
addresses
an interoperability issue

A possible counter-argument is that the interoperability questions about
which
RFC2119 was directed are within the scope of a single protocol and that
using them
in this cross-version way, although continuing previous practice, is not
valid.

The counter-counter-argument would be that if there are to be "rules"
regarding minor
versioning about minor versioning, and there have been for a while so far,
 they need
to address interoperability issues like this, or else there is no point in
having an extension model.

I used "MUST" attempting to continue the original intention, as I saw it.
The corresponding
rule in RFC 3530 is a "MUST" and it applies to all minor versions. In
RFC5661, it was
changed to  "SHOULD".   My interpretation was that the reason for the
weakening was
the size of the changes in 4.1.   It not only created a new version group,
but actually was so
large that it essentially created a new protocol.  In fact, when RFC7530
was being discussed, an
IESG member asked me why v4.1 was not named v5.0.

I thought the "SHOULD" in RFC5661 was not valid in that was being
interpreted as meaning
"MUST (but you can ignore it if you want to)" (as"SHOULD " tends to be a
fair amount).  I
thought that using "MUST" but limiting the scope to a minor version group
was consistent
with the original intention and avoided the problem of a "rule" with an
enormous loophole.

Going forward, the right answer here might be to use a "SHOULD" but be more
in line with RFC2119 by
explaining the likely interoperability consequences of choosing not to
follow the RECOMMENDATION.

I'm thinking of something like

> Servers supporting a given minor version SHOULD support any earlier minor
version in the same minor version group.

> If  a server does not do so it will be unable to interoperate with
 clients built to interoperate with servers supporting

> earlier minor versions, despite the fact that all features expected by
the client are still required of the server and
> the client is unaware of added OPTIONAL server added since then.
>
This is the kind of thing that belongs in a standard-track document, if
there is a split.  I will address this in -04
and will try to include the corresponding change in
draft-dnoveck-nfsv4-extension-00.
David Noveck wrote:

> The potential division into two documents is a result of some discussion
> during the conference call and my response to it.
[...]

Okay, thanks for clarifying what would go into each document if a split
does happen.

> Right now I'm planning to submit a draft-ietf-nfsv4-versioning-04 in the
> next three weeks addressing the specific issues. in 6.4 and 5.1.3 that you
> mentioned.  With regard to 4.1.1-2 and 5.1.2-3, I'd like to see more
> discussion of people's preferences regarding document structuring issues
> before proceeding to make changes.  If anyone has any other suggestions
> for needed changes in  draft-ietf-nfsv4-versioning-04, please let me know
> in the next few weeks.

Here are additional concerns and questions that I have.  It's far from a
complete list, but the remaining items are mostly lower-level editorial
concerns that probably should wait until the overall document
organization is settled.

* Can a minor version group contain non-contiguous minor versions?

  The definition on page 9 allows for that, but I'm not sure that's what
  people would intuitively expect.

* determining support for new flag bits

  Section 4.4.3 says

    o  When a request is made including an operation with a new flag
       bit, if the operation returns with the error NFS4ERR_INVAL, then
       it can be concluded that the responder has no knowledge of the
       flag bit in question.  Other responses indicate that the
       responder is aware of the flag bit in question.

  I have 2 concerns with this text.

  First, use of INVAL here precludes using it to mean that the flag bit
  is known but not valid for some reason.

  Second, what if the request has more than one new flag bit?  It might
  not be appropriate for the client to retry the request in pieces.

  I think NFS4ERR_BADXDR would be more appropriate than NFS4ERR_INVAL,
  though it doesn't handle the multiple-bit concern.

  The multiple-bit issue could be addressed by introducing a new
  NFS4ERR_BADFLAGS error which includes a bitmask to identify the
  unknown flag bits.  But that would require an XDR change.

  Perhaps the answer is that the client should use some other extension
  element to determine whether a given flag bit is known.

* stopping extensions for a given minor version

  Section 7.4 says

    Extensibility of minor versions are governed by the following rules:
    [...]
    o No new feature may be added to a minor version once the
      specification document for a subsequent minor version becomes a
      working group standards-track document.

  This is okay as a recommendation, but I think the working group should
  be free to use its discretion about when it will stop accepting
  extensions for a given minor version.

* support for minor versions in a group

  Section 8.3.2 says

    o  Servers supporting a given minor version MUST support any earlier
       minor version in the same minor version group

  Why MUST?

mike

PS. I'll be away from email May 27 through June 1.

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 24 Jun 2016 15:33:38 -0700

> them in -04, if I can.  Keeping things on a big to-do list  can result in

Okay.  Apologies for not getting any additional comments written up
prior to -04.  Now that -04 is out, should I hold off on these low-level
editorial issues until after you've resolved the issue about
informational vs standards-track RFCs?

[...]
> My understanding is that current implementations report INVAL for
> invalid flag bits and that was my reason for adopting this
> approach. If anyone knows of servers that do anything else, please let
> me know.

I noticed the new text in -04 (Section 4.4.3) to address this.  I'm
still not happy with using INVAL this way.  But if this is already what's
being used, then perhaps it's best to stick with INVAL.

> responder, the requester is finding out which feature packages the
> responder knows about.  You seem to be assuming that the client is
> going to defer that, and then just try a mix of new features and retry
> when it finds something unknown or unsupported.  I don't think people
> should be doing things that way and the spec needs to make that clear.
[...]
> It could be made more explicit that the client only needs to test a
> single protocol elements and is free to pick one that is easy to test.
> Also, that someone defining an extension is well-advised to make sure
> that there is it at least one protocol element to test to determine
> whether the feature package is known.

Agreed.

[...]
>   the client is unaware of added OPTIONAL server added since then.

Yes, I like that.

mike

---

From: David Noveck <[email-masked]>
Date: Mon, 27 Jun 2016 09:47:17 -0400

> prior to -04.

No need to apologize.  I wasn't all that clear about my plans.

> Now that -04 is out, should I hold off on these low-level

You might want to wait given that there Is not going to be a -05
out before IETF96. On the other hand, I'm interested in any comments
you have and will try to respond to them in the next version.  If
there is a document reorganization, it is likely that the same comments
will be relevant.

With regard to issues relating to whether there will be an informational
or standards-track document or both, we will be discussing this issue
at IETF96 and I'm hoping an actual decision will be made soon after
the meeting. However, I don't think one can assume that will happen.  In
other
words, if you wait for this issue to be "resolved", you may be waiting
a long time.  Also, I urge you and other interested members of the group
to contribute to that discussion.

Even if there is no actual decision/consensus, I expect further
versions to be produced after IETF96, taking into account the
discussion there, so any comments you send me will be addressed
at that time.

.

[...]

[...]

Agreed.

[...]

Yes, I like that.

mike

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 29 Jun 2016 14:42:59 -0700

> there is a document reorganization, it is likely that the same comments

Okay, I'll go ahead and start posting comments on -04.  I don't know how
long it will take me to get through the entire document, so I'll be
posting them in batches.

> With regard to issues relating to whether there will be an
> informational or standards-track document or both, we will be
> discussing this issue at IETF96 and I'm hoping an actual decision will
> be made soon after the meeting. However, I don't think one can assume
> that will happen.  In other words, if you wait for this issue to be
> "resolved", you may be waiting a long time.

Heh, okay.

> Also, I urge you and other interested members of the group to
> contribute to that discussion.

I'll read through draft-dnoveck-nfsv4-extension-00 and see if I have
anything to offer.  To be honest, I don't really care much one way or
the other about informational versus standards-track.

cheers,
mike