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