AFS S. Wilkinson University of Edinburgh July 15, 2008 Options for AFS Standardisation Abstract With the impending formation of the foundation to house OpenAFS, the increasing pace of OpenAFS development, and the emergence of other AFS implementations, there is a growing need for a more formal, independent, standardisation body. This document seeks to provoke debate as the form that such a body should take. Wilkinson [Page 1] Options for AFS Standardisation July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A possible model . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Standardisation Group . . . . . . . . . . . . . . . . 4 2.2. Group Chairs . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Appointment Term . . . . . . . . . . . . . . . . . . . 5 2.2.2. Election procedure . . . . . . . . . . . . . . . . . . 5 2.2.3. Recall Procedure . . . . . . . . . . . . . . . . . . . 6 2.3. The Standardisation Process . . . . . . . . . . . . . . . 6 2.3.1. Drafts . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2. The Registrar . . . . . . . . . . . . . . . . . . . . 7 2.3.3. Document States and Series . . . . . . . . . . . . . . 8 2.3.4. Decision making and consensus . . . . . . . . . . . . 9 2.4. Patents . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Relationship with the foundation . . . . . . . . . . . . . 9 3. Bootstrapping the Process . . . . . . . . . . . . . . . . . . 10 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Wilkinson [Page 2] Options for AFS Standardisation July 2008 1. Introduction The formation of a foundation to provide a home for OpenAFS was announced at the Best Practices Workshop at NJIT in 2008. At that meeting, concerns were raised regarding the mechanism for standardising extensions to the AFS protocol. In particular, the view was expressed that, as a matter of good governance, it was undesirable to have the standardisation of the protocol in the grasp of a single vendor. This document defines a standardisation process that is practically independent of this foundation. At this time there are insufficient resources, both human and financial, to create a separate legal entity to house the standards work. It is also apparent that standardising extensions to the AFS protocol is unlikely to be a good fit for any other, existing, standards organisation. This means that the body must exist, for legal purposes, as part of the foundation, and mechanisms must be found to ensure its day-to-day independence within it. These mechanisms should sufficiently encapsulate the standards process so it is possible to either donate it to another standards body, or to spin it off into its own foundation, should this be desirable at some future point. Retaining this independence sets us a number of simple ground rules: 1. It must be impossible for the foundation to use its position to standardise its ideas against the wishes of the community, or to prevent the standardisation of items approved by the community. 2. It must be impossible for the foundation to control the distribution, or implementation, of standards developed by the group 3. It must be impossible for the foundation to prevent the membership of the group by any person or organisation. 4. Should an irreparable breakdown of trust occur between the standardisation group and the foundation, it must be possible to move the standardisation effort elsewhere. Until recently, standardisation of extensions to AFS has occurred in a relatively adhoc fashion, with informal proposals generally being sent to and discussed on the afs3-standardisation list. The issuing of code points, and other numeric registrations is then handled by the grand.central.org registrar (Jeffrey Hutzelman). This process has only been in place for a couple of years - extensions which predate it lack formal specification, and extensions which have been through it are often only documented in the mailing list archives. This lack of specifications for many recent additions to AFS causes significant issues for implementers outside of the OpenAFS project. In order to preserve the ability of third parties to create their own Wilkinson [Page 3] Options for AFS Standardisation July 2008 AFS implementations, it is vital that there is a clear set of definitions of AFS RPCs and code points that is independent of the OpenAFS source code. Any successful standardisation process must establish, and maintain, a repository of specifications for all public extensions and refinements whoever they are designed and implemented by. To achieve this the process must allow participation by all, without regard for their organisational affiliation, so anyone with an interest in the development of the AFS protocol may contribute ideas and proposals. It would seem unwise to devoted a large amount of energy now in defining rules and procedures to cater for all eventualities. Instead, I believe we should do the minimum necessary work in order to formally create a standardisation group satisfying the above goals to coincide with the formation of the foundation. That group may then further define and refine its policies as it deems necessary. 2. A possible model This section discusses a possible model for AFS standardisation, designed to build upon as many existing resources as possible. It is loosely based on, and builds heavily upon, the IETF processes as documented in RFC2026 [RFC2026] and http://ietf.org/IESG/content/procdocs.html. 2.1. The Standardisation Group The standardisation group consists of a mailing list. Membership of this mailing list is freely open to all with an interest in AFS standardisation. The list of mailing list members is freely available to all subscribers, and defines the membership of the AFS Standardisation Group. Discussions amongst the group are expected to occur upon this mailing list. In order to ensure open participation decisions of the group must only be made on the list, and not at any other meetings that may occur. In essence, this simply formalises the existing afs3-standardisation@openafs.org mailing list. It is proposed that this list be the initial home of the standardisation group, and its current membership be the initial members of the group. Wilkinson [Page 4] Options for AFS Standardisation July 2008 2.2. Group Chairs The standardisation group has two chairs. These chairs have a number of responsibilities to the group, and the wider AFS community. These responsibilities are discussed throughout this document, but in summary they comprise of Judgement of group opinion by determining rough consensus Encouraging momentum and forwards progress of group discussions and proposals Maintenance of the Standards Web site, including maintaining lists of proposals and standards and their statuses A successful chair will require a high level of organisational and people skills, and the respect of the wider AFS community. They will not necessarily require a high degree of specific technical knowledge, as they are expected to interpret and act upon the will of the wider standardisation group, rather than imposing their personal views upon the group. 2.2.1. Appointment Term Each chair serves a term of 2 years, with their terms offset by a year from each other. This means a chair will be replaced every year, with the other chair remaining to provide continuity. The outgoing chair's term ends on the last day of September of the appropriate year. 2.2.2. Election procedure Chairs are appointed by election. On the first day of August each year the current chairs send the mailing list a request for nominations. Each nomination must be accompanied by a proposer and seconder. In order to maintain balance between the two chairs, it is highly desirable that a candidate should not have the same affiliation as the remaining chair. Nominations are open for 14 days from the day the call is issued. Seven days after the nomination period has ended, if more than one candidate has emerged, the chairs will issue a call for votes, which will last for 14 days. In the event of no eligible nominations being received, the chairs may, at their discretion appoint an interim candidate to serve the full term. The results of the election would be announced one week after the close of voting, with the new chair taking office from the 1st October Eligibility to vote is determined by membership of the standardisation group on the 1st of July of the appropriate year. Votes are submitted by email to both of the incumbent chairs. The chairs shall make no public pronouncements regarding the number or Wilkinson [Page 5] Options for AFS Standardisation July 2008 character of votes received until the end of the election period. At the end of the election, each chair shall independently count the votes received and post to the group list the total number of votes received by each candidate, and the email addresses of all those who voted. Under no circumstances shall the nature of individual votes be revealed. The candidate who receives the most votes is elected as the incoming chair. In the event of there being no chairs available to perform vote counting duties, the election shall be run by the registrars. Anyone, be it chair or registrar, who is standing for election should not be a vote counter. At their discretion, the chairs may vary the above timeline, within the following constraints The new chair must take office on 1st October The eligibility cut-off must be 1st July The nominations period must last a minimum of 14 days The voting period must last a minimum of 14 days Results must be announced within 7 days of the close of voting The timeline to be used must be announced with the call for nominations. 2.2.3. Recall Procedure In the event of a substantial breakdown of trust between the chairs and the rest of the standardisation group, a recall procedure may be employed to remove one, or both, of the chairs from their position. The use of this procedure is likely to be severely damaging to the community, and so should only be considered as a last resort. Recall shall be performed by means of a public ballot. The proposers of the recall shall post their proposal to the afs3-standardisation list, which triggers a 7 day public voting period. Group members then publicly post to the list indicating their agreement or disagreement with the proposal. A successful recall requires a majority of those posting to agree, and for more than 20% of the groups total membership to have voted. 2.3. The Standardisation Process The standardisation process is similar that of an IETF working group with proposals being submitted as drafts and refined by group members. When a document is judged to be ready the chairs issue a call for opinions and determine the views of the group. If the chairs determine that the group has achieved a rough consensus that the document should be approved then it advances to experimental status, code points are issued for the protocol elements, and Wilkinson [Page 6] Options for AFS Standardisation July 2008 developers proceed to create implementations. The document may then be further refined based on the experience of these implementers. Providing one successful implementation exists, and the group acheives rough consensus that it is still worthy of standardisation, the document then advances to 'standard' status, reserved code points are marked as such, and it is published as part of an archival series. 2.3.1. Drafts Proposals for standardisation are made as Internet Drafts. These documents must be compliant with all of the provisions of the IETF's Guidelines to Authors of Internet Drafts [ID-Guide] and the documents it references. Note that it is not permissible for documents that wish to progress through the AFS standardisation process to prohibit modification or derivative works, or to bar publication as an RFC. Drafts should be named as individual contributions, and contain the string afs3-stds within their name. Note that publishing drafts in this way assigns copyright of the document text to the IETF Trust. This avoids the issue of not having an umbrella organisation for AFS that may hold these copyrights. Proposals are submitted by adding the draft to the Internet-Drafts Directory, and mailing a pointer to the resulting entry to the afs3- standardisation list. During the quiet periods prior to IETF conferences, drafts may be sent directly to the list, but should be uploaded once the quiet period ends. Drafts which define new RPCs must include suitable RPCL definitions for those RPCs. Drafts must not include code points for new RPCs, error codes, or similar items, until those code points have been issued by the registrars. The registrars will not normally allocate these code points to a standardisation group document until a draft has achieved consensus within the group. The group chairs will maintain a web page containing a list of all of the drafts currently under consideration by the group. These will simply be pointers into the I-D repository - our drafts will have the same 6 month expiry period. 2.3.2. The Registrar The registrar maintains a register of protocol constants for the AFS protocols. A number of registries already exist as a function of the core AFS protocols, and additional registries may be added as required by extensions to the protocol. The registrar's function is to maintain these lists for the community - to make them publicly Wilkinson [Page 7] Options for AFS Standardisation July 2008 available, and to allocate entries as required. Unlike the rest of the systems outlined in this document, the AFS has had the benefit of the services of a volunteer registrar for a number of years. What follows proposes changes in order to formalise the relationship between registrar and standardisation group, and to deal with single points of failure. The registrar would allocate protocol constants on demand. These registrations may be for 'experimental' items, 'standard' items, or for private extensions. Both experimental and standard items are allocated by documents advancing through our standardisation process. Private extensions would be allocated entries upon request. Private extensions do not require public documentation. In addition to these allocation roles, the registrar will serves as a vote counter of last resort, for chair elections where no incumbent chair is available to perform the count. This combination of roles makes it difficult for a single individual to serve as registrar. Instead, it is proposed to expand the role of registrar to include a number of individuals from the community This group of people would include the current registrar, the current standardisation group chairs, and a number of private individuals. The registrars may determine that set of individuals themselves - appointing additional registrars as required. The registers themselves will be held as a set of collaboratively editable documents, to which all of the registrars will have equal access. In the first instance, the repository for these documents will be provided by the foundation. 2.3.3. Document States and Series Documents may be either a draft, experimental, or a standard. Advancing between these states requires the consensus of the standardisation group, and only experimental and standard items may have protocol code points assigned to them. For a document to advance to 'standard', at least one implementation must exist of all of the protocol elements defined within the document - these implementations do not have to all be within the same product. As noted earlier, the group chairs are responsible for maintaining lists of documents at each of these stages. Draft documents are held within the IETF's Internet Drafts repository, as are experimental documents. It is the responsibility of the group chairs to ensure Wilkinson [Page 8] Options for AFS Standardisation July 2008 that experimental documents which are still being actively worked upon are kept current within the internet draft collection. The intention is that standard documents will be submitted by their authors to the RFC-Editor as an individual submission. Upon successful completion of the RFC-Editor process, the resulting RFCs should be linked to by the group chairs, and referenced by the relevant registries. Whilst this usage appears consistent with the individual submission process, it needs to be confirmed that the RFC Editor is happy with this. 2.3.4. Decision making and consensus Decisions of the standardisation group are achieved by rough consensus, as determined by the group chairs. It should be noted that, beyond determining consensus, the chairs have no veto or casting vote. In fact, they should be careful to avoid their own personal beliefs interfering when judging the opinion of the group. For document actions, the document authors request that the chair determine whether there is consensus within the group. The chair issues a consensus call, with a clear cut off point (typically 1 week) during which group participants are invited to review the document, and express their opinions both for and against. At the end of this period, the chair should have amassed sufficient information to determine whether there is a rough consensus for the document to advance. 2.4. Patents The use of the I-D process, and of the RFC Editor Individual Submissions process for document publishing, means that the terms of BCP-79 apply with respect to patent notification. 2.5. Relationship with the foundation The day to day operation of the standardisation group is independent of the foundation. However, the foundation provides certain services to the group. These services are such that they could easily be transferred to a third party should that be required. Hosting of the standardisation group mailing list Hosting of the standardisation group web pages Hosting of the registrar's web pages Hosting of the registrar's document editing system Once the foundation is in existence we should obtain an agreement that they own no copyright in any of that data, that they will not discontinue providing those services without reasonable notice, and Wilkinson [Page 9] Options for AFS Standardisation July 2008 that they will supply all data necessary to allow a 3rd party to host those services. 3. Bootstrapping the Process Should the proposals in this document be accepted, we need to consider how to bootstrap the process. I propose that once consensus has been reached on this document, we elect two chairs in the manner described above, with a start date to be determined. The chair with the lower number of votes would serve a 1 year term, the chair with the higher number, 2 years as normal. The registrars would be initially comprised of the current registrar, plus a representative from each of the currently available AFS implementations (IBM, OpenAFS, kAFS and Arla) A document describing the standardisation process would be the first task for the resulting group and would be used to pilot the entire document publishing process. 4. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [ID-Guide] Fenner (for the IESG), B., "I-D Guidelines", February 2008, . Author's Address Simon Wilkinson School of Informatics, University of Edinburgh Informatics Forum 10 Crichton Street Edinburgh EH8 9AB Scotland Email: sxw@inf.ed.ac.uk Wilkinson [Page 10]