I think it's important to publish this document, to make it
clear why NAT-PT is a solution of very dubious value.
Brian
On 2007-02-27 20:14, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Reasons to Move NAT-PT
Just to clarify the current situation...
The statement below says that the recommendation is for RFC 2766 to be
reclassified to experimental.. As is implied by the title of the draft,
it actually recommends reclassification to Historic.
This error results form a piece of history ;-) - The
Hi Vidya,
On Sat, February 17, 2007 11:43 pm, Narayanan, Vidya wrote:
Yes, the problem of an authenticator providing different identities to
the peer and the server is the typical channel binding problem and can
be detected by simply doing a protected exchange of the identity between
the
Hi,
I understand this draft is in IESG evaluation and would like to register
some comments. I apologize for the tardiness of this email.
This draft is well-written and much needed but I feel it does not
completely address the issue of using AAA for key distribution. Let me
summarize the
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On page 22, the second bullet point has a type, roaming is spell
roamig, without the 'n'.
Alan DeKok.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Hi Pekka
Regarding your following remark:
However, to be clear, I have no objection to using the ECN field(s) if
that does not hinder the current use (or lack thereof) of ECN. What I
specifically don't want is to define new fields for PCN, especially
extension headers or IP options. I should
For remote participants and local monitoring, the broadcast schedule for
the audio streaming is being put up on the IETF 68 streaming webpage:
http://videolab.uoregon.edu/events/ietf/
Streaming begins Monday March 18, at 0900 CET.
I would like to thank the Network Startup Resource Center at the
Pekka Savola wrote:
On Sun, 18 Feb 2007, Michael StJohns wrote:
At 06:29 PM 2/18/2007, Janet P Gunn wrote:
My guidebook says 6 months.
Feel free to argue with the US State Dept.. :-)
I don't think it's the US State Dept you will need to argue with but
rather the officials in Prague
Pekka,
[logical components being:] encoding and transport along forward
path from marker to egress, metering of congestion information at
the egress, and transport of congestion information back to the
controlling ingress.
I'd like to see it explicitly stated that transporting
Harald Tveit Alvestrand wrote:
And think of the Security Considerations section. (And do we need IANA
considerations, too?)
For this subject, there is absolutely no way to avoid an
internationalization considerations section - and of course the
scalability considerations section needs to be
Hi Bill,
Yes - from the IEEE/ISTO Printer Working Group, see the
Job Monitoring MIB (RFC 2707) which defined the textual
convention 'JmNaturalLanguageTagTC' on page 69. It uses
max length 63 octets to be consistent with the earlier
Internet Printing Protocol/1.0 (RFC 2566, now RFC 2911)
that
On Tuesday 27 February 2007 08:53, IESG Secretary wrote:
The IESG is considering re-approving this draft with knowledge of the
IPR disclosure from Redphone Security. The IESG solicits final
comments on whether the IETF community has consensus to publish
draft-housley-tls-authz-extns as a
Review of draft-ietf-geopriv-radius-lo-10.txt
Overview comments:
Overall, this document includes many normative statements relating
to privacy in a number of sections. As it stands, this makes it very
difficult to understand exactly what privacy support will be provided
in various scenarios.
I support making this a Proposed Standard. It fills in a very usable
way a long-standing gap in the semantics of fragment identifiers,
and makes it possible to refer to frozen text/plain documents
and makes it possible to refer to portions of frozen text/plain
documents (for example, sections of
Hi Fred
I think that one of the goals of the PCN WG will be to investigate
the implications of using ECN and/or DSCP for PCN encoding purposes.
Best Regards,
Georgios
-Original Message-
From: Fred Baker [mailto:[EMAIL PROTECTED]
Sent: dinsdag 20 februari 2007 15:31
To: Georgios
Michael,
One just can tell one's 9 year-old to change the diapers
of the 2 year old.
Sure you can.
Now, getting the desired response may be harder.
Adrian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
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.
The last time I heard that it was in IPSEC One objection is that IPSEC is not
NAT-friendly, some of us consider that a feature not a bug. The result was an
IPSEC
Dear Joel;
Thank you for all of your efforts here over the years.
On Feb 28, 2007, at 1:43 AM, Joel Jaeggli wrote:
For remote participants and local monitoring, the broadcast
schedule for
the audio streaming is being put up on the IETF 68 streaming webpage:
Good catch - that seems to be a little obsolete text that's
sitting around in the I-D tracker. The draft itself is
clear that Historic is the intention.
Brian
On 2007-02-28 15:07, Elwyn Davies wrote:
Just to clarify the current situation...
The statement below says that the recommendation
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, The core assumption here seems to be that NAT is a
Hallam-Baker, bad thing so lets get rid of NAT rather than trying
Hallam-Baker, to make NAT work.
I disagree with this characterization of the
For your interest:
The document below has a date of 13 july 2005, it was a result of a
reviews of several months by
various people in various areas of the French adminstration and other
public services.
The text essentially does:
- establish a secure communication among two organisations
On Wed, Feb 28, 2007 at 05:12:45PM +0100, Brian E Carpenter wrote:
Good catch - that seems to be a little obsolete text that's
sitting around in the I-D tracker. The draft itself is
clear that Historic is the intention.
For your information:
I have asked the secretariat to reissue the Last
Sam,
On Feb 28, 2007, at 8:37 AM, Sam Hartman wrote:
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 different
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.
NAT-PT is not NAT. It does a whole lot more, but it *cannot* do what it
claims to do completely, because the semantics on the two sides
- Original Message -
From: Sam Hartman [EMAIL PROTECTED]
To: Tom.Petch [EMAIL PROTECTED]
Cc: ietf ietf@ietf.org
Sent: Saturday, February 24, 2007 10:09 PM
Subject: Re: Last Call: draft-klensin-norm-ref (Handling Normative References
for Standards Track Documents) to BCP
My strong
Is there a document that describes a deployment plan under a two stack
transition?
I am somewhat uncomfortable moving documents to historic just because they
contain ideas we find unpleasant. And in particular I would rather see
documents that say 'this is how to solve a problem' rather than
This document has a reasonable goal, but the implementation is objectionable.
The reasonable goal (from the introduction):
This document replaces the hold on normative reference rule with a
note downward normative reference and move on approach for
normative references to
On Wednesday, February 28, 2007 03:56:44 PM -0500 Eric Rosen
[EMAIL PROTECTED] wrote:
In many cases (probably the vast majority) where a document is
advancing despite a downward normative reference, the referenced
document (and the technology described therein) is no less stable
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.
...
The only protocol which really cares about the source and
destination IP addresses is IPSEC and we have
On Feb 28, 2007, at 12:40 PM, Hallam-Baker, Phillip wrote:
Is there a document that describes a deployment plan under a two
stack transition?
Well, I can't say they are exacty what you're looking for, but you
might glance at:
http://www.ietf.org/rfc/rfc2767.txt
2767 Dual Stack Hosts
From: Fred Baker [mailto:[EMAIL PROTECTED]
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.
...
The only protocol which really cares about the source
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
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
On Fri, 16 Feb 2007 12:06:51 -0500
Michael Richardson [EMAIL PROTECTED] wrote:
Further, as the technology matures, one can't tell a 14-year old
anything. (I've noticed the latter only second hand.
Okay, I saw it on TV.)
That gets worse, too, as the teenager progresses. I'm speaking from
On Wed, 28 Feb 2007 20:42:04 -0500
Sam Hartman [EMAIL PROTECTED] wrote:
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED]
writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption
From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]
More precisely, any protocol that uses secondary connections,
the parameters of which are carried in-band in a secured
connection, can't easily be NATted. The most obvious example
is FTP. 4217 notes that it only works through NAT if
Steven == Steven M Bellovin [EMAIL PROTECTED] writes:
Steven On Wed, 28 Feb 2007 20:42:04 -0500
Steven Sam Hartman [EMAIL PROTECTED] wrote:
Hallam-Baker, == Hallam-Baker, Phillip
[EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On
At 6:31 PM -0800 2/28/07, Hallam-Baker, Phillip wrote:
This is a design choice in the protocol, one that I would see as a layering
violation. Application layer protocols should not be talking about IP
addresses.
Network management protocols are arguably at the application layer (and
they
The IESG has approved the following document:
- 'Benchmarking Terminology for Resource Reservation Capable Routers '
draft-ietf-bmwg-benchres-term-08.txt as an Informational RFC
This document is the product of the Benchmarking Methodology Working
Group.
The IESG contact persons are David
The IESG has approved the following document:
- 'Using IPsec to Secure IPv6-in-IPv4 Tunnels '
draft-ietf-v6ops-ipsec-tunnels-05.txt as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are David Kessens and Dan Romascanu.
A URL
The IESG has approved the following document:
- 'Recommendations for Filtering ICMPv6 Messages in Firewalls '
draft-ietf-v6ops-icmpv6-filtering-recs-03.txt as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are David Kessens
The IESG has received a request from the Multiprotocol Label Switching
WG (mpls) to consider the following document:
- 'ICMP Extensions for MultiProtocol Label Switching '
draft-ietf-mpls-icmp-08.txt as a Proposed Standard
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:
- 'Support for Multiple Hash Algorithms in Cryptographically Generated
Addresses (CGAs) '
draft-bagnulo-multiple-hash-cga-02.txt as a Proposed Standard
The IESG plans to make a decision in the
A new Request for Comments is now available in online RFC libraries.
RFC 4809
Title: Requirements for an IPsec Certificate
Management Profile
Author: C. Bonatti, Ed.,
S. Turner, Ed.,
G.
A new Request for Comments is now available in online RFC libraries.
RFC 4855
Title: Media Type Registration of RTP
Payload Formats
Author: S. Casner
Status: Standards Track
Date: February 2007
A new Request for Comments is now available in online RFC libraries.
RFC 4801
Title: Definitions of Textual Conventions for
Generalized Multiprotocol Label Switching (GMPLS)
Management
Author: T. Nadeau, Ed.,
46 matches
Mail list logo
