MEC GS/GR Rapporteur
A Rapporteur is the main editor of a MEC GS or GR deliverable, she/he is responsible of integrating all accepted contributions by MEC, that are relevant to the GS or GR she/he is in charge of. Also, when a draft is sent to ETSI editHelp, the Rapporteur is in charge of answering their questions.
The Rapporteur has to follow the ETSI Drafting Rules (EDRs) contained in the ETSI Directives (last version). For instance, Clause 3.2 of the EDRs is on Verbal forms for the expression of provisions (e.g. use of shall, should, may, can etc).
The Rapporteur’s guide and  the Guide to Writing World Class Standards may help Rapporteurs.
Note: in some cases, there may be the need for a Co-Rapporteur to help progress on the GS or GR work. It has to be agreed on a case by case by ISG MEC and this information will be reported in the MEC Work Programme as a remark.

How to manage baseline MEC GS/GR drafts?
It is recommended that a Rapporteur uploads a baseline GS/GR draft regularly on the ETSI Portal/ MEC/Drafts, e.g. when several technical contributions have been accepted, so any MEC member can access it and possibly use it as a draft baseline for further proposed changes.

In addition, Rapporteurs are encouraged to inform the ISG MEC 1) via email of such upload, or 2) upload this draft baseline to a MEC Tech call/meeting, for information.

Note: currently most of the MEC GRs deliverables are following the structures of GR 031 (MEC 5G integration) and GR 035 (on federation requirements). Rapporteurs of other work items are encouraged to consider these 2 studies as references and as a first working assumption. In any case, deviation from these 2 structures can be foreseen, e.g. based on the specific WI needs.

MEC process for preparing a GS/GR draft before its status can be changed to “Stable draft”

   1. The Rapporteur proposes to MEC (e.g. in a MEC plenary, or in an email to the MEC list) that the draft is ready to go to Stable, seeking if any
       objection within 1 week.
   2. The Rapporteur sends the Early draft-ready to go to Stable to Chantal.
   3. Chantal sends that draft to ETSI editHelp for clean-up (i.e. light editorial check to apply main ETSI Drafting Rules).
   4. The Rapporteur applies editorial changes/comments from editHelp, the output is a Stable draft.
   5. The Rapporteur, or Chantal, shall upload that Stable draft to the ETSI Portal in MEC/Drafts, ideally a version with change marks and a clean
       one (Word format in a zip file).
   6. The Stable draft (in pdf form, with filename: ***_stable draft.pdf) shall be made available in ETSI MEC Open area on
       docbox (https://docbox.etsi.org/ISG/MEC/Open), that is ensured by Chantal.
NOTE: steps 3 and 4 apply only to MEC GS/GR Stable drafts where the former GS/GR has not been published in the last 12 months.

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. 
A draft may be made available in "Early draft" stage if there is an explicit group decision to do so. 
Drafts made available in the Open Area shall be properly watermarked Draft, with a disclaimer on the first page; it is usually done by ETSI Secretariat (Chantal).  

MEC approval process of Final drafts before publication
   1. First, to be able to move a GR/GS "Stable draft" to a "Final draft", the Rapporteur should consult MEC via email, 
       seeking agreement/no objection over 1 week, or at a MEC plenary. The announcement of the planned Remote Consensus (RC), for review and
       for approval, is done at the same time.
   2. The Rapporteur shall upload the first Final draft for review on the ETSI Portal in MEC/Drafts, and as a contribution for
       Discussion, and inform Chantal.  
   3. Chantal starts a RC for a review period over 2 weeks, one week after its announcement to respect the ETSI Directives/TWP, clause 1.7.1.3
       Decision taken by Consensus in between meetings .
       It is an RC for collecting comments only, it is not an RC for approval.
   4. After the RC, the Rapporteur has up to 2 weeks (e.g. in Tech calls) to resolve the comments made during the RC, if any.
       The Rapporteur may use for that purpose a table for comments resolution. The result of the comments resolution shall be
       documented in a contribution.
   5. 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 inform Chantal.
   6. Chantal starts a RC for approval over 2 weeks.
   7. 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
             approval.

Approval process of WG Final drafts before publication
• The approval has to be done first within the WG, e.g. via WG Remote Consensus over 2 weeks of the Final draft version of the document.
• Once approved by the WG, an approval at the ISG level is required. It can be done via Remote Consensus as well, over 1 week.

Making changes in Phase 1, Phase 2 and Phase 3 specifications
MEC is currently in Phase 4. Changes to specifications related to previous phases are possible.
   1. First step is always a contribution towards Phase 4 work. In all cases (i.e. even when a text change to a published Phase 1,2 or 3
      deliverable is being proposed), this shall be submitted as “Other Contribution” for Decision, not a CR. 
   2. Once a contribution to Phase 4 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, Phase 2 and Phase 3 specs (or one of the three). If so, they need to submit a CR to the appropriate
       Phase 1, 2 or 3 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 4 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 4 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/2/3, 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.

Guidance for opening MEC new WIs for maintenance and for current Phase 4
New WIs to target Phase 3 maintenance can be opened. Also new WIs (on the same spec) targeting Phase 4 to include new features can be opened. These two actions are independent and can be performed at same time or in different moments. However, in such case the new WI for Phase 4 may also include Phase 3 maintenance updates.

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.

Numbering Phase 3 Drafts Specifications:
• All Phase 3 drafts and subsequent publications shall have a version number with the leading integer “3” (format 3.x.x). This also applies
  to specifications without a preceding specification in Phase 1 or 2 (i.e. without a specification with a version number 1.x.x or 2.x.x).
• Precise numbering of the second and third positions shall be done in accordance with standard ETSI procedures.

Numbering Phase 4 Drafts Specifications:
• All Phase 4 drafts and subsequent publications shall have a version number with the leading integer “4” (format 4.x.x). This also applies
  to specifications without a preceding specification in Phase 1, 2 or 3 (i.e. without a specification with a version number 1.x.x, 2.x.x or 3.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 Phases 1, 2 or 3 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, as per ETSI Directives/TWP, clause 1.7.13 Decision taken by
  Consensus in between meetings..

Late Contribution Procedures 
• The purpose of this process is to retain the flexibility to allow MEC 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 (February 2024) these are as follows:
    o 23:59 UTC Monday of the week before a F2F meeting, e.g. plenary.
    o 23:59 UTC Friday of the week before a Tech 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
       Chair).
    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
       meeting.
    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.

Last update: 13/06/2024