5.  IANA Considerations

   The following registration in the "ns" subregistry of the "IETF XML
   Registry" [RFC3688] was detailed in [RFC6087] and has been updated by
   IANA to reference this document.

       URI: urn:ietf:params:xml:ns:yang:ietf-template

       Registrant Contact: The IESG.

       XML: N/A, the requested URI is an XML namespace.

   The following assignment was detailed in [RFC6087] and has been
   updated by IANA in the "YANG Module Names" registry.  This document
   has also been added as a reference for the "YANG Module Names"
   registry itself as it contains the template necessary for
   registration in Appendix B.

         +-----------+-------------------------------------------+
         | Field     | Value                                     |
         +-----------+-------------------------------------------+
         | Name      | ietf-template                             |
         | Namespace | urn:ietf:params:xml:ns:yang:ietf-template |
         | Prefix    | temp                                      |
         | Reference | RFC 8407                                  |
         +-----------+-------------------------------------------+

                         YANG Registry Assignment

6.  Security Considerations

   This document defines documentation guidelines for NETCONF or
   RESTCONF content defined with the YANG data modeling language;
   therefore, it does not introduce any new or increased security risks
   into the management system.

7.  References

7.1.  Normative References

   [ID-Guidelines]
              Housley, R., "Guidelines to Authors of Internet-Drafts",
              December 2010,
              <https://www.ietf.org/standards/ids/guidelines/>.

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

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
              DOI 10.17487/RFC5378, November 2008,
              <https://www.rfc-editor.org/info/rfc5378>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [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,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

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

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [W3C.REC-xpath]
              Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", W3C Recommendation REC-xpath-19991116,
              November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.

7.2.  Informative References

   [IANA-MOD-NAMES]
              IANA, "YANG Module Names",
              <https://www.iana.org/assignments/yang-parameters/>.

   [IANA-XML] IANA, "IETF XML Registry",
              <https://www.iana.org/assignments/xml-registry/>.

   [RFC-STYLE]
              RFC Editor, "Style Guide",
              <http://www.rfc-editor.org/styleguide/>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

   [RFC4151]  Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
              RFC 4151, DOI 10.17487/RFC4151, October 2005,
              <https://www.rfc-editor.org/info/rfc4151>.

   [RFC4181]  Heard, C., Ed., "Guidelines for Authors and Reviewers of
              MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
              September 2005, <https://www.rfc-editor.org/info/rfc4181>.

   [RFC6087]  Bierman, A., "Guidelines for Authors and Reviewers of YANG
              Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
              January 2011, <https://www.rfc-editor.org/info/rfc6087>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

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

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,
              <https://www.rfc-editor.org/info/rfc7322>.

   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
              "RFC Streams, Headers, and Boilerplates", RFC 7841,
              DOI 10.17487/RFC7841, May 2016,
              <https://www.rfc-editor.org/info/rfc7841>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
              Routing Management (NMDA Version)", RFC 8349,
              DOI 10.17487/RFC8349, March 2018,
              <https://www.rfc-editor.org/info/rfc8349>.

Appendix A.  Module Review Checklist

   This section is adapted from RFC 4181.

   The purpose of a YANG module review is to review the YANG module for
   both technical correctness and adherence to IETF documentation
   requirements.  The following checklist may be helpful when reviewing
   an I-D:

   o  I-D Boilerplate -- verify that the document contains the required
      I-D boilerplate (see <https://www.ietf.org/id-info/
      guidelines.html>), including the appropriate statement to permit
      publication as an RFC, and that the I-D boilerplate does not
      contain references or section numbers.

   o  Abstract -- verify that the abstract does not contain references,
      that it does not have a section number, and that its content
      follows the guidelines in <https://www.ietf.org/id-info/
      guidelines.html>.

   o  Copyright Notice -- verify that the document has the appropriate
      text regarding the rights that document contributors provide to
      the IETF Trust [RFC5378].  Verify that it contains the full IETF
      Trust copyright notice at the beginning of the document.  The IETF
      Trust Legal Provisions (TLP) can be found at:

      <https://trustee.ietf.org/license-info/>

   o  Security Considerations section -- verify that the document uses
      the latest approved template from the Operations and Management
      (OPS) area website (see <https://trac.ietf.org/area/ops/trac/wiki/
      yang-security-guidelines>) and that the guidelines therein have
      been followed.

   o  IANA Considerations section -- this section must always be
      present.  For each module within the document, ensure that the
      IANA Considerations section contains entries for the following
      IANA registries:

         XML Namespace Registry: Register the YANG module namespace.

         YANG Module Registry: Register the YANG module name, prefix,
         namespace, and RFC number, according to the rules specified in
         [RFC6020].

   o  References -- verify that the references are properly divided
      between normative and informative references, that RFCs 2119 and
      8174 are included as normative references if the terminology
      defined therein is used in the document, that all references
      required by the boilerplate are present, that all YANG modules
      containing imported items are cited as normative references, and
      that all citations point to the most current RFCs, unless there is
      a valid reason to do otherwise (for example, it is okay to include
      an informative reference to a previous version of a specification
      to help explain a feature included for backward compatibility).
      Be sure citations for all imported modules are present somewhere
      in the document text (outside the YANG module).  If a YANG module
      contains reference or "description" statements that refer to an
      I-D, then the I-D is included as an informative reference.

   o  License -- verify that the document contains the Simplified BSD
      License in each YANG module or submodule.  Some guidelines related
      to this requirement are described in Section 3.1.  Make sure that
      the correct year is used in all copyright dates.  Use the approved
      text from the latest TLP document, which can be found at:

      <https://trustee.ietf.org/license-info/>

   o  Other Issues -- check for any issues mentioned in
      <https://www.ietf.org/id-info/checklist.html> that are not covered
      elsewhere.

   o  Technical Content -- review the actual technical content for
      compliance with the guidelines in this document.  The use of a
      YANG module compiler is recommended when checking for syntax
      errors.  A list of freely available tools and other information,
      including formatting advice, can be found at:

      <https://trac.ietf.org/trac/netconf/wiki>
       and
      <https://trac.ietf.org/trac/netmod/wiki>

      Checking for correct syntax, however, is only part of the job.
      It is just as important to actually read the YANG module document
      from the point of view of a potential implementor.  It is
      particularly important to check that "description" statements are
      sufficiently clear and unambiguous to allow interoperable
      implementations to be created.

Appendix B.  YANG Module Template

   <CODE BEGINS> file "ietf-template@2016-03-20.yang"

   module ietf-template {
     yang-version 1.1;

     // replace this string with a unique namespace URN value

     namespace "urn:ietf:params:xml:ns:yang:ietf-template";

     // replace this string, and try to pick a unique prefix

     prefix temp;

     // import statements here: e.g.,
     // import ietf-yang-types { prefix yang; }
     // import ietf-inet-types { prefix inet; }
     // identify the IETF working group if applicable

     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     // update this contact statement with your info

     contact
       "WG Web:   <http://datatracker.ietf.org/wg/your-wg-name/>
        WG List:  <mailto:your-wg-name@ietf.org>

        Editor:   your-name
                  <mailto:your-email@example.com>";

     // replace the first sentence in this description statement.
     // replace the copyright notice with the most recent
     // version, if it has been updated since the publication
     // of this document

     description
       "This module defines a template for other YANG modules.

        Copyright (c) <insert year> IETF Trust and the persons
        identified as authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions

        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

     // RFC Ed.: replace XXXX with actual RFC number and remove
     // this note

     // replace '2016-03-20' with the module publication date
     // the format is (year-month-day)

     revision 2016-03-20 {
       description
         "what changed in this revision";
       reference "RFC XXXX: <Replace With Document Title>";
     }

     // extension statements
     // feature statements
     // identity statements
     // typedef statements
     // grouping statements
     // data definition statements
     // augment statements
     // rpc statements
     // notification statements
     // DO NOT put deviation statements in a published module
   }

   <CODE ENDS>

Acknowledgments

   The structure and contents of this document are adapted from
   "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181], by
   C. M. Heard.

   The working group thanks Martin Bjorklund, Juergen Schoenwaelder,
   Ladislav Lhotka, Jernej Tuljak, Lou Berger, Robert Wilton, Kent
   Watsen, and William Lupton for their extensive reviews and
   contributions to this document.

Author's Address

   Andy Bierman
   YumaWorks

   Email: andy@yumaworks.com