--- a/draft-ietf-dime-erp-05.xml	Fri Oct 22 15:46:32 2010 +0900
+++ b/draft-ietf-dime-erp-05.xml	Fri Oct 22 15:47:25 2010 +0900
@@ -24,7 +24,7 @@
 <?rfc rfcedstyle="yes"?>
 <?rfc rfcprocack="no"?>
 <?rfc tocindent="yes"?>
-<rfc category="std" docName="draft-ietf-dime-erp-04.txt" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-dime-erp-05.txt" ipr="trust200902">
   <front>
     <title abbrev="Diameter ERP Application">Diameter Support for the EAP
     Re-authentication Protocol (ERP)</title>
@@ -407,7 +407,7 @@
             (code TBD)</t>
 
             <t>Extract and cache the content of the Key AVP with Key-Type set
-            to rRK, as described in implicit scenario. </t>
+            to rRK, as described in implicit scenario.</t>
           </list> The ERP/DEA message is then forwarded to the authenticator,
         that can use the rMSK as described in <xref target="RFC5296">RFC
         5296</xref>. <vspace blankLines="1" /> The figure below captures this
@@ -494,7 +494,7 @@
             </list></t>
 
           <t>The Auth-Request-Type AVP content is set to [Editor's note: FFS
-          -- cf. open issues]. </t>
+          -- cf. open issues].</t>
 
           <t>The EAP-Payload AVP contains the EAP-Initiate/Re-Auth
           message.</t>
@@ -612,7 +612,7 @@
           authenticator learn what the home domain is?)</t>
 
           <t>how does the peer learn the ERP domain of the new authenticator
-          -- this is being addressed in HOKEY architecture draft; </t>
+          -- this is being addressed in HOKEY architecture draft;</t>
 
           <t>how does the home server reachs the peer to for example terminate
           the session if there is no notification sent to the home domain;</t>