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

["Shwetha Bhandari (shwethab)" <[e-mail]>]

Hi Jouni,

Thank you for the review! We will take care of your comments in the next
version of the draft.
Some responses inline @shwetha

-----Original Message-----
From: jouni korhonen [mailto:[e-mail]] 
Sent: Wednesday, December 09, 2009 4:01 AM
To: [e-mail]
Cc: Frank Brockners (fbrockne); Shwetha Bhandari (shwethab);
[e-mail]; [e-mail]
Subject: Review of draft-ietf-dime-nat-control-01

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?

[shwetha] When the AAA server authenticates/authorizes or receives an
accounting record for the subscriber session it would trigger a DNCA
session with DNCA Agent. We will add this detail. We are considering
dropping of pull mode as it would keep the application simple. 

      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..
[shwetha] We are considering deleting any reference to Pull mode for
session recovery. Will reword the details accordingly.


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?
[shwetha] Yes, we will add the Proxyable flag.

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.
[shwethab] We will modify NCR to carry Calling-Station-Id, which will be
the layer 2 address of the subscriber. This will be encoded as specified
in RFC 4005. We will remove reference to Called-Station-Id as we are not
using it. Calling-Station-Id will serve as another identifier for the
subscriber and can be repeated by DNCA-agent in the accounting requests
for that subscriber. Will clarify it in the draft.

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?

[shwetha]We have reused Port AVP, Protocol AVP and Direction AVP from
draft-ietf-dime-qos-attributes. We found Classifier-AVP to be too
generic to be reused as is in NAT-Control-Definition, as bindings are
address per IP/port combinition only, hence the NAT-Internal-Address is
Framed-IP-Address and port.

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?
[shwetha] We will update the draft with this detail. We are thinking of
using Diameter NAT Control Application ID with ACR/ACA. Thoughts?

Thanks,
Shwetha

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