One document matched: draft-chairs-netmod-opstate-reqs-00.xml

<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml">
<!ENTITY rfc4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc4254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4254.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY rfc6187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6187.xml">
<!ENTITY rfc6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY rfc6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY rfc6335 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY rfc6520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6520.xml">
<!ENTITY rfc7589 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7589.xml">
-->
]>


<?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 category="std"
     ipr="trust200902"
     docName="draft-chairs-netmod-opstate-reqs-00">
    <front>
        <title>NETMOD Operational State Requirements</title>
        <author initials="K.W." surname="Watsen" fullname="Kent Watsen">
            <organization>Juniper Networks</organization>
            <address>
                <email>kwatsen@juniper.net</email>
            </address>
        </author>
        <author initials="T.N." surname="Nadeau" fullname="Thomas Nadeau">
            <organization>Brocade Networks</organization>
            <address>
                <email>tnadeau@lucidvision.com</email>
            </address>
        </author>
        <date/>
        <area>Operations</area>
        <workgroup>NETMOD Working Group</workgroup>
        <keyword>opstate</keyword>
        <abstract>
            <t>This document captures consensus on operational state requirements
            by the NETMOD working group.</t>
        </abstract>
      </front>

    <middle>
      <section title="Terminology">
        <t>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 RFC 2119 <xref target="RFC2119"/>.</t>

        <t>The following terms are defined in <xref target="draft-openconfig-netmod-opstate-01"/>:
          <list style="symbols">
            <t>intended configuration - this data represents the state that the
            network operator intends the system to be in.  This data is
            colloquially referred to as the 'configuration' of the system.</t>
            <t>applied configuration - this data represents the state that the
            network element is actually in, i.e., that which is currently
            being run by particular software modules (e.g., the BGP daemon),
            or other systems within the device (e.g., a secondary control-
            plane, or line card).</t>
            <t>derived state - this data represents information which is
            generated as part of the system's own interactions.  For example,
            derived state may consist of the results of protocol interactions
            (the negotiated duplex state of an Ethernet link), statistics
            (such as message queue depth), or counters (such as packet input
            or output bytes).</t>
          </list>
        </t>
      </section>

      <section title="Requirements" anchor="reqs">
        <t>
          <list style="numbers">
            <t>Ability to interact with both intended and applied configuration
              <list style="letters">
                <t>The ability to ask the operational components of a system
                   (e.g., line cards) for the configuration that they are currently
                   using. This is the "applied configuration".</t>
                <t>Applied configuration is read-only</t>
                <t>The data model for the applied configuration is the same as
                   the data model for the intended configuration (same leaves)</t>
                <t>For asynchronous systems, when fully synchronized, the data
                   in the applied configuration is the same as the data in the
                   intended configuration.</t>
              </list>
            </t>
            <t>Applied configuration as part of operational state
              <list style="letters">
                <t>The ability to retrieve the applied configuration and
                derived state nodes in a single protocol operation.</t>
              </list>
            </t>
            <t>Support for both transactional, synchronous management
            systems as well as distributed, asynchronous management
            systems
              <list style="letters">
                <t>For asynchronous systems, the ability to request a protocol
                 operation to not return (i.e. block) until the intended
                 configuration has been fully synchronized.</t>
                <t>The protocol operation's response would indicate the result
                  of the operation (success, failure, partial, etc.)</t>
              </list>
            </t>
            <t>Separation of configuration and operational state data; ability
            to retrieve them independently
              <list style="letters">
                <t>Be able to retrieve only the derived state aspects of operational state</t>
                <t>Be able to retrieve only the non-derived state aspects of operational state</t>
              </list>
            </t>
            <t>Ability to retrieve operational state corresponding only to
            derived values, statistics, etc.
              <list style="empty">
                <t>// this is a duplicate of # 4-a</t>
              </list>
            </t>
            <t>Ability to relate configuration with its corresponding operational state
              <list style="letters">
                <t>Ability to map intended config nodes to corresponding applied config nodes</t>
                <t>Ability to map intended config nodes to associated derived state nodes</t>
                <t>The mappings needs to be programmatically consumable</t>
              </list>
            </t>
            <t>Ability for distinct modules to leverage a common model-structure
              <list style="letters">
                <t>Scope is limited to IETF-defined modules</t>
                <t>Multiple domain-specific trees are okay</t>
                <t>Multiple namespaces are okay</t>
              </list>
            </t>
          </list>
        </t>
      </section>

      <section anchor="sec-con" title="Security Considerations">
        <t>None</t>
      </section>

      <section title="IANA Considerations" anchor="iana-con">
        <t>None</t>
      </section>

      <section title="Acknowledgements">
        <t>TBD</t>
      </section>

    </middle>

    <back>

      <references title="Normative References">
          &rfc2119;
      </references>
      <references title="Informative References">
        <reference anchor="draft-openconfig-netmod-opstate-01" target="https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01">
          <front>
            <title>Consistent Modeling of Operational State Data in YANG</title>
            <author initials="R.S." surname="Shakir" fullname="Rob Shakir">
              <organization>BT</organization>
            </author>
            <author initials="A.S." surname="Shaikh" fullname="Anees Shaikh">
              <organization>Google</organization>
            </author>
            <author initials="M.H." surname="Hines" fullname="Marcus Hines">
              <organization>Google</organization>
            </author>
            <date year="2015"/>
          </front>
          <seriesInfo name='Internet-Draft' value='draft-openconfig-netmod-opstate-01' />
        </reference>
        <reference anchor="draft-openconfig-netmod-model-structure-00" target="https://tools.ietf.org/html/draft-openconfig-netmod-model-structure-00">
          <front>
            <title>Operational Structure and Organization of YANG Models</title>
            <author initials="A.S." surname="Shaikh" fullname="Anees Shaikh">
              <organization>Google</organization>
            </author>
            <author initials="R.S." surname="Shakir" fullname="Rob Shakir">
              <organization>BT</organization>
            </author>
            <author initials="K.D." surname="D'Souza" fullname="Kevin D'Souza">
              <organization>AT&T</organization>
            </author>
            <author initials="L.F." surname="Fang" fullname="Luyuan Fang">
              <organization>Microsoft</organization>
            </author>
            <date year="2015"/>
          </front>
          <seriesInfo name='Internet-Draft' value='draft-openconfig-netmod-model-structure-00' />
        </reference>

      </references>

      <section title="Relation to Requirements in Other Drafts">
        <t>The requirements in this document roughly map onto the requirements listed in 
        <xref target="draft-openconfig-netmod-opstate-01"/> and
        <xref target="draft-openconfig-netmod-model-structure-00"/> as list below.  Some 
        liberty was taken to adjust the requirements based on what looked liked consensus
        from on list discussions:
          <list style="numbers">
            <t>draft-openconfig-netmod-opstate-01, Section 3</t>
            <t>draft-openconfig-netmod-opstate-01, Section 4.1</t>
            <t>draft-openconfig-netmod-opstate-01, Section 4.2</t>
            <t>draft-openconfig-netmod-opstate-01, Section 4.3</t>
            <t>draft-openconfig-netmod-opstate-01, Section 4.4</t>
            <t>draft-openconfig-netmod-opstate-01, Section 4.5</t>
            <t>draft-openconfig-netmod-model-structure-00 (no section)</t>
          </list>
        </t>
      </section>

<!--
      <section title="Change Log">
        <section title="00 to 01">
          <t>
            <list style="symbols">
            </list>
          </t>
        </section>
      </section>
-->

      <section title="Open Issues">
        <t>All issues with this draft are tracked using GitHub issues.  Please see: https://github.com/netmod-wg/opstate-reqs/issues to see currently opened issues.</t>
      </section>

    </back>

</rfc>