[NAT] Re: IESG review of draft-ietf-nat-interface-framework-03.txt

Scott,

Thank you for the comments. I will respond to the broad themes you raised. 
As for specific comments, I will respond to you in a separate e-mail.

History:

   09/98 - The NAT interface Framework draft had been around since 
           09/98. It had since evolved based on comments received 
           from several people (including Kjeld, Yakov for example)
           mostly through private e-mails and corridor conversations. 
   02/01 - Had several e-mail exchanges with the NAT-MIB draft authors
           who were using NAT interface framework draft as the basis for 
           their draft. The NAt draft was presented at MIDCOM BOF. 
           Several people suggested that I mention MIDCOM in the draft -
           so it is not a conflicting with MIDCOM, but rather complementary.
   04/01 - A new rev of the draft released including reference for MIDCOM.
   05/02/01 - The NAT draft completed WG last call and submitted to IESG. 
   06/02 - IESG sent me a note saying that MIDCOM WG should look at the
           draft for consistency with MIDCOM. 
   07/30 - No comments from MIDCOM list. Melinda sent you her referal.
   09/20 - IESG comments on the draft.

Editorial/Wording issues: 
   I apologize for having to put you through the ordeal. That was not 
   intentional. Hope you understand. I appreciate your feedback. I will
   fold in your comments and comb through the material meticulously one 
   more time as best as I can to fix these issues.

Relevance to the WG and interest from WG:

   Matt and I can certainly poll the WG to see if they believe the draft
   content is relevant to the WG and if there is any interest pursuing 
   the draft in the WG. If not this WG, I dont know what other WG would 
   be a more appropriate forum to review NAT interface stuff. When someone
   raised this issue, I recall polling the folks for interest level in 
   one of the IETF meetings. There were some nods that it is useful and 
   should be continued. There was no dissent that I can recall. Lastly, 
   the fact that the MIB draft was able to use this draft as the basis 
   for MIB definition, in my mind, is a direct proof of its relevance and
   usefulness.

Reference to MIDCOM, basis for MIDCOM:

   The NAT interface draft, along with Kuthan-firewall-traversal draft
   was indeed used as the basis for the MIDCOM Architecture and framework
   draft. The fact that the core architecture diagram (figure 1) in the
   MIDCOM framework draft is derived directly from the NAT interface
   draft figure-1 just goes to show how relevant the draft is. Several of
   the cocepts discussed (ALG interface, Callback notifications, API for
   BIND and session query, set and free) were borrowed into the MIDCOM
   draft discussion.

I hope to work with you in resolving the issues. Thank you.

Regards,
Suresh

--- Scott Bradner <sob@harvard.edu> wrote:
> 
> The IESG has discussed draft-ietf-nat-interface-framework-03.txt and
> has the following comments
> 
> Scott & Allison
> 
> ------
> The IESG has some concerns with the document
> draft-ietf-nat-interface-framework-03.txt.
> 
> 1) The document has numerous editorial and wording issues that make it
>    difficult to give the document a proper technical review. Moreover,
>    it is believed that many of these issues should be apparent to
>    others who attempt to give the document a serious technical
>    review. As the document is currently written, it is not believed to
>    be ready for publication as an RFC. Consequently:
> 
> 2) It is not job of the IESG to provide detailed technical and
>    editorial corrections on documents to the degree needed on this
>    document. A sample of such commentary on the first few pages of the
>    ID is appended. The remainder of the document has similar issues,
>    but the details are not provided.
> 
> 3) A brief perusal of the mailing list archives suggests that WG
>    support for this document is limited; i.e., the document appears to
>    have no opposition, rather than significant support. If the WG
>    believes that this document is important, it should take steps to 
>    demonstrate that support more explicitely.
> 
> 4) If the WG believes that work on this document should continue, it
>    should take steps to cleanup the document. Suggested steps in this
>    direction would be to have WG members perform detailed reviews,
>    feed comments back to the author, and then indicate satisfaction
>    with the resultant revised document. It may also be useful to find
>    an additional document editor willing to do some technical editing.
> 
> 5) The document makes a lot of references to MIDCOM, implying that the
>    document is of relevance to MIDCOM and will serve as a starting
>    point for additional MIDCOM work (i.e., an API for accessing MIDCOM
>    resources). If this document really is of use/interest to MIDCOM,
>    that WG should perhaps pick up the work. If the MIDCOM WG does not
>    agree, then much of the text implying this is of use to MIDCOM
>    would seem to be inappropriate, and the scope of the document
>    should be appropriately narrowed.
> 
> 
> Specific document comments (not complete - intended as examples): 
> 
>    flavors of NAT that abound. Many internet applications use IP
> s/use IP/use an IP/
>    address as host identifier rather than just as a way to locate a
> s/as host/as a host/
>    host.  For this reason, routing transparency by NAT alone is not
> 
> It is not just applications, it is also transport protocols like UDP
> and TCP.
> 
> Thus, saying "for this reason, ..." is misleading. One would not get
> end-to-end transparancey just by fixing applications.
> 
> >    operating across realms.  Application specific ALGs are required
> >    in conjunction with NAT to provide end-to-end transparency for
> >    some applications.
> 
> ALGs do NOT provide end-to-end transparency. Perhaps I'm having
> trouble with some of this text because the authors may have a
> different idea of what end-to-end transparency means (e.g., does IPsec
> work through an ALG)? Perhaps the document should define the term.
> 
>    specific. The API illustration assumes a trusted environment and
>    does not address authentication, authorization or discovery of
>    middlebox location. It is also important to note that the
> 
> Ommitting security issues seems a significant ommision in practice.
> 
> > 2.1. MiddleBox and Middlebox services
> >
> >    Middlebox is a network intermediate device implementing a
> s/Middlebox/A middlebox/
> >    middlebox service. Middlebox service is characterized as a
> s/Middlebox/A middlebox/
>    networking function requiring application intelligence for
>    its operation. A middlebox service is also referred as
> s/referred/referred to/
>    Middlebox function throughout this document. Examples of
>    middlebox functions include NAT, firewall, intrusion
>    detection, load balancing, policy based tunneling and
>    IPsec security Gateway enforcement. A middlebox may
>    implement one or more of these functions. 
> 
> NAT is not a middlebox per the document's own definition. NAT does not
> require "application intelligence". NAT does require ALGs when NAT
> doesn't work, but an ALG is not a NAT.
> 
> I also wonder whether  folks would agree that firewalls need
> "application intelligence".
> 
>    Clearly, NAT is a specific middlebox function and NAT device
>    is a specific Middlebox device.
> 
> Not by the current definition, IMO.
> 
>    MIDCOM agents are entities performing ALG function, logically
>    external to a middlebox. MIDCOM agents possess a combination of
> 
> Is the defn of a midcom agent consistent with the terminology the
> midcom WG uses?
> 
>    The protocol used by MIDCOM agents to interface with the middlebox
>    and its resources to influence its operation. This is a protocol
> 
> sentence doesn't parse.
> 
>    through 3.1.2 are independent of the service the devise supports.
> 
> s/devise/device/
> 
> >    agent may influence NAT operation. This section describes objects
> >    within NAT, that could be externalized via Management Information
> >    Base (MIB).
> 
> Is this intended to mean MIB in the standard IETF sense? If so, how
> does this relate to the NAT-MIB document? Indeed, why isn't this
> document just an API to get at the same objects as defined in the MIB?
> 
> >    Of the fields listed below to describe the service, items 3.1.1
> >    through 3.1.2 are independent of the service the devise supports.
> 
> s/devise/device/
> 
> >   instances or there may be multiple NAT middleboxs associated
> s/middleboxs/middelboxes/
> 
> 3.1.1. Service IDentifier
> 
>    A service identifier uniquely identifies service instantiation
>    within a middlebox. The external interface address may be
>    one way to uniquely describe this Identifier.
> 
> Circular definition? (at least, I don't understand what this means).
> 
> >    Every NAT device will have a minimum of two routing
> >    interfaces, one connecting to a private realm and one
> >    connecting to external realm. An IPv4 NAT device will
> >    have both its realm types set to IPv4.
> 
> What is a "realm type"? Document doesn't seem to say.
> 
>    Address map on a NAT device is constituted of one or more of
>    static/ dynamic Address maps. Transport-ID mapping, on
> 
> s/Address/An address/? 
> 
> > 3.2. Address (and Transport-ID) BIND Descriptor
> >
> >    Hereafter, the term BIND will be used in place of BINDing, for ease
> >    of use. BIND descriptor is specific to NAT service. These BINDs
> >    can be static or dynamic. When external agents do not intervene,
> 
> This above is really unclear. What is a "BINDing" Why use the
> terminology "BIND"?
> 
> > 3.2.1. Bind ID
> >
> >    A number (say, in the range of 1 through 0xFFFFFFFF) assigned
> >    to BIND to uniquely identify the BIND on a NAT middlebox.
> 
> "the BIND". Is there one BIND on a NAT box? Or many? you never define
> just what a BIND is.
> 
> 
> > 3.2.2. Direction of Bind
> >
> >    A bind can be uni-directional or bi-directional, same as the 
> >    orientation of address map based on which this BIND is formed.
> >    As before, the direction is with reference to private realm.
> 
> This is confusing. When NAT is in place, it seems like there would be
> one binding that shows the translations going in both directions (for
> a particular connection/flow). Why would one have separate binding to
> show what is going on in only one direction? And there is
> unidirectional NAT?  What is that?
> 
>    the same concept to the tuple of Address and transport ID (such as
> 
> Why is Address capitalized?
> 
> > 3.2.4. Private and External addresses (and Transport-IDs)
> >
> >    These parameters specify the BINDing items in private and
> >    external realms.
> 
> The use of terminology is really hard to follow. I'm having a hard
> time understanding what is meant by "specify the BINDing items".
> Do you really mean to say something like "... specify the items that
> define a binding ..." Or something else? And why "parameters"? Are
> these inputs from somewhere? 

=====

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com

_______________________________________________
nat mailing list
nat@ietf.org
http://www1.ietf.org/mailman/listinfo/nat