MEC process for preparing a GS/GR draft before its status can be changed to “Stable draft”
1. MEC decides that the draft is ready to go to Stable (e.g. decision in a MEC plenary, email from Rapporteur to MEC list
seeking if any objection to move draft to Stable).
2. Rapporteur sends Early draft-ready to go to Stable email to Chantal, including the draft.
3. Chantal sends that draft to ETSI editHelp for clean-up (i.e. light editorial check to apply main ETSI Drafting Rules).
4. Rapporteur applies editorial changes/comments from editHelp. Output is a Stable draft.
5. Rapporteur, or Chantal, shall upload that Stable draft to the ETSI Portal in MEC/Drafts folder (in Microsoft Word form).
6. Stable draft (in pdf form, with filename: ***_stable draft.pdf) shall be made available in ETSI MEC Open area on
Draft availability in the Open Area of docbox
A draft shall be made available once it is “Stable”, unless there is an explicit group decision not to do so. See the “Stable draft” procedure for details. The document made available in the Open Area shall be properly watermarked.
A draft in "Early draft" stage may be made available if there is an explicit group decision to do so.
MEC approval process of Final drafts before publication
1. Rapporteur shall upload the first Final draft for review on the ETSI Portal in MEC/Drafts, and as a contribution for
Discussion, and informs Chantal.
2. Chantal starts a Remote Consensus (RC) for a review period over 2 weeks.
It is an RC for collecting comments only, it is not an RC for approval.
3. After the first RC the Rapporteur has 2 weeks (e.g. in Tech calls) to resolve the comments made during the RC.
The Rapporteur may use for that purpose a table for comments resolution. The result of the comment resolution shall be
documented in a contribution.
4. Once ready the Rapporteur shall upload the new (i.e. the second) Final draft for approval, based on the resolved
comments, in MEC/Drafts and as a contribution for Decision, and informs Chantal.
5. Chantal starts a RC for approval over 2 weeks.
6. Depending on RC results:
a. A new final draft including editorial RC comments is uploaded.
MEC list is informed of that and Chantal takes care of ETSI publication.
b. A new final draft including editorial and technical comments has to be uploaded, discussed in Tech call and sent to a
new RC (over 1 week) for approval.
c. If there are objections, these shall be resolved in a Tech call or in a dedicated call.
A new final draft including objections/comments resolution shall be uploaded and sent to a new RC (over 2 weeks) for
Making changes in Phase 1 specifications
1. First step is always a contribution towards Phase 2 work. In all cases (i.e. even when a change to a published Phase 1 text
is being proposed), this shall be submitted as “Other Contribution” for Decision, not a CR.
2. Once a contribution to Phase 2 in Step 1 is accepted, the authors (or other MEC members) need to decide if they want to
propagate the change back to Phase 1 specs. If so, they need to submit a CR to the appropriate Phase 1 GS detailing the
proposed change. Our CR process will carry a few add-ons on top of the standard ETSI process, as follows:
a. The CR template from ETSI shall be used.
b. In the cover page of the template, under “Other comments” the contributors MUST add the following:
i. “Consequence if not approved:” with appropriate text provided
ii. Link to the original approved contribution to Phase 2 on which the CR is based.
c. When creating the New Change Request, the Related Contributions should be completed with original approved
contribution to Phase 2 on which the CR is based.
3. The CR will be considered as follows:
a. Since the CR is based on an agreed contribution, consideration should be focused on whether the change needs to be
propagated to Phase 1, not on the details of the change itself. I.e. we should not be using this as an opportunity to reopen a
closed discussion. (Note the word “should” – there can, of course, be exceptions). If needed, the meeting chair will need to
exercise his/her judgement in keeping the discussion on track.
b. The CR will be discussed at the first TIMELY OPPORTUNITY – i.e. if it is submitted late, we will not discuss it.
c. If a CR is discussed and accepted in a non-plenary meeting, it shall remain open for 1 more cycle (confcall or meeting,
whatever happened earlier), at which point a “confirmation of agreement” will be asked for.
4. Once that’s done – the CR is accepted and should be implemented in BOTH the spec and on the FORGE site (see “ETSI Forge
guidance”) as soon as possible. Note that an open WI is ALWAYS required in order to make changes to a specification and
therefore a CR may trigger the opening of a WI and that process shall follow standard procedures.
Numbering Phase 2 Drafts Specifications:
• All Phase 2 drafts and subsequent publications shall have a version number with the leading integer “2” (format 2.x.x). This also
applies to specifications without a preceding specification in Phase 1 (i.e. without a specification with a version number 1.x.x).
• Precise numbering of the second and third positions shall be done in accordance with standard ETSI procedures.
Decision-making in non-plenary meetings (online or F2F)
• Decisions on contributions marked as “Other” or “CR” can be made (i.e. such contributions can be Accepted, Noted, etc.). Such
decisions are subject to other procedure detailed in this document, e.g. the procedure for late contributions, procedure for changes
to Phase 1 specs.
• Non-plenary meeting reports (minutes), meeting agenda can be accepted during a non-plenary meeting.
• All other decisions can be made either during a plenary meeting or using RC per standard ETSI procedures.
Late Contribution Procedures
• The purpose of this process is to retain the flexibility to allow us to consider late contributions, while recognizing and respecting
the fact that members/participants need enough time to be given an opportunity to review contributions, including reviewing it
with colleagues within their companies who are not attending the meeting.
• This process does not apply to procedural contribution types: LSin, LSout, Meeting Agenda, Meeting Report.
• It does apply to contribution types Change Request, New Draft, New WI Description/Proposal and Other Contribution.
• Contribution due dates are announced well in advance of the due date. At the current time (April 12, 2018) these are as follows:
o 23:59 UTC Monday of the week before a F2F meeting
o 23:59 UTC Thursday of the week before a conf. call.
o These are subject to change based on ISG agreements.
• Any contribution to a meeting submitted after the due date / time is considered “Late.” Late contributions are treated as follows:
o If time allows, the contribution will be presented (precise schedule depends on the agenda as put together by the meeting
o If the late contribution is submitted for Decision, objection to making a decision due to “lack of time to consider” shall be
respected and decision shall be postponed to the next meeting.
o If no such objections are made, the contribution is treated as a regular timely contribution.
• Any contribution to a meeting submitted on the day prior to the meeting or later is considered “Very late.” Very late contributions
are treated as follows:
o It is up to the meeting chair whether to include the contribution in the meeting agenda.
o If the contribution is included in the agenda AND the revised agenda is approved, an objection to presenting the contribution
on the grounds of “lack of time to review” can be made. If such an objection is made, the contribution is postponed to the next
o Otherwise, contribution is treated as a “Late contribution” – see process above.
ETSI Forge guidance
For ETSI Forge (https://forge.etsi.org/) related aspects (i.e. OpenAPI and protobuf MEC API specification description maintenance), please see https://mecwiki.etsi.org/index.php?title=OpenAPI_development_guidelines.