draft-ietf-netconf-http-client-server.xml

<?xml version="1.0" encoding="UTF-8"?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     consensus="true"
     submissionType="IETF"
     docName="draft-ietf-netconf-http-client-server-latest"
     ipr="trust200902">
  <front>
    <title abbrev="Groupings for HTTP Clients and Servers">YANG Groupings for
      HTTP Clients and HTTP Servers</title>
    <author fullname="Kent Watsen" initials="K." surname="Watsen">
      <organization>Watsen Networks</organization>
      <address>
        <email>kent+ietf@watsen.net</email>
      </address>
    </author>
    <date/>
    <area>Operations</area>
    <workgroup>NETCONF Working Group</workgroup>
    <abstract>
      <t>This document presents three YANG 1.1 modules as follows. The
        "iana-http-versions" module defines a YANG "typedef" for HTTP
        protocol versions.  The "ietf-http-client" module defines a YANG
        "grouping" for configuring an HTTP client's ability to communicate
        with an HTTP service endpoint.  The "ietf-http-server" module
        defines a "grouping" for configuring an HTTP server's service
        endpoints.</t>
    </abstract>
    <note title="Editorial Note (To be removed by RFC Editor)">
      <t>This draft contains placeholder values that need to be replaced
        with finalized values at the time of publication. This note summarizes
        all of the substitutions that are needed. No other RFC Editor
        instructions are specified elsewhere in this document.</t>
      <t>Artwork in this document contains shorthand references to drafts in
        progress.  Please apply the following replacements (note: not all may be present):
        <list style="symbols">
          <t><spanx style="verb">GGGG</spanx> --&gt; the assigned RFC value for this draft</t>
          <t><spanx style="verb">HHHH</spanx> --&gt; the assigned RFC value for draft-ietf-netconf-netconf-client-server</t>
          <t><spanx style="verb">IIII</spanx> --&gt; the assigned RFC value for draft-ietf-netconf-restconf-client-server</t>
          <t><spanx style="verb">JJJJ</spanx> --&gt; the assigned RFC value for draft-ietf-netconf-udp-client-server</t>
        </list>
      </t>
      <t>Artwork in this document contains placeholder values for the date of
        publication of this draft. Please apply the following replacement:
        <list style="symbols">
          <t><spanx style="verb">YYYY-MM-DD</spanx> --&gt; the publication date of this draft</t>
        </list>
      </t>
      <t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
        the text "one or more YANG modules" and, later, "modules".  This text is sourced
        from a file in a context where it is unknown how many modules a draft defines.
        The text is not wrong as is, but it may be improved by stating more directly how
        many modules are defined.</t>
      <t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
          a self-reference to this draft, along with a corresponding reference in
          the Appendix.  Please replace the self-reference in this section with "This RFC"
          (or similar) and remove the self-reference in the "Normative/Informative References"
          section, whichever it is in.</t>
        <t>Tree-diagrams in this draft may use the '&#92;' line-folding mode defined in RFC 8792.
          However, nicer-to-the-eye is when the '&#92;&#92;' line-folding mode is used.  The AD suggested
          suggested putting a request here for the RFC Editor to help convert "ugly" '&#92;' folded
          examples to use the '&#92;&#92;' folding mode.  "Help convert" may be interpreted as, identify
          what looks ugly and ask the authors to make the adjustment.</t>
         <t>Due to a bug in the pyang tool used to create tree diagrams, some "key" nodes appear as
           optional (i.e., have a '?' postfix).  Ideally the '?' character is removed in the tree
           diagrams for "key" nodes.  Recipe: search for lists using the string "* [", then note
           the nodes appearing in the square brackets (e.g., "* [name]"), then look for matching child
           nodes and remove the '?' characters (e.g., "name?" becomes "name").</t>
      <t>The following Appendix section is to be removed prior to publication:
        <list style="symbols">
          <t><xref target="change-log"/>.  Change Log</t>
        </list>
      </t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document presents four YANG 1.1 <xref target="RFC7950"/> modules.
      <ol>
        <li>The "iana-http-versions" module defines a YANG "typedef" for HTTP protocol
          versions.  This module is maintained by IANA, such that new revisions will
          be automatically published whenever the underlying IANA registry is updated
          to define new HTTP versions.</li>
        <li>The "ietf-http-client" module defines a YANG "grouping" for configuring an
          HTTP client's ability to communicate with an HTTP service endpoint.  Unlike
          other groupings in the suite of "client-server" drafts mentioned in
          <xref target="collective-effort"/>, this client grouping is not intended
          to be used in conjunction with others to define a complete protocol stack.
          This is due to the "uri" node encoding configuration for lower protocol
          stack layers.  For instance, the "scheme" and "authority" parts of the
          URI encode information that portains to lower-level to transport layers.</li>
        <li>The "ietf-http-server" module defines a YANG "grouping" for configuring an
          HTTP server's service endpoints.  This grouping is intended to be used
          in conjunction with others described in <xref target="collective-effort"/>
          to define a complete protocol stack.  This module defines an additional YANG
          "grouping" as a convenience for such a complete protocol stack.</li>
      </ol>
    </t>

INSERT_TEXT_FROM_FILE(../common-intro-snippet.xml,150)

      <section title="Adherence to the NMDA">
        <t>This document is compliant with the Network Management Datastore
          Architecture (NMDA) <xref target="RFC8342"/>.  For instance, as
          described in <xref target="RFC9641"/> and
          <xref target="RFC9642"/>, trust anchors and keys
          installed during manufacturing are expected to appear
          in &lt;operational&gt; (<xref section="5.3" target="RFC8342"/>), and &lt;system&gt;
          <xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t>
      </section>
    </section>

    <section anchor="http-client-model" title="The &quot;ietf-http-client&quot; Module">

      <t>This section describes a YANG 1.1 module called "ietf-http-client".  This module
      defines a YANG grouping called "http-client-grouping" for configuring an HTTP client's
      ability to communicate with an HTTP service endpoint.  Unlike other groupings in
      the suite of "client-server" drafts mentioned in <xref target="collective-effort"/>,
      this grouping is not intended to be used in conjunction with others to define a
      complete protocol stack.  This is due to the "uri" node encoding configuration
      for lower protocol stack layers.  For instance, the "scheme" and "authority" parts
      of the URI encode information that portains to lower-level to transport layers.</t>

      <t>This section contains three sub-sections.  A high-level overview of the
      "ietf-http-client" module is provided in <xref target="client-overview"/>.  Examples
      illustrating the module's use are provided in <xref target="client-examples"/>.
      The YANG module itself is defined in <xref target="client-yang-module"/>.</t>

      <section title="Data Model Overview" anchor="client-overview">

       <t>This section provides an overview of the "ietf-http-client" module
          in terms of its features and groupings.</t>

        <section title="Features" anchor="client-features" toc="exclude">
          <t>The following diagram lists all the "feature" statements
            defined in the "ietf-http-client" module:</t>
          <t>
            <figure>
              <artwork><![CDATA[
Features:
  +-- proxy-connect
  +-- version-discovery
]]></artwork>
            </figure>
          </t>
          <!--<aside>-->
            <t>The diagram above uses syntax that is similar to but not
              defined in <xref target="RFC8340"/>.</t>
          <!--</aside>-->
        </section>

        <section title="Groupings" toc="exclude">
          <t>The "ietf-http-client" module defines one "grouping" statement called
            "http-client-grouping".</t>

          <section title="The &quot;http-client-grouping&quot; Grouping" anchor="http-client-grouping">
            <t>The following tree diagram <xref target="RFC8340"/> illustrates the
              "http-client-grouping" grouping:</t>
            <t>
              <figure>
               <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-client-grouping.no-expand.txt)
]]></artwork>
              </figure>
            </t>
            <t>Comments:</t>
            <ul>
              <li>The "uri" node is mandatory due to the "scheme" and "host"
                descendant nodes being mandatory. The "uri" node is the only
                mandatory part of the "http-client-grouping" grouping.</li>
              <li>The optional "supported-versions" node indicates which
                HTTP protocol versions are supported by the implementation,
                independent of current configuration.</li>
              <li>The optional "protocol-versions" node specifies the HTTP
                protocol versions the client is configured to allow, such
                as may be constrained by local policy.</li>
              <li>The optional "tls-client-parameters" node specifies TLS-level
                client identity and server authentication credentials to use,
                if needed per the configured URI.  When unspecified, TLS-based
                connections are not possible.  The "tls-client-grouping"
                grouping is discussed in <relref section="3.1.2.1" target="RFC9645"/>.</li>
              <li>The optional "proxy-connect" node specifies how to proxy the
                connection through a proxy server.</li>
            </ul>
          </section>
        </section>

        <section title="Protocol-accessible Nodes" toc="exclude">
          <t>The "ietf-http-client" module defines only "grouping" statements that are
          used by other modules to instantiate protocol-accessible nodes.  Thus this
          module, when implemented, does not define any protocol-accessible nodes.</t>
        </section>

      </section>

      <section title="Example Usage" anchor="client-examples">
        <t>This section presents three examples showing the http-client-grouping
          populated with some data.  All three examples show both configuration
          and state data (i.e., the "supported-versions" node).</t>
        <t>The first example illustrates the case where the HTTP client
          is configured to connect directly to an HTTP server without TLS.</t>
        <t>
          <figure>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-tcp.xml)
]]></artwork>
          </figure>
        </t>
        <t>The second example illustrates the case where the HTTP client
          is configured to connect directly to an HTTP server with TLS.</t>
        <t>This example is consistent with examples presented in
          <relref section="2.2.1" target="RFC9641"/> and
          <relref section="2.2.1" target="RFC9642"/>.</t>
        <t>
          <figure>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-tls.xml)
]]></artwork>
          </figure>
        </t>
        <t>The following example illustrates the case where the HTTP client
          is configured to connect through an HTTP proxy.</t>
        <t>This example also is consistent with examples presented in
          <relref section="2.2.1" target="RFC9641"/> and
          <relref section="2.2.1" target="RFC9642"/>.</t>
        <t>
          <figure>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-proxy.xml)
]]></artwork>
          </figure>
        </t>
      </section>

      <section anchor="client-yang-module" title="YANG Module">
        <t>This YANG module has references to <xref target="RFC3986"/>,
          <xref target="RFC6991"/>, <xref target="RFC8341"/>, <xref target="RFC9110"/>,
          and <xref target="RFC9645"/>.</t>
        <t>
          <figure>
            <preamble>&lt;CODE BEGINS&gt; file "ietf-http-client@YYYY-MM-DD.yang"</preamble>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-http-client@YYYY-MM-DD.yang)
]]></artwork>
            <postamble>&lt;CODE ENDS&gt;</postamble>
          </figure>
        </t>
      </section>
    </section>

    <section anchor="http-server-model" title="The &quot;ietf-http-server&quot; Module">

      <t>This section describes a YANG 1.1 module called "ietf-http-server".  This module
      defines a YANG grouping called "http-server-grouping" for configuring an
      HTTP server's service endpoints, used in conjunction with others described in
      <xref target="collective-effort"/> to define a complete protocol stack.
      This module defines an additional YANG grouping called
      "http-server-listen-stack-grouping" as a convenience for such a complete protocol stack.</t>

      <t>This section contains three sub-sections.  A high-level overview of the
      "ietf-http-server" module is provided in <xref target="server-overview"/>.  Examples
      illustrating the module's use are provided in <xref target="server-examples"/>.
      The YANG module itself is defined in <xref target="server-yang-module"/>.</t>

      <section title="Data Model Overview" anchor="server-overview">

       <t>This section provides an overview of the "ietf-http-server" module
          in terms of its features and groupings.</t>

        <section title="Features" anchor="server-features" toc="exclude">
          <t>The following diagram lists all the "feature" statements
            defined in the "ietf-http-server" module:</t>
          <t>
            <figure>
              <artwork><![CDATA[
Features:
  +-- client-auth-supported
  +-- local-users-supported {client-auth-supported}?
  +-- basic-auth {local-users-supported}?
  +-- tcp-supported
  +-- tls-supported
  +-- quic-supported
  +-- version-discovery
]]></artwork>
            </figure>
          </t>
          <!--<aside>-->
            <t>The diagram above uses syntax that is similar to but not
              defined in <xref target="RFC8340"/>.</t>
          <!--</aside>-->
        </section>

        <section title="Groupings" toc="exclude">
          <t>The "ietf-http-server" module defines two "grouping" statements:</t>
          <ul spacing="compact">
            <li>http-server-grouping</li>
            <li>http-server-listen-stack-grouping</li>
          </ul>
          <t>Each of these groupings are presented in the following subsections.</t>

          <section title="The &quot;http-server-grouping&quot; Grouping" anchor="http-server-grouping">
            <t>The following tree diagram <xref target="RFC8340"/> illustrates the
              "http-server-grouping" grouping:</t>
            <t>
              <figure>
               <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-server-grouping.no-expand.txt)
]]></artwork>
              </figure>
            </t>
            <t>Comments:</t>
            <ul>
              <li>The "http-server-grouping" defines the configuration for just the
                "HTTP" part of a protocol stack.  It does not, for instance,
                define any configuration for the "TCP" or "TLS" protocol layers.</li>
              <li>The "server-name" node defines the HTTP server's name, as
                presented to HTTP clients.</li>
              <li>The "client-authentication" node, which must by enabled by
                a feature, defines a very simple user-database.  Only the
                "basic" authentication scheme is supported, albeit it must
                be enabled by a "feature".  Other authentication schemes
                MAY be augmented in.</li>
            </ul>
          </section>

          <section title="The &quot;http-server-listen-stack-grouping&quot; Grouping" anchor="http-server-listen-stack-grouping">
            <t>The following tree diagram <xref target="RFC8340"/> illustrates the
              "http-server-listen-stack-grouping" grouping:</t>
            <t>
              <figure>
               <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-server-listen-stack-grouping.no-expand.txt)
]]></artwork>
              </figure>
            </t>
            <t>Comments:</t>
            <ul>
              <li>The "http-server-listen-stack-grouping" is a convenience grouping for consuming
                modules.  It defines protocol stacks for HTTP/1.1, HTTP/2, and HTTP/3, with each
                option enabled by a "feature" statement for application control.  Other
                protocols may be added by future work using the YANG "augment" statement.</li>
              <li>For the referenced grouping statement(s):
                <ul spacing="compact">
                  <li>The "udp-server-grouping" grouping is discussed in
                    <relref section="3" target="I-D.ietf-netconf-udp-client-server"/>.</li>
                  <li>The "tcp-server-grouping" grouping is discussed in
                    <relref section="4.1.2.1" target="RFC9643"/>.</li>
                  <li>The "tls-server-grouping" grouping is discussed in
                    <relref section="4.1.2.1" target="RFC9645"/>.</li>
                  <li>The "http-server-grouping" grouping is discussed in
                    <xref target="http-server-grouping"/> in this document.</li>
                </ul>
              </li>
            </ul>
          </section>
        </section>

        <section title="Protocol-accessible Nodes" toc="exclude">
          <t>The "ietf-http-server" module defines only "grouping" statements that are
          used by other modules to instantiate protocol-accessible nodes.  Thus this
          module, when implemented, does not define any protocol-accessible nodes.</t>
        </section>
      </section>

      <section title="Example Usage" anchor="server-examples">
        <t>This section presents an example showing the http-server-grouping
        populated with some data.  All three examples show both configuration
        and state data (i.e., the "supported-versions" node).</t>
        <t>
          <figure>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-server.xml)
]]></artwork>
          </figure></t>
      </section>

      <section anchor="server-yang-module" title="YANG Module">
        <t>This YANG module has references to <xref target="RFC6991"/>,
        <xref target="RFC7317"/>, <xref target="RFC7617"/>, <xref target="RFC8341"/>,
        <xref target="RFC9110"/>, <xref target="RFC9643"/>, <xref target="RFC9645"/>,
        and <xref target="I-D.ietf-netconf-udp-client-server"/>.</t>
        <t>
          <figure>
            <preamble>&lt;CODE BEGINS&gt; file "ietf-http-server@YYYY-MM-DD.yang"</preamble>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ietf-http-server@YYYY-MM-DD.yang)
]]></artwork>
            <postamble>&lt;CODE ENDS&gt;</postamble>
          </figure>
        </t>
      </section>
    </section>

    <section title="Security Considerations">

      <t>This document defines three YANG modules, one that defines only a
        "typedef" and the other two defining only "grouping" statements.
        These modules will not be deployed as standalone modules. Their
        security implications may be context dependent based on their use
        in other modules.  The designers of modules which import these
        grouping must conduct their own analysis of the security considerations.</t>


      <section title='Considerations for the "iana-http-versions" Module'>
        <t>This section is modeled after the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>

          <t>The "iana-http-versions" YANG module defines a typedef
          that is solely used by other YANG modules, which would present
          data nodes accessed via YANG-based management
          protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
          <xref target="RFC8040"/>.  The YANG-based management protocols
          have to use a secure transport layer such as SSH <xref target="RFC4252"/>,
          TLS <xref target="RFC8446"/>, or QUIC <xref target="RFC9000"/>.
          The YANG-based management protocols also have to use mutual
          authentication.</t>
        <t>This YANG module defines an "enumeration" typedef for values 
          in a public IANA-maintained registry.  YANG enumerations for a
          publicly-accessible registry are not security-sensitive.</t>
        <t>IANA MAY deprecate and/or obsolete HTTP versions over time as needed.</t>
        <t>This module does not define any readable nodes, writable nodes,
          RPCs, actions, or notifications, and thus the security consideration
          for such is not provided here.</t>
      </section>


      <section title="Considerations for the &quot;ietf-http-client&quot; YANG Module">
        <t>This section is modeled after the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>

        <t>The "ietf-http-client" YANG module defines data nodes
          that are designed to be accessed via YANG-based management
          protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
          <xref target="RFC8040"/>.  The YANG-based management protocols
          have to use a secure transport layer such as SSH <xref target="RFC4252"/>,
          TLS <xref target="RFC8446"/>, or QUIC <xref target="RFC9000"/>.
          The YANG-based management protocols also have to use mutual
          authentication.</t>

        <t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
          provides the means to restrict access for particular users to a
          pre-configured subset of all available protocol operations and
          content.</t>

        <t>Please be aware that this YANG module uses groupings from
          other YANG modules that define nodes that may be considered
          sensitive or vulnerable in network environments.  Please
          review the Security Considerations for dependent YANG modules
          for information as to which nodes may be considered sensitive
          or vulnerable in network environments.</t>

        <t>None of the readable data nodes defined in this YANG module,
          i.e., excluding imported modules, are considered sensitive
          or vulnerable in some network environments.</t>

        <t>Some of the readable data nodes defined in this YANG module,
          i.e., excluding imported modules, may be considered sensitive
          or vulnerable in some network environments. It is thus important
          to control read access to these data nodes. The following data
          nodes have particular sensitivity/vulnerability:
          <list style="symbols">
            <t>The "userinfo" node:
              <ul empty="true">
                <li>The "userinfo" node may encode a cleartext password (basic
                  or digest authentication).  For this reason, the NACM
                  extension "default-deny-all" is applied to it.</li>
              </ul>
            </t>
          </list>
        </t>

        <t>This module does not define any RPCs, actions, or notifications,
          and thus the security consideration for such is not provided here.</t>
      </section>

      <section title="Considerations for the &quot;ietf-http-server&quot; YANG Module">
        <t>This section is modeled after the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>

        <t>The "ietf-http-server" YANG module defines data nodes
          that are designed to be accessed via YANG-based management
          protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
          <xref target="RFC8040"/>.  The YANG-based management protocols
          have to use a secure transport layer such as SSH <xref target="RFC4252"/>,
          TLS <xref target="RFC8446"/>, or QUIC <xref target="RFC9000"/>.
          The YANG-based management protocols also have to use mutual
          authentication.</t>

        <t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
          provides the means to restrict access for particular users to a
          pre-configured subset of all available protocol operations and
          content.</t>

        <t>Please be aware that this YANG module uses groupings from
          other YANG modules that define nodes that may be considered
          sensitive or vulnerable in network environments.  Please
          review the Security Considerations for dependent YANG modules
          for information as to which nodes may be considered sensitive
          or vulnerable in network environments.</t>

        <t>None of the readable data nodes defined in this YANG module,
          i.e., excluding imported modules, are
          considered sensitive or vulnerable in network environments.
          The NACM "default-deny-all" extension has not been set for
          any data nodes defined in this module.</t>

        <t>The following writable data nodes defined in this YANG module,
          i.e., excluding imported modules, are considered sensitive or
          vulnerable in network environments:
          <list style="symbols">
            <t>The "server-name" node in the "http-server-grouping"
              grouping may be considered sensitive or vulnerable in some
              network environments.  For this reason, the NACM extension
              "default-deny-write" has been applied to it.  A misconfigured
              "server-name" may mislead clients into not knowing how to
              interoperate with the server (e.g., "foo v1.0" vs "foo 2.0").</t>
            <t>The "client-authentication" node in the "http-server-grouping"
              grouping may be considered sensitive or vulnerable in some
              network environments.  For this reason, the NACM extension
              "default-deny-write" has been applied to it.  Misconfigured
              "client-authentication" may lead the server to authenticate
              invalid client credentials.</t>
          </list>
        </t>

        <t>This module does not define any RPCs, actions, or notifications,
          and thus the security consideration for such is not provided here.</t>
      </section>



    </section>

    <section title="IANA Considerations">
      <section title='The "IETF XML" Registry'>
        <t>This document registers four URIs in the "ns" subregistry of the
        IETF XML Registry <xref target="RFC3688"/>. Following the format in
        <xref target="RFC3688"/>, the following registrations are
        requested:</t>
        <t><figure>
            <artwork>
   URI: urn:ietf:params:xml:ns:yang:iana-http-versions
   Registrant Contact: The IESG
   XML: N/A, the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-http-client
   Registrant Contact: The IESG
   XML: N/A, the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-http-server
   Registrant Contact: The IESG
   XML: N/A, the requested URI is an XML namespace.
</artwork>
          </figure></t>
      </section>

      <section title='The "YANG Module Names" Registry'>
        <t>This document registers two YANG modules in the YANG Module Names
        registry <xref target="RFC6020"/>. Following the format in <xref
        target="RFC6020"/>, the following registrations are requested:</t>
        <t><figure>
            <artwork>
   Name:         iana-http-versions
   Namespace:    urn:ietf:params:xml:ns:yang:iana-http-versions
   Prefix:       httpv
   Reference:    RFC GGGG
   Maintained by IANA:  Y

   Name:         ietf-http-client
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-http-client
   Prefix:       httpc
   Reference:    RFC GGGG
   Maintained by IANA:  N

   Name:         ietf-http-server
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-http-server
   Prefix:       https
   Reference:    RFC GGGG
   Maintained by IANA:  N
</artwork>
          </figure></t>
      </section>

      <section title='Considerations for the "iana-http-versions" Module'>
        <t>This section follows the template defined in <xref section="4.30.3.1"
          target="I-D.ietf-netmod-rfc8407bis"/>.</t>
        <t>IANA is requested to add the following note to the registry:</t>
        <blockquote>New values must not be directly added to the "iana-http-versions"
          YANG module.  They must instead be added to the "TLS Application-Layer Protocol
          Negotiation (ALPN) Protocol IDs" sub-registry of the "Transport Layer Security
          (TLS) Extensions" registry <xref target="IANA-TLS-ALPN-IDS"/>.</blockquote>
        <t>When an HTTP-specific value is added to the "TLS Application-Layer Protocol Negotiation
          (ALPN) Protocol IDs" sub-registry, a new "enum" statement must be added to
          the "iana-http-versions" YANG module.  The "enum" statement, and sub-statements
          thereof, should be defined as follows:</t>
        <dl newline="true">
          <dt>enum</dt>
          <dd>Replicates a name from the registry.</dd>
          <dt>status</dt>
          <dd>Include only if a registration has been deprecated or obsoleted.</dd>
          <dt>description</dt>
          <dd>Contains "Enumeration for the "HTTP/FOO" HTTP protocol version.", where
            "HTTP/FOO" is a placeholder for the algorithm's name (e.g., "HTTP/3").</dd>
          <dt>reference</dt>
          <dd>Replicates the reference(s) from the registry with the title of the
            document(s) added (e.g., "RFC 9114: HTTP/3").</dd>
        </dl>
        <t>When the "iana-http-versions" YANG module is updated, a new "revision"
          statement with a unique revision date must be added in front of the
          existing revision statements. The "revision" must have a "description"
          statement explaining why the the update occurred, and must have a
          "reference" substatement that points to the document defining the
          registry update that resulted in this change.  For instance:</t>
          <artwork>
revision yyyy-mm-dd {
    description
        "This revision reflects the update made to the underlying
         'TLS Application-Layer Protocol Negotiation (ALPN) Protocol
         IDs' registry per RFC XXXX.";
    reference
        "RFC XXXX: RFC Title for Some New HTTP Version";
}</artwork>
        <t>IANA is requested to add the following note to the "TLS Application-Layer
          Protocol Negotiation (ALPN) Protocol IDs" sub-registry of the "Transport
          Layer Security (TLS) Extensions" registry <xref target="IANA-TLS-ALPN-IDS"/>.</t>
          <blockquote>When this registry has an HTTP-specific version added or modified,
          the YANG module "iana-http-versions" <xref target="IANA-YANG-PARAMETERS"/>
          must be updated as defined in RFC GGGG.</blockquote>
        <section title='Recommended Initial Version for the "iana-http-versions" YANG Module' removeInRFC="true">
          <t>
            <figure>
            <preamble>&lt;CODE BEGINS&gt; file "iana-http-versions@YYYY-MM-DD.yang"</preamble>
            <artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/iana-http-versions@YYYY-MM-DD.yang)
]]></artwork>
            <postamble>&lt;CODE ENDS&gt;</postamble>
            </figure>
          </t>
        </section>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9640.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9643.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9645.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-udp-client-server.xml"/>
    </references>

    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9641.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9642.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9644.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-http-client-server.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-netconf-client-server.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-restconf-client-server.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netmod-system-config.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netmod-rfc8407bis.xml"/>

      <reference anchor="IANA-TLS-ALPN-IDS" target="https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids" quoteTitle="true" derivedAnchor="IANA-TLS-ALPN-IDS">
        <front>
          <title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title>
          <author>
            <organization showOnFrontPage="true">IANA</organization>
          </author>
        </front>
      </reference>

      <reference anchor="IANA-YANG-PARAMETERS" target="https://www.iana.org/assignments/yang-parameters" quoteTitle="true" derivedAnchor="IANA-YANG-PARAMETERS">
        <front>
          <title>YANG Parameters</title>
          <author>
            <organization showOnFrontPage="true">IANA</organization>
          </author>
        </front>
      </reference>

    </references>

    <section title="Change Log" anchor="change-log">
      <section title="00 to 01">
        <t>
          <list style="symbols">
            <t>Modified Abstract and Intro to be more accurate wrt intended applicability.</t>
            <t>In ietf-http-client, removed "protocol-version" and all auth schemes except "basic".</t>
            <t>In ietf-http-client, factored out "client-identity-grouping" for proxy connections.</t>
            <t>In ietf-http-server, removed "choice required-or-optional" and "choice inline-or-external".</t>
            <t>In ietf-http-server, moved the basic auth under a "choice auth-type" limited by new "feature basic-auth".</t>
          </list>
        </t>
      </section>
      <section title="01 to 02">
        <t>
          <list style="symbols">
            <t>Removed the unused "external-client-auth-supported" feature from ietf-http-server.</t>
          </list>
        </t>
      </section>
      <section title="02 to 03">
        <t>
          <list style="symbols">
            <t>Removed "protocol-versions" from ietf-http-server based on HTTP WG feedback.</t>
            <t>Slightly restructured the "proxy-server" definition in ietf-http-client.</t>
            <t>Added http-client example show proxy server use.</t>
            <t>Added a "Note to Reviewers" note to first page.</t>
          </list>
        </t>
      </section>
      <section title="03 to 04">
        <t>
          <list style="symbols">
            <t>Added a parent "container" to "client-identity-grouping" so that it could be
              better used by the proxy model.</t>
            <t>Added a "choice" to the proxy model enabling selection of proxy types.</t>
            <t>Added 'http-client-stack-grouping' and 'http-server-listen-stack-grouping' convenience groupings.</t>
            <t>Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams].</t>
            <t>Updated the Security Considerations section.</t>
          </list>
        </t>
      </section>
      <section title="04 to 05">
        <t>
          <list style="symbols">
            <t>Fixed titles and a ref in the IANA Considerations section</t>
            <t>Cleaned up examples (e.g., removed FIXMEs)</t>
            <t>Fixed issues found by the SecDir review of the "keystore" draft.</t>
            <t>Updated the "ietf-http-client" module to use the new "password-grouping"
              grouping from the "crypto-types" module.</t>
          </list>
        </t>
      </section>
      <section title="05 to 06">
        <t>
          <list style="symbols">
            <t>Removed note questioning if okay for app to augment-in a 'path' node
              when needed, discussed during the 108 session.</t>
            <t>Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.</t>
          </list>
        </t>
      </section>
      <section title="06 to 07">
        <t>
          <list style="symbols">
            <t>Added XML-comment above examples explaining the reason for the unusual top-most element's presence.</t>
            <t>Renamed 'client-auth-config-supported' to 'client-auth-supported' consistent with other drafts.</t>
            <t>Wrapped 'container basic' choice inside a 'case basic' per best practice.</t>
            <t>Aligned modules with `pyang -f` formatting.</t>
            <t>Fixed nits found by YANG Doctor reviews.</t>
          </list>
        </t>
      </section>
      <section title="07 to 08">
        <t>
          <list style="symbols">
            <t>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</t>
            <t>Minor editorial nits</t>
          </list>
        </t>
      </section>
      <section title="08 to 09">
        <t>
          <list style="symbols">
            <t>Fixed up the 'WG Web' and 'WG List' lines in YANG module(s)</t>
            <t>Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s)</t>
          </list>
        </t>
      </section>
      <section title="09 to 10">
        <t>
          <list style="symbols">
            <t>NO UPDATE.</t>
          </list>
        </t>
      </section>
      <section title="10 to 11">
        <t>
          <list style="symbols">
            <t>Updated per Shepherd reviews impacting the suite of drafts.</t>
          </list>
        </t>
      </section>
      <section title="11 to 12">
        <t>
          <list style="symbols">
            <t>Updated per Shepherd reviews impacting the suite of drafts.</t>
          </list>
        </t>
      </section>
      <section title="12 to 13">
        <t>
          <list style="symbols">
            <t>Updated per Tom Petch reviews.</t>
            <t>Renamed draft title to limit to HTTP 1.1 and 2.0.</t>
            <t>Added refs to RFCs 7317, 7617, and 9110.</t>
            <t>Added "if-feature local-users-supported" to "feature basic-auth".</t>
          </list>
        </t>
      </section>
      <section title="13 to 14">
        <t>
          <list style="symbols">
              <t>Addresses AD review comments.</t>
              <t>Added note to Editor to fix line foldings.</t>
              <t>Removed "Conventions" section as there are no "BASE64VALUE=" values used in draft.</t>
              <t>Clarified that the modules, when implemented, do not define any protocol-accessible nodes.</t>
              <t>Added Security Considerations text to also look a SC-section from imported modules.</t>
              <t>Removed "A wrapper around the foobar parameters to avoid name collisions" text.</t>
              <t>Removed "public-key-format" and "public-key" nodes from examples.</t>
          </list>
        </t>
      </section>
      <section title="14 to 15">
        <t>
          <list style="symbols">
            <t>Addresses AD review by Rob Wilton.</t>
          </list>
        </t>
      </section>
      <section title="15 to 16">
        <t>
          <list style="symbols">
            <t>Addresses 1st-round of IESG reviews.</t>
          </list>
        </t>
      </section>
      <section title="16 to 18">
        <t>
          <list style="symbols">
            <t>Addresses issues found in OpsDir review of the ssh-client-server draft.</t>
            <t>s/defines/presents/ in a few places.</t>
            <t>Add refs to where the 'operational' and 'system' datastores are defined.</t>
            <t>Renamed Security Considerations section s/Template for/Considerations for/.</t>
            <t>Updated "http-client-stack-grouping" and "http-server-listen-stack-grouping" for HTTP/3.</t>
          </list>
        </t>
      </section>
      <section title="18 to 19">
        <t>
          <list style="symbols">
            <t>Address IESG review comments.</t>
          </list>
        </t>
      </section>
      <section title="19 to 20">
        <t>
          <list style="symbols">
            <t>Updated to reflect comments from Paul Wouters.</t>
          </list>
        </t>
      </section>
      <section title="23 to 24">
        <t>
          <list style="symbols">
            <t>Replaced 'uri' as string with a container with components.</t>
            <t>Added 'if-feature full-uri-supported' statement to the 'path', 'query' and 'fragment' components</t>
            <t>Replaced 'protocol-versions' as 'bits' with a min/max range</t>
            <t>Fixed 'proxy-connect' to reflect RFC 9110 (not legacy the HTTP/S Proxy mechanism)</t>
            <t>Added support for CONNECT-UDP per RFC 9298</t>
            <t>Eliminated the 'http-client-common-grouping' grouping (not needed after updating the proxy solution)</t>
            <t>Renamed 'http-server-stack-grouping' to 'http-server-listen-stack-grouping', to make way for a possible future 'http-server-callhome-stack-grouping'</t>
          </list>
        </t>
      </section>
      <section title="24 to 25">
        <t>
          <list style="symbols">
            <t>Updated 2nd paragraph in Security Considerations section to match RFC Editor's version for other drafts in the suite of client-server drafts.</t>
            <t>Removed the 'full-uri-supported' feature added in -24, after discussing some with Mahesh.</t>
          </list>
        </t>
      </section>
      <section title="25 to 26">
        <t>
          <list style="symbols">
            <t>Updated to reflect some of Med's AD-review comments</t>
          </list>
        </t>
      </section>
      <section title="26 to 27">
        <t>
          <list style="symbols">
            <t>Added ability for HTTP server's to also limit what HTTP versions are supported.</t>
          </list>
        </t>
      </section>
      <section title="27 to 28">
        <t>
          <list style="symbols">
            <t>Factored the "uri" node into a grouping defined in another module.</t>
          </list>
        </t>
      </section>
      <section title="28 to 29">
        <t>
          <list style="symbols">
            <t>Replaced min/max versions with a list of versions, defined by an
              IANA-maintained YANG module.</t>
            <t>Since "feature" statements cannot be used with IANA-maintained
              modules, a new conifg false "supported-versions" list is used to
              express which HTTP versions the implementation programatically
              supports.</t>
            <t>Notably, the "supported-versions" list, which is  "config false",
              is defined per use (not globally), which is actually very cool,
              as it enables various parts of the data tree to express support
              for different HTTP versions.</t>
          </list>
        </t>
      </section>
      <section title="29 to 30">
        <t>
          <list style="symbols">
            <t>Addressed Mike Bishop's comments and nits.</t>
          </list>
        </t>
      </section>
    </section>

    <section title="Acknowledgements" numbered="no">
      <t>The authors would like to thank the following for lively discussions
        on list and in the halls (ordered by first name):
          Ben Schwartz,
          Dale Worley,
          Darrel Miller,
          Éric Vyncke,
          Francesca Palombini,
          Mark Nottingham,
          Martin Thomson,
          Mahesh Jethanandani,
          Med Boucladair,
          Mike Bishop,
          Murray Kucherawy,
          Orie Steele,
          Rob Wilton,
          Robert Varga,
          Roman Danyliw,
          Shivan Sahib,
          Tim Bray,
          Willy Tarreau,
          and Zaheduzzaman Sarker.
      </t>
    </section>

  </back>
</rfc>