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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
