> > The interesting thing here is that this approach pretty much makes > all > > of the unused or spare protocol fields unusable. I can completely see > > the justification for it, but it does significantly reduce our > > flexibility, both now and in the future. > > Yeah, I was thinking of that, and that may be too strong. We may want > to apply the strong version only with protocol fields that we know > people have been using.
Which could start an IPv4 address space land rush (sorry, wrong list, but somewhat relevant). If "the first person there" wins, there is actually an incentive to get there first (and (re)use the field) and then declare ownership. > It occurs to me that if we know of unused and spare fields that we're > pretty sure no one is using, we should try to make a really loud noise > about how we're reserving them for *only* protocol changes that come > out of this working group so that we can hang on to them. A (documentation) change for un(der)used fields or bits to names with comments such as "Reserved for allocation by afs3-std only", would seem to be a good idea. It is about as loud as one can be. _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
