One document matched: draft-taylor-dime-addressorprefix-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6733 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-
Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" docName="draft-taylor-dime-addressorprefix-00"
ipr="trust200902" updates="6733">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902,
noDerivativesTrust200902
     pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only
necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="AddressOrPrefix AVP Data Format">The AddressOrPrefix
Derived AVP Data Format For Diameter</title>

    <author initials="T." surname="Taylor" fullname="Tom Taylor">
      <organization>PT Taylor Consulting</organization>
      <address>
        <postal>
          <street></street>
          <city>Ottawa</city>
          <region></region>
          <code></code>
          <country>Canada</country>
        </postal>
        <phone></phone>
        <email>tom.taylor.stds@gmail.com</email>
      </address>
    </author>

    <date year="2014" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>Diameter</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Section 4.3.1 of the Diameter base specification [RFC6733] 
      defines a number of derived AVP data formats. This collection
      includes the Address format, which is suitable for encoding
      complete addresses. In some potential applications, however, there
      is a requirement to encode a prefix rather than a complete address.
      This document defines the AddressOrPrefix derived AVP data format,
      modelled after the Address format defined in [RFC6733], but allowing
      the same AVP to represent a prefix of any length up to a full
      address. This document updates RFC 6733. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>AVP data formats are used in Diameter <xref target="RFC6733"/>
      to specify AVP syntax for non-grouped AVPs. Section 4.3.1 of
      <xref target="RFC6733"/> defines the Address data format for the
      encoding of full addresses. However, no AVP data format has been 
      defined to encode prefixes, which are required in some potential
      applications. This document defines the AddressOrPrefix derived
      AVP data format, which is modelled on the Address format but 
      provides for a prefix length varying from zero to a full address.     
      </t>
    
      <t>Section 4.3 of <xref target="RFC6733"/> introduces the topic
      of derived AVP data
      formats, and provides direction for specifying additional such
      formats. The present document conforms to the stated requirements.</t>
      
      <section title="Requirements Language">
        <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 
        <xref target="RFC2119"/>.</t>
      </section>
    </section>
    
    
    <section anchor="deriv" title="Derived AVP Data Formats">

      <t>This section defines a new derived AVP data format, 
      AddressOrPrefix, according to the rules given in Section 4.3
      of <xref target="RFC6733"/>.</t>
      
      <t>AddressOrPrefix
      <list style="empty">
        <t>The AddressOrPrefix data format is an extension of the Address
        data format defined in Section 4.3.1 of <xref target="RFC6733"/>.
        Like the Address data format, it is derived from the OctetString basic
        AVP format. As well as an AddressType, it contains a PrefixLength field.
        The detailed specification is as follows:
        <list style="symbols">
          <t>As with the Address AVP, the first two octets represent the
          AddressType, which contains an Address Family, defined in
          <xref target="IANAADFAM"/>.</t>
          
          <t>The next two octets are interpreted as a 16-bit unsigned integer
          representing the PrefixLength. Valid values of PrefixLength are
          from 0 to 32 for IPv4 and from 0 to 128 for IPv6. The value 0 is
          included in each range to allow for presentation of a "null prefix",
          the meaning of which MUST be defined by applications that use AVPs
          based on the AddressOrPrefix data format. 
          </t>
          
          <t>The remaining octets present the prefix or address, most
          significant octet first. If the prefix does not extend to an
          octet boundary, the low-order bits of the final octet MUST be
          padded with zeroes.</t> 
        </list>
        </t>
      </list></t>

    </section>  <!-- deriv -->
    

    <section anchor="IANA" title="IANA Considerations">

      <t>This memo contains no actions for IANA. </t>
      
    </section>

    <section anchor="Security" title="Security Considerations">

      <t>The definition of the AddressOrPrefix AVP data format has
      no security implications in itself. AVPs defined using this
      format may be sensitive and require security anaqlysis.</t>

    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
      &RFC2119;
      &RFC6733;
       
  <reference anchor="IANAADFAM" 
      target="http://www.iana.org/assignments/address-family-numbers">
    <front>
      <title>Address Family Numbers</title>
      <author initials="" surname="">
        <organization>IANA</organization>
      </author>
      <date month="" year=""/>
    </front>
  </reference> 
  
 </references>

  </back>
</rfc>