Internet Engineering Task Force                         A. Somaraju,                        M. Veillette, Ed.
Internet-Draft                                     Tridonic GmbH & Co KG                                   Trilliant Networks Inc.
Intended status: Standards Track                       M. Veillette,                           A. Pelov, Ed.
Expires: April 29, November 3, 2017                          Trilliant Networks Inc.
                                                                A. Pelov                                         Acklio
                                                               R. Turner
                                                              Landis+Gyr
                                                             A. Minaburo
                                                                  Acklio
                                                        October 26, 2016
                                                             A. Somaraju
                                                   Tridonic GmbH & Co KG
                                                            May 02, 2017

                   YANG Schema Item iDentifier (SID)
                         draft-ietf-core-sid-00
                         draft-ietf-core-sid-01

Abstract

   YANG Schema Item iDentifiers (SID) are globally unique 64-bit numeric
   identifiers used to identify different
   YANG all items using a numeric identifier. used in YANG.  This document
   defines the
   registration semantics, the registration, and assignment processes of
   SIDs.  To enable the implementation of these processes, this document
   also defines a file format used to persist and publish assigned SIDs.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 29, November 3, 2017.

Copyright Notice

   Copyright (c) 2016 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Notation  . . . . . . . . . . . . . . . . . .   2   4
   3.  YANG Schema Item iDentifier (SID) . . . . . . . . . . . . . .   3
   4.  ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . .   4
   5.
   4.  ".sid" file format  . . . . . . . . . . . . . . . . . . . . .   6
   6.   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  "SID" range  11
     6.1.  "SID mega-range" registry . . . . . . . . . . . . . . . .  11
       6.1.1.  IANA SID Mega-Range Registry  . . . .   9
     7.2.  YANG module registry . . . . . . . .  11
       6.1.2.  IANA "RFC SID range assignment" sub-registries  . . .  12
     6.2.  "YANG module assignment" registry . . . . . . . . .  11
   8. . . .  13
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12  14
   Appendix A.  ".sid" file example  . . . . . . . . . . . . . . . .  13  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21  23

1.  Introduction

   This document describes

   Some of the registries required to manage SIDs and items defined in YANG [RFC7950] require the use of a
   file format used to persist
   unique identifier.  In both NETCONF [RFC6241] and publish RESTCONF [RFC8040],
   these identifiers are implemented using names.  To allow the assigned SIDs.

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   implementation of data models defined in this
   document are to be interpreted as described YANG in [RFC2119]. constrained devices
   and constrained networks, a more compact method to identify YANG
   items is required.  This compact identifier, called SID, is encoded
   using a 64-bit unsigned integer.  The following terms items are defined in [RFC7950]:

   o  action

   o  feature identified
   using SIDs:

   o  module  identities

   o  notification  data nodes

   o  RPC  RPCs and associated input(s) and output(s)

   o  schema node  actions and associated input(s) and output(s)

   o  schema tree  notifications and associated information
   o  submodule

   This specification also makes use of the following terminology:

   o  identifier: An identifier embodies the information required to
      distinguish what is being identified from all other things within
      its scope of identification.

   o  delta : Difference  YANG modules, submodules and features

   To minimize their size, SIDs are often represented as a difference
   between the current SID and a reference SID.  A
      reference SID  Such difference is defined for each context
   called "delta", shorthand for which "delta-encoded SID".  Conversion from
   SIDs to deltas are
      used.

   o  item: A schema node, an identity, a module, a submodule or a
      feature defined using the YANG modeling language.

   o  path: A path and back to SIDs is a string that identifies a schema node within the
      schema tree.  A path consists of the list of schema node
      identifier(s) separated by slashes ("/").  Schema node
      identifier(s) are always listed from the top-level schema node up
      to the targeted schema node. (e.g. "/system-state/clock/current-
      datetime")

3.  YANG Schema Item iDentifier (SID)

   Some of stateless process.  Each
   protocol implementing deltas must unambiguously define the items defined in reference
   SID for each YANG [RFC7950] require the use of a
   unique identifier.  In both NETCONF and RESTCONF, these identifiers item.

   SIDs are implemented using names.  To allow the implementation of data
   models defined in YANG in constrained devices and constrained
   networks, globally unique numbers, a more compact method to identify YANG items is required.

   This compact identifier, called SID, registration system is encoded using an unsigned
   integer.  To minimize its size, used in
   order to guarantee their uniqueness.  SIDs are often implemented using a
   delta from a reference SID and the current SID.  To guaranty the
   uniqueness of each assigned SID, SID ranges MUST be registered. registered in blocks
   called "SID ranges".  Section 7.1 6.1 provide more details about the
   registration process of SID range(s).

   To avoid duplicate assignment of SIDs, the registration

   Assignment of the SIDs
   assigned to YANG module(s) is recommended.  Section 7.2 provide more
   details about items can be automated, the registration process of YANG modules.

   The following items are identified using SIDs:

   o  identities
   o  data nodes

   o  RPCs and associated input(s) and output(s)

   o  actions and associated input(s) and output(s)

   o  notifications and associated information

   o  YANG modules, submodules and features

   Assignment of SIDs can be automated, the recommended recommended
   process to assign SIDs is as follows:

   o  A tool extracts the different items defined for a specific YANG
      module.

   o  The list of items is ordered in alphabetical order by type and
      label.  Valid types and label formats are described within the
      'ietf-sid-file' YANG module defined in Section 4.

   o  SIDs are assigned sequentially for from the entry point up to the size
      of the registered SID range.  This approach is recommended to
      minimize the serialization overhead, especially when delta
      encoding is implemented.

   o  If the number of items exceeds the SID range(s) allocated to a
      YANG module, an extra range is added for subsequent assignments.

   SIDs are assigned permanently, items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.  This
   process can also be automated using the same method described above
   except that the assignment need to be restarted restart from the highest SID already assigned.
   assigned plus one.

   To avoid duplicate assignment of SIDs, the registration of the SIDs
   assigned to YANG module(s) is recommended.  Section 5 6.2 provide more
   details about the registration process of YANG modules and associated
   SIDs.  To enable the implementation of this registry, Section 4
   defines a standard file format used to store and publish SIDs.

4.  ".sid" file lifecycle

2.  Terminology and Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following activity diagram summarize the life cycle of ".sid"
   files.

         +---------------+
    O    | Creation terms are defined in [RFC7950]:

   o  action

   o  feature

   o  module

   o  notification

   o  RPC

   o  schema node

   o  schema tree

   o  submodule

   This specification also makes use of the following terminology:

   o  delta : Difference between the current SID and a |
   -|- ->| YANG module   |
   / \   +---------------+
                 |
                 V
          /-------------\
         / Standardized  \ yes
         \ YANG module ? /-------------+
          \-------------/              |
                 | no                  |
                 V                     V
          /-------------\      +---------------+
         / Constrained   \ yes | reference SID.  A
      reference SID range     |
     +-->\ application ? /---->| registration  |
     |    \-------------/      +---------------+
     |           | no                  |
     |           V                     V
     |   +---------------+     +---------------+
     +---| YANG module   |     | .sid file     |
         | update        |     | generation    |
         +---------------+     +---------------+
                                       |
                                       V
                                /-------------\      +---------------+
                               /  Publicly     \ yes | is defined for each context for which deltas are
      used.

   o  item: A schema node, an identity, a module, a submodule or a
      feature defined using the YANG module   |
                 +------------>\  available ?  /---->| registration  |
                 |              \-------------/      +---------------+
                 |                     | no                  |
                 |                     +---------------------+
                 |                     V
         +---------------+     +---------------+
         | .sid file     |     | Update modeling language.

   o  path: A path is a string that identifies a schema node within the
      schema tree.  A path consists of the |
         | update based  |     | list of schema node
      identifier(s) separated by slashes ("/").  Schema node
      identifier(s) are always listed from the top-level schema node up
      to the targeted schema node. (e.g. "/system-state/clock/current-
      datetime")

   o  YANG module   |
         | on previous   |     | or include(s) |
         | .sid file     |     | or import(s)  |
         +---------------+     +---------------+
                 ^                     |
                 |                     V
                 |              /-------------\      +---------------+
                 |             /  More SIDs    \ yes | Extra range   |
                 |             \  required ?   /---->| assignment    |
                 |              \-------------/      +---------------+
                 |                     | no                  |
                 +---------------------+---------------------+ Schema Item iDentifier (SID): Unsigned integer used to
      identify different YANG items.

3.  ".sid" file lifecycle

   YANG is a language designed to model data sent between clients and
   servers using one of the compatible protocol (e.g.  NETCONF
   [RFC6241], RESCONF [RFC8040] and CoMI [I-D.ietf-core-comi]).  A YANG
   module defines hierarchies of data, including configuration, state
   data, RPCs, actions and notifications.

   YANG modules are not necessary created in the context of constrained
   applications.  YANG modules can be implemented using NETCONF
   [RFC6241] or RESTCONF [RFC8040] without the need to assign SIDs.

   As needed, authors of YANG modules can assign SIDs to their YANG
   modules.  This process starts by the registration of a SID range.
   Once a SID range is registered, the owner of this range assigns sub-ranges sub-
   ranges to each YANG module in order to generate the associated ".sid"
   files.  Generation of ".sid" files SHOULD be performed using an
   automated tool.

   Registration of the .sid file associated to a YANG module is optional
   but recommended to promote interoperability between devices and to
   avoid duplicate allocation of SIDs to a single YANG module.

   The following activity diagram summarizes the creation of a YANG
   module and its associated .sid file.

          +---------------+
     O    | Creation of a |
    -|- ->| YANG module   |
    / \   +---------------+
                  |
                  V
           /-------------\
          / Standardized  \ yes
          \ YANG module ? /-------------+
           \-------------/              |
                  | no                  |
                  V                     V
           /-------------\      +---------------+
          / Constrained   \ yes | SID range     |
      +-->\ application ? /---->| registration  |
      |    \-------------/      +---------------+
      |           | no                  |
      |           V                     V
      |   +---------------+     +---------------+
      +---| YANG module   |     | SID sub-range |
          | update        |     | assignment    |
          +---------------+     +---------------+
                                        |
                                        V
                                +---------------+
                                | .sid file     |
                                | generation    |
                                +---------------+
                                        |
                                        V
                                 /-------------\      +---------------+
                                /  Publicly     \ yes | YANG module   |
                                \  available ?  /---->| registration  |
                                 \-------------/      +---------------+
                                        | no                  |
                                        +---------------------+
                                        |
                                      [DONE]

   Each time a YANG module or one of its imported module(s) or included
   sub-module(s) is updated, the ".sid" file MAY need to be updated.
   This update SHOULD also be performed using an automated tool.

   If a new revision requires more SIDs than initially allocated, a new
   SID range MUST be added to the assignment ranges as defined in the
   ".sid" file header.  These extra SIDs are used for subsequent
   assignments.

5.
   assignements.

   The following activity diagram summarizes the update of a YANG module
   and its associated .sid file.

          +---------------+
     O    | Update of the |
    -|- ->| YANG module   |
    / \   | or include(s) |
          | or import(s)  |
          +---------------+
                  |
                  V
           /-------------\      +----------------+
          /  More SIDs    \ yes | Extra sub-range|
          \  required ?   /---->| assignment     |
           \-------------/      +----------------+
                  | no                  |
                  +---------------------+
                  |
                  V
          +---------------+
          | .sid file     |
          | update based  |
          | on previous   |
          | .sid file     |
          +---------------+
                  |
                  V
           /-------------\      +---------------+
          /  Publicly     \ yes | YANG module   |
          \  available ?  /---->| registration  |
           \-------------/      +---------------+
                  | no                  |
                  +---------------------+
                  |
                [DONE]

4.  ".sid" file format

   ".sid" files are used to persist and publish SIDs assigned to the
   different YANG items of a specific YANG module.  The following YANG
   module defined the structure of this file, encoding is performed
   using the rules defined in [RFC7951].

   <CODE BEGINS> file "ietf-sid-file@2015-12-16.yang"
   module ietf-sid-file {
     namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file";
     prefix sid;
     organization
       "IETF Core Working Group";

     contact
    "Ana Minaburo
     <ana@ackl.io>

     Alexander
       "Alexander Pelov
        <mailto:a@ackl.io>

        Abhinav Somaraju
        <mailto:abhinav.somaraju@tridonic.com>

        Laurent Toutain
        <Laurent.Toutain@telecom-bretagne.eu>

        Randy Turner
        <mailto:Randy.Turner@landisgyr.com>

        Michel Veillette
        <mailto:michel.veillette@trilliantinc.com>";

     description
       "This module define the structure of the .sid files.
        .sid files contains the identifiers (SIDs) assigned
        to the different items defined in a YANG module.
        SIDs are used to encode a data model defined in YANG
        using CBOR.";

     revision 2015-12-16 {
       description
         "Initial revision.";
       reference
         "RFC XXXX";
         // RFC Ed.: replace XXXX with RFC number assigned to
         // draft-ietf-core-yang-cbor and remove this note
     }

     typedef yang-identifier {
       type string {
         length "1..max";
         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
       }
       description
         "A YANG identifier string as defined by the 'identifier'
          rule in Section 12 of RFC 6020.";
     }

     typedef revision-identifier {
       type string {
         pattern '\d{4}-\d{2}-\d{2}';
       }
       description
         "Represents a date in YYYY-MM-DD format.";
     }

     leaf module-name {
       type yang-identifier;
       description
         "Name of the module associated with this .sid file.";
     }

     leaf module-revision {
       type revision-identifier;
       description
         "Revision of the module associated with this .sid file.
          This leaf is not present if no revision statement is
          defined in the YANG module.";
     }

     list assigment-ranges {
       key "entry-point";
       description
         "Range(s) of SIDs available for assignment to the
          different items defined by the associated module.";

       leaf entry-point {
         type uint32;
         mandatory true;
         description
           "Lowest SID available for assignment.";
       }

       leaf size {
         type uint16;
         mandatory true;
         description
           "Number of SIDs available for assignment.";
       }
     }

     list items {
       key "type label";
       description
         "List of items defined by the associated YANG module.";

       leaf type {
         type string {
           pattern 'Module|Submodule|feature|' +
                   'identity$|node$|notification$|rpc$|action$';
         }
         mandatory true;
         description
           "Item type assigned, this field can be set to:
             - 'Module'
             - 'Submodule'
             - 'feature'
             - 'identity'
             - 'node'
             - 'notification'
             - 'rpc'
             - 'action'";
       }

       leaf label {
         type string;
         mandatory true;
         description
           "Label associated to this item, can be set to:
             - a module name
             - a submodule name
             - a feature name
             - a base identity encoded as
               '/<base identity name>'
             - an identity encoded as
               '/<base identity name>/<identity name>'
             - a schema data node path";
       }

       leaf sid {
         type uint32;
         mandatory true;
         description "Identifier assigned to this YANG item.";
       }
     }
   }
   <CODE ENDS>

6.

5.  Security Considerations

   The security considerations of [RFC7049] and [RFC7950] apply.

   This document defines an a new type of identifier used to encode data
   models defined in YANG [RFC7950].  As such, this identifier does not
   contribute to any new security issues in addition of those identified
   for the specific protocols or contexts for which it is used.

7.

6.  IANA Considerations

7.1.  "SID" range

6.1.  "SID mega-range" registry

   IANA is requested to create a

   The name of this registry for YANG Schema Item
   iDentifier (SID) ranges. is "SID mega-range".  This registry needs is used
   to guarantee that delegate the
   ranges registered do not overlap.  The registry SHALL record management of block of SIDs for each
   entry: third party's (e.g.
   SDO, registrar).

   Each entry in this registry must include:

   o  The entry point (first entry) of the registered SID range.

   o  The size of the registered SID range.

   o  The contact information of the owner of the range such as requesting organization including:

      *  Organization name

      *  Primary contact name, email address, and phone number. number

      *  Secondary contact name, email address, and phone number

   The initial entry in this registry is allocated to IANA:

   +-------------+---------+-------------------+
   | Entry Point | Size    | Organization name |
   +-------------+---------+-------------------+
   | 0           | 1000000 | IANA              |
   +-------------+---------+-------------------+

   The IANA policy policies for future additions to this registry are
   "Hierarchical Allocation, Expert Review" [RFC5226].  Prior to a first
   allocation, the requesting organization must demonstrate a functional
   registry infrastructure.  On subsequent allocation request(s), the
   organization must demonstrate the exhaustion of the prior range.
   These conditions need to be asserted by the assigned expert(s).

6.1.1.  IANA SID Mega-Range Registry

   The first million SIDs assigned to IANA is split into four tiers sub-divided as
   follows: follow:

   o  The range of 0 to 999 and 0x40000000 to 0xFFFFFFFFFFFFFFFF are is reserved for future extensions of extensions.  The IANA
      policy for this protocol.  Allocation
      within these ranges require IETF review or IESG approval. range is "IETF review" [RFC5226].

   o  The range of 1000 to 59999 59,999 is reserved for standardized YANG
      modules. modules defined
      in RFCs.  The IANA policy for future additions to this sub-
      registry is "RFC required" [RFC5226].  Allocation within this
      range requires publishing of the associated ".yang" and ".sid" files.  (Specification required.)
      files in the YANG module registry.

   o  The range of 60000 60,000 to 99999 99,999 is reserved for experimental YANG
      modules.  Use of this  This range MUST NOT be used in operational deployments
      since these SIDs are not globally unique which limit their
      interoperability.

   o  The IANA policy for this range of 100000 to 0x3FFFFFFF is available on a first come
      first served basis.  The only information required from the
      registrant is a valid contact information. "Experimental
      use" [RFC5226].

   o  The recommended size range of the SID ranges allocated 100,000 to 999,999 is 1,000 reserved for private use and 10,000 standardized YANG
      modules.  The IANA policy for standard development organizations (SDOs).  Registrants MAY
      request fewer or more SIDs based on their expected, sat needs. future additions to this sub-
      registry is "Specification Required" [RFC5226].  Allocation of a significantly larger SID range MAY required IETF
      review or IESG approval.  IANA MAY delegate within
      this registration
      process to one or multiple sub-registries.  The recommended size range requires publishing of the SID range allocation for a sub-registry is 1,000,000.

   +------------+-----------------+------------------------------------+ associated ".yang" and
      ".sid" files in the YANG module registry.

   +-------------+---------------+------------------------+
   | Entry      | Size            | Registration Procedures            |
   | Point | Size          | IANA policy            |
   +------------+-----------------+------------------------------------+
   +-------------+---------------+------------------------+
   | 0           | 1,000         | IETF review or IESG approval            |
   | 1,000       | 59,000        | Specification and associated       |
   |            |                 | ".yang" and ".sid" files RFC required           |
   | 60,000      | 40,000        | Experimental use       |
   | 100,000     | 0x3ffe7960      | Contact information is required.   |
   |            |                 | Registration of the module name(s) |
   |            |                 | and associated ".yang" and ".sid"  |
   |            |                 | files are optional.                |
   | 0x40000000 | 2^64-0x40000000 1,000,000,000 | Specification required, expert Required |
   |            |                 | review                             |
   +------------+-----------------+------------------------------------+

7.2.  YANG module registry

   Each registered
   +-------------+---------------+------------------------+

   The size of SID range can be used to assign SIDs to one or more
   YANG modules.  To track which YANG modules have been assigned and to
   avoid duplicate allocation, IANA is requested to provide a method to
   register and query the following information:

   o  The YANG module name

   o  The contact information should be between 50%
   and 60% of the author

   o  The specification reference

   o  The associated ".yang" file(s) (Optional)

   o  The associated ".sid" file (Optional)

   Registration current number of YANG modules items.  This headroom allows
   assignment within the same range of new YANG items introduced by
   subsequent revisions.  A larger SID range size may be requested by
   the authors if this recommendation is optional.  When a considered insufficient.  It is
   important to note that an extra SID range can be allocated to
   existing YANG module is
   registered, the registrant MUST provide if the module name and contact
   information and/or a specification reference. initial ranges(s) are exhausted.

6.1.2.  IANA "RFC SID range assignment" sub-registries

   The registration name of the associated ".yang" and ".sid" files this sub-registry is
   optional.  When provided, the validity of the files MUST be verified. "RFC SID range assignment".  This can be accomplished by a YANG validation tool specially modified
   sub-registry corresponds to support ".sid" file verification.  The the SID entry point 1000, size 59000.
   Each entry in this sub-registry must include the SID range specified within
   the ".sid" file SHOULD also be checked against entry
   point, the "SID" SID range
   registry (Section 7.1) and against size, the other YANG modules registered
   to detect any duplicate use of SIDs. module name, the RFC number.

   Initial entries in this registry are as follows:

   +-------------+------+-----------------+-------------------+

   +------------+------+-----------------+-----------------------------+
   | Entry Point      | Size | Module name     | Reference                   |
   +-------------+------+-----------------+-------------------+
   | Point      |      |                 |                             |
   +------------+------+-----------------+-----------------------------+
   | 1000       | 100  |                 | Reserved for CoMI                |
   |            |      |                 | [I-D.ietf-core-comi]        |
   | 1100       | 400  | iana-if-type    | [RFC7224]                   |
   | 1500       | 100  | ietf-interfaces | [RFC7223]                   |
   | 1600       | 100  | ietf-ip         | [RFC7277]                   |
   | 1700       | 100  | ietf-system     | [RFC7317]                   |
   +-------------+------+-----------------+-------------------+

8.
   +------------+------+-----------------+-----------------------------+

6.2.  "YANG module assignment" registry

   The name of this registry is "YANG module assignment".  This registry
   is used to track which YANG modules have been assigned and the
   specific YANG items assignment.  Each entry in this sub-registry must
   include:

   o  The YANG module name

   o  The associated ".yang" file(s)

   o  The associated ".sid" file

   The validity of the ".yang" and ".sid" files added to this registry
   MUST be verified.

   o  The syntax of the registered ".yang" and ".sid" files must be
      valid.

   o  Each YANG item defined by the registered ".yang" file must have a
      corresponding SID assigned in the ".sid" file.

   o  Each SID is assigned to a single YANG item, duplicate assignment
      is not allowed.

   o  The SID range(s) defined in the ".sid" file must be unique, must
      not conflict with any other SID ranges defined in already
      registered ".sid" files.

   o  The ownership of the SID range(s) should be verify.

   The IANA policy for future additions to this registry is "First Come
   First Served" as described in [RFC5226].

7.  Acknowledgments

   The authors would like to thank Carsten Bormann for his help during
   the development of this document and his useful comments during the
   review process.

9.

8.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <http://www.rfc-editor.org/info/rfc7049>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <http://www.rfc-editor.org/info/rfc7950>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <http://www.rfc-editor.org/info/rfc7951>.

9.2.

8.2.  Informative References

   [I-D.ietf-netconf-restconf]

   [I-D.ietf-core-comi]
              Stok, P., Bierman, A., Bjorklund, Veillette, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-17 A. Pelov, "CoAP
              Management Interface", draft-ietf-core-comi-00 (work in
              progress), September 2016. January 2017.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              <http://www.rfc-editor.org/info/rfc7224>.

   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management",
              RFC 7277, DOI 10.17487/RFC7277, June 2014,
              <http://www.rfc-editor.org/info/rfc7277>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <http://www.rfc-editor.org/info/rfc7317>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <http://www.rfc-editor.org/info/rfc8040>.

Appendix A.  ".sid" file example

   The following .sid file (ietf-system@2014-08-06.sid) have been
   generated using the following yang modules:

   o  ietf-system@2014-08-06.yang

   o  ietf-yang-types@2013-07-15.yang

   o  ietf-inet-types@2013-07-15.yang

   o  ietf-netconf-acm@2012-02-22.yang

   o  iana-crypt-hash@2014-04-04.yang

   {
    "assignment-ranges": [
     {
      "entry-point": 1700,
      "size": 100
     }
    ],
    "module-name": "ietf-system",
    "module-revision": "2014-08-06",
    "items": [
     {
      "type": "Module",
      "label": "ietf-system",
      "sid": 1700
     },
     {
      "type": "feature",
      "label": "authentication",
      "sid": 1701
     },
     {
      "type": "feature",
      "label": "dns-udp-tcp-port",
      "sid": 1702
     },
     {
      "type": "feature",
      "label": "local-users",
      "sid": 1703
     },
     {
      "type": "feature",
      "label": "ntp",
      "sid": 1704
     },
     {
      "type": "feature",
      "label": "ntp-udp-port",
      "sid": 1705
     },
     {
      "type": "feature",
      "label": "radius",
      "sid": 1706
     },
     {
      "type": "feature",
      "label": "radius-authentication",
      "sid": 1707
     },
     {
      "type": "feature",
      "label": "timezone-name",
      "sid": 1708
     },
     {
      "type": "identity",
      "label": "/authentication-method",
      "sid": 1709
     },
     {
      "type": "identity",
      "label": "/authentication-method/local-users",
      "sid": 1710
     },
     {
      "type": "identity",
      "label": "/authentication-method/radius",
      "sid": 1711
     },
     {
      "type": "identity",
      "label": "/radius-authentication-type",
      "sid": 1712
     },
     {
      "type": "identity",
      "label": "/radius-authentication-type/radius-chap",
      "sid": 1713
     },
     {
      "type": "identity",
      "label": "/radius-authentication-type/radius-pap",
      "sid": 1714
     },
     {
      "type": "node",
      "label": "/system",
      "sid": 1715
     },
     {
      "type": "node",
      "label": "/system-state",
      "sid": 1716
     },
     {
      "type": "node",
      "label": "/system-state/clock",
      "sid": 1717
     },
     {
      "type": "node",
      "label": "/system-state/clock/boot-datetime",
      "sid": 1718
     },
     {
      "type": "node",
      "label": "/system-state/clock/current-datetime",
      "sid": 1719
     },
     {
      "type": "node",
      "label": "/system-state/platform",
      "sid": 1720
     },
     {
      "type": "node",
      "label": "/system-state/platform/machine",
      "sid": 1721
     },
     {
      "type": "node",
      "label": "/system-state/platform/os-name",
      "sid": 1722
     },
     {
      "type": "node",
      "label": "/system-state/platform/os-release",
      "sid": 1723
     },
     {
      "type": "node",
      "label": "/system-state/platform/os-version",
      "sid": 1724
     },
     {
      "type": "node",
      "label": "/system/authentication",
      "sid": 1725
     },
     {
      "type": "node",
      "label": "/system/authentication/user",
      "sid": 1726
     },
     {
      "type": "node",
      "label": "/system/authentication/user-authentication-order",
      "sid": 1727
     },
     {
      "type": "node",
      "label": "/system/authentication/user/authorized-key",
      "sid": 1728
     },
     {
      "type": "node",
      "label": "/system/authentication/user/authorized-key/algorithm",
      "sid": 1729
     },
     {
      "type": "node",
      "label": "/system/authentication/user/authorized-key/key-data",
      "sid": 1730
     },
     {
      "type": "node",
      "label": "/system/authentication/user/authorized-key/name",
      "sid": 1731
     },
     {
      "type": "node",
      "label": "/system/authentication/user/name",
      "sid": 1732
     },
     {
      "type": "node",
      "label": "/system/authentication/user/password",
      "sid": 1733
     },
     {
      "type": "node",
      "label": "/system/clock",
      "sid": 1734
     },
     {
      "type": "node",
      "label": "/system/clock/timezone/timezone-name/timezone-name", "/system/clock/timezone-name",
      "sid": 1735
     },
     {
      "type": "node",
      "label": "/system/clock/timezone/timezone-utc-offset/timezone-utc-offset", "/system/clock/timezone-utc-offset",
      "sid": 1736
     },
     {
      "type": "node",
      "label": "/system/contact",
      "sid": 1737
     },
     {
      "type": "node",
      "label": "/system/dns-resolver",
      "sid": 1738
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/options",
      "sid": 1739

     },
     {
      "type": "node",
      "label": "/system/dns-resolver/options/attempts",
      "sid": 1740
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/options/timeout",
      "sid": 1741
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/search",
      "sid": 1742
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/server",
      "sid": 1743
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/server/name",
      "sid": 1744
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/server/transport/udp-and-tcp/udp-and-tcp", "/system/dns-resolver/server/udp-and-tcp",
      "sid": 1745
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/server/transport/udp-and-tcp/udp-and-tcp/address", "/system/dns-resolver/server/udp-and-tcp/address",
      "sid": 1746
     },
     {
      "type": "node",
      "label": "/system/dns-resolver/server/transport/udp-and-tcp/udp-and-tcp/port", "/system/dns-resolver/server/udp-and-tcp/port",
      "sid": 1747
     },
     {
      "type": "node",
      "label": "/system/hostname",
      "sid": 1748
     },
     {
      "type": "node",
      "label": "/system/location",
      "sid": 1749
     },
     {
      "type": "node",
      "label": "/system/ntp",
      "sid": 1750
     },
     {
      "type": "node",
      "label": "/system/ntp/enabled",
      "sid": 1751
     },
     {
      "type": "node",
      "label": "/system/ntp/server",
      "sid": 1752
     },
     {
      "type": "node",
      "label": "/system/ntp/server/association-type",
      "sid": 1753
     },
     {
      "type": "node",
      "label": "/system/ntp/server/iburst",
      "sid": 1754
     },
     {
      "type": "node",
      "label": "/system/ntp/server/name",
      "sid": 1755
     },
     {
      "type": "node",
      "label": "/system/ntp/server/prefer",
      "sid": 1756
     },
     {
      "type": "node",
      "label": "/system/ntp/server/transport/udp/udp", "/system/ntp/server/udp",
      "sid": 1757
     },
     {
      "type": "node",
      "label": "/system/ntp/server/transport/udp/udp/address", "/system/ntp/server/udp/address",
      "sid": 1758
     },
     {
      "type": "node",
      "label": "/system/ntp/server/transport/udp/udp/port", "/system/ntp/server/udp/port",
      "sid": 1759
     },
     {
      "type": "node",
      "label": "/system/radius",
      "sid": 1760
     },
     {
      "type": "node",
      "label": "/system/radius/options",
      "sid": 1761
     },
     {
      "type": "node",
      "label": "/system/radius/options/attempts",
      "sid": 1762
     },
     {
      "type": "node",
      "label": "/system/radius/options/timeout",
      "sid": 1763
     },
     {
      "type": "node",
      "label": "/system/radius/server",
      "sid": 1764
     },
     {
      "type": "node",
      "label": "/system/radius/server/authentication-type",
      "sid": 1765
     },
     {
      "type": "node",
      "label": "/system/radius/server/name",
      "sid": 1766
     },
     {
      "type": "node",
      "label": "/system/radius/server/transport/udp/udp", "/system/radius/server/udp",
      "sid": 1767
     },
     {
      "type": "node",
      "label": "/system/radius/server/transport/udp/udp/address", "/system/radius/server/udp/address",
      "sid": 1768
     },
     {
      "type": "node",
      "label": "/system/radius/server/transport/udp/udp/authentication-port", "/system/radius/server/udp/authentication-port",
      "sid": 1769
     },
     {
      "type": "node",
      "label": "/system/radius/server/transport/udp/udp/shared-secret", "/system/radius/server/udp/shared-secret",
      "sid": 1770
     },
     {
      "type": "rpc",
      "label": "/set-current-datetime",
      "sid": 1771
     },
     {
      "type": "rpc",
      "label": "/set-current-datetime/input/current-datetime",
      "sid": 1772
     },
     {
      "type": "rpc",
      "label": "/system-restart",
      "sid": 1773
     },
     {
      "type": "rpc",
      "label": "/system-shutdown",
      "sid": 1774
     }
    ]
   }

Authors' Addresses

   Abhinav Somaraju (editor)
   Tridonic GmbH & Co KG
   Farbergasse 15
   Dornbirn, Vorarlberg  6850
   Austria

   Phone: +43664808926169
   Email: abhinav.somaraju@tridonic.com

   Michel Veillette (editor)
   Trilliant Networks Inc.
   610 Rue du Luxembourg
   Granby, Quebec  J2J 2V2
   Canada

   Phone: +14503750556
   Email: michel.veillette@trilliantinc.com
   Alexander Pelov (editor)
   Acklio
   2bis rue de la Chataigneraie
   Cesson-Sevigne, Bretagne  35510
   France

   Email: a@ackl.io

   Randy Turner
   Landis+Gyr
   30000 Mill Creek Ave
   Suite 100
   Alpharetta, GA  30022
   US

   Phone: ++16782581292
   Email: randy.turner@landisgyr.com
   URI:   http://www.landisgyr.com/

   Ana Minaburo
   Acklio
   2bis rue de la chataigneraie
   Cesson-Sevigne, Bretagne  35510
   France

   Email: ana@ackl.io

   Abhinav Somaraju
   Tridonic GmbH & Co KG
   Farbergasse 15
   Dornbirn, Vorarlberg  6850
   Austria

   Phone: +43664808926169
   Email: abhinav.somaraju@tridonic.com