[AFS3-std] RxOSD claim on 2 structure members

[Simon Wilkinson]

On 11 Jun 2009, at 20:18, David Boyes wrote:

>> If we know of existing widespread use, that's a different matter.  It
>> might not be if we'd had an active AFS standardization process that
>> those users should have come to and didn't, but we had no
>> standardization process apart from what Jeff was maintaining on grand
>> (which I don't believe covers this area).  I don't think it's okay to
>> punish people for not following a non-existent process.  We're the  
>> ones
>> who didn't provide a way for them to reserve a field, so we should  
>> take
>> the lumps and be the ones to provide a backward-compatible way  
>> forward.
>
> So mark the ones you know of as "used by differing parties" and give  
> the folks who want a new field a new one so things can actually  
> progress.

It's the lack of 'a new one' that is the issue. There are no free  
fields in the RPCs we are interested in once you discard those fields  
that are 'used by differing parties'.

> If they step on each other, there is then a process to get a new  
> permanent place, and the onus is on the conflicting users with local  
> hacks to clean up their act and move their bits to the permanent  
> place. Let's get the problem under control, and move on. Registries  
> aren't rocket science.

And we have a proposal that was discussed last year that includes  
consolidating and expanding the work that's been done by the  
grand.central.org registrar.

That proposal requires that RPC changes (which in effect this is, as  
it changes the semantics of a particular field) go through a  
standardisation process that we're just getting off the ground. In the  
future this means that there will be an avenue for those who wish to  
register an unused field for their own use to do so. However, the  
future isn't the issue - it's the past we have to contend with. For  
many years, there has been a free for all on the unused fields and  
bits in the AFS protocol. This means that any use of them has to be  
carefully considered. I suspect that our only way forwards is going to  
be to (as David H. suggests) revise the protocol, and then make very  
clear that unused fields are not 'spare', but 'reserved'.

It's not hard to make new RPCs. We need to strike a balance between  
not requiring clients and servers support 20 different versions of  
each procedure, and the problem of standardising the kitchen sink.

I would like to propose the following (which is similar to what  
Jeffrey has already stated, but with some timescales)

*) Authors of protocol enhancements or changes which affect existing  
RPCs should send rough descriptions of those enhancements to this  
list, including a list of affected RPCs. This should include details  
of client and server behaviour if the new RPCs are implemented before  
the necessary backend features are available on the client or server.  
People wishing to be considered for this round of modifications should  
aim to make these proposals within the next month.

*) From this a list of those RPCs which we intend on revising will be  
published, with a final request for those wishing to amend those RPCs  
to comment. Following this a detailed specification of each of the new  
RPCs will be produced. This process would ideally be complete by the  
end of August.

*) We aim to reach consensus by the end of September, allowing the new  
RPCs to be implemented by developers from that point on.

*) There is a moratorium on further changes to RPCs which we have  
revised for at least one calendar year, unless exceptional grounds are  
presented to the standardisation group (and "Sorry, I missed the  
deadline for inclusion" is not exceptional)

Comments?

S.