[Dime] Review of draft-ietf-dime-nat-control-01

[jouni korhonen <[e-mail]>]

Hi,

In Hiroshima I volunteered to review this I-D. I would say the I-D is in rather good shape and my comments are not too technical. See my initial comments inline (after the first read of this draft). Comments are prefixed with [JiK].

-----


In Section 4.1.

   The current version of the draft assumes that the NAT control
   requesting entity is always the DNCA manager.  Sessions will always
   be initiated, updated, or terminated by the DNCA manager.  This mode
   of operation is sometimes also referred to as "push mode".  Session
   initiation by the DNCA agent (sometimes referred to as "pull mode")
   will be covered in a future version of this draft.

[JiK] How is the push mode supposed to work when the manager is located in the AAA server? What trigger the AAA to send a NCR request to a LSN?

      return a NCA with Result-Code set to Insufficient- Classifiers.

[JiK] extra space above.. and probably the Insufficient-Classifiers should be in uppercase like the other result codes in this draft are.

In Section 4.3 (and through out the draft):


[JiK] In general, when discussing of AVPs in the text, for example:

   o  In case Max-NAT-Binding and Nat-Control-Definition are included in
      the NCR along with a reference to a binding rule (i.e. a ...

  I would actually add the "AVP" acronym after the appropriate AVP has been mentioned:

   o  In case Max-NAT-Binding and Nat-Control-Definition AVPs are included in
      the NCR along with a reference to a binding rule (i.e. a ...

In Section 4.5. and onwards

[JiK] .,$s/TERMINATE REQUEST/TERMINATE_REQUEST/g
[JiK] s/Terminate REQUEST/TERMINATE_REQUEST

In Section 4.6.

   Disclaimer: This version of the draft does not cover details in case
   DNCA manager and DNCA agent go out of sync, which could happen for
   example due to DNCA manager or DNCA agent restart, (temporary) loss
   of network connectivity etc.  Future versions of this draft will
   cover failure cases and corresponding behavior of DNCA manager and
   DNCA agent in detail.

[JiK] Will there be a future version of this draft that covers this case?

   o  The DNCA manager is unreachable (as e.g. detected by Diameter
      watchdog) or down and accounting requests from the DNCA agent fail
      to get a response.  The current version of the draft does not
      specify procedures for DNCA agent session state clean up or
      recovery.  The mechanism to ensure that a DNCA manager no longer
      has associated state for a session being cleared at the DNCA agent
      is beyond the scope of this document.

[JiK] Same comment as above..


In Section 5.1.

[JiK] s/IPSec may be used/IPSec MAY be used
[JiK] s/The DNCA agent may verify/The DNCA agent MAY verify

In Section 5.4.

   It is assumed that the DNCA manager knows the address/name of the
   DNCA agent for a given endpoint.  Both the Destination-Realm and
   ...

[JiK] I would rather say "knows the DiameterIdentity and the realm of the.."

In Section 6.2. (NCA)

[JiK] Is redirection supported?

In Section 7.3.

[JiK] How and what goes into Called/Calling-Station-Id ? I would not mind saying more specifically what identifier goes there and using what encoding.

In Section 7.7.*

[JiK] Have you thought of reusing the Classifier AVPs from draft-ietf-dime-qos-attributes e.g. within the NAT-Internal-Address and NAT-Control-Definition grouped AVPs? Or is the reference in Section 7.5 just wrong?

In Section 7.7.5.

     NAT-Internal-Address ::= < AVP Header: TBD >
                               [ Framed-IP-Address ]
                               [ Port]
                               [ AVP ]

[JiK] s/[ AVP ]/* [ AVP ]

In Section 7.7.6.

[JiK] Same as above.

In Section 8.

[JiK] Which application id is used for accounting?


Is Section 13.1.

[JiK] I-D.ietf-dime-qos-attributes is not referenced.
      I-D.ietf-dime-qos-parameters is not referenced.
      TS32299 is not referenced (and is rather old version as well, latest being 9.1.0 from Oct 2009)
 


Cheers,
	Jouni