| TOC |
|
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 define an initial form for that body.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on December 17, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
1.
Introduction
2.
The proposed model
2.1.
The Standardisation Group
2.2.
Group Chairs
2.2.1.
Appointment Term
2.2.2.
Election procedure
2.2.3.
Mid-term vacancies
2.2.4.
Recall Procedure
2.3.
The Standardisation Process
2.3.1.
Drafts
2.3.2.
The Registrar
2.3.3.
Document States and Series
2.3.4.
Decision making and consensus
2.4.
Patents
2.5.
Relationship with the foundation
3.
Bootstrapping the Process
4.
Security Considerations
5.
IANA Considerations
6.
References
§
Author's Address
| TOC |
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:
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-standardization@grand.central.org 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 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 devote 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.
| TOC |
This section proposes a model for AFS standardisation, designed to build upon as many existing resources as possible. It is loosely based on, and borrows heavily upon, the IETF processes as documented in RFC2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [RFC2026] and http://ietf.org/IESG/content/procdocs.html.
| TOC |
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-standardization@grand.central.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.
| TOC |
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
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 need 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.
| TOC |
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.
| TOC |
Chairs are appointed by an election run by one or more vote-takers. In normal operation, the vote-takers are the current standardisation group chairs. In the event that no chair is available to act as a vote-taker, then the registrars will perform the vote-taking role. If a vote-taker wishes to stand in an election, they must recuse themselves from the vote-taking role. Vote-takers who are also eligible voters may vote in the same manner as any other voter.
At the start of the election process (typically the first of August each year) the vote-takers send the mailing list a request for nominations, accompanied by a list of currently eligible voters
Eligibility to vote is determined by those who are subscribed to, or have posted to, the standardisation group during the time period from the 1st of June to the 1st July of the appropriate year.
Nominations shall be sent to both the vote-takers, and the afs3-standardization mailing list. Any consenting individual may be nominated, but shall be both proposed and seconded by eligible voters. Self-nomination is not permitted. 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 vote-takers will issue a call for votes, which will last for 14 days. In the event of no eligible nominations being received, the vote-takers 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
Votes are submitted by email to all of the vote-takers. The vote-takers shall make no public pronouncements regarding the number or character of votes received until the end of the election period. At the end of the election, each vote-taker 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. If voting is tied, then the vote-takers shall collectively have a single casting vote.
At their discretion, the vote-takers may vary the above timeline, within the following constraints
The timeline to be used must be announced with the call for nominations.
| TOC |
In the event of the outgoing chair position becoming vacant on or after June 1, but before October 1, then the office will remain vacant until it is filled by the winner of the regular election
If the returning chair position becomes vacant after June 1, but before the start of nominations for the regular election, then the election will select two candidates, with the returning chair's position being filled by the candidate with the second highest number of votes.
If the returning chair's position becomes vacant between the opening of nominations, and the conclusion of the election, then the office remains vacant during the election, and the incoming chair shall hold a new election as soon as practical after taking office.
In the event of any chair's position becoming vacant at any other time, the remaining chair (or the registrars, in the event of no chair remaining) shall run an election as soon as is reasonably practicable.
When the election process must be started at an unusual time, the normal timeline is used, subject to the vote-taker's discretion, except that the new chair must take office two months after the call for nominations. The eligibility cut-off remains the most recent July 1, as defined above.
| TOC |
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-standardization 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.
| TOC |
The standardisation process is similar to 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 developers proceed to create implementations. The document may then be further refined based on the experience of these implementors. Providing one successful implementation exists, and the group achieves 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.
| TOC |
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 (Fenner (for the IESG), B., “I-D Guidelines,” February 2008.) [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.
Proposals are submitted by adding the draft to the Internet-Drafts Directory, and mailing a pointer to the resulting entry to the afs3-standardization 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.
| TOC |
All drafts published through the I-D and RFC Editor process must already license certain rights to the IETF, as described in section 4 of BCP 78. Documents published as part of the AFS standardisation process must also grant certain additional licenses, and include the following copyright statement.
Copyright (C) <author(s)> (year).
By submitting this Internet-Draft, I accept the provisions of
Section 4 of BCP 78.
In addition, by submitting this Internet-Draft, to the extent that
this Internet-Draft or any portion thereof is protected by copyright
and other rights of authorship, the Contributor, and each named
co-Contributor, and the organization he or she represents or is
sponsored by (if any) grant a perpetual, irrevocable, non-exclusive,
royalty-free, world-wide right and license to any and all persons
under all intellectual property rights in this Internet-Draft:
(A) to copy, publish, display, and distribute this Internet-Draft,
(B) to prepare or allow the preparation of translations of this
Internet-Draft into languages other than English,
(C) to prepare and distribute derivative works (other than
translations) that are based on or incorporate all or part of
this Internet-Draft, or comment upon it, the license to such
derivative works not granting to any party any more rights than
the license to this Internet-Draft,
(D) to reproduce any trademarks, service marks, or trade names
which are included in this Internet-Draft solely in connection
with the reproduction, distribution, or publication of this
Internet-Draft and derivative works thereof as permitted by
this paragraph and/or by section 4 of BCP 78, and
(E) to extract, copy, publish, display, distribute, modify, and
incorporate into other works, for any purpose, any executable
code or code fragments that are included in this Internet-Draft,
it being understood that the licenses granted under this
paragraph (E) shall not be deemed to grant any right under any
patent, patent application, or other similar intellectual
property right disclosed by me.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
The above text may be directly incorporated into the Copyright section of the document, or by incorporating a reference to this document.
Copyright (C) <author(s)> (year). By submitting this Internet-Draft, I accept the provisions of Section 4 of BCP 78, and of Section 2.3.1.1 of the AFS standardisation document
| TOC |
The registrar maintains a register of protocol constants for the AFS protocols. A number of registries already exist for 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 available, and to allocate entries as required.
Unlike the rest of the systems outlined in this document, the AFS community 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 serve 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.
The registrars set their own procedures for adding new registrars, removing registrars, and determining the size of the group. In the event there are no registrars, a new group will be formed consisting of one representative from each active AFS implementation and one representative chosen by the chairs.
The registries themselves will be held as a set of collaboratively editable documents, to which all of the registrars will have equal access. The registrars must make the current set of registries available to the community, including versions in the preferred source form.
| TOC |
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. (Private extensions may also have code points, but as these are not part of the standardisation process, we won't consider them further here)
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 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.
| TOC |
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.
| TOC |
The use of the Internet-Draft 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.
| TOC |
The day to day operation of the standardisation group is independent of the foundation.
| TOC |
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 all of the currently available AFS implementations (IBM, OpenAFS, kAFS and Arla) who wish to participate.
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.
| TOC |
As this memo describes a process, rather than a protocol, no security considerations are raised by its contents.
| TOC |
This memo includes no request to IANA.
| TOC |
| [RFC2026] | Bradner, S., “The Internet Standards Process -- Revision 3,” BCP 9, RFC 2026, October 1996 (TXT). |
| [RFC3979] | Bradner, S., “Intellectual Property Rights in IETF Technology,” BCP 79, RFC 3979, March 2005 (TXT). |
| [ID-Guide] | Fenner (for the IESG), B., “I-D Guidelines,” February 2008 (HTML). |
| TOC |
| Simon Wilkinson | |
| School of Informatics, University of Edinburgh | |
| Informatics Forum | |
| 10 Crichton Street | |
| Edinburgh EH8 9AB | |
| Scotland | |
| Email: | sxw@inf.ed.ac.uk |