One document matched: draft-wing-avt-register-srtp-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc4568 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY rfc5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY xml2rfcversion SYSTEM "/xml2rfc/version.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-avt-register-srtp-00"
     ipr="trust200902" updates="4568, 3711">
  <front>
    <title abbrev="Policy for Registering SRTP Transforms">Policy for Registering SRTP Transforms</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date year="2009" />

    <workgroup>AVT Working Group</workgroup>

    <abstract>
      <t>This document updates existing RFCs so that Informational-track
RFCs can add new SRTP cryptographic transforms.</t>
    </abstract>

    <note 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 <xref
      target="RFC2119"></xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
<t>It is desirable to extend SRTP and its keying mechanisms to 
support country-specific cryptographic transforms.  This document
resolves a clash between IETF procedure and existing RFCs.  IETF
procedure requires that country-specific cryptographic transforms
be published as Informational-track documents [citation needed],
but existing documents require extensions to SRTP and extensions
to SRTP keying to be published as Standards-Track documents.</t>
<t>The IANA Considerations section of this document resolves this
clash by allowing Informational-track documents to register new
cryptographic transforms.</t>
</section>


    <section anchor="security_considerations" title="Security Considerations">
      <t>There are no security considerations for this document.</t>
</section>

    <section anchor="iana" title="IANA Considerations">
<t>This document updates Section 6 and 12 of <xref
target="RFC3711"></xref> and Section 10.2.1 of <xref
target="RFC4568"></xref>.  New SRTP cryptographic transforms for those
documents MUST be allocated by IANA using the "IETF Review" policy of
<xref target="RFC5226"></xref> using either informational-track or
standards-track RFCs.</t> </section>

    <section title="Acknowledgements">
      <t>Thanks to Roni Even for guidance on this document.</t>
<t>This document was produced using version &xml2rfcversion; of XML2RFC.</t>
</section> </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
&rfc4568;
&rfc3711;
&rfc5226;
    </references>

<!--
    <references title="Informative References">

      &rfc2766;

      &I-D.perkins-sourceipnat;

      <reference anchor="DynDNS"
                 target="http://www.dyndns.com/services/webredirect">
        <front>
          <title>Web Redirection</title>

          <author fullname="DynDNS" surname="DynDNS">
            <organization></organization>
          </author>

          <date month="September" year="2009" />
        </front>
      </reference>

    </references>
-->

    <!--
    <section title="Changes">
<section title="Changes from -02 to -03">
<t><list style="symbols">
<t>Removed FTP interworking, because <xref target="I-D.van-beijnum-behave-ftp64"></xref> proposes that FTP
clients use the same IP address for the data connection as the 
control connection.  This eliminates the need for the FTP client
to learn the translator's prefix.</t>
<t>Added multicast to DHCP and RA messages.</t>
</list></t>
</section>
      <section title="Changes from -01 to -02">
        <t><list style="symbols">
            <t>provided another method of using RA message for a host to learn
            its translator's IPv6 prefix and length</t>

            <t>added IPv4 address literals in URIs and multicast as
            benefactors for learning the translator's prefix.</t>

            <t>added FTP interworking using PASV</t>

            <t>clarified which Scenarios this applies to, and that this is for
            stateful and stateless.</t>
          </list></t>
      </section>

      <section title="Changes from -00 to -01">
        <t><list style="symbols">
            <t>made clearer this is for NAT64 prefix (changed title and some
            text).</t>

            <t>changed from querying for "_aft_prefix" TXT record to querying
            ipv6.arpa NAPTR record.</t>

            <t>BitTorrent is another application that benefits from knowing
            the NAT64 prefix; previously only DNSSEC was listed.</t>

            <t>changed to standards track.</t>
          </list></t>
      </section>
    </section>
-->
  </back>
</rfc>