Subject: [Dime] Quick look at draft-ietf-dime-nat-control-01.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Jan 2010 16:58:45 +0200

Hi Frank, et al., 

I had a brief look at your document and I noticed two things: 

A) The document is a bit long with a lot of duplication in there. I
suggest to shorten it to make it easier to read. I have a proposals for
the first few sections and you can find them below. 

B) Section 4.1 says that the "pull mode" will be provided in a future
version of the document. So, when are you going to add the description? 

Ciao
Hannes

-----------

-- Document heading: Diameter NAT Control Application

--> Expand the term "NAT" and call it Diameter Network Address and Port
Translation (NAPT) Application

You describe more than just a NAT control application but rather a the
NAPT functionality. Hence the change in title. Other suggestions are
welcome!

-- Change Victor's mail address to [email-masked] and ask him for
updated information about his affiliation. 

-- Abstract 

FROM:

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
   Application allows external devices to configure and manage a Large
   Scale NAT (LSN) device - expanding the existing Diameter-based AAA
   and policy control capabilities with a NAT control component.  These
   external devices can be network elements in the data plane such as a
   Network Access Server (NAS), or can be more centralized control plane
   devices such as AAA-servers.  DNCA establishes a context to commonly
   identify and manage endpoints on a gateway or server, and a large
   scale NAT device.  This includes, for example, the control of the
   total number of NAT-bindings allowed or the allocation of a specific
   NAT-binding for a particular endpoint.  In addition, it allows large
   scale NAT devices to provide information relevant to accounting
   purposes.

Do you think that the reference to "large scale NAT devices" is useful
given that these types of NATs have been deployed already before the
term was coined. Cannot we just call them NATs? Is the term Large Scale
NAT (LSN) the "official" term used in the BEHAVE working group? 

--- Introduction

Avoid mentioning the term "National Regulatory Authority (NRA)" anywhere
in draft. 

Terminology: Typically, we just call the two parties of a Diameter
application client and server. You use the term manager and agent. Any
reason for the terminology? 

I personally would combine parts of Section 1 with Section 3. Then,
Section 3.2 "LSN Control Deployment Framework" would become a separate
"Framework" section. 

Here is my text proposal:

--------

1.  Introduction

   Internet service providers have started to deploy Network Address
Translators (NATs) 
   and Network Address and Port Translators (NAPTs) at the edge of their
networks 
   (in addition to NAT boxes typically being deployed at customer
premises) to deal 
   with the foreseeable depletion of available IPv4 addresses. 

   This document defines a Diameter application for providers 
   deploying such NATs and NAPT devices. The use of a Diameter
application 
   allows for simple integration into the existing AAA environment of 
   a provider. The Diameter NAPT application offers the following
capabilities: 
   
   1.  Limit the number of NAT-bindings made available to an individual 
       subscriber or end point. 
	   
   2.  Support the allocation of specific NAT-bindings. This approach is

       useful for provider-controlled services. 
	   
   3.  Define the external address-pool(s) to be used for allocating an
       external IP-address.  External address-pools can either be pre-
       assigned at the NAT, or specified within a request.  If pre-
       assigned address-pools are used, a request needs to include a
       reference to identify the pool. Otherwise, the request will 
	   contain a description of the IP-
       address pool(s) to be used (e.g. list of IP-subnets).

   4.  Accounting/Reporting: Report established bindings for a
       particular user. The collected information is used by accounting 
	   systems and for statistical purposes. 

   5.  Query functionality to retrieve details about bindings on demand.

       This feature complements the previously mentioned
push-functionality
	   mentioned under item (4). 

This document is structured as follows: Section 2 lists terminology,
Section 
3 provides a description of deployment options as part of the overall
framework, 
.... 

2. Terminology

3. Framework

--------

A few editorial things: 

s/DIAMETER/Diameter 
All subject headings are written with capitals. Example: 
s/5.2.  Accounting functionality/5.2. Accounting Functionality