Subject: [nfsv4] NFSv4 version management.

From: David Noveck <[email-masked]>
Date: Wed, 1 Apr 2015 11:02:40 -0400

This is a followup to my talk at IETF 92.  The slides are at
http://www.ietf.org/proceedings/92/slides/slides-92-nfsv4-9.pdf.

Work is now proceeding on draft-ietf-nfsv4-versioning-01.  Before that's
submitted, I'd like to get people's opinions so that
the draft when produced will not be too far from the general sense of the
group on these issues.  I don't expect us to be
anywhere near consensus for a while but I want the upcoming version to be
close enough to where the group as a whole
is that we will mostly be resolving issues of detail.  At least I hope so.

I think there is a genera;l agreement as to two points:

   - We want to do a lot of our future work in terms of the addition of
   individual features, as specified in draft-ietf-nfsv4-versioning-00.

   - We don't want any more minor versions as big/disruptive as NFSv4.1 was.

This leaves us with a series of issues that relate to the question of what
minor versions are for.   Since the versioning RFC is
to define our approach to NFSv4 versioning as a whole, we have to address
creation of minor versions as well extensions of
existing minor versions.  An important goal for the NFSv4 versioning RFC is
to address both of those in a coherent way.

One way to look at the issues is to look at each of  the  things that were
done  in NFSv4.1 or could be done in minor versions
according to the minor versioning rules in RFC5661 (or
draft-ietf-nfsv4--versioning-00) and see whether we want to allow
such things in minor versions, disallow them, or allow them with
restrictions

   - Describe the protocol from ground zero, rather than as a series of
   deltas

I think there is general agreement that we don;t want to do this any more.
In a way, this general agreement is beside

the point.  There is nobody to do this and the IESG isn't going to let us
do it anyway.

One interesting question is whether making this restriction is sufficient
to prevent minor versions from becoming too

big/disruptive.  If it is, perhaps we might want to be relatively liberal
about other sorts of potential restrictions.

   - Introduce required new features.

Since this was forbidden by the rules in RFC3530, and only changed for
v4.1, we might simply go back to the v4.0 version

of this.

On the other hand, it may be that the problem was the size of the feature
being introduced, rather than the fact that it

was introduced as required.  The whole issue is complicated by the text of
rule #12 in RFC5661, which seems to

suggest that you can only introduce a feature as required if it is
big/disruptive.

It may be that the ability to refactor any parts of the protocol  depends
on the ability to make a required changed at some

point, and that the ability to do so at introduction is not the essential
issue.

   - Change the statuses of existing features, including making features
   mandatory to not support

If you believe, as I do, that "recommended" feature status should be done
away with somehow, then this boils down to

changes in the sets of required or allowed features.  This inherently
raises interversion compatibility issues and we

need to give some kind of guidance about dealing with this conflict.

   - Making non-XDR-based changes in the protocol

The existing minor versioning rules do not mention this possibility,
focusing solely on possible XDR changes.

There were a number of Non-XDR-based protocol changes going from 4.0 to
4.1.  Examples are the creation of a new

a new special stateid to represent the current stateid, the handling of
seqid 0 in stateid's and the semantic changes

eliminating the use of owner seqids and clientids in locking requests.

The basic choice we have is whether to forbid things like this going
forward.  If they are allowed they should not be allowed
in features done as separate extensions.  Interestingly, all the ones done
in v4.1 were required at introduction but there's no
good reason not to change that going forward.

   - Adding pNFS-like extension mechanisms to the protocol,

This has happened in going from 4.0 to 4.1 since the pNFS extension
mechanism has to be a pNFS-like one :-).  It doesn't seem

like we want to say this is something that must not be repeated.

Since there are no likely candidates for additional mechanisms of this sort
on the horizon, we could defer this.

On the other hand, this is a possible means of protocol extension which has
been used and we might as well give some

guidance as far as incorporating such alternate means of protocol extension
in our version management framework. Although, we

have the option of updating this document later, it would be better if we
could avoid the necessity to do so, if we can.

There are also a number of other questions I'd appreciate hearing people's
views about:

   - What to do about recommended/RECOMMENDED as a feature status?

This is tied to he specification of non-REQUIRED attributes as
"RECOMMENDED" in RFC's 5661 and 7530.  "recommended" was used in
RFC3530. It doesn't seem that "RECOMMENDED" is in line with RFC 2119.

As RFC7350 now says that "RECOMMENDED" attributes are not RECOMMENDED
according to RFC2119, we might well get rid of the
current assumption that that most attributes are recommended/RECOMMENDED at
introduction.  Unfortunately, RFC5661 still has
"RECOMMENDED" attributes with the implication that this is in line with
RFC2119.  In any case, as far as version management

goes, I don't see how it makes sense to specify features as "RECOMMENDED".
What really makes a difference is whether clients

can  assume support or have to deal with the possibility of non-support.

   - Upper-case vs. lower-case feature status

The -00 now uses upper-case terms for features statuses including
"RECOMMENDED".

If we could ditch RECOMMENDED/recommended as a feature status, REQUIRED and
OPTIONAL would work.

If we can't do that, then we could make the relevant feature statuses as
required and non-required, treating any potential recommendation

with regard to support as out-of-scope from the viewpoint of version
management.

   - How to deal with the current assumption that features will
   normally/naturally progress to being required.

I think this has to change.  It is quite possible for a feature to be
successful/useful without it becoming essential for use in every NFSv4

server.

In any case, I'd appreciate any comments people have on these or other
version management issues.  As I indicated, one can't expect anything
like consensus at this point.  I anticipate that this Working Group First
Call :-) will be over in about two weeks after which I'd like us to have a
concrete -01 that we can discuss.

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 11:09:33 -0500

>    individual features, as specified in draft-ietf-nfsv4-versioning-00.

I think you mean *independent* addition of individual features.

I've been insisting on that for years.

> This leaves us with a series of issues that relate to the question of
> what minor versions are for.   [...]

The major version number is not locked at 4 forever.  The minor version
is now effectively the "major" version: to be changed only at backward-
incompatible boundaries.  From here onwards new individual features
should be negotiated without regard to minor versions.

It's that simple.

> One way to look at the issues is to look at each of  the  things that
> were done  in NFSv4.1 or could be done in minor versions according to
> the minor versioning rules in RFC5661 (or draft-ietf-nfsv4-versioning-00)
> and see whether we want to allow such things in minor versions,
> disallow them, or allow them with restrictions

To be blunt, this is navel-gazing, and hopefully this new I-D will be
the last instance of NFSv4 minor version navel gazing.  No prior version
of NFSv4 binds us to continue on the feature-train approach.

> I think there is general agreement that we don;t want to do this any
> more.  In a way, this general agreement is beside the point.  There is
> nobody to do this and the IESG isn't going to let us do it anyway.

Some day you might want to (once many individual feature additions pile
up).  But there's no reason to do it, and it's EWAYTOOHARD to do for
every feature.

> One interesting question is whether making this restriction is
> sufficient to prevent minor versions from becoming too big/disruptive.
> If it is, perhaps we might want to be relatively liberal about other
> sorts of potential restrictions.

Which restriction.

> [...]

Yes, that would require a new minor version.  Hopefully there will be no
need for it.  But even if there is, the new minor version should simply
consist of a spec bumping the minor version and stating what new
[separately-specified] features are required.  This is easy; don't sweat it.

Although I don't think there's even a need to bump the minor version in
this case: it will simply be the case that implementations that do not
coincide as to now-required features simply won't interop.  Which means
we'll do the utmost to avoid requiring new features.  And either way
we'll end up not bumping the version number.

> On the other hand, it may be that the problem was the size of the
> feature being introduced, rather than the fact that it was introduced
> as required.  The whole issue is complicated by the text of rule #12
> in RFC5661, which seems to suggest that you can only introduce a
> feature as required if it is big/disruptive.

Whatever.  We'll know it when we see it.

> It may be that the ability to refactor any parts of the protocol
> depends on the ability to make a required changed at some point, and
> that the ability to do so at introduction is not the essential issue.

There will be no refactoring, because ETOOHARD.  See above.

> If you believe, as I do, that "recommended" feature status should be
> done away with somehow, then this boils down to changes in the sets of
> required or allowed features.  This inherently raises interversion
> compatibility issues and we need to give some kind of guidance about
> dealing with this conflict.

NO, we don't need to give any such guidance.  This is not guidance to
implementors, but to our future selves (who will not be stupid).

You are making this way too hard on yourselves.

We don't do this in TLS WG.

We don't do this in KITTEN WG.

We didn't do this in SECSH WG.

And so on.

What makes NFSv4 so special that you must waste time doing something no
other WG bothers to do (because they know that protocol engineers
working on the same protocol years later will not be stupid).

> 4.1.  Examples are the creation of a new a new special stateid to
> represent the current stateid, the handling of seqid 0 in stateid's
> and the semantic changes eliminating the use of owner seqids and
> clientids in locking requests.

Are you referring to changing the forms of existing structures, to
changing the forms of structures that are then super-encoded as opaque,
or to introducing new structures that don't use XDR at all?

Anyways, the only key thing is backwards incompatible (non-interoperable)
changes: either they're out or they require bumping the minor version
number (and they must not be so far reaching that implementations
couldn't even exchange minor version numbers).

> forward.  If they are allowed they should not be allowed in features
> done as separate extensions.  Interestingly, all the ones done in v4.1
> were required at introduction but there's no good reason not to change
> that going forward.

See above.

> [...]

>    - What to do about recommended/RECOMMENDED as a feature status?

Nothing.

>    normally/naturally progress to being required.

That's an inappropriate assumption.

> successful/useful without it becoming essential for use in every NFSv4

Indeed.

> [...]

The new I-D should be dead simple.  It should say:

 - We don't expect the minor version number to change except when it is
   critical to signalling backwards incompatible (non-interoperable)
   changes in the protocol.

 - From now on features can be added to NFSv4 individually and
   independently.

You will also need to create IANA registries for all the namespaces
(e.g., operation name and number) that individual features will need to
get name/number assignments from.

Anything else is overwrought.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Thu, 2 Apr 2015 08:32:28 -0400

First of all, since you've let lapse our informal ban on the use
transportation metaphors
in this context,  I'll respond by using food service metaphors.  I hope it
won't lead to
any shouting back and forth.

> I think you mean *independent* addition of individual features.

I didn't use the word 'independent' and neither does
draft-ietf-nfsv4-versioining-00.

There are different possible contexts for possible inter-feature
independence.

   - Features are developed and specified independently.  While the word is
   not used in the -00, that is the sense of the treatment there.  I'll be
   looking at where it makes sense to say that explicitly in the -01.
   - Features are not incorporated n the protocol independently.  The
   working group will be making judgments about how well each one is likely to
    to work together with existing ones before approving each as a working
   group document. Similarly, the IESG will be making a similar judgment when
   approving a feature as a Proposed standard.
   - Features can be selected independently and implemented (or not) by
   servers and clients can test for the presence.  This is not new with the
   -00 but has always been true of optional features.  This is the a la
   carte model and it has always been part of the NFSV4 approach.  You can
   order any dish you want on

> I've been insisting on that for years.

If and when we have an NFSv4 version management RFC, you'll get a lot of
what you were insisting on, even though it might be longer than the document
you would have written (or will write).

> the last instance of NFSv4 minor version navel gazing.

Actually, the RFC that results from completion of this document will, i
hope,
be the last instance of what you call "NFSv4 minor version navrel gazing".

> No prior version

Once we publish a new approach as an RFC, this is so.  but until we do, the
existing
rules in RFC5661 remain normative, and that's not a desirable state of
affairs.

> [separately-specified] features are required.  This is easy; don't sweat
it.

I just have to document this clearly in the -01.  Once that's done, there's
no
need to sweat it.

> coincide as to now-required features simply won't interop.

As i think about writing this and dealing with the IESG, wildly waving my
hands
and saying, "Don't worry. Implementations that don't coincide simply won't
interop'",
all of a sudden I'm perspiring profusely.

> implementors, but to our future selves (who will not be stupid).

We give guidance to implementors, even if we don't think they will be
stupid.

Regardless of any possible stupidity on the part of our future selves, i
think
some sort of guidance would be helpful.

Let's look at NFSv4.1, edited by Spencer, me, and Mike Eisler.  I don't
think any
of those people were stupid.  You are free to disagree.  I think the
problem was
not stupidity but focusing on the wrong thing.  We were thinking about how
nice
sessions were and didn't consider version management important.  Instead of
clear
guidance, we had rules which didn't let us do what we wanted but said we
could
change the rules as we liked and the result was rule #12.  I don't know who
wrote that,
but in any case we wound up with something that doesn't make much sense,
even though I'm pretty sure the person who wrote it wasn't stupid.  I don't
think
it was me but I can't be sure.

> working on the same protocol years later will not be stupid).

Before I address what makes NFSv4 special, let me note that sometimes
"special"
can mean "differently abled', i.e. "extremely dim".

Anyway, what makes us different from those other groups is that we do not
have a
clean slate to work with.  We  have over ten years of assuming a rigid
minor version model
and, until we publish an RFC that says something different, it is the NFSv4
versioning
model.  While it might be obvious to you and others that this is the wrong
model, we have
to explain to the IESG why it is the wrong model and show how we cam switch
to a new
model in a sane way.  If you consider that "overwrought", I can deal with
that.

> or to introducing new structures that don't use XDR at all?

I'm talking about the changes that we actually made in v4.1 that were not
XDR-based changes.
These included;

   - The addition of of a new special stateid to represent the current
   stateid.  Since this involved special handling for the "other' field of a
   stateid which is nominally opaque, the XDR didn't change.  the same field
   is still nominally opaque.  It is just there different rules about what to
   do with certain special values.
   - new rules about dealing with seqid's of zero in stateids.  No change
   to XDR as this field remained an integer.
   - Rules about how to deal with the effect of changes in mode as they
   affect acl's.  There is no change in XDR but there is a change to the
   semantics.
   - The fact that clientid and owner seqids are no longer used in locking
   requests.  The XDR didn't change (in that the fields still exist) but some
   fields are not set and so the semantics are incompatible.

These are all incompatible changes and I think we agree that they (and
similar future changes) would require a version number change.