Subject: RE: (NAT) Revised NAT WG minutes - IETF 46

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 24 Nov 1999 07:23:17 -0800 (PST)

--- "SCHOEFER, WEBB (PB)" <[email-masked]> wrote:
> IETF Working Group,
> 
> I was just reading the minutes from the IETF NAT Working Group meeting 11/7.
> 
> I got the impression of a complete lack of urgency regarding NAT/IPSec
> resolution.
> 

I assume, you are refering to RSIP framework, protocol and Security documents
when you say NAT/IPsec. NAT/IPsec is independently covered in RFC 2709. 

I understand your concern for the drafts not moving forward fast enough.
Drafts are expedited principally by the interested parties who are willing
to contribute. Issues come to a close quickly when all stake holders 
contribute towards issue resolution rather than be on the side lines 
waiting for someone else to resolve. In other words, I encourage you to
contribute to the on-going discussion.

> I understand that the IETF is looking at the big picture. So big, I fear
> that a solution is still years away. I desire 1Q2000 solution.
> 

On the contrary, I believe, IETF Work Groups are really focussed on 
fairly well scoped problem sets. Please refer NAT WG charter for the 
problem scope we are addressing.

> An example of this is the talk of UDP .vs. IP.  Being a relative layman here
> - lets try to follow the 80% rule here.  IP is the big hitter here, focus is
> everything, UDP is not, to stop and consider it is a waste of time.
> 

I assume, you are refering to the transport layer usage (TCP vs. UDP) for
RSIP protocol. Are you saying that it is a waste of time to consider UDP,
because TCP is a big hitter? I dont see how this sets a criteria one way 
or another. Please explain.
 
> The IETF appears to "warm and comfortable" and plans to talk things to
> death.  In the meantime, people are "freezing to death".
>
Please see my comments earlier. Issues can come to quick resolution when
stake holders take part in discussions and agree to come to a resolution.
 
> I am looking for a client-side NAT/IPSec device for a home router solution.
> I believe that this will involve 1 router and 2 to 8 workstations.  I
> believe there will be tens of millions of these devices.  What I need now is
> a Volkswagen not a Learjet.  I fear that the IETF is overly focused on
> high-end complicated devices that will only be used in relatively few
> instances.
>

Fair enough. I understand and agree with the concern. It is certainly not
our intent to design a Learjet-like protocol. Small customer premises setup
like what you describe is certainly our principal goal (right, Mike et.al?).
But, the design should also be not so constrained as to not have any hope
of extensions or use outside the limited environment.
 
Having said that, I also encourage you to pitch in and express your concern
when a certain suggestion is too far out for the scope of the problem.
 
> I believe the IETF needs to focus on a timely deliverable.  This deliverable
> should be flexible enough to allow for future capabilities (e.g. SMNP).
> 

Agreed. See my comments earlier w.r.t. flexibility.

> I cannot stress enough that there is an urgency for a NAT/IPSec solution.  I
> fear that if the IETF takes much longer to come to some kind of solution,
> and non-directional standard may emerge.
> 
> That's the end of my tirade.  I know all of you are working hard to get the
> best possible solution, but some the NAT drafts are nearly a year old and I
> am unclear when one can be expected.
> 

You are right. Some of the drafts have been around for quite some time. 
It has been our objective to advance the base NAT drafts before pursuing
advancing others. Specifically, we are working to move forward the following
base drafts. To our credit, we do have RFCs for 3 of the base documents.
Note however, irrespective of the progresson order, all drafts are 
reviewed on the mailing list and when there is a rough consensus that a 
draft is close to being ready, a WG last call is issued.

   1. <draft-iab-nat-implications-04.txt>                              
      "Architectural Implications of NAT" 
   2. <draft-ietf-nat-traditional-03.txt>
      "Traditional IP Network Address Translator (Traditional NAT)"
   3. <draft-ietf-nat-protocol-complications-01.txt>
      "Protocol Complications with the IP Network Address Translator (NAT)"	
	   
> 
> Webb Schoefer
> Systems Manager
> SBC Network Products & Technology Planning
> 

cheers,
suresh
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.