[nfsv4] draft haynes-nfsv4-versioning: Issues relating to opcode assignments etc.

[David Noveck <[e-mail]>]

> 1) Are new operations assigned by IANA or by publishing a draft?

Just to clarify here, the draft in question would be a draft (i.e.
typically the first draft) of a working group document.  No assignments by
publishing individual drafts are contemplated.

> Actually Christoph's observation, but there seems to be controversy here.
:-)

I did recall Christoph asking about this but I didn't recall any
controversy.  I've looked for the email in which this was discussed but
haven't found it.

There are some issues here that need to be clarified, whether "controversy"
is the right word or not.  Also, It makes sense to consider issues related
to assignment of attribute numbers, other enums, and flag bits, at the same
time we consider operation code assignment (including those for callbacks,
I assume).

I think we need to distinguish a couple of related issues:

   - How (or by whom) the assignment is made.
   - When the assignment is made

I think the issue about which there is likely to be disagreement or
controversy will be the question of when (i.e. how early) the assignment is
to be made. My understanding of the connection between these two issues is
as follows:

   - If the assignment is to be made when the RFC is published, then we
   could implement IANA-based assignment by creating one or more registries
   with a "specification required" assignment policy.  However, this could be
   complicated to do, although it is relatively simple if you just do it for
   operations.  The big issue is that doing this doesn't buy you anything (see
   below for a discussion of this).
   - If the assignment is to made earlier than that (e.g. when the document
   becomes a working-group document as suggested in the current draft), it
   isn't clear how to specify an assignment policy that IANA would accept.

If IANA is to be making the assignment, I'll  assume the assignment policy
people are thinking about is "specification required", essentially meaning
you have to have an RFC.   If there's been any discussion of a different
assignment policy, I haven't heard of it.

If we are talking about assignments being made (or at least becoming
effective) at RFC approval time, I don't see how an IANA registry will add
anything to the process.  For example, we could have set up an opcode
registry when RFC3530 was published and then added the v4.1 opcodes to it
when RFC5662 was published.  Further assignments could be made when the
v4.2 XDR RFC is published.

If we had done that (and possibly set up registries for callbacks and
attributes) that would not have added anything to the process.  It's also a
lot of work to set up registries, including additional ones for various
enums and flag bits.  There's a good reason we chose not to do that and I
don't see what has changed to make this more desirable now.

So now let's turn back to the issue of when the assignment is to be made.
The following list is intended to summarize the issues raised regarding the
approach outlined in draft-haynes-nfsv4-versioning-01.  It is likely not to
be complete, as I can't remember what Christoph said about the issue and
it's possible that I've forgotten other stuff as well.

   - Benny raised issues regarding the potential existence of holes in the
   set of opcode and attribute assignments.  He was concerned about the
   performance implications.  This didn't turn into a controversy, but in my
   mind this remains an open issue which the working group should come to a
   consensus  on. Personally, I don't feel that the performance issues are
   significant enough to arouse concern.


   - Tom had some concerns that, while not explicitly directed to the
   time-of-opcode-assignment issue, may be relevant here.  Tom was concerned
   about situations in which an (unofficial) assignment was made, and code was
   shipped on the basis of that assignment, making it difficult to change that
   assignment, without impacting those running the previously shipped code.

This issue could have some bearing on the time-of-assignment question but
it could be argued both ways.  First, if one is concerned about assignments
being made too early, that might argue for either a later assignment point
(e.g RFC approval) or the group being a little more restrained about the
implementation of a earlier assignment policy (i.e. the working group
taking due note of the consequences of making an assignment at the point
the document is made a working group document.

Also, if one is concerned about the consequences, of people shipping code
that depends on assignments not formally made, this would argue against an
assignment policy subject to unpredictable delays.  Maybe I've been unduly
influenced by experiences with rfc3530bis, but i think that if you have a
policy that requires IESG approval and going through the RFC editing
process, one will sometimes wind up needing to ship code without waiting
for the process to complete.  My fear is that if one has a policy like
that, one may be faced with the choice of discouraging reasonable
implementation progress or violating ones own rules. That's what led me to
choose the policy of assignment at the time that the feature specification
document becomes a working group document.


   - Possibly (tangentially) related to this issue are Benny's remarks
   regarding assignment of experimental ranges for attributes, opcode and
   potentially other feature elements.   While it is true that such ranges
   could support some degree of experimental use, I would have to say that is
   so only in a very limited context.    It seems to me that the model is
   doing something in a very constrained environment in which the code you
   write is restricted environment and you don't want to let it escape into
   the wild, since the opcodes in the experimental assignments cannot be
   relied upon, since they are inherently transient.  Let's call that
   alpha-test-style experimental use.

The provisional assignments that are to be made as described in
draft-haynes-versioning-01 allow something that we might cal
beta-test-style experimental use.  The idea is that we may at times, need
to get the benefit of something nearer real use, as we dot the i's and
cross the t's on the spec.  In many cases, there needs to be extensive
specification work, and that work, while necessary to support the most
general sort of use, does not affect a large portion of typical use and
there are benefits to be had from getting that experience earlier.  As an
example, consider server-side copy, first proposed in an I-D in early
2009.  A lot of the work from that time to now concerned it's extension to
the case of inter-server copy and exploring the security issues posed by
the requirement that the protocol not require a trust relationship between
the source and destination servers.  If we could have beta-tested the
subset of the protocol dealing with the intra-server copy, the NFSv4 user
community would have gotten the benefits of that subset of the server-side
copy feature, while the security issues in the inter-server case were
addressed.


So to summarize where I stand on these issues:

   - I think the real issue here concerns the time at which it is
   appropriate to  make these assignments and that once that decision is made,
   whichever way the group makes it, adding IANA to the process is not a help.
   - If someone wants to make the case for IANA involvement in this
   process, the working group should address that issue.
   - I see no reason to modify the time-of-assignment approach specified in
   draft-haynes-nfsv4-versioning-01, but think that there may be reason for
   the working group to discuss this further.
   - Although I continue to think early assignment is a better choice, I'm
   not all that invested in that choice.  For me, getting rid of feature
   batching (section 5 of the document) and providing a clear path to
   correcting XDR problems discovered after RFC publication (section 6 of the
   document) are the big benefits of the current draft and my focus is on
   those.
   - I'd like to see us come to a consensus on this issue but don't think
   it is required for going forward and making this a working group document.
   Even if we do come to a consensus on this issue, it may change before we
   reach WGLC.