[AFS3-std] Third draft of standardisation document
Simon Wilkinson
simon@sxw.org.uk
Mon, 22 Sep 2008 11:51:31 +0100
--Apple-Mail-1--1039644371
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
I've let this slide a little, but now that the recent round of debate
seems to have concluded, here's a third draft of the standardisation
document.
Significant changes in this draft are:
*) Give vote-takers a casting vote in the event of a tie
*) Clarify that vote-takers who are eligible may also vote
*) Explicitly empower the registrars to establish a removal
mechanism.
*) Explicitly empower the registrars to set the size of the group.
*) Remove mention of the "current registrar", which is meaningful
only
during initial bootstrapping.
*) Remove ex officio membership of chairs in the registrar pool.
*) Provide a way to recover from all of the registrars disappearing.
*) Insure registry source is available if someone else has to take
over.
*) Clarify who may nominate and second (any eligible voter)
*) Clarify who is eligible to be nominated (anyone)
*) Rule out self-nomination
*) Add language about mid-term vacancies
*) Get chairs to mail list of eligible voters
*) Make it clear that providing bootstrap registrars is optional
I believe that this takes care of all open issues.
The only thing I'm not sure we reached consensus on is the question
of self-nomination. I received a couple of private comments
indicating that self-nomination was probably a bad thing - if anyone
else feels strongly about this, please say so here, and we can have a
discussion on the list!
S.
--Apple-Mail-1--1039644371
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
September 22, 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. Mid-term vacancies . . . . . . . . . . . . . . . . . . 5
2.2.4. Recall Procedure . . . . . . . . . . . . . . . . . . . 6
2.3. The Standardisation Process . . . . . . . . . . . . . . . 6
2.3.1. Drafts . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. The Registrar . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Document States and Series . . . . . . . . . . . . . . 10
2.3.4. Decision making and consensus . . . . . . . . . . . . 10
2.4. Patents . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Relationship with the foundation . . . . . . . . . . . . . 11
3. Bootstrapping the Process . . . . . . . . . . . . . . . . . . 11
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Wilkinson [Page 1]
=0C
Options for AFS Standardisation September 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 September 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 September 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 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
Wilkinson [Page 4]
=0C
Options for AFS Standardisation September 2008
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
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. Mid-term vacancies
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
Wilkinson [Page 5]
=0C
Options for AFS Standardisation September 2008
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.
2.2.4. 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
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.
Wilkinson [Page 6]
=0C
Options for AFS Standardisation September 2008
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 7]
=0C
Options for AFS Standardisation September 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 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
Wilkinson [Page 8]
=0C
Options for AFS Standardisation September 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.
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
Wilkinson [Page 9]
=0C
Options for AFS Standardisation September 2008
available to the community, including versions in the preferred
source form.
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 10]
=0C
Options for AFS Standardisation September 2008
2.4. Patents
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.
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 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.
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 11]
=0C
Options for AFS Standardisation September 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 12]
=0C
--Apple-Mail-1--1039644371
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
--Apple-Mail-1--1039644371--