[AFS3-std] Standardization of the AFS3 protocol

[Jeffrey Altman]

AFS3 is not a standardized protocol in the sense of those which follow
the IETF processes.   There are many reasons for this which at the
current time are primarily historical.  If we wanted to standardize AFS3
within IETF today we would have to document RX and all of the existing
RPCs used by the various servers.   Regardless of standardization,
documenting the existing protocols would be a huge quantity of work and
we simply do not have the human resources to accomplish it.

However, this does not mean that developers can go off willy nilly
making changes to RX, adding new service RPCs or altering the behavior
of existing service RPCs.  There needs to be a process setup by which
a rough consensus can be achieved on proposed changes in a forum that
will be archived so that crucial knowledge will not be lost.

Preferably we will also be able to start a documentation process that
will include the new work that is agreed to.  As OpenAFS maintains both
a server and multiple client implementations and the OpenAFS Elders
include technical representation from IBM Pittsburgh Labs it has been
concluded by the Elders that OpenAFS would be the best place for such
standardization work to be done.

The afs3-standardization@openafs.org mailing list has been created to
be the discussion forum.  At the present time a web interface for
subscribing can be found at

http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization

There are several outstanding work efforts that should be discussed on
this new list:

* RXGK

* RX/TCP

* Addition of GetCapabilities RPCs to all services, the assignment of
  bit flag values on a per-service basis, interaction of GetCapabilities
  with Delayed Callback Breaks, and whether "capabilities" can also
  include policy hints for clients.

* Extensions to the file server SetLock RPC to support LockUpgrade and
  LockDowngrade.

* Extensions to the Protection Server RPCs to support multiple user
  names per AFS ID.

and these are just the ones that I believe are pressing issues.  If you
are not currently a member of afs3-standardization, please join.
Tomorrow I will start postings on each item listed above in order to
begin the process of obtaining rough consensus on the last three items
in the list.

Jeffrey Altman


The following discussion took place on afs3-protocol@stacken.kth.se.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3288 bytes
Desc: S/MIME Cryptographic Signature
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20060222/33eee119/smime.bin