[AFS3-std] (no subject)
Simon Wilkinson
afs3-standardization@grand.central.org
Tue, 15 Jul 2008 17:57:27 +0100
--Apple-Mail-13--536836996
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
A recurring issue that came to a head at this years AFS Best
Practices Workshop is how we manage the standardisation of extensions
to the protocol.
The attached document outlines a possible, formal, standardisation
process for AFS extensions. None of it is set in stone, and your
comments are greatly appreciated. Comments can be made either
directly to me, or on the afs3-standardization@openafs.org list, to
which replies are directed.
If you're interested in the future development of AFS, please take
the time to review and comment upon the document.
Thanks,
Simon.
--Apple-Mail-13--536836996
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
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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]
=0C
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,
<http://www.ietf.org/ietf/1id-guidelines.html>.
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]
=0C
--Apple-Mail-13--536836996--