updated new draft

1 files changed, 3 insertions, 3 deletions

diff --git a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
index cb5ebde..6021696 100644
--- a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
+++ b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
@@ -288,11 +288,11 @@ HEX
 
     <section title="Cryptography">
       <t>
-        As mentioned earlier the cryptography of SATP is based on <xref target="RFC3711">SRTP</xref>. For that reason we recommend to read this document as well. However some modifications were made in order to fit the changed conditions of SATP. The following section describes the whole cryptography of SATP.
+        As mentioned earlier the cryptography of SATP is based on <xref target="RFC3711">SRTP</xref>. For that reason we recommend to read this document as well (especially chapter 7 Rationale). However some modifications were made in order to fit the changed conditions of SATP. The following section describes the whole cryptography of SATP.
       </t>
       <section title="Basic Concepts">
         <t>
-          In order to cope with anycast and packet loss it is important to beeing able to process one packet on its own without the need for packets from the past as an additional information source. Therefore SATP as well as <xref target="RFC3711">SRTP</xref> defines a so called cryptographic context. This context consits of all information which is needed to process a single SATP packet and is divided into packet specific parameters and global parameters. The packet specific parameters can be found in the protocol header and global parameters have to be generated by the key exchange mechanism external to SATP (see <xref target="sec_key_mgmt" />). For anycast sender the global parameters have to be synchronized between all hosts which share the same anycast address. The packet specific parameters MUST NOT be synchronized.<vspace blankLines="0" />
+          In order to cope with anycast and packet loss it is important to be able to process one packet on its own without the need for packets from the past as an additional information source. Therefore SATP as well as <xref target="RFC3711">SRTP</xref> defines a so called cryptographic context. This context consits of all information which is needed to process a single SATP packet and is divided into packet specific parameters and global parameters. The packet specific parameters can be found in the protocol header and global parameters have to be generated by the key exchange mechanism external to SATP (see <xref target="sec_key_mgmt" />). For anycast sender the global parameters have to be synchronized between all hosts which share the same anycast address. The packet specific parameters MUST NOT be synchronized.<vspace blankLines="0" />
 SATP uses two types of keys: master keys and session keys. A session key is meant to be used for a cryptographic transform (encrytion or message authentication) for one packet. The master keys are used to derive packet-specific session keys in a cryptographical secure way.
         </t>
         <section title="Cryptographic Contexts">
@@ -497,7 +497,7 @@ SATP uses two types of keys: master keys and session keys. A session key is mean
 
     <section title="Security Considerations">
       <t>
-        As SATP uses the same encryption techniques as <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.
+        As the cryptography of SATP is based on <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.
       </t>
       <section title="Replay protection">
         <t>