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

From: Mike Kupfer <[email-masked]>
Date: Fri, 13 May 2016 15:33:20 -0700

Apologies for taking so long to provide feedback.  I plan to be more
ruthless about reserving time for working group activity; hopefully that
will keep me from disappearing for weeks at a time.

Anyway, I've got a bunch of issues in my notes, but I thought I'd start
with a discussion on how to make the document easier to read and digest.

One thing that gets in the way of readability (at least for me) is the
interleaving of specification with discussion (e.g., Sections
4.1.1-4.1.2, or Sections 5.1.2-5.1.3).  If we could more clearly
separate the specification from the discussion, I think that would
improve readability.  One way to do that might be to have all the
history and discussion first, and then follow that with the actual
rules, analogous to the way the specs for NFSv4.0, v4.1, and v4.2 are
organized.

Another thing that I had trouble with was the generality and complexity
of the specification.  Here are three examples.

One, Section 5.1.3 has the title "Rules for non-XDR changes", but in
that section we are told that a substantive behavior change *must have*
an associated XDR extension (which seems to conflict with the section
title), and no feature including a behavior change can be introduced as
an extension.  I'm afraid I'm lost there.

Two, Section 6.4 talks about an F-to-E status "with regard to the
feature".  I can understand having a feature introduce multiple protocol
elements.  But this wording seems to imply a many-to-many mapping
between features and elements, even though "every protocol element is
defined as a member of exactly one protocol feature" (bottom of page
24).

Three, the E-to-F statuses SINF and NSINF add complexity, but without
adding any real value (that I can see).  IMO, the spec would be better
off without ever bringing them up.

If it seems useful to address these two issues first, I can go back
through my notes to pick out all the ones that are pertinent.
Alternatively, I could go back through my notes to look for the
technical questions that I had.

Dave, do you have any preference on how to proceed?

mike

---

From: David Noveck <[email-masked]>
Date: Sat, 14 May 2016 07:35:51 -0400

Right now, I'd like to put the focus on localized issues, that
can be addressed in a  -04 that can be submitted before
the 7/8 document cutoff for IETF96.  The -03 expires during
IETF96.  I'm not sure if your issues with Sections
4.1.1-4.1.2 and Sections 5.1.2-5.1.3 fit into that
class but I'll take a look.

Regarding suggestions that might involve a general
re-organization of the document, these are not going to be
acted on for a while, until after a working group discussion
at IETF96 about how to proceed in this area.  That
does not mean such suggestions should not be made. It is useful
to make them part of the discussion.

One suggestion that was made at the working group conference
call was that this topic should be addressed in an informational
document.  I believe that it is essential that some part of the
current document go forward as standards-track. If we don't
update what existing standards-track documents say about
NFSv4 versioning, we are stuck in the land of You-MUST-use-
minor-versioning.

Nevertheless, it is clear that some of what is in the current
document would be appropriate in an informational document,
particularly material about documentation practices.  I'd
like the working group to discuss, both on the list and in Berlin,
whether a two-document approach is appropriate and how to
divide the existing material into Standards-track and informtional
documents.  I would like us to take into account your suggestions
regarding general document re-organization once the
document division question is resolved.

I'll be sending out a later message regarding the specific issues
in your mail.

---

From: David Noveck <[email-masked]>
Date: Sun, 15 May 2016 09:50:17 -0400

> Section 5.1.3 has the title "Rules for non-XDR changes", but in
> an associated XDR extension

I think it might help to explain what is going on here.  If you have a
substantive behavior change, you might have a situation in which pre- and
post-change implementations might try to interact and get confused as both
sides could think their behavior is the correct one and be unprepared for
different behavior.

By requiring an associated XDR extension we provide a way for the
participants to find out about whether the peer is an old-style
implementation unaware of the change.

Without some such requirement non-XDR changes are a dependable source of
chaos.

> (which seems to conflict with the section title),

Maybe so, but I don't think there is an actual conflict.  Would this
be clearer if the title were "Restrictions on non-XDR Changes"?

> and no feature including a behavior change can be introduced as
> an extension.

This part is a policy choice introduced later.  Once I'm clear that the
working group is OK with this, we could simplify the treatment of this by
starting off with that restriction.

> I'm afraid I'm lost there.

I hope this clarifies things.

> Section 6.4 talks about an F-to-E status "with regard to the

First let me explain what is going on here.  Then we can separately discuss
whether you have objections to either or both:

   - The actual structure chosen
   - How it is explained

As you note, each protocol element is only part of a single feature.

The E-to-F status for a given protocol element only references that
single feature.  Thus you can only infer support for a feature based
on the support for the protocol elements which are included.

In practice, the most important consequence of the assignment of
protocol elements to features concerns feature element awareness,
rather than support.  If your peer's XDR known about a protocol
element tat is part of one feature it knows about all the protool
elements that are part of the same feature or of a different feature
that is part of the same feature package.

F-to-E statuses are different and more flexible (or you might describe it as
"general" or "complicated")  in that support for a single protocol
element can be affected by support for a set of features and not only
the one of which it is a part.

Let me explain why this choice was made.  Often, one feature might
add an OPTIONAL element, such as an attribute, that a second feature
might find useful and build on, to implement another extension.  The second
feature might need that attribute to function without needing the whole
feature of which it is a part to be supported.  One way to accommodate that
would be to require that the attribute be made a separate feature and have
the second extension dependent on that new single-attribute feature.
However, the prospect of re-organizing features (including splitting them
up) after they were defined made things quite complicated and so I decided
that allowing F-to-E status relationships to cross feature boundaries was
the lesser evil

> The E-to-F statuses SINF and NSINF add complexity, but without
> adding any real value (that I can see).

I don't see that much complexity is added by these.  The basic function
here is inferring support for the feature from support from the protocol
elements.  The two clearly useful values that have to be provided for are
"IFF" and "SVAL".  The question then is if you want to say that no other
choices are to allowed.  I don't think you want to do that.  If that's the
case the choices are:

   - To list the valid possibilities, even if some might not be so useful.
   - To explain the general framework, so that either support or
   non-support for the element might imply any of support, non-support, r
   uncertainty regarding the feature.  Since that gives nine possibilities,
   you wind up having to explain the bases on which you excluded some of
   those.  I decided I wasn't up for writing all that.

I think I need to re-organize this stuff in any case, since SVAL is
basically a subset of NSINF.  When I'm clear how I might do that, I'll send
out a proposal for comment.

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 17 May 2016 14:49:07 -0700

David Noveck wrote:

> I'd

That order of attacking things sounds fine.

Putting the specification into a standards-track document and the
history/rationale/discussion into an informational document would
address my concern.

thanks,
mike

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 17 May 2016 17:20:51 -0700

> Without some such requirement non-XDR changes are a dependable source of

Agreed, more or less.  The way I think about it is that there are 2
possible ways to identify a behavioral change: an XDR change that can be
queried, or a minor version bump.  If we want, as a matter of policy, to
only use XDR changes to identify a behavioral change, I'm not sure
that's a good policy, but it's not something I'd spend much time trying
to get changed, either.

> be clearer if the title were "Restrictions on non-XDR Changes"?

I'd prefer "Restrictions on Behavioral Changes".

> I hope this clarifies things.

I'm still confused about the third point.  On page 22, we have

  o Any substantive behavior change must be part of a feature in which
    there is also an XDR extension present

That's fine.  But a few lines later we have

  o No feature including [any behavioral] change can be introduced as an
    extension.

If a behavioral change can be flagged using an XDR extension, what does
the second bullet mean?

> F-to-E statuses are different [from E-to-F] and more flexible (or you
> might describe it as "general" or "complicated") in that support for a
> single protocol element can be affected by support for a set of
> features and not only the one of which it is a part.
> 
> Let me explain why this choice was made. [...]

Okay.  I agree that we want to allow the "build on" scenario.  And
including an element from Feature1 in Feature2's F-to-E table seems
reasonable.

> choices are to allowed.  I don't think you want to do that.

It seems to me that for any new feature, there should be one key element
that can be queried.  The feature could introduce other elements that
require querying before trying to use them, but first the client has to
determine whether the feature is supported at all.  That key element
should either be IFF or SVAL, because anything else just makes life
unnecessarily hard for the client.  Once the feature has a key element,
discussing the E-to-F status of other elements seems like it just adds
clutter.

> out a proposal for comment.

Okay, thanks.

mike

---

From: David Noveck <[email-masked]>
Date: Wed, 25 May 2016 10:27:00 -0400

> history/rationale/discussion into an informational document would

That isn't going to happen.  A standards track document always has some level
of explanation.  IESG members will typically ask why certain things were
done and you need some material that explains the purpose of things.  Otherwise
you wind up explaining things in email again and again.  One can cut down on
history/discussion but eliminating it is not a good idea.

The problem with a document that consists of only
history/rationale/discussion
is that it may not be worth gong thorough the IESG approval process.  A lot of
the history/rationale you are talking  about in in
draft-dnoveck-nfs-extension which I've been keeping up to avoid it expiring
but there doesn't  seem to be enough interest in it for me to work on
making it a working group document or to consider making it into an
Informational RFC.

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

   - Bill (and perhaps others) objected that the document sought to limit
   future working group actions in a way that was inappropriate.  I believe
   that the argument was that each standards-track document, including those
   for future minor versions and extensions stood on its own and that this
   standards-track document could not effectively limit what the working group
   might do in the future.  The idea was that in proposing these extension
   patterns, the extension was not defining enforceable rules and so should be
   considered informational.
   - I felt that argument had some validity regaring
   description of documentation patterns and some procedural matters, but
   that we needed to undo the effects of previous standard-track document that
   set out rules that limited our ability to make changes to the XDR without
   making changes to the minor version number.
   - As a result, I concluded the working group needed to decide whether it
   wanted to continue with a single standards-track documernt or have two
   working-group documents dealing with extensions, with one standards-track
   and one informational.

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.

I've been looking at a potential document split and hope to be able to
submit a draft-dnoveck-nfsv4-extension-00 before IETF96.  That will give
working group members something concrete to look at, when discussing our
document structuring choices.  My expectation is that much of the material
in  4.1.1-2 and 5.1.2-3 will not appear in that document although there
will some level of explanation present.  I'm not sure where else in the
document this material could go and right now I can't see putting it into a
separate document.

After IETF96, I hope the working group will decide whether to:

   - Continue along the current path.  If that is chosen, I could propagate
   the changes regarding  4.1.1-2 and 5.1.2-3
   into draft-dnoveck-nfsv4-extension-00 , as well as making other structuring
   changes that people are comfortable with.
   - Convert draft-dnoveck-nfsv4-versioning-04 to have an expected status
   of informational.  I think this would be a bad choice.  my concern would be
   that if draft-ietf-nfsv4-xattrs or draft-ietf-nfsv4-umask were to go
   forward, the IESG would have problems with the fact that the existing
   standards track NFSv4 versioning model says you can't change the XDR
   without changing the minor version number.
   - Adopt the two document approach. In this case we would produce a
   working group standards-track document draft-ietf-nfsv4-extension-00 based
   on draft-dnoveck-nfsv4-extension-00.  I'm hoping this would be much
   smaller and be sufficient to support  draft-ietf-nfsv4-xattrs and
   draft-ietf-nfsv4-umask going forward.

In this case, draft-dnoveck-nfsv4-versioning-05 would then lose most of the
material moved into draft-ietf-nfsv4-extension-00 and get an expected
status of informational.  At that point, this new document would not
contain any specification text per se.  However much of
the specification material would still be there with only a change in
tone.  Instead of telling people how this things are to be be done, it
would tell them how it might be expected that it would be done.  We can
review the document structuring issue in that new context, if that is the
direction chosen.

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 25 May 2016 13:35:22 -0700

> during the conference call and my response to it.
[...]

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

> for needed changes in  draft-ietf-nfsv4-versioning-04, please let me know

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.