From bfd4996074678bcb65efa94f53a1476e6cec8329 Mon Sep 17 00:00:00 2001
From: Michael Gebetsroither <gebi@mgeb.org>
Date: Mon, 24 Nov 2008 16:45:10 +0000
Subject: fixed typo

Signed-off-by: Michael Gebetsroither <gebi@sbox.tugraz.at>
---
 ...enger-secure-anycast-tunneling-protocol-02.html |  56 ++++-----
 ...senger-secure-anycast-tunneling-protocol-02.txt | 130 ++++++++++-----------
 ...senger-secure-anycast-tunneling-protocol-02.xml |   2 +-
 3 files changed, 90 insertions(+), 98 deletions(-)

(limited to 'papers')

diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html
index 2374bb6..9be33dd 100644
--- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html
+++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.html
@@ -3,7 +3,7 @@
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
 <meta name="description" content="secure anycast tunneling protocol (SATP)">
 <meta name="keywords" content="satp, Internet-Draft, secure anycast tunneling protocol, anycast, tunnel, secure, protocol">
-<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)">
+<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
 <style type='text/css'><!--
         body {
                 font-family: verdana, charcoal, helvetica, arial, sans-serif;
@@ -143,8 +143,8 @@
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
 <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
 <tr><td class="header">Network Working Group</td><td class="header">O. Gsenger</td></tr>
-<tr><td class="header">Internet-Draft</td><td class="header">May 6, 2008</td></tr>
-<tr><td class="header">Expires: November 7, 2008</td><td class="header">&nbsp;</td></tr>
+<tr><td class="header">Internet-Draft</td><td class="header">May 2008</td></tr>
+<tr><td class="header">Expires: November 2, 2008</td><td class="header">&nbsp;</td></tr>
 </table></td></tr></table>
 <h1><br />secure anycast tunneling protocol (SATP)<br />draft-gsenger-secure-anycast-tunneling-protocol-02</h1>
 
@@ -172,15 +172,11 @@ The list of current Internet-Drafts can be accessed at
 The list of Internet-Draft Shadow Directories can be accessed at
 <a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
 <p>
-This Internet-Draft will expire on November 7, 2008.</p>
-
-<h3>Copyright Notice</h3>
-<p>
-Copyright &copy; The IETF Trust (2008).</p>
+This Internet-Draft will expire on November 2, 2008.</p>
 
 <h3>Abstract</h3>
 
-<p>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methods used by the <a class='info' href='#RFC3711'>Secure Real-time Transport Protocol(SRTP)<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1]. It can be used as an encrypted alternative to <a class='info' href='#RFC2003'>IP Encapsulation within IP<span> (</span><span class='info'>Perkins, C., &ldquo;IP Encapsulation within IP,&rdquo; October&nbsp;1996.</span><span>)</span></a> [3] and <a class='info' href='#RFC2784'>Generic Routing Encapsulation (GRE)<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, &ldquo;Generic Routing Encapsulation (GRE),&rdquo; March&nbsp;2000.</span><span>)</span></a> [4]. Both anycast receivers and senders are supported.
+<p>The secure anycast tunneling protocol (SATP) defines a protocol used for communication between any combination of unicast and anycast tunnel endpoints. It allows tunneling of every ETHER TYPE protocol (ethernet, ip ...). SATP directly includes cryptography and message authentication based on the methods used by the <a class='info' href='#RFC3711'>Secure Real-time Transport Protocol(SRTP)<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711]. It can be used as an encrypted alternative to <a class='info' href='#RFC2003'>IP Encapsulation within IP<span> (</span><span class='info'>Perkins, C., &ldquo;IP Encapsulation within IP,&rdquo; October&nbsp;1996.</span><span>)</span></a> [RFC2003] and <a class='info' href='#RFC2784'>Generic Routing Encapsulation (GRE)<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, &ldquo;Generic Routing Encapsulation (GRE),&rdquo; March&nbsp;2000.</span><span>)</span></a> [RFC2784]. Both anycast receivers and senders are supported.
             
 </p><a name="toc"></a><br /><hr />
 <h3>Table of Contents</h3>
@@ -255,8 +251,8 @@ Intellectual Property and Copyright Statements<br />
 <a name="rfc.section.1"></a><h3>1.&nbsp;
 Introduction</h3>
 
-<p>SATP is a mixture of a generic encapsulation protocol like <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, &ldquo;Generic Routing Encapsulation (GRE),&rdquo; March&nbsp;2000.</span><span>)</span></a> [4] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, &ldquo;Security Architecture for the Internet Protocol,&rdquo; November&nbsp;1998.</span><span>)</span></a> [5] in tunnel mode.  It can be used to build redundant virtual private network (VPN) connections.  It supports peer-to-peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <a class='info' href='#RFC1546'>Host Anycast Service<span> (</span><span class='info'>Partridge, C., Mendez, T., and W. Milliken, &ldquo;Host Anycasting Service,&rdquo; November&nbsp;1993.</span><span>)</span></a> [6]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes.
-				To reduce header overhead ncryption techniques of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] are being used. 
+<p>SATP is a mixture of a generic encapsulation protocol like <a class='info' href='#RFC2784'>GRE<span> (</span><span class='info'>Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, &ldquo;Generic Routing Encapsulation (GRE),&rdquo; March&nbsp;2000.</span><span>)</span></a> [RFC2784] and a secure tunneling protocol as <a class='info' href='#RFC2401'>IPsec<span> (</span><span class='info'>Kent, S. and R. Atkinson, &ldquo;Security Architecture for the Internet Protocol,&rdquo; November&nbsp;1998.</span><span>)</span></a> [RFC2401] in tunnel mode.  It can be used to build redundant virtual private network (VPN) connections.  It supports peer-to-peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <a class='info' href='#RFC1546'>Host Anycast Service<span> (</span><span class='info'>Partridge, C., Mendez, T., and W. Milliken, &ldquo;Host Anycasting Service,&rdquo; November&nbsp;1993.</span><span>)</span></a> [RFC1546]. Encryption is done per packet, so the protocol is robust against packet loss and routing changes.
+				To reduce header overhead, encryption techniques of <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711] are being used. 
 				
 </p>
 <a name="anchor2"></a><br /><hr />
@@ -264,7 +260,7 @@ Introduction</h3>
 <a name="rfc.section.1.1"></a><h3>1.1.&nbsp;
 Notational Conventions</h3>
 
-<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in  <a class='info' href='#RFC2119'>RFC2119<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a> [2].
+<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in  <a class='info' href='#RFC2119'>RFC2119<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a> [RFC2119].
 </p>
 <a name="anchor3"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -419,7 +415,7 @@ Fragmentation</h3>
 <a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
 ICMP messages</h3>
 
-<p>ICMP messages MUST be relayed according to <a class='info' href='#RFC2003'>rfc2003 section 4<span> (</span><span class='info'>Perkins, C., &ldquo;IP Encapsulation within IP,&rdquo; October&nbsp;1996.</span><span>)</span></a> [3]. This is needed for path MTU detection.
+<p>ICMP messages MUST be relayed according to <a class='info' href='#RFC2003'>rfc2003 section 4<span> (</span><span class='info'>Perkins, C., &ldquo;IP Encapsulation within IP,&rdquo; October&nbsp;1996.</span><span>)</span></a> [RFC2003]. This is needed for path MTU detection.
 </p>
 <a name="anchor12"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -529,7 +525,7 @@ padding count (OPTIONAL)</h3>
 <a name="rfc.section.4.9"></a><h3>4.9.&nbsp;
 MKI (OPTIONAL)</h3>
 
-<p>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <a class='info' href='#RFC3711'>SRTP Section 3.1<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details.
+<p>The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See <a class='info' href='#RFC3711'>SRTP Section 3.1<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711] for details.
 </p>
 <a name="anchor22"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -543,7 +539,7 @@ authentication tag (RECOMMENDED)</h3>
 <a name="rfc.section.4.11"></a><h3>4.11.&nbsp;
 Encryption</h3>
 
-<p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1]. This section will only discuss some small changes that HAVE TO be made. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details. 
+<p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711]. This section will only discuss some small changes that HAVE TO be made. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711] for details. 
 </p>
 <p>The least significant bits of SSRC are replaced by the sender ID and the most significant bits are replaced by the MUX. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.
 </p><br /><hr class="insert" />
@@ -578,7 +574,7 @@ Encryption</h3>
 <a name="rfc.section.5"></a><h3>5.&nbsp;
 Security Considerations</h3>
 
-<p>As SATP uses the same encryption techniques as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details.
+<p>As SATP uses the same encryption techniques as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711], it shares the same security issues. This section will only discuss some small changes. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [RFC3711] for details.
 </p>
 <a name="anchor25"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -603,24 +599,24 @@ References</h3>
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
 <h3>7.1.&nbsp;Normative References</h3>
 <table width="99%" border="0">
-<tr><td class="author-text" valign="top"><a name="RFC3711">[1]</a></td>
-<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">The Secure Real-time Transport Protocol (SRTP)</a>,&rdquo; RFC&nbsp;3711, March&nbsp;2004.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2119">[2]</a></td>
-<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2003">[3]</a></td>
-<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">IP Encapsulation within IP</a>,&rdquo; RFC&nbsp;2003, October&nbsp;1996 (<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2003.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2003.xml">XML</a>).</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC3711">[RFC3711]</a></td>
+<td class="author-text">Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;<a href="http://tools.ietf.org/html/rfc3711">The Secure Real-time Transport Protocol (SRTP)</a>,&rdquo; RFC&nbsp;3711, March&nbsp;2004 (<a href="ftp://ftp.isi.edu/in-notes/rfc3711.txt">TXT</a>).</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
+<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC2003">[RFC2003]</a></td>
+<td class="author-text"><a href="mailto:perk@watson.ibm.com">Perkins, C.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2003">IP Encapsulation within IP</a>,&rdquo; RFC&nbsp;2003, October&nbsp;1996 (<a href="ftp://ftp.isi.edu/in-notes/rfc2003.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2003.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2003.xml">XML</a>).</td></tr>
 </table>
 
 <a name="rfc.references2"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
 <h3>7.2.&nbsp;Informational References</h3>
 <table width="99%" border="0">
-<tr><td class="author-text" valign="top"><a name="RFC2784">[4]</a></td>
-<td class="author-text"><a href="mailto:dino@procket.com">Farinacci, D.</a>, <a href="mailto:tony1@home.net">Li, T.</a>, <a href="mailto:stan_hanks@enron.net">Hanks, S.</a>, <a href="mailto:dmm@cisco.com">Meyer, D.</a>, and <a href="mailto:pst@juniper.net">P. Traina</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">Generic Routing Encapsulation (GRE)</a>,&rdquo; RFC&nbsp;2784, March&nbsp;2000.</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC2401">[5]</a></td>
-<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>,&rdquo; RFC&nbsp;2401, November&nbsp;1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2401.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr>
-<tr><td class="author-text" valign="top"><a name="RFC1546">[6]</a></td>
-<td class="author-text"><a href="mailto:craig@bbn.com">Partridge, C.</a>, <a href="mailto:tmendez@bbn.com">Mendez, T.</a>, and <a href="mailto:milliken@bbn.com">W. Milliken</a>, &ldquo;<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">Host Anycasting Service</a>,&rdquo; RFC&nbsp;1546, November&nbsp;1993.</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC2784">[RFC2784]</a></td>
+<td class="author-text"><a href="mailto:dino@procket.com">Farinacci, D.</a>, <a href="mailto:tony1@home.net">Li, T.</a>, <a href="mailto:stan_hanks@enron.net">Hanks, S.</a>, <a href="mailto:dmm@cisco.com">Meyer, D.</a>, and <a href="mailto:pst@juniper.net">P. Traina</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2784">Generic Routing Encapsulation (GRE)</a>,&rdquo; RFC&nbsp;2784, March&nbsp;2000 (<a href="ftp://ftp.isi.edu/in-notes/rfc2784.txt">TXT</a>).</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC2401">[RFC2401]</a></td>
+<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2401">Security Architecture for the Internet Protocol</a>,&rdquo; RFC&nbsp;2401, November&nbsp;1998 (<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2401.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2401.xml">XML</a>).</td></tr>
+<tr><td class="author-text" valign="top"><a name="RFC1546">[RFC1546]</a></td>
+<td class="author-text"><a href="mailto:craig@bbn.com">Partridge, C.</a>, <a href="mailto:tmendez@bbn.com">Mendez, T.</a>, and <a href="mailto:milliken@bbn.com">W. Milliken</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc1546">Host Anycasting Service</a>,&rdquo; RFC&nbsp;1546, November&nbsp;1993 (<a href="ftp://ftp.isi.edu/in-notes/rfc1546.txt">TXT</a>).</td></tr>
 </table>
 
 <a name="rfc.authors"></a><br /><hr />
@@ -688,8 +684,4 @@ or other
 proprietary rights that may cover technology that may be required
 to implement this standard.
 Please address the information to the IETF at <a href='mailto:ietf-ipr@ietf.org'>ietf-ipr@ietf.org</a>.</p>
-<h3>Acknowledgment</h3>
-<p class='copyright'>
-Funding for the RFC Editor function is provided by
-the IETF Administrative Support Activity (IASA).</p>
 </body></html>
diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
index e0169de..b0fb6bf 100644
--- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
+++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
@@ -2,8 +2,8 @@
 
 
 Network Working Group                                         O. Gsenger
-Internet-Draft                                               May 6, 2008
-Expires: November 7, 2008
+Internet-Draft                                                  May 2008
+Expires: November 2, 2008
 
 
                 secure anycast tunneling protocol (SATP)
@@ -32,11 +32,10 @@ Status of this Memo
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on November 7, 2008.
+   This Internet-Draft will expire on November 2, 2008.
+
 
-Copyright Notice
 
-   Copyright (C) The IETF Trust (2008).
 
 
 
@@ -52,7 +51,8 @@ Copyright Notice
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 1]
+
+Gsenger                 Expires November 2, 2008                [Page 1]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -64,10 +64,10 @@ Abstract
    tunnel endpoints.  It allows tunneling of every ETHER TYPE protocol
    (ethernet, ip ...).  SATP directly includes cryptography and message
    authentication based on the methods used by the Secure Real-time
-   Transport Protocol(SRTP) [1].  It can be used as an encrypted
-   alternative to IP Encapsulation within IP [3] and Generic Routing
-   Encapsulation (GRE) [4].  Both anycast receivers and senders are
-   supported.
+   Transport Protocol(SRTP) [RFC3711].  It can be used as an encrypted
+   alternative to IP Encapsulation within IP [RFC2003] and Generic
+   Routing Encapsulation (GRE) [RFC2784].  Both anycast receivers and
+   senders are supported.
 
 
 Table of Contents
@@ -108,28 +108,28 @@ Table of Contents
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 2]
+Gsenger                 Expires November 2, 2008                [Page 2]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 1.  Introduction
 
-   SATP is a mixture of a generic encapsulation protocol like GRE [4]
-   and a secure tunneling protocol as IPsec [5] in tunnel mode.  It can
-   be used to build redundant virtual private network (VPN) connections.
-   It supports peer-to-peer tunnels, where tunnel endpoints can be any
-   combination of unicast, multicast or anycast hosts, so it defines a
-   Host Anycast Service [6].  Encryption is done per packet, so the
-   protocol is robust against packet loss and routing changes.  To
-   reduce header overhead ncryption techniques of SRTP [1] are being
-   used.
+   SATP is a mixture of a generic encapsulation protocol like GRE
+   [RFC2784] and a secure tunneling protocol as IPsec [RFC2401] in
+   tunnel mode.  It can be used to build redundant virtual private
+   network (VPN) connections.  It supports peer-to-peer tunnels, where
+   tunnel endpoints can be any combination of unicast, multicast or
+   anycast hosts, so it defines a Host Anycast Service [RFC1546].
+   Encryption is done per packet, so the protocol is robust against
+   packet loss and routing changes.  To reduce header overhead,
+   encryption techniques of SRTP [RFC3711] are being used.
 
 1.1.  Notational Conventions
 
    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 [2].
+   document are to be interpreted as described in RFC2119 [RFC2119].
 
 
 
@@ -164,7 +164,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 3]
+Gsenger                 Expires November 2, 2008                [Page 3]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -220,7 +220,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 4]
+Gsenger                 Expires November 2, 2008                [Page 4]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -276,7 +276,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 5]
+Gsenger                 Expires November 2, 2008                [Page 5]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -332,7 +332,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 6]
+Gsenger                 Expires November 2, 2008                [Page 6]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -388,7 +388,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 7]
+Gsenger                 Expires November 2, 2008                [Page 7]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -411,8 +411,8 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 3.2.  ICMP messages
 
-   ICMP messages MUST be relayed according to rfc2003 section 4 [3].
-   This is needed for path MTU detection.
+   ICMP messages MUST be relayed according to rfc2003 section 4
+   [RFC2003].  This is needed for path MTU detection.
 
 
 
@@ -444,7 +444,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 8]
+Gsenger                 Expires November 2, 2008                [Page 8]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -500,7 +500,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008                [Page 9]
+Gsenger                 Expires November 2, 2008                [Page 9]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -508,7 +508,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 4.5.  payload type
 
    The payload type field defines the payload protocol.  ETHER TYPE
-   protocol numbers are used.  See IANA assigned ethernet numbers [7] .
+   protocol numbers are used.  See IANA assigned ethernet numbers [1] .
    The values 0000-05DC are reserverd and MUST NOT be used.
 
    Some examples for protocol numbers
@@ -546,7 +546,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 4.9.  MKI (OPTIONAL)
 
    The MKI (Master Key Identifier) is OPTIONAL and of configurable
-   length.  See SRTP Section 3.1 [1] for details.
+   length.  See SRTP Section 3.1 [RFC3711] for details.
 
 4.10.  authentication tag (RECOMMENDED)
 
@@ -556,7 +556,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 10]
+Gsenger                 Expires November 2, 2008               [Page 10]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -567,9 +567,9 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 4.11.  Encryption
 
-   Encryption is done in the same way as for SRTP [1].  This section
-   will only discuss some small changes that HAVE TO be made.  Please
-   read SRTP RFC3711 section 3-9 [1] for details.
+   Encryption is done in the same way as for SRTP [RFC3711].  This
+   section will only discuss some small changes that HAVE TO be made.
+   Please read SRTP RFC3711 section 3-9 [RFC3711] for details.
 
    The least significant bits of SSRC are replaced by the sender ID and
    the most significant bits are replaced by the MUX.  For the SRTP SEQ
@@ -612,16 +612,17 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 11]
+Gsenger                 Expires November 2, 2008               [Page 11]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 5.  Security Considerations
 
-   As SATP uses the same encryption techniques as SRTP [1], it shares
-   the same security issues.  This section will only discuss some small
-   changes.  Please read SRTP RFC3711 section 9 [1] for details.
+   As SATP uses the same encryption techniques as SRTP [RFC3711], it
+   shares the same security issues.  This section will only discuss some
+   small changes.  Please read SRTP RFC3711 section 9 [RFC3711] for
+   details.
 
 5.1.  Replay protection
 
@@ -667,8 +668,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-
-Gsenger                 Expires November 7, 2008               [Page 12]
+Gsenger                 Expires November 2, 2008               [Page 12]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -724,7 +724,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 13]
+Gsenger                 Expires November 2, 2008               [Page 13]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -733,26 +733,27 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 7.1.  Normative References
 
-   [1]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
-        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
-        RFC 3711, March 2004.
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
 
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
-   [3]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
-        October 1996.
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              October 1996.
 
 7.2.  Informational References
 
-   [4]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
-        "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
+   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+              March 2000.
 
-   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
-        Internet Protocol", RFC 2401, November 1998.
+   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
 
-   [6]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-        Service", RFC 1546, November 1993.
+   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
+              Anycasting Service", RFC 1546, November 1993.
 
 
 
@@ -779,15 +780,14 @@ Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 
-
-Gsenger                 Expires November 7, 2008               [Page 14]
+Gsenger                 Expires November 2, 2008               [Page 14]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
 
 URIs
 
-   [7]  <http://www.iana.org/assignments/ethernet-numbers>
+   [1]  <http://www.iana.org/assignments/ethernet-numbers>
 
 
 
@@ -836,7 +836,7 @@ URIs
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 15]
+Gsenger                 Expires November 2, 2008               [Page 15]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -892,7 +892,7 @@ Author's Address
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 16]
+Gsenger                 Expires November 2, 2008               [Page 16]
 
 Internet-Draft  secure anycast tunneling protocol (SATP)        May 2008
 
@@ -939,14 +939,14 @@ Intellectual Property
    ietf-ipr@ietf.org.
 
 
-Acknowledgment
 
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
 
 
 
 
 
-Gsenger                 Expires November 7, 2008               [Page 17]
+
+
+
+Gsenger                 Expires November 2, 2008               [Page 17]
 
diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
index b34df1e..f74eea1 100644
--- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
+++ b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
@@ -51,7 +51,7 @@
     <middle>
     <section title='Introduction'>
         <t>SATP is a mixture of a generic encapsulation protocol like <xref target="RFC2784">GRE</xref> and a secure tunneling protocol as <xref target="RFC2401">IPsec</xref> in tunnel mode.  It can be used to build redundant virtual private network (VPN) connections.  It supports peer-to-peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines a <xref target="RFC1546">Host Anycast Service</xref>. Encryption is done per packet, so the protocol is robust against packet loss and routing changes.
-				To reduce header overhead ncryption techniques of <xref target="RFC3711">SRTP</xref> are being used. 
+				To reduce header overhead, encryption techniques of <xref target="RFC3711">SRTP</xref> are being used. 
 				</t>
       <section title='Notational Conventions'>
         <t>The keywords "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">RFC2119</xref>.</t>
-- 
cgit v1.2.3