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

[Nico Williams <[e-mail]>]

On Tue, Oct 28, 2014 at 02:15:04PM -0400, David Noveck wrote:
> > 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.
> [...]

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