<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- You need one entry like the following for each RFC referenced -->
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!-- You need one entry like the following for each I-D referenced -->
<!ENTITY DRAFT-config-ps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jiang-config-negotiation-ps.xml">
<!ENTITY DRAFT-AN-def SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-autonomic-network-definitions.xml">
<!ENTITY DRAFT-AN-gap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-an-gap-analysis.xml">

]>
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc category="std" docName="draft-jiang-config-negotiation-protocol-02"
     ipr="trust200902">
  <front>
    <title abbrev="Configuration Discovery and Negotiation Protocol">Configuration
    Discovery and Negotiation Protocol for Network Devices</title>

    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus</street>

          <street>No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing</city>

          <code>100095</code>

          <country>P.R. China</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

    <author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
      <organization abbrev="Univ. of Auckland"></organization>

      <address>
        <postal>
          <street>Department of Computer Science</street>

          <street>University of Auckland</street>

          <street>PB 92019</street>

          <city>Auckland</city>

          <region></region>

          <code>1142</code>

          <country>New Zealand</country>
        </postal>

        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>

    <author fullname="Bing Liu" initials="B." surname="Liu">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus</street>

          <street>No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing</city>

          <code>100095</code>

          <country>P.R. China</country>
        </postal>

        <email>leo.liubing@huawei.com</email>
      </address>
    </author>

<!--    <author fullname="Yuanbin Yin" initials="Y." surname="Yin">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q15, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>yinyuanbin@huawei.com</email>
      </address>
    </author> -->

    <date day="26" month="June" year="2014" />

    <abstract>
      <t>This document defines a new protocol that enables intelligent devices
      to dynamically discover and negotiate their configuration with counterpart devices.
      This document only defines a general protocol as a negotiation platform
      while the negotiation objectives for specific scenarios are to be described
      in separate documents.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The success of the Internet has made IP-based networks bigger and
      more complicated. Large-scale ISP networks have become more and more
      problematic for human based management. Also operational costs are growing
      quickly. Consequently, there are therefore increased requirements for
      autonomy in the networks. General aspects of autonomic networks are
      discussed in
      <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> and
      <xref target="I-D.irtf-nmrg-an-gap-analysis"/>.
      In order to fulfil autonomy, devices that are
      more intelligent need to be able to negotiate directly with each other.
      <xref target="I-D.jiang-config-negotiation-ps"></xref> describes the
      requirements and application scenarios for network device negotiation.
      It also describes a behavior model of a generic negotiation protocol.
      Prior to negotiation, devices must discover each other. 
      The design of Configuration Discovery and Negotiation Protocol (CDNP) in this document
      is mainly based on this behavior model.</t>

      <t>Although many negotiations may happen between distributed horizontal
      peers, the main target scenarios are still hierarchical networks, which is
      the major structure of current large-scale networks. Thus, where
      necessary, we assume that each network element has a hierarchical
      superior. Of course, the protocol itself is capable of being used in a
      small and/or flat network structure such as a small office or  home network, too.</t>

      <t>This document defines a generic discovery and  negotiation protocol, named
      Configuration Discovery and Negotiation Protocol (CDNP), that can be used to control
      decision process among distributed devices or between networks. The
      newly defined CDNP in this document adapts a tight certificate-based
      mechanism, which needs a Public Key Infrastracture (PKI, <xref target="RFC5280"/>)
      system. The PKI may be managed by an operator or be autonomic. The document also
      introduces a new discovery mechanism, which is based on a neighbor
      learning process and is oriented towards negotiation objectives.</t>

      <t>It is understood that in realistic deployments, not all devices will
      support CDNP. Such mixed scenarios are not discussed in this specification. </t>

    </section>

    <section title="Requirements Language and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in <xref
      target="RFC2119"></xref> when they appear in ALL CAPS. When these words
      are not in ALL CAPS (such as "should" or "Should"), they have their
      usual English meanings, and are not to be interpreted as <xref
      target="RFC2119"></xref> key words.</t>

      <t><list style="symbols">
          <t>Negotiation Objective: specific negotiation content, which needs
          to be decided in coordination with another network device. It is
          naturally based on a specific service or function or action.
          It could be a logical, numeric, or string value or a more
          complex data structure. </t>

          <t>Negotiation Initiator: a device that spontaneously starts
          discovery or negotiation by sending a request message referring
          to a specific negotiation objective.</t>

          <t>Negotiation Counterpart: a peer device with which the Negotiation
          Initiator negotiates a specific negotiation objective.</t>

          <t>Device Identifier: a public key, which identifies the device in
          CDNP messages. It is assumed that its associated private key is
          maintained in the device only.</t>

          <t>Device Certificate: A certificate for a single device, also the
          identitier of the device, further described in <xref
          target="DeviceID"></xref>.</t>

          <t>Device Certificate Tag: a tag, which is bound to the device
          identitier. It is used to present Device Certificate in short
          form.</t>
        </list></t>
    </section>

    <!--Terminology-->

    <section anchor="Overview" title="CDNP Protocol Overview">
      <t>The Configuration Discovery and Negotiation protocol is designed to be 
      a generic platform, which is independent from the negotiation contents. 
      It only takes care of the general intercommunication between negotiation
      counterparts. The negotiation contents vary, giving the various
      negotiation objectives and the different pairs of negotiating
      counterparts. CDNP runs over UDP. </t>

      <t>The CDNP has been designed based on simple initiator/responder model,
      while multiple-party negotiations could be completed by indirect
      steps. The initiator requests a particular objective and the
      counterpart responds accordingly. </t>

      <section title="IP Version Independent">
        <t>To be a generic platform, CDNP should be IP version independent. In
        other words, it should be able to run over IPv6 and IPv4. Its messages
        and general options are neutral with respect to the IP version.</t>

        <t>However, some functions, such as multicasting or broadcasting on a link, 
        might need to be IP version dependent. For these parts, the document defines
        support for both IP versions separately.</t>
      </section>

      <section title="Objective Oriented Discovery Mechanism">
        <t>Typically, one network device has multiple functions. It may be
        involved in different negotiation processes for different
        negotiation objectives. Therefore, the traditional topology-oriented
        device discovery mechanisms are not sufficient for CDNP. A new
        discovery mechanism is needed to find negotiation counterparts based
        on a specific negotiation objective. As a result, an objective-based
        discovery mechanism is described in this document.</t>

        <t>For every new negotiation objective, the negotiation initiator
        needs to start a new discovery process in order to find the
        proper negotiation counterpart. Because a listening CDNP-enabled device
        has to know the requested negotiation objective to decide whether it
        is a proper negotiation counterpart and make a response, the discovery
        process needs to be tightly coupled with the request process.
        Therefore, in this document, the discovery process is merged into the
        request process. There is no need for an independent discovery message
        and process.</t>
      </section>

      <section title="Neighbor Diverting Discovery Mechanism">
        <t>We now discuss the general flow of Request, Negotiation, and
        Negotiation-Ending messages, and Accept, Decline and Divert options.
        Details of the options are given later.</t>

        <t>Discovery starts as on-link operation. However, negotiation may
        continue either on-link or off-link. The Divert option can tell
        the negotiation initiator to contact an off-link counterpart. </t>

        <t>Every Request message is sent by a negotiation initiator to the
        ALL_CDNP_NEIGHBOR multicast address (<xref target="Constants"></xref>).</t>

        <t>If the neighbor device is a proper negotiation counterpart, it MAY
        respond with a Negotiation message to start a negotiation process, or
        with a Negotiation-Ending message in the case of a clear Accept or
        Decline.</t>

        <t>If the neigbor device is not a proper negotiation counterpart for
        the objective given in the Request message, but knows a proper
        negotiation counterpart, for example because it negotiated the same
        objective with that other negotiation counterpart before, it SHOULD respond
        with a Negotiation-Ending message with a Divert option pointed to the
        proper negotiation counterpart. If the neigbor device is not a proper
        negotiation counterpart, but does not know a proper negotiation
        counterpart, it SHOULD respond with a Negotiation-Ending message with
        a Divert option pointed to its hierachical upstream device.</t>

        <t>After a CDNP device successfully negotiated a specific objective
        with a negotiation counterpart, it SHOULD record this negotiation
        counterpart with this objective type locally. This record may be used
        for future negotiation or to pass to another neighbor as a Divert option.
        This learning mechanism should be able to support most network
        establishment scenarios.</t>
      </section>

      <section title="Certificate-based Security Mechanism">
        <t>A certification based security mechanism provides security
        properties for CDNP:</t>

        <t><list style="symbols">
            <t>the identity of a CDNP message sender can be verified by a
            recipient.</t>

            <t>the integrity of CDNP message can be checked by the recipient of
            the message.</t>

            <t>anti-replay protection on the CDNP message recipient.</t>
          </list>The authority of the CDNP message sender depends on a Public
        Key Infrastructure (PKI) system with a Certification Authority (CA),
        which should normally be run by the network
        operator. In the case of a network with no operator, such as a small
        office or home network, the PKI itself needs to be established by an
        autonomic process, which is out of scope for this specification. </t>

        <t>A Request message MUST carry a Certificate option, defined in <xref
        target="CertOption"></xref>. The first Negotiation Message, responding
        to a Request message, SHOULD also carry a Certificate option. Using
        these messages, recipients build their certificate stores, indexed
        by the Device Certificate Tags included in every CDNP message. 
        This process is described in more detail below. </t>

        <t>Every message MUST carry a signature option, defined in <xref
        target="SignOption"></xref>.</t>

        <t>For now, the authors do not think packet size is a problem. In this
        CDNP specification, there SHOULD NOT be multiple certificates in a
        single message. The current most used public keys are 1024/2048 bits,
        some may reach 4096. With overhead included, a single certificate is
        less than 500 bytes. Messages should be far shorter than the normal
        packet MTU within a modern network.</t>

        <section title="Support for algorithm agility">
          <t>Hash functions are used to provide message integrity checks. In
          order to provide a means of addressing problems that may emerge in
          the future with existing hash algorithms, as recommended in <xref
          target="RFC4270"></xref>, a mechanism for negotiating the use of
          more secure hashes in the future is provided.</t>

          <t>In addition to hash algorithm agility, a mechanism for signature
          algorithm agility is also provided.</t>

          <t>The support for algorithm agility in this document is mainly a
          unilateral notification mechanism from sender to recipient. If the
          recipient does not support the algorithm used by the sender, it
          cannot authenticate the message. Senders in a single administrative
          domain are not required to upgrade to a new algorithm simultaneously.</t>

          <t>So far, the algorithm agility is supported by one-way
          notification, rather than negotiation mode. As defined in <xref
          target="SignOption"></xref>, the sender notifies the recipient what
          hash/signature algorithms it uses. If the responder doesn't know a
          new algorithm used by the sender, the negotiation request would
          fail. In order to establish a negotiation session, the sender MAY
          fall back to an older, less preferred algorithm. To avoid downgrade
          attacks it MUST NOT fall back to an algorithm considered weak. </t>
        </section>

        <section title="Message validation on reception">
          <t>When receiving a CDNP message, a recipient MUST discard the CDNP
          message if the Signature option is absent, or the Certificate option
          is in a Request Message.</t>

          <t>For the Request message and the Response message with a
          Certification Option, the recipient MUST first check the authority
          of this sender following the rules defined in <xref
          target="RFC5280"></xref>. After successful authority validation, an
          implementation MUST add the sender's certification into the local
          trust certificate record indexed by the associated Device Certificate
          Tag, defined in <xref target="DeviceID"></xref>.</t>

          <t>The recipient MUST now authenticate the sender by verifying the
          Signature and checking a timestamp, as specified in <xref
          target="TimeCheck"></xref>. The order of two procedures is left as
          an implementation decision. It is RECOMMENDED to check timestamp
          first, because signature verification is much more computationally
          expensive.</t>

          <t>The signature field verification MUST show that the signature has
          been calculated as specified in <xref target="SignOption"></xref>.
          The public key used for signature validation is obtained from the
          certificate either carried by the message or found from a local
          trust certificate record by searching the message-carried Device
          Certicate Tag.</t>

          <t>Only the messages that get through both the signature
          verifications and timestamp check are accepted and continue to be
          handled for their contained CDNP options. Messages that do not pass
          the above tests MUST be discarded as insecure
          messages.</t>

        </section>

        <section anchor="TimeCheck" title="TimeStamp checking">
          <t>Recipients SHOULD be configured with an allowed timestamp Delta
          value, a "fuzz factor" for comparisons, and an allowed clock drift
          parameter. The recommended default value for the allowed Delta is
          300 seconds (5 minutes); for fuzz factor 1 second; and for clock
          drift, 0.01 second.</t>

          <t>The timestamp is defined in the Signature Option, <xref target="SignOption"/>.
          To facilitate timestamp checking, each recipient SHOULD store the
          following information for each sender:</t>

          <t><list style="symbols">
              <t>The receive time of the last received and accepted CDNP
              message. This is called RDlast.</t>

              <t>The time stamp in the last received and accepted CDNP message.
              This is called TSlast.</t>
            </list>An accepted CDNP message is any successfully verified (for
          both timestamp check and signature verification) CDNP message from
          the given peer. It initiates the update of the above variables.
          Recipients MUST then check the Timestamp field as follows:</t>

          <t><list style="symbols">
              <t>When a message is received from a new peer (i.e., one that is
              not stored in the cache), the received timestamp, TSnew, is
              checked, and the message is accepted if the timestamp is recent
              enough to the reception time of the packet, RDnew: <list
                  style="empty">
                  <t>-Delta &lt; (RDnew - TSnew) &lt; +Delta</t>
                </list><vspace blankLines="1" />The RDnew and TSnew values
              SHOULD be stored in the cache as RDlast and TSlast.</t>

              <t>When a message is received from a known peer (i.e., one that
              already has an entry in the cache), the timestamp is checked
              against the previously received CDNP message:<list style="empty">
                  <t>TSnew + fuzz &gt; TSlast + (RDnew - RDlast) x (1 - drift)
                  - fuzz</t>
                </list><vspace blankLines="1" />If this inequality does not
              hold, the recipient SHOULD silently discard the message. If, on
              the other hand, the inequality holds, the recipient SHOULD
              process the message. <vspace blankLines="1" />Moreover, if the
              above inequality holds and TSnew &gt; TSlast, the recipient
              SHOULD update RDlast and TSlast. Otherwise, the recipient MUST
              NOT update RDlast or TSlast.</t>
            </list>An implementation MAY use some mechanism such as a
          timestamp cache to strengthen resistance to replay attacks. When
          there is a very large number of nodes on the same link, or when a
          cache filling attack is in progress, it is possible that the cache
          holding the most recent timestamp per sender will become full. In
          this case, the node MUST remove some entries from the cache or
          refuse some new requested entries. The specific policy as to which
          entries are preferred over others is left as an implementation
          decision.</t>
        </section>
      </section>

      <section title="Negotiation Procedures">
        <t>A negotiation initiator sends a negotiation request to discovered
        negotiation counterpart devices, which may be different according to
        different negotiation objectives. It may request relevant information
        from the negotiation counterpart so that it can decide its local
        configuration to give the most coordinated performance. It may request
        the negotiation counterpart to make a matching configuration in
        order to set up a successful communication with it. It may request
        certain simulation or forecast result by sending some dry run
        conditions. The details will be defined separately for each type
        of negotiation objective. </t>

        <t>If the counterpart can immediately apply the requested confguration,
        it will give a positive (yes) answer. This will normally end the
        negotiation phase immediately. Otherwise it will give a negative (no)
        answer. Normally, this will not end the negotiation phase. </t>

        <t>In the negative (no) case, the negotiation counterpart
        should be able to reply with a proposed alternative configuration
        that it can apply (typically, a configuration that uses fewer resources
        than requested by the negotiation initiator). This will start a bi-directional
        negotiation to reach a compromise between the two network devices.</t>

        <t>The negotiation procedure is ended when one of the negotiation
        peers sends a Negotiation Ending message, which contains an accept or
        decline option and does not need a response from the negotiation peer.</t>

        <t>A negotiation procedure concerns one objective and one counterpart.
        Both the initiator and the counterpart may take part in simultaneous
        negotiations with various other devices, or in simultaneous negotiations
        about different objectives. Thus, CDNP is expected to be used in a
        multi-threaded mode. Certain negotiation objectives may have restrictions
        on multi-threading, for example to avoid over-allocating resources. </t>

      </section>
    </section>

    <section anchor="Constants" title="CDNP Constants">
      <t><list style="symbols">
          <t>ALL_CDNP_NEIGHBOR (TBD1)<vspace blankLines="1" />A link-local
          scope multicast address used by a CDNP-enabled router to discover
          CDNP-enabled neighbor (i.e., on-link) devices . All routers that
          support CDNP are members of this multicast group.<list
              style="symbols">
              <t>IPv6 multicast address: TBD1</t>

              <t>IPv4 multicast address: TBD2</t>
            </list></t>

          <t>CDNP Listen Port (TBD3)<vspace blankLines="1" />A UDP port that
          every CDNP-enabled network device always listens to.</t>
        </list></t>
    </section>

    <section anchor="DeviceID" title="Device Identifier and Certificate Tag">
      <t>A CDNP-enabled Device MUST generate a stable public/private key pair
      before it participates in CDNP. There MUST NOT be any way of accessing
      the private key via the network or an operator interface. The device then
      uses the public key as its identifier, which is cryptographic in nature.
      It is a CDNP unique identifier for a CDNP participant.</t>

      <t>It then gets a certificate for this public key, signed by a
      Certificate Authority that is trusted by other network devices. The
      Certificate Authority SHOULD be managed by the network administrator, to
      avoid needing to trust a third party. The signed certificate would be
      used for authentication of the message sender. In a managed network,
      this certification process could be performed at a central location before
      the device is physically installed at its intended location. In an unmanaged
      network, this process must be autonomic, including the bootstrap phase. </t>

      <t>A 128-bit Device Certifcate Tag, which is generated by taking a
      cryptographic hash over the device certificate, is a short presentation
      for CDNP messages. It is the index key to find the device certificate in
      a recipient's local trusted certificate record.</t>

      <t>The tag value is formed by taking a SHA-1 hash algorithm over the
      corresponding device certificate and taking the leftmost 128 bits of the
      hash result.</t>
    </section>

    <section title="Session Identifier">
      <t>A 24-bit opaque value used to distinguish multiple sessions between
      the same two devices. A new Session ID SHOULD be generated for every new
      Request message. All followup messages in the same negotiation
      procedure, which is initiated by the request message, SHOULD carry the
      same Session ID.</t>

      <t>The Session ID SHOULD have a very low collision rate locally. It is
      RECOMMENDED to be generated by a pseudo-random algorithm using a seed
      which is unlikely to be used by any other device in the same network.</t>
    </section>

    <section anchor="CDNPMessages" title="CDNP Messages">
      <t>This document defines the following CDNP message format and types.
      Message types not listed here are reserved for future use. The numeric
      encoding for each message type is shown in parentheses.</t>

      <section title="CDNP Messsage Format">
        <t>All CDNP messages share an identical fixed format header and a
        vaiable format area for options. Every Message carries the Device
        Certificate Tag of its sender and a Session ID. Options are presented
        serially in the options field, with no padding between the options.
        Options are byte-aligned.</t>

        <t>The following diagram illustrates the format of CDNP messages:</t>

        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_TYPE  |                Session ID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   Device Certificate Tag                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Options  (variable length)             |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MESSAGE_TYPE   Identifies the CDNP message type. 8-bit. 

Session ID     Identifies this negotiation session, as defined in
               Section 6. 24-bit.

Device Certificate Tag
               Present the Device Certificate, which identifies
               the negotiation deviceas, as defined in Section 5.
               The Device Certificate Tag is 128 bit, also defined
               in Section 5. It is used as index key to find the
               device certificate.

Options        CDNP Options carried in this message. Options are
               definded in Section 8.
]]></artwork>
          </figure></t>
      </section>

      <section title="Request Message">
        <t><figure>
            <artwork><![CDATA[REQUEST (1)    A negotiation requesting node sends a REQUEST message
               to initiate a negotiation.

               If the requesting node does not know any negotiation
               counterpart, it sends the REQUEST messages to the
               link-local ALL_CDNP_NEIGHBOR multicast address.

               If the requesting node re-contacts a known negotiation
               counterpart, it sends the REQUEST message to the
               unicast address of the negotiation counterpart
               directly.]]></artwork>
          </figure></t>
      </section>

      <section title="Negotiation Message">
        <t><figure>
            <artwork><![CDATA[NEGOTIATION (2)A negotiation counterpart sends an NEGOTIATION
               message in response to a REQUEST message or a 
               Negotiation message in a negotiation process which
               may need multiple steps.]]></artwork>
          </figure></t>
      </section>

      <section title="Negotiation-ending Message">
        <t><figure>
            <artwork><![CDATA[NEGOTIATION-ENDING (3)
               A negotiation counterpart sends an NEGOTIATION-EDNING
               message to close the negotiation. It MUST contain 
               one, but only one of accept/decline/divert option, 
               defined in Section 8. It could be sent either by the 
               requesting node or the responding node.]]></artwork>
          </figure></t>
      </section>

      <section title="Confirm-waiting Message">
        <t><figure>
            <artwork><![CDATA[CONFIRM-WAITING (4)
               A responding node sends a CONFIRM-WAITING message to
               indicate the requesting node to wait for a further
               negotiation response. It might be that the local
               process needs more time or that the negotiation 
               depends on another triggered negotiation. This
               message MUST NOT include any other options than the
               WAITING option defined in Section 8.5.]]></artwork>
          </figure></t>
      </section>
    </section>

    <section anchor="CDNPOptions" title="CDNP General Options">
      <t>This section defines the CDNP general option for the negotiation
      protocol signalling. Option type 10~64 is reserved for CDNP general
      options defined in the future.</t>

      <section title="Format of CDNP Options">
        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          option-code          |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          option-data                          |
|                      (option-len octets)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    An unsigned integer identifying the specific option
               type carried in this option.

Option-len     An unsigned integer giving the length of the
               option-data field in this option in octets.

Option-data    The data for the option; the format of this data
               depends on the definition of the option.
]]></artwork>
          </figure>CDNP options are scoped by using encapsulation. If an
          option contains other options, the outer Option-len includes
          the total size of the encapsulated options, and the latter apply
          only to the outer option.</t>
      </section>

      <section title="Divert Option">
        <t>The divert option is used to redirect a CDNP request to another
        node, which may be more appropriate for the intended negotiation. It may
        redirect to an entity that is known as a specific negotiation
        counterpart or a default gateway or a hierarchically upstream devices.
        The divert option MUST only be encapsulated in Negotiation-ending
        messages. If found elsewhere it SHOULD be silently ignored. </t>

        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         OPTION_DIVERT         |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Locator Option (s) of Diversion Device(s)         |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_DIVERT (1).

Option-len     The total length of diverted destination
               sub-option(s) in octets.

Locator Option (s) of Diverted Device
               Emedded Locator Option(s), defined in Section 8.8,
               that point to diverted destination device(s).
]]></artwork>
          </figure></t>
      </section>

      <section title="Accept Option">
        <t>The accept option is used to indicate the negotiation counterpart
        that the proposed negotiation content is accepted.</t>

        <t>The accept option MUST only be encapsulated in Negotiation-ending
        messages. If found elsewhere it SHOULD be silently ignored.</t>



        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION_ACCEPT          |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_ACCEPT (2).

Option-len     0.]]></artwork>
          </figure></t>
      </section>

      <section title="Decline Option">
        <t>The decline option is used to indicate the negotiation counterpart
        the proposed negotiation content is declined and end the negotiation
        process.</t>

        <t>The decline option MUST only be encapsulated in Negotiation-ending
        messages.  If found elsewhere it SHOULD be silently ignored.</t>

        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION_DECLINE         |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_DECLINE (3).

Option-len     0.]]></artwork>
          </figure></t>

        <t>Notes: there are scenarios where a negotiation counterpart wants to
        decline the proposed negotiation content and continue the negotiation
        process. For these scenarios, the negotiation counterpart SHOULD use a
        Response message, with either an objective option that contains at
        least one data field with all bits set to 1 to indicate a meaningless
        initial value, or a specific objective option that provides
        further conditions for convergence.</t>



      </section>

      <section title="Waiting Time Option ">
        <t>The waiting time option is used to indicate that the negotiation
        counterpart needs to  wait for a further negotiation response, since the
        processing might need more time than usual or it might depend on
        another triggered negotiation.</t>

        <t>The waiting time option MUST only be encapsulated in
        Confirm-waiting messages. If found elsewhere it SHOULD be silently ignored.</t>

        <t>The counterpart SHOULD send a Response message or another Confirm-waiting message
        before the current waiting time expires. If not, the initiator
        SHOULD abandon or restart the negotiation procedure, to avoid an indefinite
        wait. </t>


        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_WAITING          |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Time                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_WAITING (4).

Option-len     4, in octets.

Time           The time is counted in millisecond as a unit.]]></artwork>
          </figure></t>

      </section>

      <section anchor="CertOption" title="Certificate Option">
        <t>The Certificate option carries the certificate of the sender. The
        format of the Certificate option is as follows:</t>

        <t><figure>
            <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION Certificate      |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                    Certificate (variable length)              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_CERT_PARAMETER (5)

Option-len     Length of certificate in octets

Public key     A variable-length field containing a certificate
]]></artwork>
          </figure></t>

      </section>

      <section anchor="SignOption" title="Signature Option">
        <t>The Signature option allows public key-based signatures to be
        attached to a CDNP message. The Signature option is REQUIRED in
        every CDNP message and could be any place
        within the CDNP message. It protects the entire CDNP header and options.
        A TimeStamp has been integrated in the Signature Option for
        anti-replay protection. The format of the Signature option is
        described as follows:</t>

        <t><figure>
            <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     OPTION_SIGNATURE          |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           HA-id               |            SA-id              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Timestamp (64-bit)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                    Signature (variable length)                .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_SIGNATURE (6)

Option-len     12 + Length of Signature field in octets.

HA-id          Hash Algorithm id. The hash algorithm is used for
               computing the signature result. This design is
               adopted in order to provide hash algorithm agility.
               The value is from the Hash Algorithm for CDNP
               registry in IANA. The initial value assigned
               for SHA-1 is 0x0001.

SA-id          Signature Algorithm id. The signature algorithm is
               used for computing the signature result. This
               design is adopted in order to provide signature
               algorithm agility. The value is from the Signature
               Algorithm for CDNP registry in IANA. The initial
               value assigned for RSASSA-PKCS1-v1_5 is
               0x0001.

Timestamp      The current time of day (NTP-format timestamp
               [RFC5905] in UTC (Coordinated Universal Time), a
               64-bit unsigned fixed-point number, in seconds
               relative to 0h on 1 January 1900.). It can reduce
               the danger of replay attacks.

Signature      A variable-length field containing a digital
               signature. The signature value is computed with
               the hash algorithm and the signature algorithm, as
               described in HA-id and SA-id. The signature
               constructed by using the sender's private key
               protects the following sequence of octets:

               1. The CDNP message header.

               2. All CDNP options including the Signature option
               (fill the signature field with zeroes).

               The signature field MUST be padded, with all 0, to
               the next 16 bit boundary if its size is not an even
               multiple of 8 bits. The padding length depends on
               the signature algorithm, which is indicated in the
               SA-id field.

]]></artwork>
          </figure></t>
      </section>

      <section title="Locator Options">
        <t>These locator options are used to present a device's or interface's
        reachability information. They are Locator IPv4 Address Option,
        Locator IPv6 Address Option and Locator FQDN (Fully Qualified Domain
        Name) Option.</t>

        <section title="Locator IPv4 address option">
          <t><figure>
              <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    OPTION_LOCATOR_IPV4ADDR    |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          IPv4-Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_LOCATOR_IPV4ADDR (7)

Option-len     4, in octets.

IPv4-Address   The IPv4 address locator of the device/interface. ]]></artwork>
            </figure></t>
        </section>

        <section title="Locator IPv6 address option">
          <t><figure>
              <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   OPTION_LOCATOR_IPV6ADDR     |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          IPv6-Address                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_LOCATOR_IPV6ADDR (8).

Option-len     16, in octets.

IPv6-Address   The IPv6 address locator of the device/interface.]]></artwork>
            </figure>Note: link-local IPv6 address SHOULD be avoided when this
          option is used in the Divert option. It may create a connection
          problem.</t>
        </section>

        <section title="Locator FQDN option">
          <t><figure>
              <artwork><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         OPTION_FQDN           |           option-len          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Fully Qualified Domain Name                 |
|                       (variable length)                       |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option-code    OPTION_FQDN (9).

Option-len     Length of Fully Qualified Domain Name in octets.

Domain-Name    The Fully Qualified Domain Name of the entity.]]></artwork>
            </figure></t>
        </section>
      </section>
    </section>

    <section anchor="ObjOption" title="Objective Options and Considerations">
      <t>The Objective options contains negotiation objectives, which are
      various according to different functions/services. They MUST be carried
      by Request or Negotiation Messages only. Objective options SHOULD be
      assigned an option type greater than 64 in the CDNP option table.</t>

      <t>For most scenarios, there SHOULD be initial values in the negotiation
      requests. Consequently, the Objective options SHOULD always be
      completely presented in a Request message. If there is no initial value,
      the bits in the value field SHOULD all be set to 1 to indicate a meaningless
      value, unless this is inappropriate for the specific negotiation objective.</t>

      <section title="Organizing of CDNP Options">
        <t>Naturally, a negotiation objective, which is based on a specific
        service or function or action, SHOULD be organized as a single CDNP option.
        It is NOT RECOMMENDED to organize multiple negotiation objectives into a
        single option.</t>

        <t>A negotiation objective may have multiple parameters. Parameters
        can be categorized into two class: the obligatory ones presented as
        fixed fields; and the optional ones presented in TLV sub-options. It is
        NOT RECOMMENDED to split parameters in a single objective into multiple
        options, unless they have different response periods. An exception
        scenario may also be described by split objectives.</t>
      </section>

      <section title="Vendor Specific Options ">
        <t>Option codes 128~159 have been reserved for vendor specific
        options. Multiple option codes have been assigned because a single
        vendor may use multiple options simultaneously. These vendor specific
        options are highly likely to have different meanings when used by
        different vendors. Therefore, they SHOULD NOT be used without
        an explicit human decision. They are not suitable for unmanaged
        networks such as home networks.</t>
      </section>

      <section title="Experimental Options">
        <t>Option code 176~191 have been reserved for experimental options.
        Multiple option codes have been assigned because a single experiment
        may use multiple options simultaneously. These experimental
        options are highly likely to have different meanings when used for
        different experiments. Therefore, they SHOULD NOT be used without
        an explicit human decision. They are not suitable for unmanaged
        networks such as home networks. </t>
      </section>
    </section>

    <section title="Items for Future Work">
      <t>There are a few open design questions that are worthy of more work in
      the near future, as listed below:</t>

      <t><list style="symbols">
          <t>UDP vs TCP: For now, this specification has chosen UDP as message
          transport mechanism. However, this is not closed yet. UDP is good
          for short conversations, fitting the divert scenarios well. However,
          it may have issues with large packets. TCP is good for stable and
          long sessions, with a little bit of time comsumption during the
          session establishment stage. If messages exceed a reasonable MTU,
          a TCP mode may be necessary.</t>

          <t>Message encryption: should CDNP messages be encrypted as well as
          signed, to protect against internal eavesdropping within the
          network?</t>

          <t>TLS or DTLS vs built-in security mechanism. For now, this specifcation
          has chosen a PKI based build-in security mechanism. However, TLS or DTLS might
          be chosen as security infrastructure for simplification reasons.</t>

          <t>Timeout for lost Negotiation Ending and other messages to be added. </t>

          <t>CDNP currently requires every participant to have an NTP-synchronized
          clock. Is this OK for low-end devices? </t>

          <t>Would use of MDNS have any impact on the Locator FQDN option?</t> 

          <t>Use case. A use case may help readers to understand the
          applicability of this specification. However, the authors have not
          yet decided whether to have a separate document or have it in this
          document. General uses cases for AN have been developed, but they
          are not specific enough for this purpose. </t>

          <t>Rules about how data items are defined in a negotiation
          objective. Maybe a formal information model is needed.</t>

          <t>We currently assume that there is only one counterpart for each discovery action.
          If this is false or one negotiation request receives multiple different responses,
          how does the initator choose between them? Could it split them into
          multiple follow-up negotiations? </t>

          <t>Alternatives to TLV format. It may be useful to provide a generic
          method of carrying negotiation objectives in a high-level format
          such as YANG or an XML schema. It may also be useful to provide a generic
          method of carrying existing configuration information such as DHCP(v6) or
          IPv6 RA messages. These features could be provided by encapsulating
          such messages in their own TLVs. </t>

        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Using certificate-based security mechanism and its verification
      mechanism in CDNP message exchanging provides the authentication and data
      integrity protection. The timestamp mechanism provides an anti-replay
      function.</t>

      <t>Since CDNP is intended to be deployed in a single administrative
      domain recommended to operate its own CA, there is no need for a trusted
      third party.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t><xref target="Constants"></xref> defines the following mtwpulticast
      addresses, which have been assigned by IANA for use by CDNP:</t>

      <t><list style="hanging">
          <t hangText="ALL_CDNP_NEIGHBOR multicast address">(IPv6): (TBD1)</t>

          <t hangText="ALL_CDNP_NEIGHBOR multicast address">(IPv4): (TBD2)</t>
        </list></t>

      <t><xref target="Constants"></xref> defines the following UDP port,
      which have been assigned by IANA for use by CDNP:</t>

      <t><list style="hanging">
          <t hangText="CDNP Listen Port:">(TBD3)</t>
        </list></t>

      <t>This document defined a new Configuration Discovery and Negotiation Protocol. The
      IANA is requested to create a new CDNP registry. The IANA is also
      requested to add two new registry tables to the newly-created CDNP
      registry. The two tables are the CDNP Messages table and CDNP Options
      table.</t>

      <t>Initial values for these registries are given below. Future
      assignments are to be made through Standards Action or Specification
      Required <xref target="RFC5226"></xref>. Assignments for each registry
      consist of a type code value, a name and a document where the usage is
      defined.</t>

      <t>CDNP Messages table. The values in this table are 16-bit unsigned
      integers. The following initial values are assigned in <xref
      target="CDNPMessages"></xref> in this document:</t>

      <t><figure>
          <artwork><![CDATA[      Type  |          Name               |   RFCs
   ---------+-----------------------------+------------
        0   |Reserved                     | this document
        1   |Request Message              | this document
        2   |Negotiation Message          | this document
        3   |Negotiation-end Message      | this document
        4   |Confirm-waiting Message      | this document
]]></artwork>
        </figure>CDNP Options table. The values in this table are 16-bit
      unsigned integers. The following initial values are assigned in <xref
      target="CDNPOptions"></xref> and <xref target="ObjOption"> </xref> in
      this document:</t>

      <t><figure>
          <artwork><![CDATA[      Type  |          Name               |   RFCs
   ---------+-----------------------------+------------
        0   |Reserved                     | this document
        1   |Divert Option                | this document
        2   |Accept Option                | this document
        3   |Decline Option               | this document
        4   |Waiting Time Option          | this document 
        5   |Certificate Option           | this document
        6   |Sigature Option              | this document
        7   |Device IPv4 Address Option   | this document
        8   |Device IPv6 Address Option   | this document
        9   |Device FQDN Option           | this document
     10~64  |Reserved for future CDNP     | this document
            |General Options              |
    128~159 |Vendor Specific Options      | this document
    176~191 |Experimental Options         | this document
]]></artwork>
        </figure>The IANA is also requested to create two new registry tables
      in the CDNP Parameters registry. The two tables are the Hash Algorithm
      for CDNP table and the Signature Algorithm for CDNP table.</t>

      <t>Initial values for these registries are given below. Future
      assignments are to be made through Standards Action or Specification
      Required <xref target="RFC5226"></xref>. Assignments for each registry
      consist of a name, a value and a document where the algorithm is
      defined.</t>

      <t>Hash Algorithm for CDNP. The values in this table are 16-bit unsigned
      integers. The following initial values are assigned for Hash Algorithm
      for CDNP in this document:</t>

      <t><figure>
          <artwork><![CDATA[          Name          |  Value    |  RFCs
   ---------------------+-----------+------------
         Reserved       |   0x0000  | this document
         SHA-1          |   0x0001  | this document
         SHA-256        |   0x0002  | this document
]]></artwork>
        </figure>Signature Algorithm for CDNP. The values in this table are
      16-bit unsigned integers. The following initial values are assigned for
      Signature Algorithm for CDNP in this document:</t>

      <t><figure>
          <artwork><![CDATA[          Name          |   Value   |  RFCs
   ---------------------+-----------+------------
         Reserved       |   0x0000  | this document
    RSASSA-PKCS1-v1_5   |   0x0001  | this document
]]></artwork>
        </figure></t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Valuable comments were received from Zhenbin Li and Dacheng Zhang,
      and other participants in the xxx working group.</t>

      <t>This document was produced using the xml2rfc tool <xref
      target="RFC2629"></xref>.</t>
    </section>

    <section anchor="changes" title="Change log [RFC Editor: Please remove]">
      <t>draft-jiang-config-negotiation-protocol-02: adapted scope to include discovery,
      multiple threads, mentioned YANG etc. encapsulation, 2013-06-26.</t>
      <t>draft-jiang-config-negotiation-protocol-01: corrections and additions,
      2014-04-21.</t>
      <t>draft-jiang-config-negotiation-protocol-00: original version,
      2013-10-19.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      <?rfc include='reference.RFC.5280'?>
    </references>

    <references title="Informative References">
      &RFC2629;

      <?rfc include='reference.RFC.5226'?>

      <?rfc include='reference.RFC.4270'?>

      <?rfc include='reference.RFC.5905'?>

      &DRAFT-config-ps;
      &DRAFT-AN-def;
      &DRAFT-AN-gap;
    </references>
  </back>
</rfc>
