Gating Criteria (GC)

List of tasks that will be used to review each package prior to submission for Board ratification

This section is updated regularly.


TEMPLATE / GC flow 


GC Flow

LATEST TEMPLATES

Legal Disclaimer Templates
Legal Disclaimer Templates
Word File Legal Disclaimer
SUP File Legal Disclaimer


Validating Draft Documents

Content to Validate Validation When Using Word Documents Validation When Using GitHub/Markdown/HTML

Templates
  • Use the right document Template.
    • Ensure the document complies with the template.
  • Use the right document Template.
    • Ensure the document complies with the template.

File Name

    OMA-[DocType]-FunctionalName]-

Vx_y_z-YYYYMMDD-[Status]
  • Filename reflects the version of the Enabler under which the document was developed:
    • X – Major Version Indicator
      • Major versions contain major feature additions & MAY contain incompatibilities with previous documents or specifications revisions.
    • Y – Minor Version Indicator
      • It is incremented every time a minor change is made to the approved document version
    • Z – Service Indicator
      • The service indicator is increased each time a corrective update is made to the approved (not candidate) document.

Note

Please note in the case of OMA LwM2M Objects the Object-Version inside of the XML matches the Enabler Version Vx.y, the service indicator value (z) indicates the revision of the document (if the documents received changes after Board approval).

Front Cover

  • New OMASpecWorks Logo
  • Title
  • [Status] | [Version x.y.z] | [DD MM YYYY]
  • File Name
    • See above


  • <Name of Document>
  • Draft Version x.y – dd Mmm 2018
  • OMA-<Doc_type>-<FunctionalName>-Vx_y-2018mmdd-D

Note

Before the package is sent to Board Approval, the OMA staff will input the final date of the document

Header

  •  
  • File Name
  • Pages
  • OMA-TS-<FunctionalName>-Vx_y-2018mmdd-D Page 2 (12)
  • Relevant information is available in the "header" constructor.

Footer

  • Copyright year
  • OMA statement
  • © 2018 Open Mobile Alliance.
  • Used with the permission of the Open Mobile Alliance under the terms as stated in this document.
  • Relevant information is available in the "footer" constructor.

Legal Disclaimer

  • Statement
  • Copyright year
  • Ensure that you use the latest Template that will have the correct Legal Disclaimer.
  • The md2html conversion tool contains its own legal statement.
  • In any case, the GitHub repository needs to have a license document. (See Template repository)

Contents

  • Table of Contents
  • Table of Figures
  • Table of Tables


  • Relevant information is available in the "Index" constructor.


References

  • Normative (if applicable)
  • Informative

See Templates that include examples of references.

  • Check if there are any references (particularly normative) to draft documents (especially IETF). This is particularly problematic in documents being submitted for final Approval. From OMA-ORG-ReferencingPolicy-V1_0-20110524-A:

"When there is a reference to a document that is not considered stable in the referenced organization, a note should be added to the OMA Specification making such reference, that clearly states that the referenced document is not stable and, if possible, provides an indication of the potential date when it may become stable, and in the case of specific reference (see below), with the version number of the referenced document.
...
An OMA document being submitted for final approval, e.g. following the interoperability validation of a candidate specification, containing any normative reference that is not stable should be reviewed and a path to updating them should be identified if still necessary at the time of the update."

  • Check if there are references included in the body of the document that are omitted from the references section.
  • Check that URLs in references work.

See Templates that include examples of references.

  • Check if there are any references (particularly normative) to draft documents (especially IETF). This is particularly problematic in documents being submitted for final Approval. From OMA-ORG-ReferencingPolicy-V1_0-20110524-A:

"When there is a reference to a document that is not considered stable in the referenced organization, a note should be added to the OMA Specification making such reference, that clearly states that the referenced document is not stable and, if possible, provides an indication of the potential date when it may become stable, and in the case of specific reference (see below), with the version number of the referenced document.
...
An OMA document being submitted for final approval, e.g. following the interoperability validation of a candidate specification, containing any normative reference that is not stable should be reviewed and a path to updating them should be identified if still necessary at the time of the update."

  • Check if there are references included in the body of the document that are omitted from the references section.
  • Check that URLs in references work.

Terminology & Conventions

  • Definitions
  • Abbreviations
  • This content established the references and dependencies among technical requirements.

Document History

  • Approved History Vx.y.z
  • Draft History Vx.y.z
  • Confirm all CRs have been applied
  • Confirm Portal CR database is up to date
  • In this type of documents, the Draft History section is not used.

Static Conformance Requirements

  • Client
  • Server

Document Body

  • Links to sections & References

Constructors to use in GitHub when creating a Markdown/HTML document
Images/Figures

Note

The best way to view Image errors is to convert the document to PDF 


Validating Supporting Documents

Content to Validate Validation When Using Word Documents Validation When Using GitHub/Markdown/HTML

Templates
  • Use the right supporting document Template.
    • Ensure the document complies with the template.
  • Use the right XML document Template.
    • Ensure the document complies with the template.

File Name (Ensure file header information matches the ERELD)

  • OMA-SUP- [FunctionalName]-Vx_y_z-
    YYYYMMDD-[Status].(extension)
  • OMA-SUP- [FunctionalName]-Vx_y_z-YYYYMMDD-[Status].(extension)
    • OMA-SUP-XML_LWM2M_Connectivity_Monitoring-V1_0_1-20170704-A
    • LWM2M_Connectivity_Monitoring-v1_0_1.xml
  • See file name below.

OMA Permanent Document

  • File Name:
  • Type:
  • OMA-SUP-XML_FunctionalName-Vx_y_Z-YYYYMMDD-Status
    • e.g. OMA-SUP-XML_LWM2M_Connectivity_Monitoring-V1_0_1-20170704-A
  • XML
  • File Name:
  • Type:
  • Date: DD - MMM -YYY

Note

Before the package is sent to Board Approval, the OMA staff will input the final date of the document

SUP File naming SUP File Naming;

  • Baseline XML file




  • Where possible, the {publicNamePart} is derived from the specific parts of the namespace. The following is an example of the desired relationship.   

        • perm doc - OMA-SUP-XML_foo_barcode-V1_0-20190123-C.txt     

        • public doc - foo_barcode-v1_0.xml


  • Service indicator for the document is Incremented every time a corrective update is made to the Approved (not candidate) document version by the WG.

        • perm doc - OMA-SUP-XML_foo_barcode-V1_0_1-20190123-C.txt     

        • public doc - foo_barcode-v1_0_1.xml

In GitHub repositories the names of the SUP documents have changed, see below:

LWM2M_Connectivity_Monitoring.xml

File Names

The latest version is stored in the branch of the repo. Previous versions will be available in the "Release" function of the repo.

Public Reachable Information

  • Path:
  • Name:

Normative Information

  • TS File Name
  • OMA URL
  • Technical Comments

Change History
  • 08022017 Status changed to Approved by WG, WG Ref # OMA-WG-2017-0009-INP_LightweightM2M-V1_0_ERP_for_Final_Approval
  • N/A as documents developed using GitHub do not contain this section.

Legal Disclaimer

  • Check matches the appropriate SUP document Template
  • Check matches the appropriate SUP document Template

XML Validations

Note many other XML Validation tools are also available.

Note many other XML Validation tools are also available.
Line Endings
  • Ensure the line endings (CRLF) match the appropriate SUP document Template.
  • Ensure the line endings (CRLF) of extracted SUP files match the corresponding SUP document Template.
  • It is good practice for GitHub Repositories to include a .gitattributes file.


Validating ERELDs / README files

Note that if the release consists only of one document then the production of the ERELD is optional.

Content to Validate Validation When Using Word Documents Validation When Using GitHub/Markdown/HTML constructors
Template
  • Use the right supporting document Template.
    • Ensure the document complies with the template.
  • Use the right document Template.
    • Ensure the document complies with the template.
References

Document Content

List of Documents in the Package (Section 5)
  • Including any public working filenames and storage locations for SUP files
  • Including any public working filenames and storage locations for SUP files

    Note

     In the case of LwM2M Objects, the same ERELD covers all of the LwM2M Objects.

    • At the time of publication, the OMA staff will split this single ERELD into multiple ERELD's (one for each LwM2M Object enabler)
API Considerations (Section 7)
  • If enabler is an API then section 7 API Considerations should be completed.
  • If enabler is an API then section 7 API Considerations should be completed

Registration Requirements

Validating White Papers

Validating Draft Documents above applies, with the exception that White Papers no longer have to be approved as Candidate before final Approval i.e. draft White Papers can be Approved by the WG and then ratified by the BoD.

Templates

The OMA SpecWorks templates are available from Portal Templates and GitHub Templates.

Below are two examples of legal disclaimers:


Word File Legal Disclaimer

Word File Legal Disclaimer

Word File Legal Disclaimer

Use of this document is subject to all of the terms and conditions of the Use Agreement located at https://omaspecworks.org/about/policies-and-terms-of-use/.

Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice.

You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner.  The information contained in this document may be used, at your sole risk, for any purposes.  You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance.  The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms.  This copyright permission does not constitute an endorsement of the products or services.  The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.

Each Open Mobile Alliance member has agreed to use reasonable endeavours to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification.  However, the members do not have an obligation to conduct IPR searches.  The declared Essential IPR is publicly available to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at https://www.omaspecworks.org/about/intellectual-property-rights/.  The Open Mobile Alliance has not conducted an independent IPR review of this document and the information contained herein, and makes no representations or warranties regarding third-party IPR, including without limitation patents, copyrights or trade secret rights.  This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions.  Defined terms above are set forth in the schedule to the Open Mobile Alliance Application Form.

NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY THE OPEN MOBILE ALLIANCE OR ANY OPEN MOBILE ALLIANCE MEMBER OR ITS AFFILIATES REGARDING ANY OF THE IPR’S REPRESENTED ON THE “OMA IPR DECLARATIONS” LIST, INCLUDING, BUT NOT LIMITED TO THE ACCURACY, COMPLETENESS, VALIDITY OR RELEVANCE OF THE INFORMATION OR WHETHER OR NOT SUCH RIGHTS ARE ESSENTIAL OR NON-ESSENTIAL.

THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.

THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

© 20yy Open Mobile Alliance.
Used with the permission of the Open Mobile Alliance under the terms set forth above.



SUP File Legal Disclaimer

SUP File Legal Disclaimer

SUP File Legal Disclaimer

Copyright 20xx Open Mobile Alliance.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

The above license is used as a license under copyright only. Please
reference the OMA IPR Policy for patent licensing terms:
https://www.omaspecworks.org/about/intellectual-property-rights/