Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 21 Apr 2000 00:27:35 -0700 (PDT)

--- Vernon Schryver <[email-masked]> wrote:
> > From: Matt Holdrege <[email-masked]>
> 
> > ...
> > Just so there is no more confusion, in no way is the IETF endorsing the use
> 
> > or development of NAT. You've completely missed the point of the draft. 
> > It's purpose is to clearly point out the problems that NAT causes to a 
> > given set of protocols.
> >
> > Also please do not steer this thread towards a NAT bashing-fest. We need to
> 
> > complete this document and we need constructive input to this draft. Thanks
> 
> > again for your original input.
> 
> 
> If the document is not intended to be read as advocating NAT, it also
> needs substantial non-technical changes.  It currently comes across as
> a list of fairly minor, generally easily fixed problems or problems that
> don't matter.  I don't mean to say that is the intended point of the
> document, but is how I read it.  Since I'm among those who feel that the
> situation with NAT is not quite as bad things would have been if we had
> waited for IPv6, you might expect my prejudices to make me read it the
> other way.
> 

If you an issue with specific portions of the draft, please let us know.
Minor edits could be sent to the authors privately. Thanks.

> Instead of appearing to be a complete list of problem and their complete
> and easy solutions, the document needs to have more words in each section
> saying that the sublist of problems is probably incomplete.  The
> shortcomings of solutions to the problems should be belabored instead of
> glossed over.  Seeing that the problems are significant must not require
> any technical sophistication in the reader.

Agreed. The document was not intended to be an exhaustive list of
protocols/applications that fail with NAT. The abstract actually
captures that sentiment. Anyways, if you have specific input on things
being glossed over without sufficient coverage, do let us know, with 
any proposed textual editions. We will certainly follow through on that.

>                                             For example, most people who
> should read this document will see nothing but some opaque acronyms
> whose problems surely don't matter in Section 5.  Why should anyone care
> that IPCEC doesn't work with NAT?
> 

Well, readers should know that IPsec that protects the addresses in IP 
header cannot work with NAT enroute. Dont you think?

> 
> Vernon Schryver    [email-masked]
> 

cheers,
suresh 

=====

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com