Content for TR 21.900 Word version: 18.2.0

0… 4… 4.4… 4.6… 4.7… 4.10… 5… 6… 7…

7 Management documents and tools p. 37

7.0 Overview p. 37

This clause summarizes and lists the various permanent or semi-permanent documents (and means of documenting).

All these documents/tools are within the responsibilities of the Support Team and or TSG SA.

7.1 Status List of Specifications p. 37

This list (data base) contains information about all 3GPP specifications, in terms of specification number, title, latest version, rapporteur and other details. The current list shall be annexed to every TSG SA meeting report.

7.2 Work Item Status List p. 37

This data base contains information about all 3GPP Work Items, in terms of identified future specifications, identified specifications to be amended, supplementary/temporary documentation, expected/planned completion dates and intermediary milestones, and other management information related to specifications, responsible Groups, rapporteurs, completion dates etc.

7.3 Change Request data base p. 37

The Change Request data base records all CRs to specifications.

7.4 Membership data bases p. 37

The members data base contains information of all delegates in the 3GPP TSGs.

7.5 Electronic tools used/preferred p. 37

For the various types of documents and parts of documents of 3GPP, a minimum variety of word processors etc. should be used. Those identified in TR 21.801 are permitted.

7.6 WEB and FTP services p. 38

The 3GPP website (https://www.3gpp.org) and portal (https://portal.3gpp.org) provide up-to-date information on specification work, such as: meeting calendars, meeting minutes, meeting documents and latest specifications. FTP links to file server areas of each TSG and WG can be found via the 3GPP web pages.

7.7 E-mail reflectors p. 38

TSGs, WGs and SWGs have their own e-mail lists. There are also several additional lists per topic. Further information can be found on 3GPP web pages.

8.0 E-mail decisions p. 38

WGs may apply e-mail decision procedures for decisions they are entitled to take, as defined by superior bodies (e.g. on specifications, CRs, Liaison statements, etc.). Each WG may set its rules for making e-mail decisions, however, it is required that:

the rules are clearly defined and documented;
a delegate having participated in plenary meetings is able to identify that he has possibly missed an e-mail relevant to e-mail decision.

Clauses 8.1 - 8.6 describe an e-mail decision procedure example.

8.1 E-mail drafting phase p. 38

An e-mail drafting session can be launched, either on a dedicated exploder list as a cybermeeting or as an informal discussion between interested delegates. Objectives can extend from debating an existing contribution, a Liaison Statement or a Change Request to progressing the service requirements of a specific Work Item and involving one or more Working Groups.

In case of "cybermeeting", the Chair of the discussions shall issue an un-ambiguous guideline including:

the objectives and agenda of the meeting;
input document(s) to be clearly specified;
start date and end date of the debates;
afterwards, summary of results of the "cybermeeting".

The end-goal being to reach an "agreement" on the deliverable, either at the next meeting or via an e-mail approval procedure.

8.2 E-mail decision declaration p. 38

Authority for an e-mail decision to take place should usually be agreed at plenary meeting. If this is not possible, there shall be a clear notification (i.e. status report) indicating that there will be an e-mail decision. This notification shall be sent on the main mailing lists indicating the mailing list where the discussion will take place (TSG, WG or SWG list). Target and timeframe shall be clearly indicated. A permanent Chair (i.e. WG Chair or Vice Chair) shall be nominated, who will be responsible for managing the e-mail decision procedure, including initiation, monitoring and announcing when it is complete.

8.3 Status reporting p. 38

During the e-mail decision period, there shall be a clear message stating what the status of each open item is. It is recommended to have a weekly summary of the status of all items, from the previous plenary listing:

the name of the open item;
the name of the responsible delegate;
time left for comments before the deadline & expiration date;
current work versions of documents: Tdoc number, CR number, Revision number;
status (Debate ongoing, Agreed, Postponed, Rejected, ...).

8.4 Decision announcement p. 39

When a decision is made (Agreed, rejected, postponed…) a clear notification on what has been agreed shall be sent on the main mailing lists of the relevant groups.

8.5 Timing p. 39

E-mail decision procedure should start at the latest 3 weeks before relevant plenary:

the e-mail decision period is two weeks (one status report required);
the procedure shall be completed one week before the relevant TSG, WG or SWG plenary, due to practical arrangements.

8.6 General p. 39

in exceptional cases when the procedure cannot be followed a clear notice from Chair is required;
e-mails on mailing lists shall contain a subject with meaningful keywords, e.g. SA1 Tdoc xxx on Charging and/or 22xxx CR012r4;
if there are no comments during the allowed period, agreement is granted automatically;
status reports to higher level body meetings, should be e-mailed to the-mailing list one week before the meeting. This allows delegates a final possibility to review the progress in the last period.

9 Meeting contribution document types and status values p. 39

9.1 Terminology p. 39

Written contributions to 3GPP meetings are called "TDocs".

Each TDoc shall be one of the following types:

Table 9.1-1: Permissible TDoc types

TDoc type	Remarks
agenda	Meeting agendas, including those showing allocation of TDocs to agenda items, also timing schedules
Work Plan	Ordered list of work items
LS in	Liaison Statement, received from some other 3GPP group or an external body
LS out	Liaison Statement issued by a group and directed to one or more other 3GPP groups or external bodies.
pCR	Pseudo-Change-Request: similar to a Change Request but has no CR number and is intended to propose new or revised text for inclusion in 3GPP TSs or TRs not yet under change control (i.e. still in the drafting phase). Known in some groups as "text proposal".
draftCR	Similar to a Change Request, but unnumbered; proposes new or revised text for a TS or TR already under change control. May ultimately be revised into a regular Change Request.
CR	A formal proposal to make changes to a TS or TR which is under change control - i.e. which has a version number with the first field greater than 2 (see clause 4.0A).
CR Pack	One or more Change Requests which have been agreed (or endorsed) at working group level and are being presented as a package to TSG for approval.
ToR	Terms of reference for a TSG or working group.
WID new	Work item description for a new work item - i.e. one not already approved at TSG level.
WID revised	Proposes changes to an already TSG-approved Work item description.
SID new	As "WID new", where the work item is of type "study".
SID revised	As "WID revised", where the work item is of type "study".
WI status report	Rapporteur's report (reviewed by the lead WG) of the current state of completion of a work item (degree of completion, target date, contentious issues, …).
WI exception request	Request to TSG to permit an overrun in the schedule for the completion of a work item.
TS or TR cover	Stand-alone cover sheet for a draft TS or TR being presented (normally at TSG level). Typically used in conjunction with a "draft TS" or "draft TR" type where the actual draft TS or TR and its cover are not included in the same TDoc.
draft TS	A complete TS, still in draft state, being presented either for information or approval at TSG level. May also be used at WG level. At TSG level, normally includes a separate "TS or TR cover" indicating the state of development of that TS; if the cover sheet is not included, it can be provided in a separate TDoc of type "TS or TR cover".
draft TR	As "draft TS" but pertaining to a TR rather than a TS.
report	Any report (other than "WI status report", see above). Typically documents the proceedings of a TSG or WG, or a subgroup thereof.
discussion	A TDoc which is intended to be discussed.
response	A TDoc which has been prepared to provide support for, or a counter argument to, another TDoc. Note: This type is pecular to one particular working group (RAN3).
other	Any other kind of TDoc, for which none of the above types is appropriate.

WI Summary

Summary of a work item (or a group of work items which is decided by the responsible TSG). It explains the purpose of introducing the work item(s) as well as the impacts on the system without requiring that the reader is a specialist in this field. It is issued by the completion time of the work item(s) and describes what has been specified (i.e. the solution finally selected and approved by the TSG).

9.2 TDoc status values p. 41

Each TDoc having a formal allocated TDoc number has an associated status chosen from Table 9.2-1 below.

Table 9.2-1: TDoc status values

Status value	Meaning	Used for TDocs of type …
-	Retained for compatibility with legacy TDocs.	None
reserved	TDoc number allocated, document not yet available. If this status remains at the end of the meeting, it will be reported in the minutes as "not available". Note: It is not uncommon for revised TDocs to be agreed or approved in principle prior to their becoming available, in which case the appropriate status is set against the TDoc immediately. 3GU keeps a separate field indicating whether the TDoc is, in fact, available. If a TDoc remains unavailable at the end of the meeting, or at the end of any post-meeting decision period, then the Secretary will revert its status to "reserved", and the meeting report will indicate it as being "not available".	Any
available	TDoc available, not yet treated. If this status remains at the end of the meeting, it will be reported in the minutes as "not treated".	Any
approved	Favourable conclusion; the group in question (TSG or WG) has the final say.	Any
agreed	Favourable conclusion; the decision has to be confirmed by a higher body (e.g. WG decision has to be confirmed by TSG).	Any
noted	TDoc has been presented, no specific action results.	Any except for CRs, where interpretation is ambiguous.
postponed	TDoc has been presented but no final decision could be reached; subject is likely to be raised at a subsequent meeting.	Any
withdrawn	Prior to discussion of the TDoc, its author has decided not to present it.	Any
treated	TDoc has been presented, but no other status is appropriate (for example, in the case of a CR pack, some CRs in it were revised, some postponed, and some reissued - none was approved).	Any, but principally intended for CR packs.
revised	TDoc will be modified and presented in a new TDoc.	Any
partially approved	Used for CR packs only. One or more CRs contained in the TDoc has been approved at TSG level; other CRs may have status revised, postponed, not pursued, etc.	CR packs
endorsed	The group believes that the TDoc is valid but has not reached a conclusion of "agreed" or "approved". May be used as a WG status where alternative solutions to a technical matter have been identified, and the choice between them is being left to the TSG. Also by a WG when asked to give an opinion on a matter (typically a WID) for which another WG is responsible.	Any, but principally intended for CRs where two or more solutions are proposed, WIDs belonging to another group.
merged	The TDoc is combined with one or more others and presented in a new, composite TDoc.	Any, but principally intended for pCRs, draftCRs and CRs.
reissued	Only used for the status of CRs in a CR Pack. Indicates that the CR appears unchanged in a different CR Pack created because one or more other CRs in the original pack is revised or withdrawn.	CRs within CR packs only.
replied to	Used for incoming Liaisons only. Indicates that an outgoing Liaison has been prepared in reply to this incoming Liaison.	LS in
conditionally agreed	Agreed, but conditional on a decision taken on a different TDoc, possibly in a different group.	Any, but principally intended for CRs.
conditionally approved	Approved, but conditional on a decision taken on a different TDoc, possibly in a different group.	Any, but principally intended for CRs (typically in a CR pack at TSG level)
not concluded	Discussion has started but has not finished. Typically used as a temporary status between the end of a meeting any post-meeting review or agreement/approval (for example, by email).	Any
not pursued	No further action to be taken. Replacement for "rejected", without the emotive implications sometimes inferred for "rejected".	Any
rejected	Retained for compatibility with legacy TDocs. Meaning identical to "not pursued". May be used by groups which are not sensitive to this value.	Any