Policy on Policy

1. Scope and Purpose

1.1 This policy documents and controls the process by which CAcert creates and promulgates policies.

1.2 The policy covers itself. The policy replaces prior ones. For Audit purposes, the policy is part of the Configuration-Control Specification ("CCS", DRC_A.1) and also documents part of the CCS.

1.3 The policies so created are generally binding on CAcert, registered users and related parties.

2. Basic Model

2.1 The basic concept is known as the IETF model, approximately following the mechanism of creating RFCs, in simplified form.

3. Procedure

3.1 An Editor is appointed. This person is responsible for drafting the document, following the consensus of the group.

3.2 A President may also be appointed or voted. This role resolves minor disputes and keeps order. The Editor acts as President in absence.

3.3 The policy mail group is used as the primary debating forum. A sub-group may be formed.

3.4 Decisions are taken by "Rough Consensus." A vote may be called to clarify.

3.5 Documents start with the status of "Work-In-Progress" or WIP for short.

4. DRAFT status

4.1 On completion, a document moves to DRAFT status.

4.2 During DRAFT status, it is promulgated as a working DRAFT for use by the community.

4.3 As far as the community is concerned, the DRAFT is policy (this is a major difference to the IETF process). Challenges and concerns can be addressed to the policy group, and those parts are not policy until addressed.

4.4 Revisions of DRAFTs may be called for by any convenient means.

4.5 The period of the DRAFT status is announced widely, which should be at least a month and no longer than a year.

5. POLICY status

5.1 After DRAFT period has elapsed with no revision beyond minor and editorial changes, the document moves from DRAFT to POLICY status.

5.2 Once POLICY, the community may only challenge the document in dispute resolution.

5.3 Policy group may propose changes to a POLICY document in order to update it. When changes move to DRAFT status, they may be included in the POLICY document, but must be clearly indicated within as DRAFT not POLICY.

6. Open Process

6.1 All policy discussions and documents should be open processes. There should be a fair chance for all to have their views heard. Rough Consensus is the working metric.

6.2 Contributions are transferred to copyright CAcert Inc, and/or are issued and contributed under free, open, non-restrictive, and clear licence. 'Contributions' includes Intellectual Property assets.

6.3 Contributors clearly mark any contributions that may be covered by restrictions to the extent of their knowledge. Impacted contributions must be avoided. Contributors declare any conflicts of interest.

6.4 Policies should be issued under free, open, non-restrictive and clear licence by CAcert, Inc.

6.5 Mailing lists should be archived, and important meetings should be minuted and published.

6.6 Security Officer may propose a closed process and document. This should only be granted with deep skepticism.

7. Disputes.

7.1 Any questions not resolved by these rules can be (1) referenced back to precedence created in past policies, or (2) may be voted on in forum, or (3) may be dealt with in dispute resolution.

7.2 The President may decide a tight vote in a minor matter only. Failure of Rough Consensus may be declared by dissenting members.

7.3 Matters unresolved refer back to further group discussion.

7.4 The external avenue for disputes is to file a dispute according to CAcert's Rules of Dispute Resolution. An independent arbitrator is appointed and will hear the case and rule. As with other disputes, the Arbitrator's ruling is binding.

7.5 No other avenue is available.