BLUETOOTH DOC

Prepared

Date / Year-Month-Day

Approved

Revision

Document No

2003-12-17
e-mail address

0.91

8.C.999/0.8.0
N.B.

Jennifer Bray Errata Team Members

Confidential errata-manager@bluetooth.org

Bluetooth Errata Process

ERRATA PROCESS

Abstract This document outlines the Bluetooth SIG errata process. It covers correction of errors in the specification, it does not cover improvements or enhancements, it does not cover the process of processing test specification errata (although test specification updates are required for core specification errata) The selection, and duties of section owners are also covered

BLUETOOTH SIG CONFIDENTIAL Bluetooth SIG Errata Process

Page 2 of 37

Special Interest Group (SIG)

The following companies are representatives in the Bluetooth Special Interest Group: Agere Systems, Inc. 3Com Corporation Ericsson Technology Licensing AB IBM Corporation Intel Corporation Microsoft Corporation Motorola Corporation Nokia Mobile Phones Toshiba Corporation

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 3 of 37

Revision History
Revision 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Date 07.20.01 22 Aug 2001 28 Aug 2001 18 Sept 2001 19 Sept 2001 26 September 2001 26 November 2001 Comments First draft released for review and discussion. Updated after discussions in errata process group Updated state transitions and descriptions Updated after discussions with errata process group BARB & the Open Group Updated transition system after discussion in errata process group Added opengroups web requirements as an appendix Amended after BARB review Added section owners and reviewers duties, Renamed states, added notes on waivers, changed ESR review to 4 weeks. Changed voting to always require 2/3 for selection. Added handover from working groups. Added section owner notes, added interoperability & backwards compatibility fields. Added missing transition from Trivially accepted, clarified that errata affecting tests should not be trivially accepted. Amended response time for section owners to 2 weeks, (both changes approved by BOD in December 2001) Deleted section Errata Objects information amalgamated with section 3 Process for recording errata. Changed state names. Amended voting process. Added traceability requirement. Added qualifable field, and notes. Added notes on errata Service Release. Minor corrections Clarified runoff voting Corrected state transition diagram Made 6 month release spacing normal Updated after BARB review Removed implementation/qualification details Clarified handling of contradictory errata Removed comments on transition process Deleted reference to IPR review timing being as for new specification (Working group process allows different time for errata) Changed separation to put higher layer protocols with profiles (reflects planned structure of specifications) Added note that working groups can use errata process to keep people outside group informed of errata. Made default for working group toa dopt process version 1.0

0.75

28 January 2002 14th March 2002

0.8

0.85 0.9 0.91

16th April 2002 18th April 2002

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 4 of 37

Contributors
Stefan Agnani Thomas Baker Jennifer Bray Jon Inouye David Moore Thomas Muller Brian Redding Martin Roter Tom Siep Juergen Schnitzler Johan Sorensen BTI BARB BARB, Errata Program Manager BARB BARB BARB BQRB BTI Bluetooth SIG, Inc. Nokia BARB

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 5 of 37

DISCLAIMER AND COPYRIGHT NOTICE

THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Any liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. This document is for comment only and is subject to change without notice. Copyright 2002. Bluetooth SIG, Inc. *Other third-party brands and names are the property of their respective owners.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 6 of 37

Contents
Errata Process ................................................................................................ 1 Special Interest Group (SIG) ......................................................................... 2 Revision History ............................................................................................. 3 Contributors ................................................................................................... 4 Contents.......................................................................................................... 6 1 2 Introduction ......................................................................................... 7 1.1 Requirements ............................................................................. 7 Process for Handling Requests ......................................................... 8 2.1 State Definitions.......................................................................... 9 2.2 State Transitions ....................................................................... 13 Process for recording errata ............................................................ 21 3.2 Proposed draft solution ............................................................. 25 Process for discussing solutions .................................................... 26 4.2 Access restrictions .................................................................... 27 Process for Selecting Solutions ...................................................... 28 5.1 Voting process .......................................................................... 28 5.2 Form of votes............................................................................ 29 Handover from working groups to errata process ......................... 30 Test Specification Review and Update............................................ 31 Process for Releasing Errata ........................................................... 32 8.1 Errata Service Release (ESR) .................................................. 32 8.2 Review of errata service release candidate .............................. 33 8.3 Adoption into specification ........................................................ 34 Reviewers and voters ....................................................................... 35 Section Owners ................................................................................. 36

3 4 5

6 7 8

9 10

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 7 of 37

Introduction

This document describes the Bluetooth SIG Errata Process.

1.1

Requirements

The proposed errata process shall meet the following requirements: Companies should not be surprised when errata get adopted. Notice of proposed changes shall be open and accessible to ALL SIG members. Fair and timely processing of all errata requests. All errata should be processed using the same rules and not dependent on section manager choice. Distributed responsibility for proposing solutions. Section managers shall not be solely responsible for publishing proposed solutions. Well-defined description of system so the SIG management company can implement it. Transition plan from current system must be defined. No errata shall be adopted without respective test errata updates. Lets not keep making this mistake. Democratic process used as much as possible

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 8 of 37

Process for Handling Requests

Withdrawn

Postponed

A8

A9
Appeal Postponement

A5 A6 A7 B1 B2 B3 C2 C3 D4 D5 E2 E1

A
Requested

A3

Trivially Rejected

A4 A10

B
Draft Proposed

A1 A2
Trivially Accepted

Forwarded To Working Group

Alternative proposal generated

C1
Rejected

C
Voting in Progress

F2

D1

G3

D2 D3
Appeal to BARB

D
Recommended by voters

E
Test Specifications Review and Update

F
Test Specifications Updated

G
Errata Service Release Candidate

G1 G2

Voting on removal from ESR

H
Adopted

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 9 of 37

Note: states and transitions shown in gray in the diagram above are related to appeals and are only for use in exceptional circumstances.

2.1

State Definitions

Table 1: Errata States

Requested

The request has been submitted and assigned an identifier. Comments can be attached to the request at any time. Access: Any Bluetooth SIG member with an account and password can submit a request. The requester, any Bluetooth SIG associate and any Bluetooth SIG promoter with an account and password can attach a comment to the request.

Draft Proposed

At least one solution has been attached to the request. Comments can be attached to each proposal. Access: The requester, any Bluetooth SIG associate and any Bluetooth SIG promoter with an account and password can attach a proposal to the request, or attach a comment to each proposal.

Trivially Accepted

The proposal has been accepted by the section owner who believes there is no need for voting. For example this might happen with simple editorial changes to correct typing mistakes. (note the decision can be appealed). Errata which affect test specifications must not be trivially accepted. Clarifications may affect the interpretation of the specification and thus might affect test specifications, if there is any possibility that test specifications will be affected errata must

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 10 of 37

not be Trivially Accepted. If a reviewer or voter feels errata have been incorrectly trivially accepted they can appeal to the BARB. Trivially Rejected The proposal has been rejected by the section owner who believes there is no need for voting. For example this might happen if an errata duplicates an existing errata. Whenever the section owner rejects a proposal the reason for rejection must be recorded in the errata discussion. (note the decision can be appealed). Work is being carried out to move the errata to the Draft Proposed state. For example this may be because the errata highlights a problem to which there is no obvious solution, or because the solution is not phrased in a satisfactory way for incorporation in the specification. Any Bluetooth SIG member with an account and password can view the postponed errata, it will include a note on work to be done and a means of contacting the responsible person. See 4.1.1 Postponement Access: Entry into this state must be performed by the section manager or authorized personnel. Voting in Progress Solutions to the request are now in the selection stage of the process. For details of the voting process see section 5: Process for Selecting Solutions.

Postponed

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 11 of 37

Recommended by voters

A proposed draft solution to the problem identified in the request has been selected by vote.

Access: Entry into this state must be performed by the section manager or authorized personnel as a result of the voting process. Withdrawn The requester has withdrawn the request. Access: The original requester must ask the SO or errata manager to move the request into this state. Rejected The request has been rejected. Access: Entry into this state must be performed by the section manager or authorized personnel as a result of the voting process. Appeal Postponement An appeal has been made against postponement. This is most likely to happen if the requester believes that the erratum is ready for voting (for example because comments have been submitted which could be used as a proposed draft solution). This state provides a means for the requester to challenge the system if an erratum appears to be indefinitely postponed for no good reason. Access: Entry into this state must be performed by the section manager or authorized personnel as a result of a request by the requester, or any associate or promoter member of the Bluetooth SIG. The section owner or authorized personnel may not refuse to consider the appeal.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 12 of 37

Alternative Proposal Generated

The BARB has generated an alternative proposal as the result of an appeal. In the case of conflict with work in working groups this may simply be the original proposal with some explanation of the conflict. An Associate, promoter, or the requester of an errata believes that a vote was unfair or invalid for some reason and has appealed to the BARB to consider the case. An appeal might happen because a vote was not conducted correctly, because there was insufficient technical discussion so the erratum was not understood, or because the result of a vote conflicts with developments in working groups which were not visible to the voters.

Appealed to BARB

Test Specification Review and Update

The test specifications are being reviewed and updated if necessary. Note: The process of updating test specifications is not covered in this document.

Test Specification Updated

An erratum proposal has been selected and test specification updates are available. Access: the test specification section owner or authorized personnel move the erratum into this state

Errata Service Release Candidate

Groups of approved errata are released for interoperability testing as an errata service release. A problem has been reported with an erratum in an ESR. Voting is proceeding

Voting on removal from ESR

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 13 of 37

on whether to remove the erratum from the ESR before submitting the ESR for adoption. Adopted by the Board The erratum has been adopted as part of the Bluetooth specification.

2.2

State Transitions

Table 2: Errata State Transitions

A1 Requested to Trivially Accepted

The section owner may accept an erratum before voting if it is not deemed to merit a vote. For example it may be a simple correction of a typing mistake. (The rejection may be appealed see A2 below) Errata which affect test cases should not be trivially accepted.

A2 Trivially Accepted to Requested

Any Associate, Promoter, or the proposer of an erratum may appeal the A1 transition to Trivially accepted. This is done by contacting the section owner or errata manager. The erratum will then be returned to the Requested state, and may not be Trivially accepted again (it must proceed to a vote). The section owner may reject an errata before voting if it is not deemed to merit a vote. For example it may duplicate another erratum. (The rejection may be appealed see A4 below) When an errata is moved to the Trivially rejected state a reason for rejection must be attached to the errata.

A3 Requested to Trivially rejected

A4 Trivially Rejected to Requested

Any Associate, Promoter, or the proposer of an erratum may appeal the A3 transition to Trivially rejected. This is

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 14 of 37

done by contacting the section owner or errata manager. The erratum will then be returned to the Requested state, and may not be Trivially rejected again (it must proceed to a vote). A5 Requested to Withdrawn The proposer of an erratum may withdraw it by contacting the section owner or the errata manager. An erratum which is not in a suitable format for voting or which requires more coordination between groups, may be postponed temporarily by the section owner. See below for discussion. After four weeks, a postponed errata will automatically return to the Requested state.

A6 Requested to Postponed

A7 Postponed to Requested

A8 Postponed to Appeal Postponement If the proposer, an associate or a promoter believes that a postponed errata is ready to be voted upon, they may appeal to the section owner or errata manager. The errata manager or section owner must consider this appeal within two weeks, and either move the erratum in the Draft Proposed state (B1) or return it to the postponed state (A9). This appeal is intended to prevent errata being continuously postponed. A9 Appeal Postponement to Postponed If an Appeal of Postponement is unsuccessful the erratum is returned to the postponed state. The four week clock is unaffected by this appeal. A10 Requested to Forwarded to Working Group The errata process may be used to suggest improvements or enhancements to the specification. Any erratum which has the category field set to improvement will be forwarded to the relevant working group for consideration. It will not be processed through the normal errata system. The section owner is responsible for forwarding improvements to the

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 15 of 37

relevant working group.

B Requested to Draft Proposed

Any Requested proposal should be moved into the Draft Proposed state within two weeks of entering the Requested state. The two week clock starts on A (initial submission), restarts on A7 (returned from postponed state), but does not restart if the erratum was Trivially rejected or accepted and subsequently appealed. The section owner may move an erratum to the Draft Proposed state at any time during the two weeks If an erratum is not moved during the two weeks the Errata Program Manager (btem@bluetooth.org) is automatically notified so that the cause for delay can be investigated.

B1 Appeal Postponement to Draft Proposed

If an Appeal of Postponement is successful the erratum is moved to the Draft Proposed state, and the two week clock for discussion starts. The proposer or any reviewer may generate an alternative proposal. This is not a normal state transition: it creates a branch in the current erratum. The original erratum remains in the Draft Proposed state and continues to move towards voting, whilst the alternative proposal is processed in parallel. This is discussed below in 4.1.2 Handling of alternative proposals

B2 Draft Proposed to Alternate Proposal Generated

B3 Alternate Proposal Generated to Draft Proposed

When an alternate proposal is generated, it moves into the Draft Proposed state and the voting period may be extended by up to two weeks. It is then processed in parallel with the original erratum.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 16 of 37

See 4.1.2 Handling of alternative proposals C Draft Proposed to Voting in Progress This transition occurs automatically two weeks after the move to the Draft Proposed State. (these two weeks allow for discussion). Each alternative proposal has its own separate two week clock for discussion. C1 Rejected to Alternative Proposal Generated The proposer or any reviewer may generate an alternative proposal after the original proposal has been rejected. This may be created as a new erratum or as a continuation of the original errata thread, at the discretion of the section owner. This is discussed below in 4.1.2 Handling of alternative proposals C2 Voting in Progress to Alternative Proposal Generated The proposer or any reviewer may generate an alternative proposal. This is not a normal state transition: it creates a creates a branch in the current erratum. The original erratum remains in the Voting in Progress state and continues to be voted upon, whilst the alternative proposal is processed in parallel. This is discussed below in 4.1.2 Handling of alternative proposals C3 Voting in Progress to Rejected For details of the voting process see section 5: Process for Selecting Solutions. Any erratum in the Voting in Progress stage shall remain there for four weeks unless a decisive result has been reached before that time. After four weeks it may be moved to the Recommended by voters stage if it is selected by vote. For details of the voting process see

D Voting in Progress to Recommended by voters

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 17 of 37

section 5: Process for Selecting Solutions. D1 Appealed to BARB to Alternative Proposal Generated If the BARB agrees with an appeal it results in an alternative proposal being generated even after voting on all other proposals has closed. This allows for modification or clarification of misunderstood errata, and for alteration of errata which conflict with work being done in working groups which is not visible to voters. The BARB should record reasons for their agreement with the appeal in the errata record. See 4.1.2 Handling of alternative proposals D2 Rejected to Appealed to BARB If a reviewer or the proposer of an erratum considers that it has been incorrectly rejected, they may appeal to the BARB. Examples of grounds for appeal include invalid voting, misunderstanding of proposal, insufficient discussion of erratum, or proposed draft solution is required for work being done in working groups. If the BARB disagrees with the appeal, they may return the erratum to the Rejected state. If a reviewer or the proposer of an erratum considers that it has been incorrectly Recommended by Voters, they may appeal to the BARB. Examples of grounds for appeal include invalid voting, misunderstanding of proposal, insufficient discussion of erratum, or proposed draft solution conflicts with work being done in working groups. If the BARB disagrees with the appeal, they may return the erratum to the Recommended by voters state.

D3 Appealed to BARB to Rejected

D4 Recommended by voters to Appealed to BARB

D5 Appealed to BARB to Recommended by voters

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 18 of 37

E Recommended by voters to Test Specifications Review and Update

Once an erratum is Recommended by Voters, the test specifications must be reviewed and updated if necessary. Details of the test specification update process are not documented here. If the updaters of the test specification consider that the erratum has been incorrectly recommended, they may appeal to the BARB. Examples of grounds for appeal include difficultly in testing, or technical problems discovered which have not been discussed previously. If the BARB disagrees with the appeal (E1), they may return the erratum to the Test Specifications Review and Update state. Once the test specifications for the erratum are complete and approved by BTI, the erratum automatically moves to the Test Specifications Updated state. After two weeks in the trivially accepted state if an erratum is not appealed it moved to Test Specification Updated. Note that this bypasses test specification review and update therefore any errata which could alter test specifications in any way should not be trivially accepted. Errata which are in the Test Specification Updated state are grouped to form a candidate for an Errata Service Release (ESR) which is made available via a link from the errata web page. Section owners or other authorized personnel may optionally request that some approved errata are not included in a candidate for an ESR. For instance if a group of related errata belonged together, but the whole group are not yet approved it might make sense to

E1 Test Specifications Review and Update to Appealed to BARB

E2 Appealed to BARB to Test Specification Review and Update

F Test Specifications Review and Update to Test Specifications Updated

F2 Trivially accepted to Test Specification Updated

G - Test Specification Updated to Errata Service Release Candidate

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 19 of 37

postpone some errata for the next ESR. G1-Errata Service release Candidate to Voting on removal from ESR G2 - Voting on removal from ESR to Errata Service release Candidate If problems with an erratum in an ESR that erratum is moved to the Voting on removal from ESR state. If a vote of the relevant reviewers decides that problems reported on an erratum in an errata service release candidate do not merit its removal from the release then the erratum is returned to the Errata Service Release candidate If a vote of the relevant reviewers decides that problems reported on an erratum in an errata service release candidate merit its removal from the release the erratum is returned to the Requested state. A link to the description of the problems is added to its record, and it goes back through the errata process to see if it can be reworked to solve the problem, or whether it should be rejected. A minimum period of 4 weeks (28 calendar days) must elapse after an ESR is released before the BARB considers the ESR. If during this 4 week period any problems are reported on errata in the errata service release candidate, time must be allowed for Voting on removal from ESR before the ESR may be considered for adoption. The process of Adopting an ESR is described more fully below At the BARBs discretion several ESRs may be amalgamated for consideration together or for incorporation into a new specification release.

G3 - Voting on removal from ESR to Requested

H Errata Service Release Candidate to Adopted by the Board

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 20 of 37

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 21 of 37

Process for recording errata

Errata will be submitted on a web interface, this will include the following fields: ID A unique ID identifying this request and proposal. If there are several alternative proposals solving the same request each will carry its own ID, but they will be connected into a group by the Related Errata field. The ID will automatically be allocated when an erratum is first requested, new IDs are required for each proposal. Subject The subject covered by the erratum. This allows reviewers to identify errata & to pick out those of interest. Version of the Specification, including Draft ID Radar buttons which allow selection of all affected sections (some errata may cross multiple sections). In addition to categories for each section of the specifications there will be an other option, (the other category is most likely to be used for improvement suggestions which fall in an area not currently covered by the specification). Part Page Part of specification affected e.g. K1 Page number in specification document (note this is only meaningful in association with version number) Paragraph on page. Note, where there are figures, tables and bulleted lists paragraph numbering can be subjective, if this is the case paragraphs should also be identified with the first few words. Identifies type and severity of the erratum. Proposer may set, SO may check and override if needed

Version Sections

Paragraph

Category

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 22 of 37

Requester Proposer Related Errata

Email address of original requester of erratum Email address of proposer Hyperlinks to any related errata. This field is used to group errata which must be implemented together. Vector of proposals attached to this request. This field is used to group proposals which form alternative solutions to the same problem. Motivation for requesting errata. A list of affected parts of the test specification Reqester/proposer may set, but SO, test spec SO, and BTI shall check and override if needed

Related proposals

Problem description Test specifications affected

Proposed draft solution

A draft of a proposed change to the specification, this should be in a format which makes it clear exactly which paragraphs, figures etc. are altered and how they are to be changed. This field may include links to documents with figures, tables etc. however the text part of the solution should be inserted in the field so that it is visible without downloading a separate document. If there is more than one competing draft solution proposed each draft solution will carry its own ID, but they will be grouped by the Related Errata field

Impact on interoperability

A field indicating backwards compatibility. The field gives a choice of none, low, medium, high. The requester or proposer may set this field, the section owner should check and may override the setting, any changes should be recorded in the discussion.

Implementation difficulty

A field indicating how difficult this proposal is to implement. The field gives a choice of low, medium, high or unknown.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 23 of 37

The requester or proposer may set this field, the section owner should check and may override the setting, any changes should be recorded in the discussion. Related test specification errata Status Last date to exit state Hyperlinks to test specification errata resulting from the erratum. Current state of errata, this is initially set to Requested Many states have limited duration. For example discussion period lasts 2 weeks, voting lasts 4 weeks, postponement lasts 4 weeks. For these states this field gives the date that the state will be exited. For states which do not have limited duration (such as adopted by the Board), this state will either not be visible or will be set to value undefined (depends upon the open groups implementation) Voting status A record of any votes on the errata. This will show who has voted and the total votes for each proposed draft solution. Justification of no votes is also accessible here. Errata in the Test Specifications Updated or Errata Service Release state may be qualifiable if approved by the BARB. This field indicates whether an erratum or group of errata may be used to qualify products. For sets of related errata which need to be implemented together this field must be set to match on all errata in the set A record of discussion of the errata posted to the interface. The requester of the errata, associates and promoters with a login account may add to this, but discussion cannot be deleted.

Qualifiable

Discussion

For traceability timestamp and name should be available for changes to the record. 3.1.1 Errata Categories

The errata category identifies the type and severity of the erratum. Possible values for this field are:

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 24 of 37

e = minor editorial Editorial problem that does not impact technical correctness of the document (e.g. poor grammar). E = major editorial Editorial problem that may cause a reader to misinterpret the document (e.g. failure to identify an antecedent) t = minor technical Item that is technically incorrect, but does not impact technical correctness of the proposed Standard itself (e.g. citation of incorrect reference or minor inaccuracy that is not germane to the function of the Standard) T = major technical A problem with the document that causes the functionality of the Standard to be impaired. Also included in this category are proposals for alternative methodologies. I = suggested improvement or extension in functionality Note this will not be processed through the standard errata process, but will be forwarded to relevant working groups. The improvement suggestion should include example use cases for the improved functionality. NOTE: Only ONE letter may be chosen. If in doubt, indicate the higher of the comment types (e < E < t < T). the category I should not be used for errata as Improvements or extensions will be passed to working groups, not through usual errata process Impact on Interoperability and Implementation Difficulty should be set to one of High, Medium, Low or None. 3.1.2 Related errata

This field potentially affects qualification against errata. It may be set by the section owner, but reviewers and voters may disagree with the setting and may call for a vote in which case normal voting rules apply. 3.1.3 Qualifiable errata

Usually errata may only be qualified against when they have been incorporated in an Errata Service Release which has then been adopted by the Board of Directors. The BARB may decide to grant permission for errata to be qualified against in advance of adoption. This would mean qualification happening in advance of an IPR review, so the implementer would be taking the risk that errata incorporated unidentified IPR.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 25 of 37

Version 1.0 of the Qualification Program Reference Document does not permit qualification against errata, so a modification by BQRB is required before qualification against errata can take place. If the PRD is suitably modified a possible scheme for qualifying against errata would be for the product manufacturer to request their BQB to arrange for qualification against an erratum or a set of related errata. The BQB would then submit the request to the BARB. The BARB would consider requests once a month. If the BARB approved qualification against an erratum or a group of errata then they would be marked as qualifiable by the Errata Manager This would only be allowed for errata which were in the Test Specifications Updated or Errata Service Release Candidate states. If errata were superceded by subsequent errata then they would no longer be qualifiable. Individual errata or sets of errata would only be qualifiable in isolation until the Errata Service Release was adopted by the board, then the usual rules of implementing the whole Errata Service Release would apply.

3.2

Proposed draft solution

For a draft proposal to be voted on it should contain the following elements: a clear unambiguous description of how the specification is to be changed. The technical writer should not have any room for interpretation. This should be clearly separated from other elements of the erratum. A description of the problem which gives rise to the erratum.

The draft proposal should specify all paragraphs, figures and tables to be deleted or revised, and the exact text, tables and figures to be inserted, and where they are to be inserted. When an Errata Service Release is adopted by the Board the text of the draft proposals becomes the governing text for the specification. It is therefore important that the changes specified in an erratum should be unambiguous.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 26 of 37

Process for discussing solutions

A record of discussions will be visible on a web interface. It is likely that discussions will also take part in working groups, for example during telephone conferences. Section owners will summarize discussions which take part in workgroups and post them to the web interface, so that errata voters who are not in the workgroups have access to the key points discussed. The proposer of an erratum will have access to the web interface to view discussion of that errata, and will be able to contribute comments on that errata. 4.1.1 Postponement

Errata may be postponed if they require work before voting can take place. Any work required will be assigned to members of the voting group in rotation, an exception to this is if the errata arose from a voting member of the group it will be allocated to that member. Anyone registering as a voter must be aware that they may be required to work on an errata and must be prepared to do this, if they refuse they will be removed from the group of errata voters, and may at the discretion of the section owner and errata manager be barred from voting whilst that errata remains active. Barring from the voting is intended as an incentive to participate actively, if there are good temporary reasons why the voter is unable to participate in one instance they should not be barred (e.g. holidays or unusual pressure of work prevent them from participating). The member allocated to a postponed erratum will not necessarily carry out work on that erratum themselves: it is likely for instance that they will ask the proposer of the erratum to redraft into the correct format, rather than redrafting themselves. However the member allocated is responsible for coordinating and tracking work to ensure that work on the erratum progresses. Whilst an erratum is postponed the web page will provide a form which can be used to contact the person working on the erratum (due to concerns about spam this might not display the persons email address). Errata are postponed for a maximum period of 4 calendar weeks, the web page will also display the end of the postponement period and the reason for postponement. Errata might be postponed if they do not include a solution, if the solution is not in a form which can be incorporated in the specification, or if they require co-ordination between different working groups.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 27 of 37

4.1.2

Handling of alternative proposals

During processing of an erratum one or more alternative proposals may be developed. It is useful to link concurrent discussion of related proposals together, so although each alternative could be viewed as a separate erratum in its own right there discussion threads will be linked to the original erratum. Whilst voting on a series of alternative proposals continues they will be linked together. Once the voting for the last alternative has closed the thread may be closed. If another erratum is requested which deals with a similar problem in the specification it may be useful to create hyperlinks to related errata even though their voting period has closed.

4.2

Access restrictions

The section owner is authorized to make all transitions except for marking errata as qualified, putting errata into a service release, removing errata from appeal states and marking a service release as adopted by the Board. The Errata manager is authorized to make all transitions. Voters for each section may cast votes on errata in their section. The section owner may only cast votes if they are also the designated voter for their company. The errata manager may only cast votes if they are also the designated voter for their company. Reviewers, voters, section owners, the errata manager, and the requester may submit comments. Adopters may see the initial request, and they may see errata when they reach the test specifications updated state. (This is the state at which qualification requests may be made). The exception to this rule is the requester who has access to discussions on the errata they requested via email.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 28 of 37

Process for Selecting Solutions

Once one or more solution proposals have been submitted to address the request, one proposal needs to be selected with significant support, or the errata must be rejected. This section describes the process on how proposals shall be resolved.

5.1

Voting process

Votes are taken from a voting pool. Each section of the specification has its own voting pool. Voting pools should normally have at least 7 members, though the BARB may grant permission for voting to be carried out with fewer members if the section owner has difficulty recruiting 7 voters. For more details on voters see section 9 Reviewers and voters. Once a proposal has been submitted the errata moves to the Draft Proposed state for two weeks (14 calendar days) to allow for discussion. At the end of the two weeks in the Draft Proposed state a voting period is automatically scheduled to begin. Voting periods take place over four weeks (28 calendar days), although if a proposal gathers enough votes to be decisive before the four weeks are up it may be moved to another state earlier than the end of the 4 week period. Proposals that achieve a 2/3 positive vote are moved to the Recommended by Voters state. If the proposal does not achieve 2/3 positive votes, it is moved to the Rejected state. Votes registered as abstentions are removed from the total used to calculate 2/3. Two proposals may be developed simultaneously for one erratum request, or alternative proposals may be submitted whilst a proposal is in the Draft Proposed or Voting in Progress states. If alternative proposals are submitted during voting then the voting period may be extended by up to two weeks. When there are two or more draft proposals for an erratum, voting on each draft proposal happens independently. Each separate draft proposal is accepted or rejected at this stage. Because voters vote for each proposal independently there may be several draft proposals which achieve 2/3 or more of the votes. After this phase of voting has been completed the section owner decides what needs to be done next. At this stage if more than one draft proposal has been accepted by voters a run-off vote should be held. For a draft proposal to be accepted for a run-off vote it must have 2/3 or more of the voters voting for it. The section owner selects the drafts which were accepted for the run-off vote. The run off vote is then held to decide between these drafts, the runoff vote takes at most 4 weeks.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 29 of 37

To achieve the recommended by voters stage a proposal must have 2/3 or more of the vote in the run-off stage. Because of the short period allowed for a run-off vote there may be times of the year when an extended period for the run-off vote is more appropriate. The section owner or authorized personnel may extend the voting period for a run-off vote by one week at their discretion. If alternative proposals are submitted too late to be voted upon they should mark the original erratum as a related errata. The same problem statement should be used, and the proposal should clearly state that it supercedes all previous proposals. 5.1.1 Resolution of votes accepting conflicting errata

If two errata are recommended by voters but their instructions for altering the specification contradict each other then the later erratum should refer to the earlier erratum and state that it supercedes the earlier erratum. This is to ensure that voters are aware of all the issues involved. If an erratum is recommended by voters which states that it supercedes an earlier erratum then the earlier erratum is over-ruled by the later erratum. If there is a real contradiction between two errata and there is no text in the later erratum indicating that it supercedes the earlier erratum then the solution is to create another erratum which removes or superceded one or both of the earlier errata.

5.2

Form of votes

Any negative votes must be justified, the justification will be recorded and displayed in the errata record. Positive votes and abstention votes do not have to be justified. To be eligible for a vote reviewers must be registered before the voting period starts this is to ensure adequate opportunity to review discussion, and to prevent reviewers being registered purely to affect the outcome of a single vote (reviewers should have a long term interest and commitment to contribute to the errata process)

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 30 of 37

Handover from working groups to errata process

During the development of specifications the full errata process is not appropriate for processing of errata. This is because immature specifications are likely to require many changes, and it is important for errata to be resolved speedily, as specifications mature and more products implement the specifications stability, and limiting variations become more important and a slow errata process becomes acceptable. Working groups may use the errata interface to inform SIG members outside the working group of errata, and to gather feedback, but need not necessarily use the full process. The BARB may rule on when a specification is ready to enter the full errata process, the default point at which a specification enters the full errata process is version 1.0

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 31 of 37

Test Specification Review and Update

Once an erratum has reached Recommended by Voters stage it must be reviewed to see if amendments to test specifications are required. There may be no amendments, for example a clarification should not change the meaning of the specification, and so is unlikely to require changes to test specifications. To provide an opportunity for the Bluetooth test and interoperability group (BTI) to review errata and generate test cases errata are passed to BTI once a single erratum has been passed by the voting process. If amendments are required they must be available before an erratum moves to the approved state. The process used prior to Bluetooth version 1.1 of releasing errata separately from updating the test vectors shall cease. Errata reflect problems with the specification, so if there is no test case relevant to an erratum, and the erratum affects functionality (as opposed to grammar or spelling), it is possible that a new test case be developed. The process for generating test specification errata is not covered in this document.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 32 of 37

Process for Releasing Errata

8.1

Errata Service Release (ESR)

Errata which have reached the test specifications updated state will be grouped together into an Errata Service Release Candidate. An Errata Service Release Candidate may be generated by the Errata Program Manager, or by other authorized personnel. Usually these releases will be spaced at least 6 months apart. When an Errata Service Release Candidate is first generated it has not been adopted by the Board into the Bluetooth specification. Therefore it should be clearly marked as DRAFT so that there is no confusion between adopted releases and releases which are still undergoing review. Upon adoption each Errata Service Release is deemed to include all Errata Service Releases since the previous specification has been issued. A period of 4 weeks (28 calendar days) should be left to allow for feedback on an errata service release candidate to be submitted. Once an Errata Service Release Candidate has passed the minimum review period, if there have been no objections raised it is eligible to be adopted by the Board as part of the Bluetooth specification. If objections are raised to an errata service release candidate then the errata which caused objections may be removed from that release. Because errata should not be removed due to implementation problems the voting list for the section affected shall decide whether to remove the erratum. There will be a two week period during which this is decided by a vote. Apart from the timing the rules of voting are as for passing an erratum. The timing of an Errata Service release candidate being put forward for adoption will be decided by the BARB. If there are no objections raised the BARB may consider proposing an Errata Service Release candidate for adoption four weeks after its release. Voting on removing errata from an Errata Service release candidate will delay this schedule. Errata service releases candidates will be available for download by all Bluetooth SIG members with a username and password. Feedback on problems encountered with an errata service release should be submitted via the usual errata channels. This should be stated nearby the link allowing download of the errata service release.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 33 of 37

By default an errata service release candidate will contain all approved errata available at the time of release, however section owners may request that some errata be withheld from a release if an erratum forms part of a set which for consistency needed to be released together. If section owners request that errata are withheld from a release a BARB errata task force led by the Errata Program Manager then decides whether the errata should be held for a later release. 8.1.1 Format of Errata Service Release

The proposed format for an Errata Service Release candidate is four addenda containing proposed changes as follows: Core Core prose tests Profiles & Higher layer protocols Profiles & Higher layer protocols prose tests TCRL will not be circulated with the ESR because TCRL is not visible to all adopters. However BTI will process TCRL in parallel with prose test changes & will submit TCRL changes to the BQRB for consideration. The board of directors will vote upon an Errata Service Release in the form of a series of proposed changes. These changes are limited to the Core and Profile specifications. The board does not vote upon the changes to test specifications. This is because the tests are derived documents: in the case of any conflict between the core and profile specifications and their tests the authoritative document is the core and profile specifications. A specification incorporating an Errata Service Release may be produced for the convenience of implementers. In the case of conflicts between the edited specifications and the Errata Service Release the Errata Service Release is the definitive document as this is the document which is adopted by the board.

8.2

Review of errata service release candidate

Once proposals have been grouped into an errata service release a minimum of four weeks (28 calendar days) are allowed for review.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 34 of 37

8.3

Adoption into specification

When an Errata Service Release Candidate has passed the review period it goes through the same stages as a new specification (see the working group process document): The BARB review the Errata Service Release Candidate A notification is sent out to SIG members asking member companies to review for IPR. After an IPR review period an adoption meeting of the Board of Directors shall decide whether and when to formally adopt it into the Bluetooth specification. BTI submits updates test documents to BQRB for approval. After BQRB approval updates test documents are published.

When errata are incorporated into an Errata Service Release Candidate test documents are available, so BQRB could approve test documents in parallel with approval of the Errata Service Release. An Errata Service Release is adopted as a whole.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 35 of 37

Reviewers and voters

Reviewers and voters are representatives of associate or promoter level companies. Each associate or promoter company may have one voter in each section of the specification. The same voter may vote on several sections, or different voters may be used, as long as each company only has one voter for each section. Associate and promoter companies may have as many reviewers per section as they wish. Voters discuss errata, and vote upon proposals, reviewers may only discuss errata, reviewers may not vote. The requester of an erratum may take part in discussion of the erratum whatever their class of membership, but the requester may not vote unless they are entitled to vote by being an associate or promoter company voter. When an erratum is requested which contains a problem description, but does not contain a proposal for amending the specification voters may be called upon to assist the section owner in generating proposals. Voters are eligible to vote on any errata proposals which begin their voting periods after the voter joins the voting pool. voters should not vote on errata which have begun their voting periods before they joined the voting pool. Voters should make a long term commitment to reviewing errata they should not join the voting pool just to vote on a single erratum. Voters who do not participate in voting, or who do not participate in generating proposals may be removed from the review list by the section owner. This is necessary as inactive voters could prevent a quorum being reached. Any voter missing two consecutive votes can be removed. They may apply to the section owner to be reinstated when they are ready to become active again. Candidate voters and reviewers must obtain a password for the Bluetooth website before requesting appointment as reviewers. They may then apply to the relevant section owner to be added to the review pool for a section. The section owner is contacted using the reflector bt-sect-part-X-owner@bluetooth.org where X is the section identifier, for example bt-sect-part-A-owner@bluetooth.org is the owner of the radio specification, and bt-sect-part-K1-owner@bluetooth.org is the owner of the Generic Access Profile.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 36 of 37

10

Section Owners

The section owner is responsible for supervising the errata process for their section, managing the review pool for their section and is also expected to answer specific questions on the section for which they are responsible. The timescales for managing the errata process are laid out elsewhere in this document. Emails to the section owner should be responded within 10 working days (weekends and national holidays are not working days). The response may not give all the requested information, but if it does not then the response should indicate when the information will be available, or give a reason why the question cannot be dealt with. Requests to join a review pool should be processed within 10 working days. Where there is a conflict because there is more than one request from the same company to review the same section the conflict should be pointed out to both applicants, if they do not resolve the matter within 10 working days the conflict should be referred to the primary contact for that company. If there is an existing active reviewer that reviewer remains active whilst the conflict is being resolved. If the section owner will be absent from their post and unable to meet the specified response times, they must arrange for notification of absence to people trying to contact them. They could do this by adding a colleague or secretary to the section owner's list or by setting automatic out of office notification. The notification should include a date when they will be active again All deadlines are extended by the period of absence - it is acknowledged that absence will happen for conferences, working group meetings, holidays, illness. In cases such as illness when the exact period of absence cannot be ascertained the section owner should attempt to notify the errata manager if possible. Section owners should note that all notifications to the errata manager should use the email bt-em@bluetooth.org (this is because this email reflector can be monitored by more than one person if required, any emails addressed directly to the current errata managers personal email address are not recorded for the SIG, and cannot be monitored by anyone other than the current errata manager). If the section owner will be absent for more than 6 weeks they should arrange for a temporary stand in, or notify the errata program manager so that a temporary stand in can be arranged.

BLUETOOTH SIG CONFIDENTIAL Errata Process

Page 37 of 37

Section owners who consistently fail to meet schedules or notify absences may be replaced. Consistently failing to meet schedules means missing deadlines three times in a year, or missing one deadline by more than 4 weeks. Replacement is not automatic though - special circumstances may be taken into account. Section owners are replaced by sending a call for section owner to associates & promoters, gathering petitions & presenting petitions to the BARB, the BARB picks the best candidate. Section owners may resign their post at any time by notifying the Errata Manager, or the BARB (bt-arch@bluetooth.org)