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

[Jeffrey Hutzelman]

On Mon, 2011-10-31 at 12:57 -0500, Andrew Deason wrote:
> Sine Nomine Associates would like to use two RPC code points in the
> RXAFS package for institution-private use. I have been unable to get a
> response from the AFS-3 registrars for the past couple of months for
> proper code point allocation, and I am unable to wait any longer.
> 
> So, I am simply "announcing" here that we're using two code points, and
> am just hoping that there is no collision. Most people I am aware of
> that have any interest in modifying the AFS-3 protocol read this list,
> so this is the best place to do so that I know of. The last allocated
> RXAFS code point on registrar.central.org is 65608. I'll leave some
> space to try and make sure I don't collide with someone else, so I will
> claim 65709 and 65710.
> 
> I do apologize for not following the proper procedures and all, and I do
> not wish this to be any kind of precedent for such behavior, but I don't
> know what else to do. If anyone knows of a possible collision with these
> numbers or has any problems with this, please speak up and I will
> accomodate as best I can.
> 
> I would also be fine with just using code points in a "site-local" or
> "experimental" range or something, but as far as I am aware such a thing
> does not exist.

<sigh>

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.  In fact, I saw your message to me, got distracted with something
related to my job (probably, a major shutdown scheduled for that
evening), and simply forgot to reply.

I did spend a fair bit of time getting most of the Rx registries into
shape and dealing with past and current requests, back around the time
of the workshop here in Pittsburgh.  The current registries can be found
at http://registrar.central.org/rx/ or
in /afs/grand.central.org/www/registrar.central.org.

Unfortunately, to date the only registries that have been converted are
those for capabilities and for the main Rx protocols.  I also have
ioctl, pioctl, com_err table and error codes, and syscall numbers which
have not been converted, as well as the lists of Rx services.  All of
these can be found at the old registrar page,
http://grand.central.org/numbers/index.html

Among other things, the page listing Rx services also describes
information about registering new services, and a set of service IDs
that are reserved on all ports, including service IDs which are reserved
for site-local use on all ports.

There is currently no range of RPC numbers reserved for site-local use.
However, the existing policy (documented in the old page for RXAFSCB and
intended to apply to all AFS-related services for which the registrar
manages the namespace), is as follows:


> Procedure numbers for the 'RXAFSCB_' interface are maintained by the
> AFS assigned numbers registrar. New procedure numbers will be assigned
> on request to anyone wishing to extend this interface. Requests should
> include the name and description of the new procedure, a declaration
> suitable for inclusion in the Rx interface description file, and a
> brief summary of what the new procedure does.


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


In any case, you're welcome to the two numbers you mentioned.  I'll
update the published registry just as soon as I figure out why afslog on
this machine is doing completely the wrong thing.  Probably because
someone's k_afslog() decided to be too damn clever about "guessing" what
service principal I meant instead of just using the standard one.

-- Jeff