3G TR 21.900 V3.1.0 (1999-07)
`
`Technical Report
`
`3rd Generation Partnership Project;
`Technical Specification Group;
`Working Methods
`(3G TR 21.900 version 3.1.0)
`
`The present document has been developed within the 3rd Generation Partnership Project (3GPP
`
`) and may be further elaborated for the purposes of 3GPP.
`
`The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented,
`This Specification is provided for future development work within 3GPP only. The Organisational Paitners accept no liability for any use of this Specification
`Specifications and reports for implementation of the CSGPPTM system should be obtained via the 3GPP Organisational Paitners‘ Publications Offices.
`
`TM
`
`
`Microsoft Corporation
`Exhibit 1007-00001
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`2
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`Reference
`DTS/TSGSA-0021900U
`
`Keywords
`SG Working Methods
`
`3GPP
`
`Postal address
`
`3GPP support office address
`650 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 4716
`
`Internet
`
`http://www.3gpp.org
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00002
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`3
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`Contents
`
`Foreword ............................................................................................................................................................ 4
`
`Introduction ........................................................................................................................................................ 4
`
`1
`
`2
`
`3
`
`4
`4.1
`
`4.2
`413
`4.4
`4.5
`41511
`4.5.2
`4.5.3
`4.5.4
`4 5 5
`4 6
`4. 6.1
`41612
`4.6.3
`4.6.4
`4.6.5
`
`5
`
`6
`61
`
`6.2
`6.3
`614
`
`6.4.l
`6.4.2
`6.4.3
`
`6431
`6.4.3.2
`6.4.3.3
`65
`
`7
`7.1
`712
`
`7.3
`7.4
`7.5
`
`Scope ........................................................................................................................................................ 5
`
`Definitions and Abbreviations ................................................................................................................. 5
`
`General responsibilities of the Support Team .......................................................................................... 6
`
`Handling of Specifications ....................................................................................................................... 6
`Overview ........................................................................................................................................................... 6
`
`Characteristics of a specification ....................................................................................................................... 6
`Characteristics of a major version of a specification: ........................................................................................ 7
`Characteristics of a version of a specification ................................................................................................... 8
`Actions on a specification .................................................................................................................................. 8
`Actions on a new specification (version O.X.y) iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii 8
`Actions on version l Xy ofa specification .................................................................................................. 9
`Actions on version 2 X y ofa specification .................................................................................................. 9
`Actions on version W. X.y of a specification (W > 2) .................................................................................. 10
`Actions on the major version of a specification .............................................................................................. 10
`Change Request Regime .................................................................................................................................. ll
`Change Requests ........................................................................................................................................ l 1
`Change Request forms ............................................................................................................................... 1 1
`Contents of Change Requests..................................................................................................................... l l
`Handling of the Change Requests .............................................................................................................. 12
`Updating and release of neW versions ofthe specifications ....................................................................... 13
`
`Availability and distribution of specifications ....................................................................................... l4
`
`....................................... 14
`Work items ..........................
`Creation of a Work Item .................................................................................................................................. 14
`
`Type of Work Items ......................................................................................................................................... l 5
`Start and continuation of the work and responsibilities ................................................................................... 15
`Realisation of Work Items ............................................................................................................................... 16
`
`Planning and categorisation of the deliverables (and control thereof) ....................................................... l6
`Choice of deliverables ................................................................................................................................ 16
`Contents of deliverables ............................................................................................................................. 16
`
`Service Requirements ........................................................................................................................... 16
`Technical realisation specifications ...................................................................................................... l7
`Test Specifications ................................................................................................................................ 17
`Closing of Work Items ..................................................................................................................................... 17
`
`Management documents and tools ......................................................................................................... l7
`Status List of Specifications ............................................................................................................................ 17
`Work Item Status List ...................................................................................................................................... 17
`
`Change Request data base ............................................................................................................................... l8
`Mailing lists and Membership data bases ........................................................................................................ 18
`Electronic tools used/preferred ........................................................................................................................ 18
`
`History .............................................................................................................................................................. l9
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00003
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`4
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`Foreword
`
`This Technical Report has been produced by the 3GPP.
`
`The contents of the present document are subject to continuing work within the TSG and may change following formal
`TSG approval. Should the TSG modify the contents of this TR, it will be re-released by the TSG with an identifying
`change of release date and an increase in version number as follows:
`
`Version 3.y.z
`
`where:
`
`x the first digit:
`
`1
`
`presented to TSG for information;
`
`2 presented to TSG for approval;
`
`3
`
`Indicates TSG approved document under change control.
`
`y
`
`the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
`updates, etc,
`
`2
`
`the third digit is incremented when editorial only changes have been incorporated in the specification;
`
`Introduction
`
`In order to ensure correctness and consistency of the specifications (i,e,, technical specifications and technical reports)
`under responsibility ofthe Technical Specification Groups (TSG) ofthe 3rd Generation Partnership Project (3GPP),
`clear, manageable and efficient mechanisms are necessary to handle version control, change control, document
`updating, distribution and management,
`
`Also, the fact that the specifications are/will be implemented by industry almost in parallel with the writing of them
`requires strict and fast procedures for handling of changes to the specifications.
`
`It is very important that the changes that are brought into the standard, from the past, at present and in the future, are
`well documented and controlled, so that technical consistency and backwards tracing are ensured,
`
`The 3GPP TSGs, and their sub-groups together with the Support Team are responsible for the technical content and
`consistency of the specifications whilst the Support Team alone is responsible for the proper management of the entire
`documentation, including specifications, meeting documents, administrative information and information exchange
`with other bodies.
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00004
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`5
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`1
`
`Scope
`
`This document outlines the working methods [to be] used by the 3GPP Technical Specification Groups and their sub-
`groups and by the 3GPP Support Team in relation to document management, Le. handling of specifications, updating
`procedures, change request procedures, version control mechanisms, specifications status information etc. It
`complements the rules and procedures defined for 3GPP. This document does not stipulate the details of the internal
`working of the TSG sub-groups. From the Technical Specification Group point of view, a task and responsibility is
`given to a Working Group (WG) directly answering to the Technical Specification Group. In practice, the work/task
`may be carried out in a subgroup of that WG.
`
`2
`
`Definitions and Abbreviations
`
`Change Control
`
`Closed
`
`CR
`
`Draft
`
`Frozen
`
`Major Version
`
`Specification
`
`When a specification has been put under change control, changes to the
`specification require an approval of formal change requests. Rules for
`change control are defined in section 4.
`
`A closed major version ofa specification is still published; however no
`changes to the major version of the specification are possible anymore (not
`even essential corrections).
`
`Change Request.
`
`A specification is draft before getting under change control.
`
`For a frozen major version ofa specification, the only allowed change
`requests are essential corrections.
`
`For version w.x.y of a specification, w is called the major version. Example:
`For version 3.2.0 ofa specification, the major version is 3.
`
`In this document, the generic term Specification is used for both Technical
`Specifications and Technical Reports. A distinction between the two is done
`only where relevant.
`
`TSG
`
`Technical Specification Group
`
`TSG Change Control
`
`TSG Sub-Group:
`
`TSG WG
`
`Technical Specification Group Change Control: The Technical Specification
`Group is responsible for approval of Change Requests.
`
`A TSG Working Group or a subgroup installed by a TSG Sub-Group
`(recursive definition)
`
`Technical Specification Group Working Group. A working group installed
`by the TSG and reporting to the TSG.
`
`TSG WG Change Control
`
`Technical Specification Group Working Group Change Control: The TSG
`Working Group is responsible for approval of Change Requests.
`
`Version
`
`WI
`
`WlD
`
`Withdrawn
`
`Work ltem
`
`A specification has versions which are identified by three numbers w.x.y.
`Example: version 3.12.3.
`
`Work Item.
`
`Work ltem Description.
`
`A withdrawn specification does not belong to the set of valid specifications.
`
`A work item aims at introduction of a new feature or at enhancement of
`
`existing features. It may entail new specifications and/or changes to existing
`specifications.
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00005
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`6
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`Work Item Description
`
`The description of a Work Item in a standard Work Item Description sheet
`
`3
`
`General responsibilities of the Support Team
`
`The Support Team is responsible for the management of the work of the TSG. This includes editorship and
`management of specifications once they have been put under TSG change control. It also includes preparation of and
`support for the meetings (including meeting reports) ofthe TSG and its Working-groups, in descending priority
`
`TSG > TSG WG > other TSG WG SG.
`
`It furthermore includes liaison to other bodies and relevant groups and institutions,
`
`4
`
`Handling of Specifications
`
`This section describes the general procedures and events involved in, and related to, the lifetime of a specification.
`
`4.1
`
`Overview
`
`This section gives an overview on the development ofa specification, dealing with the unexceptional cases only, and
`leaving out details. A more detailed description is given in the remainder of section 4.
`
`A new specification is created in an TSG WG. At creation, a rapporteur is nominated. The rapporteur elaborates the
`first versions, version 0.0.0, version 0.1.0, possibly 0.1.1, 0.1.2 and so on, then version 0.2.0 etc..
`
`The versions 0.1.0, 0.2.0, 0.3.0 etc. should be presented to the responsible TSG WG. The versions 0i. 1, 0.i.2 etc. may
`be internal versions.
`
`As soon as title, scope and some other information on the specification is stable, the Support Team assigns a
`specification number and enters the specification into the Status List of Specifications, see section 7.
`
`When a specification is sufficiently stable, it is presented as version 1.0.0 to the TSG for information.
`
`Further versions 1.X.y are elaborated until version 2.0.0 is presented for approval at the TSG.
`
`After approval, the specification becomes version X.0.0 Where X >=3. It is under TSG change control. Further changes
`are made by means of formal change requests, to be approved by the TSG. The number X is called the major version of
`the specification. If all change requests approved were editorial, the new version increments the right most number
`(e.g., from 7.2.1 to 7.2.2); if at least one approved CR has been non-editorial, the middle number is incremented and the
`right most number reset to 0 (e.g., from 7.2.1 to 7.30).
`
`At some point in time, the specification is frozen: Only corrections of essential errors will be applicable. (At the same
`time, a new major version may be developed for inclusion of new features.)
`
`At a later point in time, the specification is closed: it is still publicly available, but no changes are carried out any more.
`(At the same time, higher major versions of the specification may be under development.)
`
`The major versions of specifications may be developed in releases: Releases like Release 1999, Release 2000, Release
`20001 are specified in major versions of the specifications. For example, 3rd Generation Release 1999 might be
`specified in the most recent versions 3.x.y of specifications, that is in major version 7.
`
`[Example
`
`The concept of major versions has been applied for GSM specifications: Major version 5 specifies
`Release 1996, major version 6 specifies Release 1997 and so on]
`
`4.2
`
`Characteristics of a specification
`
`- The specification has a prime responsible TSG.
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00006
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`7
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`The specification may have a prime responsible TSG WG:
`
`The specification may have one or more secondary responsible TSGs and/or TSG WG.
`
`- The specification may have a prime responsible TSG Sub-Group below a Working Group as decided by the
`prime responsible TSG WG.
`
`- The specification should have a rapporteur (ie, at least one rapporteur): a delegate from a member company (or,
`in exceptional cases, a Support Team expert); the delegate participates regularly in the prime responsible TSG
`WG (and further TSG SG if applicable):
`
`- The specification is a Technical Report or a Technical Specification
`
`- A specification has versions which are identified by three numbers wixiy where w is called the major version.
`
`Note:
`
`in the description above, attribute values are underlined while attributes aren’t.
`
`The prime responsible TSG WG may assign prime responsibility for a specification to one of its subgroups
`
`4.3
`
`Characteristics of a major version of a specification:
`
`A major version 0 or 1 or 2 of a specification has the following characteristics:
`
`-
`
`-
`
`It is either a m or withdrawn.
`
`It is TSG internal:
`
`-
`
`A major version w > 2 of a specification has the following characteristics:
`
`It is either under TSG WG Change Control or under TSG Change Control or closed or withdrawn.
`
`it is either authorised for publication or TSG internal,
`
`-
`
`A major version of a specification under TSG WG Change Control is TSG internal,
`
`A major version under TSG WG Change Control or TSG Change Control is called major version under Change
`Control,
`
`A major version of a specification under TSG Change Control is
`
`-
`
`either not yet frozen or frozen.
`
`Note:
`
`In the description above, attribute values are underlined while attributes aren’t.
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00007
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`8
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`4.4
`
`Characteristics of a version of a specification
`
`1.x.y (x > 0 or y > 0)
`
`2..()xyx>Oory>O
`
`
`
`draft (or withdrawn)
`TSG internal
`no version of the specification has been presented for information to the TSG yet
`no major version of the specification is under TSG change control yet
`draft (or withdrawn)
`TSG internal
`this version 1.0.0 is presented to TSG
`for information
`or for information and approval
`no ma'or version of the Snecification has been under TSG Channe Control et
`draft (or withdrawn)
`earlier version 1.0.0 has been presented for information to the TSG
`no major version of the specification is under TSG Change Control yet
`draft or withdrawn
`TSG internal
`earlier version 1.0.0 has been presented for information to the TSG
`this version 2.0.0 is presented to the TSG for approval
`no version of the specification has been approved yet
`no major version of the specification has been under TSG Change Control yet
`draft
`TSG internal
`earlier version 1.0.0 has been presented for information to the TSG]
`no major version of the specification is under TSG Change Control yet
`earlier version 2. 0. 0 had been presented to the TSG for approval but had not been
`approved by the TSG
`-
`under TSG Change Control or closed
`-
`TSG internal or authorised for publication
`[-
`earlier version 1.0.0 has been presented for information to the TSG]
`-
`earlier major versions of the specification, if any, shall be under TSG Change Control
`or closed or withdrawn
`
`under TSG WG Change Control
`TSG internal
`earlier version 1.0.0 has been presented for information to TSG]
`[-
`earlier major versions of the specification, if any, shall be under TSG Change Control
`-
`or closed or withdrawn
`
`draft y.z of version x
`
`Notes:
`
`in a future version, file name conventions should be added in the table above.
`
`in the table above, statements between square brackets are true but not relevant. The first two lines of
`each row are implied by section 4.2.
`
`4.5
`
`Actions on a specification
`
`4.5.1
`
`Actions on a new specification (version 0.x.y)
`
`- A new specification (a specification version 0.0.0) may be created by a TSG WG. A rapporteur (more exactly: at
`least one rapporteur) is assigned by that WG. A prime responsible subgroup of the TSG WG may be allocated
`by the TSG WG.
`
`- The rapporteur prepares version 0.1.0 and presents it to the prime responsible TSG WG/SG for discussion.
`
`-
`
`in an iterative process, the rapporteur prepares a new version 0.x+1.0 incorporating comments from the prime
`responsible TSG WG/SG to versions 0.x.y and presents version 0.x+1.0 to the prime responsible TSG WG/SG
`for discussion.
`
`- Between version 0.x.0 and O.x+i .0, the rapporteur may create versions 0.x.i , 0.x.2,
`modifications,
`
`with only editorial
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00008
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`9
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`- When the title and scope of a specification is sufficiently stable, a Specification Number is assigned by the
`Support Team , which also informs the other relevant Technical Bodies.
`
`- The TSG WG reports the creation ofa new specification to the TSG.
`
`- New specifications should be co-ordinated between the TSGs and, if GSM is concerned, SMG. These bodies
`should seek agreement on prime and secondary responsibilities for each specification. In areas of common
`interest it is recommended to agree on new specifications in joint meetings
`
`- The TSG may cancel a new specification.
`
`- The TSG WG may decide to present a specification version 0.x.y to the prime responsible TSG and to the
`secondary responsible TSG SG(s) for information; the specification should then be to at least 60 stable.
`
`- The TSG WG may also conclude that the specification is already to at least 80% stable and decide to present it
`to the TSG for information and approval; before doing that, comments from secondary responsible TSG SGs, if
`any, should have been taken into account.
`
`Then the specification is handed over to the Support Team for the necessary - strictly editorial - cleaning up
`resulting in version l.0,0,
`
`4.5.2
`
`Actions on version 1.x.y of a specification
`
`- On decision of the prime responsible TSG WG, the Support Team transforms version 0.x.y of a specification
`into version 1.0.0, performing the necessary - strictly editorial - cleaning up, and version i .00 is presented by
`the TSG WG to the to the prime responsible TSG and to the secondary responsible TSG WG(s) for information
`or for information and approval.
`
`- The TSG may decide to put the specification under change control as major version X (where X > 2 depends on
`the Release which the specification belongs to). In this case, version 1.0.0 is transformed by the Support Team
`into version x00, and the further handling is described in section 4.5.4. Otherwise, the handling ofthe
`specification continues as described below:
`
`-
`
`In an iterative process, the rapporteur prepares a new version 1.x+l .O incorporating comments from the prime
`and secondary responsible TSG SGs t0 versions 1.x.y and presents version 1.x+l .0 to the prime and secondary
`responsible TSG SGs for discussion.
`
`- Between version i .x.O and l.x+l .0, the rapporteur may create versions l X] ,
`modifications,
`
`l .x.2,
`
`with only editorial
`
`- The prime responsible TSG WG may decide to present a specification version l.X.y to the prime responsible
`TSG for approval; the specification should then be to at least 80% stable; comments of the secondary
`responsible TSG SGs should have been taken into account.
`
`Then the specification is handed over to the Support Team for the necessary - strictly editorial - cleaning up
`resulting in version 2.0.0,
`
`4.5.3
`
`Actions on version 2.x.y of a specification
`
`- On decision of the prime responsible TSG WG, the Support Team transforms version 1 .x.y ofa specification
`into version 2.0.0, performing the necessary - strictly editorial - cleaning up, and version 2.0.0 is presented by
`the prime responsible TSG WG to the prime responsible TSG for approval; comments of the secondary
`responsible TSG SGs should have been taken into account. If version 2.0.0 is not approved, work continues with
`versions 2.x.y.
`
`- The TSG may decide to put the specification under change control. In this case, version 2.0.0 is transformed by
`the Support Team into version X.0.0, (where X > 2, see section a4), and the further handling is described in
`section 4.5.4. Otherwise, the handling of the specification continues as described below:
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00009
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`10
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`-
`
`In an iterative process, the rapporteur prepares a new version 2.x+l .0 incorporating comments from the prime
`and secondary responsible TSG SGs to versions 2.x.y and presents version 2.x+i ,0 to the prime and secondary
`responsible TSG SGs for discussion.
`
`- Between version 2.x.0 and 2.x+1.0, the rapporteur may create versions 2.x.1, 2.x.2,
`modifications.
`
`with only editorial
`
`- The prime responsible TSG WG may decide to present a specification version 2.x.y to the TSG for approval; the
`specification should then be to at least 80% stable; comments of the secondary responsible TSG WGs should
`have been taken into account
`
`Then the specification is handed over to the Support Team for the necessary - strictly editorial - cleaning up
`resulting in version 2.x+l .0.
`
`4.5.4
`
`Actions on version w.x.y of a specification (w > 2)
`
`- On decision of the TSG, the Support Team transforms a version v.x.y ofa specification into version w.0.0,
`performing the necessary - strictly editorial - cleaning up.
`
`- The prime responsible TSG WG may agree on Change Requests to the most recent version w.x.y of major
`version w of a specification. It will then propose these CRs to the TSG for approval, however before doing that,
`it has to seek comments from the secondary responsible TSG (WG)s - if any - and to take them into account
`(joint meetings of the appropriate TSG SGs are recommended for that purpose). If and when at least one Change
`Request to version w.x.y of major version w of that specification is approved by the TSG, the Support Team
`includes all Change Requests to version w.x.y of major version w of that specification into a new version
`
`- w.x.y+i
`
`if all change requests approved by the TSG are editorial
`
`- w.x+i .0
`
`if at least one change request approved by the TSG is not editorial
`
`-
`
`-
`
`-
`
`From a version w.x.y of major version w ofa specification, the Support Team may create a new version
`w.x.y-H where only changes in the front sheet, preface and history are performed (for publication purposes)
`
`From the most recent version w.x.y of major version w of a specification, the Support Team may create a new
`version w.x.y+l in agreement with the rapporteur and the prime responsible TSG WG where only strictly
`editorial changes are performed
`
`If Change Requests have been introduced incorrectly into the most recent version w.x.y of major version w ofa
`specification, the Support Team may create a new version w.x+1.0 in agreement with the rapporteur and the
`prime responsible TSG WG, to correct the introduction of Change Requests.
`
`4.5.5 Actions on the major version of a specification
`
`- The TSG may decide to create a new major version >2 of a specification.
`
`- The TSG may decide to withdraw a major version of a specification.
`
`- The TSG may decide to close a frozen major version of a specification.
`
`- The TSG may authorise a major version >2 for publication or decide that it is TSG internal.
`
`- The TSG may decide to freeze a major version of a specification under change control.
`
`- The TSG may decide to unfreeze a major version of a specification under change control.
`
`- The prime responsible TSG WG may decide to create a new major version > 2 of a specification under TSG WG
`Change Control.
`
`These decisions have to be taken in agreement with all relevant TSGs (all TSGs and, if GSM is concerned, SMG).
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00010
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`11
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`4.6
`
`Change Request Regime
`
`Modifications to specifications under TSG Change Control are decided by the TSG, on the basis of Change Requests
`(CR). These CRs, described in the following sections, shall in principle only be presented to the TSG after having been
`scrutinised by the TSG WG responsible for the concerned specification, comments from secondary responsible TSGs
`(if any) have to be have sought and comments have to be have taken into account.
`
`4.6.1
`
`Change Requests
`
`Whenever an error or an inconsistency is discovered or when a new feature is proposed to be included, a Change
`Request is produced, normally by the one discovering the error but in consultation with the rapporteur and/or with the
`Support Team .
`
`In the case of an essential error corrections, separate Change Requests for each affected major versions that is under
`TSG Change Control or TSG WG Change Control shall be produced.
`
`In the case of a correction of a non-essential error, separate Change Requests for each affected major versions that is
`
`-
`
`-
`
`under TSG Change Control and not yet frozen or
`
`under TSG WG Change Control
`
`shall be produced.
`
`4.6.2
`
`Change Request forms
`
`To ensure an appropriate and consistent way of presenting and documenting Change Requests, there exist standardised
`front covers (forms) for CRs as well as rules on how to accurately identify the modified parts ofthe specification
`
`The purpose ofthe CR form itselfis to provide the relevant management information of the proposed changes, eg.
`such as
`
`- Target specification with its version number,
`
`-
`
`Source of the CR,
`
`- Reason for the proposed change and consequences if not accepted,
`
`- Category of proposed change (ie. correction, change request corresponding to an earlier release change request,
`addition of feature, functional modification of feature, or editorial modification),
`
`- Cross-phase compatibility aspects.
`
`As the degree of acceptability for modifications differs between not yet frozen major versions of specifications and
`frozen major versions of specifications, the CRs differ on the allowed/possible Categories:
`
`- CRs to a frozen major version of a specification can only be essential corrections whilst
`
`- CRs to a not yet frozen major version of a specification can also fall into any other of the categories quoted
`above.
`
`The actual CR forms to be applied and guidance how to apply them are distributed by the Support Team . The access to
`them is described in an annex of each TSG plenary report.
`
`4.6.3
`
`Contents of Change Requests
`
`Although the CR form shall indicate the details of change, each CR shall have attached the pages of the specification
`that are affected by the CR, using the latest version of the major version These pages shall have the proposed
`modifications clearly marked, by means ofthe word processor‘s "revision mode", is new proposed text should be
`double underlined (g) and proposed deletions should be marked by strike through (flex), and a bar in the margin
`should further indicate the change.
`
`ETSI
`
`Microsoft Corporation
`Exhibit 1007-00011
`
`Microsoft Corporation
`
`

`

`36 TR 21.900 version 3.1.0
`
`12
`
`36 TR 21.900 V3.1.0 (1999-07)
`
`In case there are more than one independent CR to the same part of the specification, neither of them should contain the
`proposed modifications from the other(s), however any potential interaction between the modifications should of course
`be resolved before presentation.
`
`4.6.4
`
`Handling of the Change Requests
`
`Entry to the TSG WG:
`
`A proposed CR should be brought to the relevant TSG WG or, if applicable, to the prime responsible TSG WG SG in
`charge of the specification concerned and discussed there, before presentation to the TSG. If possible it should be
`distributed, by the source, as soon as possible and prior to the coming TSG SG /TSG WG meeting to at least the
`rapporteur (if not the source) and the Support Team but preferably to as many 'key delegates' as possible, for the
`purpose of shortening discussions in meetings and to try at an as early stage as possible to come to a widely acceptable
`solution. Comments from secondary responsible TSGs (if any) have to be have sought and comments have to be have
`taken into account before presentation to the TSG for approval.
`
`To ease the work of the TSG SG and of the Support Team , a proposed CR should be presented in a form suitable for
`TSG WG agreement and TSG approval. lfa CR is not immediately accepted it is the responsibility ofthe originator to
`update the CR taking into account comments and other guidelines from the relevant groups, including change of
`refere