Mercurial > hg > ietf

changeset 38:45f0d51961cf

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Cleanup text when comments are not rendered.
author Sebastien Decugis <sdecugis@nict.go.jp>
date Fri, 28 Aug 2009 18:00:57 +0900
parents a22fb485486b
children 0d94368e563c
files draft-ietf-dime-erp-01.xml
diffstat 1 files changed, 30 insertions(+), 28 deletions(-) [+]
line wrap: on
line diff
--- a/draft-ietf-dime-erp-01.xml	Fri Aug 28 17:53:44 2009 +0900
+++ b/draft-ietf-dime-erp-01.xml	Fri Aug 28 18:00:57 2009 +0900
@@ -243,7 +243,7 @@
 
       <t>We consider at most one logical ER server entity in a domain. If
       several physical servers are deployed for robustness, a replication
-      mechanism must be deployed to synchronize the ERP states (root keys,
+      mechanism must be deployed to synchronize the ERP states (root keys
       <cref>FFS: authorization attributes</cref> ) between these servers. This
       replication mechanism is out of the scope of this document. If several
       ER servers are deployed in the domain, we assume that they can be used
@@ -273,7 +273,7 @@
       <t>When the peer initiates an ERP exchange, the authenticator creates a
       Diameter-EAP-Request message, as described in Diameter EAP application
       <xref target="RFC4072"></xref>. The Application Id of the message is set
-      to Diameter ERP application (code: <cref>TBD IANA</cref>) in the
+      to Diameter ERP application (code: TBD <cref>TBD IANA</cref>) in the
       message. The exact processing to generate the ERP/DER message is
       detailed in section <xref target="Re-authentication"></xref>.</t>
 
@@ -446,8 +446,10 @@
         message, and do the following processing in addition to standard proxy
         operations:<list>
             <t>Change the Application Id in the header of the message to
-            Diameter EAP Application (code 5). <cref>What about the
-            Application-Auth-Id AVP?</cref></t>
+            Diameter EAP Application (code 5).</t>
+
+            <t>Change the content of Application-Auth-Id accordingly. <cref>Is
+            it better to leave it unmodified?</cref></t>
 
             <t>Add the ERP-RK-Request AVP, which contains the name of the
             domain where the ER server is located.</t>
@@ -470,7 +472,7 @@
 
         <t>The ER server receives this EAP/DEA and proxies it as follow, in
         addition to standard proxy operations:<list>
-            <t>Set the Application Id back to Diameter ERP (code <cref>TBD
+            <t>Set the Application Id back to Diameter ERP (code TBD<cref>TBD
             IANA</cref>)</t>
 
             <t>Extract and cache the content of the ERP-RK-Answer. <cref>And
@@ -552,7 +554,7 @@
       regards to the EAP state machine. It creates a Diameter EAP Request
       message following the general process of <xref target="RFC4072">Diameter
       EAP</xref>, with the following differences:<list>
-          <t>The Application Id in the header is set to Diameter ERP (code
+          <t>The Application Id in the header is set to Diameter ERP (code TBD
           <cref>TBD IANA</cref>).</t>
 
           <t>The value in Auth-Application-Id AVP is also set to Diameter ERP
@@ -564,10 +566,10 @@
           <t><cref>FFS: What about Session-ID AVP -- in case of re-auth at the
           same place, and in case of handover?</cref></t>
 
-          <t>The Auth-Request-Type AVP content is set to <cref>FFS -- Do we
-          really do authorization with Diameter ERP ? -- need to pass the
-          authorization attrs to the ER server in that case. Idea FFS: we do
-          authorization only for explicit bootstrapping
+          <t>The Auth-Request-Type AVP content is set to [Editor's note:
+          FFS]<cref>Do we really do authorization with Diameter ERP ? -- need
+          to pass the authorization attrs to the ER server in that case. Idea
+          FFS: we do authorization only for explicit bootstrapping
           exchanges...</cref>.</t>
 
           <t>The EAP-Payload AVP contains the ERP message,
@@ -580,7 +582,7 @@
       ERP/DEA, following the general processing described in <xref
       target="RFC4072"></xref>, with the following differences:<list>
           <t>The Application Id in the header is set to Diameter ERP (code
-          <cref>TBD IANA</cref>).</t>
+          TBD<cref>TBD IANA</cref>).</t>
 
           <t>The value in Auth-Application-Id AVP is also set to Diameter ERP
           Application.</t>
@@ -610,7 +612,7 @@
 
     <section anchor="ApplicationId" title="Application Id">
       <t>We define a new Diameter application in this document, Diameter ERP
-      Application, with an Application Id value of <cref>TBD IANA</cref>.
+      Application, with an Application Id value of TBD<cref>TBD IANA</cref>.
       Diameter nodes conforming to this specification in the role of ER server
       MUST advertise support by including an Auth-Application-Id AVP with a
       value of Diameter ERP Application in the of the
@@ -630,8 +632,8 @@
       item</cref></t>
 
       <section title="ERP-RK-Request AVP">
-        <t>The ERP-RK-Request AVP (AVP Code <cref>TBD IANA</cref>) is of type
-        grouped AVP. This AVP is used by the ER server to indicate its
+        <t>The ERP-RK-Request AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
+        type grouped AVP. This AVP is used by the ER server to indicate its
         willingness to act as ER server for a particular session.</t>
 
         <t>This AVP has the M and V bits cleared.</t>
@@ -646,7 +648,7 @@
       </section>
 
       <section title="ERP-Realm AVP">
-        <t>The ERP-Realm AVP (AVP Code <cref>TBD IANA</cref>) is of type
+        <t>The ERP-Realm AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
         DiameterIdentity. It contains the name of the realm in which the ER
         server is located.</t>
 
@@ -658,9 +660,9 @@
       </section>
 
       <section title="ERP-RK-Answer AVP">
-        <t>The ERP-RK-Answer AVP (AVP Code <cref>TBD IANA</cref>) is of type
-        grouped AVP. It is used by the home EAP server to provide ERP root key
-        material to the ER server.</t>
+        <t>The ERP-RK-Answer AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
+        type grouped AVP. It is used by the home EAP server to provide ERP
+        root key material to the ER server.</t>
 
         <t>This AVP has the M and V bits cleared.</t>
 
@@ -676,7 +678,7 @@
       </section>
 
       <section title="ERP-RK AVP">
-        <t>The ERP-RK AVP (AVP Code <cref>TBD IANA</cref>) is of type
+        <t>The ERP-RK AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
         OctetString. It contains the root key (either rRK or rDSRK) sent by
         the home EAP server to the ER server, in answer to request containing
         an ERP-RK-Request AVP. How this material is derived and used is
@@ -689,7 +691,7 @@
       </section>
 
       <section title="ERP-RK-Name AVP">
-        <t>The ERP-RK-Name AVP (AVP Code <cref>TBD IANA</cref>) is of type
+        <t>The ERP-RK-Name AVP (AVP Code TBD<cref>TBD IANA</cref>) is of type
         OctetString. This AVP contains the EMSKname which identifies the
         keying material. How this name is derived is beyond the scope of this
         document and defined in <xref target="RFC5296"></xref>.</t>
@@ -700,14 +702,14 @@
       </section>
 
       <section title="ERP-RK-Lifetime AVP">
-        <t>The ERP-RK-Lifetime AVP (AVP Code <cref>TBD IANA</cref>) is of type
-        Unsigned32 <cref>do we really need 64 as in -00 ? 2^32 secs is already
-        more than 100 years, which is too long for a key lifetime !</cref> and
-        contains the root key material remaining lifetime in seconds. It MUST
-        not be greater than the remaining lifetime of the EMSK it is derived
-        from. <cref>FFS: is it better to pass an absolute value here, for
-        example expiration date? How to express it then (TZ, ...)?
-        Synchronization problems?</cref></t>
+        <t>The ERP-RK-Lifetime AVP (AVP Code TBD<cref>TBD IANA</cref>) is of
+        type Unsigned32 <cref>do we really need 64 as in -00 ? 2^32 secs is
+        already more than 100 years, which is too long for a key lifetime
+        !</cref> and contains the root key material remaining lifetime in
+        seconds. It MUST not be greater than the remaining lifetime of the
+        EMSK it is derived from. <cref>FFS: is it better to pass an absolute
+        value here, for example expiration date? How to express it then (TZ,
+        ...)? Synchronization problems?</cref></t>
 
         <t>This AVP has the M and V bits cleared.</t>
       </section>
"Welcome to our mercurial repository"