[AFS3-std] Re: Claim on 2 RXAFS code points for private use

[Andrew Deason]

On Tue, 01 Nov 2011 16:38:30 -0400
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> Sorry about that.  To be fair, though the ticket has existed for a
> couple of months, it's only been a little over a week since you pinged
> me in email.  It's not like you've been bugging all three registrars
> every day for the last two months and we've been completely blowing
> you off.

Yes, sorry, I didn't mean for it to sound like that. But when something
appears to be a black hole, there's little motivation to just send more
bits to oblivion... (and er, who is the third? I only sent something to
you and Tom Kula)

I also didn't give you any indication of a deadline or anything, which
was just an oversight on my part; I do apologize for that.

> I'm not opposed to reserving a block of procedure numbers for
> site-local use, if that's what the group would like to see.  However,
> these would have to be truly site-local, subject to agreement by all
> parties using a number for a particular purpose.  It would _not_ be
> appropriate to use such numbers for vendor-specific extensions
> delivered to customers.  In fact, it would be best in most cases for
> site-local RPC numbers not to ever be used in production, because
> there is no way to tell whether a peer assigns the same meaning to an
> RPC number that you do.

If it's a completely isolated cell with centralized control of the
client software, I don't see any problems. For an "experimental" range,
I'm not trying to prevent any other clients from using the numbers, I'm
trying to prevent the numbers from being used as "standard" ones in the
long-term (for example, in OpenAFS stable releases), so I don't have to
move the numbers around on upgrades.

It's just an idea, though; I'm not too vehement about it, and I agree
the use case is small and it could be abused. Just using really large
numbers arguably already sort-of makes this possible if you just don't
tell anyone about it, but that's obviously not ideal. Having a specific
range for that purpose would at least (in theory) restrict such use to
that range.

> For an example of how badly this can go wrong, see the Solaris
> versions where what was the OpenAFS syscall number was reallocated to
> unlinkat(2).

I don't think I'm likely to forget that one any time soon :)

> In any case, you're welcome to the two numbers you mentioned.

Thank you.

-- 
Andrew Deason
adeason@sinenomine.net