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

From: David Noveck <[email-masked]>
Date: Tue, 28 Oct 2014 11:23:30 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 11:01:17 -0500

>    isn't clear how to specify an assignment policy that IANA would accept.

There are a number of allocation policies that you can use.  Having a
Protocol Action from the IESG is not the only way.  You can have a
first-come-first-served-with-Expert-review process, which is what I
would recommend for any namespaces large enough that you're not going to
worry about running out.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Tue, 28 Oct 2014 14:15:04 -0400

> There are a number of allocation policies that you can use.

Perhaps so, but we still have the issue of whether there is a reason to use
them, i.e. whether they add anything to the process., other than an extra
interaction with IANA.

> You can have a first-come-first-served-with-Expert-review process,

I don't think you can combine FCFS with expert-review in that way, and
have things work..

For example, RFC5661, specified, for the named attribute registry, both
FCFS and specification-required.  That got thorough IESG and IANA review
and RFC%661 was approved as a Proposed Standard.  So far so good, but ...

rfc3530bis dutifully copied the language of RFC5661 (since we wanted to be
compatible with RFC5661 on this point).  When the bis document went through
the review process, we ran into a brief period of IANA-NOT-OK and IANA
explained to us that we had to choose one policy or the other.

> which is what I would recommend for any namespaces large enough that
you're not going to
> worry about running out.

The problem is that  the issues of holes in the allocations, that Benny was
concerned about becomes magnified.  Even  if you aren't worried about
an occasional unassigned attribute or operation code, this policy could
create large spaces in the allocations.  For example, if someone assigned
attribute number 10,000, some GETATTR's might be thousands of bytes long.
Given current implementations, which we don't want to change radically,
running out of opcodes/attributes is not the only issue.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 14:32:05 -0500

On Tue, Oct 28, 2014 at 02:15:04PM -0400, David Noveck wrote:
> [...]

I spoke loosely.  I meant that the way numbers are allocated should be
first-come-first-served, but the policy should be Expert review.

> The problem is that  the issues of holes in the allocations, that
> Benny was concerned about becomes magnified.  Even  if you aren't
> worried about an occasional unassigned attribute or operation code,
> this policy could create large spaces in the allocations.  For
> example, if someone assigned attribute number 10,000, some GETATTR's
> might be thousands of bytes long.  Given current implementations,
> which we don't want to change radically, running out of
> opcodes/attributes is not the only issue.

Because bitmap4 is just an uncompressed bit string.  That's sad, but not
too sad: this is what an Expert is for.  The expert can reject large
allocations, and they can be given this guidance.  For the kinds of
extensions we can expect, this seems like a non-problem.

It shouldn't be hard to negotiate a different interpretation of bimap4
if this ever did become a problem, incidentally.

Nico
--