Sam,
I disagree with this characterization of the document. I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work. Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a
On 2007-02-28 17:02, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get rid of
NAT rather than trying to make NAT work.
This is startlingly irrelevant to the present document. We have a large corpus
of documents about the issues caused by NAT
Fred Baker writes:
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing so lets get
rid of NAT rather than trying to make NAT work.
...
Actually this has already been done, please see draft-ietf-v6ops-nap-06.txt
which has
This is a repost of 2 messages previously sent to the ietf@ietf.org list
which did not make it to the list. They are being re-sent here at the
request of the RAI ADs.
To: ietf@ietf.org
Subject: Re: Last Call: draft-ietf-geopriv-radius-lo (Carrying
Hi Bernard,
I received your review. I need more time to process it given its length.
In fact the length of your review surprised me a bit given the long (16
months) discussion we already had about the document.
Ciao
Hannes
-Ursprüngliche Nachricht-
Von: Bernard Aboba
Hannes,
I haven't had time to go through these items either, much less time
to compare them against the wglc comments from both GEOPRIV and
RADEXT (https://ops.ietf.org/lists/radiusext/2006/msg00698.html). If
these are new issues, it is unsettling that they did not surface
during the
On a thread now unrelated to the topic of NATs,
At 9:42 AM +0100 3/1/07, Eliot Lear wrote:
With IPv4 the impetus for NAT was a combination of address
exhaustion concerns and routing issues.
It is far deeper than that for many IT departments and network users.
NATs are seen as an
Paul,
Without going down the NAThole my real intent here is simply to motivate
people who think they're bad to please look at the management
complexities of renumbering. I know I am looking.
Eliot
___
Ietf mailing list
Ietf@ietf.org
Jeffrey Hutzelman wrote:
while I don't think the document necessarily needs to be changed to
REQUIRE this, I think it would be good if last call announcements
continued to call out normative downrefs, for two reasons:
(1) To make it easier to catch potentially problematic downrefs
(2) To
--On Thursday, 01 March, 2007 08:07 -0800 Paul Hoffman
[EMAIL PROTECTED] wrote:
On a thread now unrelated to the topic of NATs,
At 9:42 AM +0100 3/1/07, Eliot Lear wrote:
With IPv4 the impetus for NAT was a combination of address
exhaustion concerns and routing issues.
It is far
Hi, all
I'm shepherding - I will talk through the issues with Bernard and Hannes -
did send mail about this, and I've been studying the mail from Bernard.
Hannes, I'm sorry I missed the phone date with you on Tuesday - day job
came up. We should re-group asap; if we could get a handle on where
On Mar 1, 2007, at 9:57 AM, John C Klensin wrote:
I continue to believe that, until and unless we come up with models
that can satisfy the underlying problems that NATs address in the
above two cases and implementations of those models in mass-market
hardware, NATs are here to stay, even
The IESG has approved the following document:
- 'Authenticated Chunks for Stream Control Transmission Protocol (SCTP) '
draft-ietf-tsvwg-sctp-auth-08.txt as a Proposed Standard
This document is the product of the Transport Area Working Group Working
Group.
The IESG contact persons are
The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'NAT Behavioral Requirements for TCP '
draft-ietf-behave-tcp-05.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from an individual submitter to consider
the following document:
- 'CableLabs - IETF Standardization Collaboration '
draft-mule-ietf-cablelabs-collaboration-03.txt as an Informational
RFC
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from an individual submitter to consider
the following document:
- 'Common Local Transmit and Receive Ports (Symmetric RTP) '
draft-wing-behave-symmetric-rtprtcp-02.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final
All revised Internet-Drafts (version -01 and higher) must be submitted
by Monday, March 5th at 9:00 AM ET.
Revised Internet-Drafts received after the cutoff date will not be made
available in the Internet-Drafts directory or announced until on or
after Monday, March 19th at 9:00 AM ET, when
17 matches
Mail list logo
