[AFS3-std] Second Draft of Standardisation Document
Simon Wilkinson
simon@sxw.org.uk
Tue, 26 Aug 2008 22:49:58 +0100
--Apple-Mail-2-962030222
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Attached is a second draft of my AFS standardisation proposal. I
believe I've updated it to reflect all of the discussions to date.
Comments, including expressions of support, highly welcome!
Cheers,
Simon.
--Apple-Mail-2-962030222
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
x-unix-mode=0644;
name=afs-standardisation.txt
Content-Disposition: attachment;
filename=afs-standardisation.txt
AFS S. Wilkinson
University of Edinburgh
August 26, 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 define an initial form for that body.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The proposed model . . . . . . . . . . . . . . . . . . . . . . 3
2.1. The Standardisation Group . . . . . . . . . . . . . . . . 3
2.2. Group Chairs . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Appointment Term . . . . . . . . . . . . . . . . . . . 4
2.2.2. Election procedure . . . . . . . . . . . . . . . . . . 4
2.2.3. Recall Procedure . . . . . . . . . . . . . . . . . . . 5
2.3. The Standardisation Process . . . . . . . . . . . . . . . 5
2.3.1. Drafts . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. The Registrar . . . . . . . . . . . . . . . . . . . . 8
2.3.3. Document States and Series . . . . . . . . . . . . . . 9
2.3.4. Decision making and consensus . . . . . . . . . . . . 9
2.4. Patents . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Relationship with the foundation . . . . . . . . . . . . . 10
3. Bootstrapping the Process . . . . . . . . . . . . . . . . . . 10
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Wilkinson [Page 1]
=0C
Options for AFS Standardisation August 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-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.
Wilkinson [Page 2]
=0C
Options for AFS Standardisation August 2008
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.
2. The proposed model
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 [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-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.
Wilkinson [Page 3]
=0C
Options for AFS Standardisation August 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
o Judgement of group opinion by determining rough consensus
o Encouraging momentum and forwards progress of group discussions
and proposals
o 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 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.
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 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. Votes are
submitted by email to both of the incumbent chairs. The chairs shall
make no public pronouncements regarding the number or character of
Wilkinson [Page 4]
=0C
Options for AFS Standardisation August 2008
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
o The new chair must take office on 1st October
o The eligibility cut-off must be 1st July
o The nominations period must last a minimum of 14 days
o The voting period must last a minimum of 14 days
o 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-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.
2.3. The Standardisation Process
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
Wilkinson [Page 5]
=0C
Options for AFS Standardisation August 2008
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
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.
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.
2.3.1.1. Copyright
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.
Wilkinson [Page 6]
=0C
Options for AFS Standardisation August 2008
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 portionthereof 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
Wilkinson [Page 7]
=0C
Options for AFS Standardisation August 2008
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
2.3.2. The Registrar
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 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.
Wilkinson [Page 8]
=0C
Options for AFS Standardisation August 2008
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. (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.
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.
Wilkinson [Page 9]
=0C
Options for AFS Standardisation August 2008
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.
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,
<http://www.ietf.org/ietf/1id-guidelines.html>.
Wilkinson [Page 10]
=0C
Options for AFS Standardisation August 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 11]
=0C
--Apple-Mail-2-962030222--