On Tue, 01 Nov 2011 16:38:30 -0400 Jeffrey Hutzelman <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
