Subject: [Dime] Review Reminder: draft-ietf-dime-nat-control-01.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 15 Dec 2009 22:47:56 +0200

Hi all, 

At the last IETF meeting I have asked the DIME WG participants for
reviews of the Diameter NAT Control document. The following persons
promised to review the document:  Jouni, Tom, Glen and myself

So far, I have only seen a review by Jouni:
http://www.ietf.org/mail-archive/web/dime/current/msg03950.html

It would be great if we could see review comments from the other
volunteers before Xmas as well. Every review is obviously highly
appreciated so that we can finish the document as soon as possible. 
 
Ciao
Hannes

---

From: Qin Wu <[email-masked]>
Date: Tue, 29 Dec 2009 17:09:46 +0800

Hi,:
I am volunteering to review this document.
please see my minimal comments inline.

-----
Abstract

   This document describes the framework, messages, and procedures for
   the Diameter NAT Control Application (DNCA), allowing for per-
   endpoint control of large scale NAT devices, which are put in place
   to cope with IPv4-address space completion.  The Diameter NAT Control

[Qin]:  completion or depletion?

In section 1:
   LSNs will be inserted into the existing subscriber access and
   aggregation networks which typically provide for per-endpoint service
   management and control as well as per-endpoint accounting.  Per-
   endpoint rules include those which relate to service offerings of the
   SP (e.g. access bandwidth, time or volume based access restrictions)

   [Qin]: There is no abbrevation for "SP" in this document. Is it service provider?

   The per-endpoint management capabilities of a LSN comprise, for
   example the control of the number of NAT-address-port pairs (often
   called "NAT-bindings" or simply "bindings") allocated to a single
   endpoint.  Given that global IPv4 address-port pairs are becoming a
   scarce resource, several service providers intend to restrict the
   number of NAT-bindings on a per endpoint basis and thus increase
   address utilization efficiency.  The number of bindings an endpoint
   can consume becomes another parameter within a tiered-service
   offering.  In addition, the service provider might offer static

   [Qin]: What is the tiered-service offering? Would you like to clarify this?

In Section 3.2.1:
   Figure 1 shows a typical network deployment for internet access.  A
   user's IPv4-host gains access to the internet though a Network Access
   
   [Qin]: s/though/through
   [Qin]: It seems figure 1 and related description of figure 1 in section 3.2.1 are redundant.
   I am wondering whether they are relevant to NAT control, if not,  suggest to remove it.

   Figure 2 depicts the deployment scenario when a service provider
   introduces a LSN to increase the efficiency of the global IPv4
   address pool utilization.  The objective is to provide the customer
   with connectivity to the public IPv4 Internet.  The LSN performs
   network address translation between private IPv4 addresses and public
   IPv4 addresses.  If the LSN would be put in place without any
   endpoint awareness, the service offerings of the service provider
   would be hampered.  Provisioning static NAT-bindings for particular
   endpoints, using different public IP-address pools for different set
   of endpoints (e.g. residential or business customers), as well as
   reporting on the allocated bindings on a per-endpoint basis would be
   burdensome for a service provider if the LSN would not be aware of
   endpoints and allow for per-endpoint control and management which
   easily integrates with the already existing per-endpoint management
   infrastructure of the service provider.
   
  [Qin]: So what's your point for this paragraph ? Suggest to add one conclusion at the end of this paragraph like:
   "
   Provisioning static NAT-bindings is bad choice in the deployment scenario mentioned above
   "
   right? 

In section 4.2:
   The DNCA manager initiates the Diameter NAT Control session to the
   DNCA agent.  The DNCA manager generates a NAT-Control Request (NCR)

   [Qin]: suggest to use "issues" instead of "generates"
  
 o  A reference to a predefined binding rule on DNCA agent that will
      be applied to the session.  Such a predefined binding rule on DNCA
      agent may contain, for example, the name of the IP-address pool
      that the external IP-addresses should be allocated from, the
      maximum number of bindings permitted for the endpoint etc.
      
      [Qin]: It seems the maximum number of bindings is not reasonable 
      to be taken as a reference,right?

In section 4.3:
   Session re-authorization is performed if the DNCA manager desires to
   change the behavior of the LSN for an existing session.  Re-
   authorization could be used, for example, to change the number of
   allowed bindings for a particular session, or establish or remove a
   pre-defined binding.

   [Qin]: It seems to me this section is not talking about Re-authorization but
   session modification or session update. What am I missing?

In section 4.4:

   [Qin]:Binding is part of Session, maybe it is better to change the title as session Query.

In section 5.3:
   
   Each DNCA session MUST have a globally unique Session-Id as defined
   in [RFC3588], which MUST NOT be changed during the lifetime of a DNCA
   session.  The Diameter Session-Id serves as the global endpoint
   identifier (see also capabilities Section 3.1).  The DNCA agent and
   DNCA manager maintain state associated with the Session-Id.  This
   globally unique Session-Id is used for updating, accounting for and

   [Qin]:s/accounting for/accounting

Regards!
-Qin

----- Original Message ----- 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 16, 2009 4:47 AM
Subject: [Dime] Review Reminder: draft-ietf-dime-nat-control-01.txt

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime