[OpenAFS] (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--