<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-dlep-containers-00" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title>Container Data Items for DLEP</title>
    <author initials="R." surname="Taylor" fullname="Rick Taylor">
      <organization>Airbus Defence &amp; Space</organization>
      <address>
        <postal>
          <street>Quadrant House</street>
          <street>Celtic Springs</street>
          <street>Coedkernew</street>
          <city>Newport</city>
          <code>NP10 8FZ</code>
          <country>UK</country>
        </postal>
        <email>rick@tropicalstormsoftware.com</email>
      </address>
    </author>
    <date/>
    <!--<area>Routing</area> <workgroup>Mobile Ad hoc Networks Working Group</workgroup> -->
    <abstract><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --><t>Several DLEP extensions are being suggested that require the ability to group a set of DLEP Data Items into a logical set or bag. This document species a generic method of defining such a bag of Data Items, in what this document defines as a Data Item Container. This document also describes what an extension using Data Item Containers must specify in the extension specification.  </t> </abstract>
  </front>
  <middle><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --><section title="Introduction" anchor="introduction" toc="default"><t>A DLEP Data Item Container defined by this document is a generic wrapper or container of DLEP Data Items, where the presence of the container around the Data Items implies a logical association between the Data Items in the Container.  </t><t>This document does not define a new DLEP extension, but does instead define a set of guidelines for DLEP extension authors.  </t><section title="Conventions and Terminology" anchor="conventions-and-terminology" toc="default"><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 BCP 14, RFC 2119 <xref target="RFC2119" pageno="false" format="default"/>.  </t></section></section><section title="Container Data Item" anchor="container-data-item" toc="default"><t>The Container Data Item allows a DLEP extension to parenthesize a set of DLEP Data Items, implying a logical assocaition between the Data Items in the container.  </t><t>The Container Data Item contains the following fields: </t><figure title="" suppress-title="false" align="left" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:               DLEP Data Items (zero or more)                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure><t><list style="hanging"><t hangText="Data Item Type:">Defined by the extension. Allocated from IANA "DLEP Data Item Values" registry.  </t><t hangText="Length:">Sum of Lengths of contained DLEP Data Items, including header lengths, i.e. the total length of the Container Data Item </t><t hangText="DLEP Data Items:">0 or more DLEP Data Items, as defined in <xref target="I-D.ietf-manet-dlep" pageno="false" format="default"/>.  </t></list></t><section title="Specification of Conatiner Data Items" anchor="specification-of-conatiner-data-items" toc="default"><t>When the use of a Container Data Item is defined in a DLEP extension specification, the specification MUST define which DLEP Data Items are valid within the Conatiner, and also the multiplicity of Data Items in the Container.  </t><t>Unless otherwise allowed by an individual DLEP extension specification, any Data Item not defined as allowed in the Container MUST NOT appear, and an implementation receiving such a Data Item MUST teminate the DLEP session, using the DLEP Status Code 'Invalid Data'.  </t></section></section><section title="Security Considerations" anchor="security-considerations" toc="default"><t>I'm not sure there are any.  </t></section><section title="IANA Considerations" anchor="iana-considerations" toc="default"><t>None.  </t></section> </middle>
  <back><references title="Normative References"><reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119" quote-title="true"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author><date year="1997" month="March"/><abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><seriesInfo name="DOI" value="10.17487/RFC2119"/></reference> <reference anchor="I-D.ietf-manet-dlep" quote-title="true"><front><title>Dynamic Link Exchange Protocol (DLEP)</title><author initials="S" surname="Ratliff" fullname="Stan Ratliff"><organization/></author><author initials="S" surname="Jury" fullname="Shawn Jury"><organization/></author><author initials="D" surname="Satterwhite" fullname="Darryl Satterwhite"><organization/></author><author initials="R" surname="Taylor" fullname="Rick Taylor"><organization/></author><author initials="B" surname="Berry" fullname="Bo Berry"><organization/></author><date month="December" day="9" year="2016"/><abstract><t>When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  A bidirectional, event- driven communication channel between the router and the modem is necessary.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-ietf-manet-dlep-26"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-manet-dlep-26.txt"/></reference> </references><references title="Informative References"><reference anchor="RFC5226" target="http://www.rfc-editor.org/info/rfc5226" quote-title="true"><front><title>Guidelines for Writing an IANA Considerations Section in RFCs</title><author initials="T." surname="Narten" fullname="T. Narten"><organization/></author><author initials="H." surname="Alvestrand" fullname="H. Alvestrand"><organization/></author><date year="2008" month="May"/><abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract></front><seriesInfo name="RFC" value="5226"/><seriesInfo name="DOI" value="10.17487/RFC5226"/></reference> </references><!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc --> </back>
</rfc>
