I do not support forwarding the draft (In fact, i oppose it
strongly.). Chopping away bits of the usable v4 space to create more
unusable space does not in any way help.
I can but hope to emulate Randys terse and on-the-spot argumentation,
so I'll have to make do with concurring.
--
Måns
Fixed.
(This was an issue lingering after a disk-crash on one of the machines much
earlier this year, exposed by a major rev Python upgrade (2.6 -- 2.7)
which didn't pull in all the needed packages because they weren't registered
as installed, although present on disk for 2.6)
Best regards,
Date:Tue, 29 Nov 2011 21:09:22 -0700
From:Sumanth Channabasappa suma...@cablelabs.com
Message-ID: 76AC5FEF83F1E64491446437EA81A61F81D7CBBA11@srvxchg
This whole question is weird, when someone needs an address to use,
and given that the pool of free (or close to it),
Thanks Henrik!
Back to the eye gouging fun ;)
Cheers,
Terry
On 30/11/2011, at 6:42 PM, Henrik Levkowetz hen...@levkowetz.com wrote:
Fixed.
(This was an issue lingering after a disk-crash on one of the machines much
earlier this year, exposed by a major rev Python upgrade (2.6 --
On 30/11/2011 05:46, Mark Andrews wrote:
In messagem2r50q42nn.wl%ra...@psg.com, Randy Bush writes:
skype etc. will learn. This does prevent the breakage it just makes
it more controlled. What's the bet Skype has a patched released
within a week of this being made available?
Aren't there a
On Wed, Nov 30, 2011 at 5:27 AM, Stewart Bryant stbry...@cisco.com wrote:
On 30/11/2011 05:46, Mark Andrews wrote:
In messagem2r50q42nn.wl%randy@**psg.com m2r50q42nn.wl%25ra...@psg.com,
Randy Bush writes:
skype etc. will learn. This does prevent the breakage it just makes
it more
Folks,
Can anyone present empirical evidence that skype will break? I have heard
claims in both directions.
Ron
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Mark Andrews
Sent:
My review of draft-ietf-mpls-tp-mib-management-overview-05.txt
It was a quick review, so that you have some idea of what I looked at.
For a real review, I think it would take a lot of time.
But feel free to use my comments as you see fit.
As long as people realize that it was a quick skim and
Randy == Randy Bush ra...@psg.com writes:
skype etc. will learn. This does prevent the breakage it just
makes it more controlled. What's the bet Skype has a patched
released within a week of this being made available?
Randy cool. then, by that logic, let's use 240/4. the
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Randy Bush
talk to free.fr, camron byrne, ... there are roadmaps.
but this proposal is not about migrating to ipv6. it is about ipv4
life extension and nat444 4ever. to hell with that.
[WEG] let's see... free.fr
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Doug Barton
Sent: Tuesday, November 29, 2011 7:00 PM
To: Chris Grundemann
Cc: IESG IESG; IETF Discussion
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request
On
On Nov 28, 2011, at 4:25 PM, Ronald Bonica wrote:
...
Because the October 10 last call elicited so little response, and because
many community members have privately expressed strong opinions regarding
this draft, I will summarize outstanding issues below. The following are
arguments
On Nov 30, 2011, at 1:40 AM, Bob Hinden wrote:
On Nov 29, 2011, at 10:16 PM, Christian Huitema huit...@microsoft.com wrote:
I did share what I was smoking - it's called 'reality' :).
Which reality? I think Randy is much more realistic!
+1
+lots.
You are telling us that you
I support and encourage the immediate adoption of a /10 shared IPv4 transition
space for service providers. I strongly believe that this will dramatically
reduce the impact that service providers will already be burdened with when
moving to CGN solutions in these last days of IPv4.In
I strongly support both of these drafts.
Allocation of the /10 will have only minimal negative impacts on the community,
if any.
Almost all of the impacts raised in the objections to draft weil will occur
whether or not
draft weil is moved to BCP status. The difference is that with draft weil
Two comments, admittedly from someone who's been well out of ISP
sysadmin for some years now:
1) The proposal in draft-weil sucks. It fills me with abject horror
that some ISPs - and I hope not all - are going to deploy CGN and
other, similar, half-arsed connectivity tricks to pretend to
From: Ronald Bonica rbon...@juniper.net
Allocation of a special-use /10 does not hasten the deployment of IPv6.
Snark=0 - or as close to it as I can humanly manage.
So, after reading the back-and-forth in the thread, I'm moved to come back to
this. Just what measures, within the I*'s
I'd like to thank Owen for explaning his point of view with such clarity
and I'd like to concur with him by rephrasing in my own words (most of
this has already been said by others thought).
Taking the objections in order, again:
1. Allocation of a special-use /10 does not hasten the
Draft-donley-nat444-impacts-03:
+--++++--+--+
| Skype video | Pass | Pass | Pass | Pass | |
| chat
+--++++--+--+
We tested it. Skype worked in our lab
On Wed, Nov 30, 2011 at 12:18 PM, Chris Donley c.don...@cablelabs.comwrote:
Draft-donley-nat444-impacts-03:
+--++++--+--+
| Skype video | Pass | Pass | Pass | Pass | |
| chat
On Nov 30, 2011, at 6:27 AM, Michael Richardson wrote:
Randy == Randy Bush ra...@psg.com writes:
skype etc. will learn. This does prevent the breakage it just
makes it more controlled. What's the bet Skype has a patched
released within a week of this being made available?
Randy
Bob Hinden wrote:
Michael Richardson wrote:
Randy Bush ra...@psg.com writes:
cool. then, by that logic, let's use 240/4. the apps will
patch within a week. ok, maybe two.
Seriously, I think we *SHOULD* use 240/10.
(let's keep some for the next horrible hack)
I agree, this is a
Bob Hinden bob.hin...@gmail.com wrote:
On Nov 30, 2011, at 6:27 AM, Michael Richardson wrote:
Seriously, I think we *SHOULD* use 240/10.
(let's keep some for the next horrible hack)
I agree, this is a good use of the Experimental Class E IPv4 addresses.
It seems to me that this is for new
but this proposal is not about migrating to ipv6. it is about ipv4 life
extension and nat444 4ever. to hell with that.
ipv6 deployment enthusiast
If NAT444 gets deployed, then IPv4 will become progressively less
reliable over time. As more people work on IPv6, IPv6 will become more
On Tue, Nov 29, 2011 at 17:00, Doug Barton do...@dougbarton.us wrote:
On 11/29/2011 15:37, Chris Grundemann wrote:
I support draft-weil-shared-transition-space-request and the
allocation of a /10 as Shared CGN Space because we are approaching
complete global exhaustion of unallocated IPv4
At 11:38 30-11-2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DKIM Authorized Third-Party Signers'
draft-kucherawy-dkim-atps-11.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and
Chris,
On Nov 30, 2011, at 12:28 PM, Chris Grundemann wrote:
They will deploy CGN with or without us.
True.
We are giving them a way to do it in the least disruptive way.
Could you expand on the disruption you believe would be minimized by
implementation of this draft?
That is, what do you
On 2011-12-01 09:28, Chris Grundemann wrote:
...
It is more conservative to share a common pool.
It suddenly occurs to me that I don't recall any serious analysis
of using 172.16.0.0/12 for this. It is a large chunk of space
(a million addresses) and as far as I know it is not used by default
in
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Wed, Nov 30, 2011 at 03:18:24PM -0500 Quoting Wes Beebee (wbee...@cisco.com):
Eventually, IPv6 will become more reliable than IPv4.
for me, v6 is more reliable at my two most frequented tethering points
for the
I echo Owen and JF's comments
Given the available options, the dedicated /10 provides the least
problematic solution.
If the address space used by CGN is standardised, and identifiable then it
can be managed appropriately by everyone in a consistent way.
The sooner this is adopted, the easier
Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH].
The references to RFC 5598 and RFC 5322 should be normative.
I agree; I missed that in my shepherd review. So sorry.
A Verifier implementing both ADSP and ATPS SHOULD treat a message for
It's not just about the CPE devices and customer LANs.
Address conflicts are also going to happen within the ISP network /
back-office etc. 172.16.0.0/12 is used there.
Daryl
On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.comwrote:
On 2011-12-01 09:28, Chris Grundemann
Hi Barry,
At 13:03 30-11-2011, Barry Leiba wrote:
It does not. There's no reason that anyone implementing ADSP need pay
attention to this. *IF* you implement this, it might change your
behaviour with respect to ADSP, but information about that is
contained here. There's no reason for this to
Hi, SM. Thanks for your comments.
In reply to the stuff Barry hasn't already covered:
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
Sent: Wednesday, November 30, 2011 12:35 PM
To: ietf@ietf.org
Subject: Re: Last Call:
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Murray S. Kucherawy
Sent: Wednesday, November 30, 2011 2:21 PM
To: ietf@ietf.org
Subject: RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to
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
In case you didn't see this:
http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html
It's a complete IPv6 NAT implementation with the functionality of the IPv4 one
in the same stack. ALGs. Port translation. Connection tracking. You don't
need me
Does it support RFC 6296?
Regards
Brian Carpenter
On 2011-12-01 13:07, Sabahattin Gucukoglu wrote:
In case you didn't see this:
http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html
It's a complete IPv6 NAT implementation with the
I'm one of the authors of RFC 5617, which this document would update
if it moved into the standards track. It doesn't seem very useful to
me, but it also seems mostly harmless so there's no reason not to
publish it as experimental.
This strikes me a hack that appeals primarily to bulk mail
On 1 Dec 2011, at 01:20, Brian E Carpenter wrote:
Does it support RFC 6296?
That was done in a separate, non-official implementation here:
http://lwn.net/Articles/451914/
With this one, you can NAT between ranges, and that's it, if I've got this
right. Fragmentation is also an issue. I'm not
Daryl,
The problem described in the draft is that CPEs use 1918 space *and that
many of them can't deal with the fact that there might be addresses on
the outside interface that are the same as on the inside interface*. The
claim was made by Randy, among others, that only 192.168/16 space was
On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote:
Daryl,
The problem described in the draft is that CPEs use 1918 space *and that many
of them can't deal with the fact that there might be addresses on the outside
interface that are the same as on the inside interface*. The claim
Ralph,
Please note the following report:
WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)
Report suggested that all three RFC1918 blocks are well utilized.
Regards,
Victor K
On 11-11-30 9:19 PM, Ralph Droms rdroms.i...@gmail.com wrote:
On Nov 30, 2011, at 9:14 PM
On 11/30/11 8:41 PM, Victor Kuarsingh wrote:
Ralph,
Please note the following report:
WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)
Report suggested that all three RFC1918 blocks are well utilized.
Well utilized in devices that can't deal with identical addresses on
On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote:
Ralph,
Please note the following report:
WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)
Thanks for the reference. Do you have an easy pointer to retrieve the doc? I'm
curious about how the data was
On Wed, Nov 30, 2011 at 6:57 PM, Ralph Droms rdroms.i...@gmail.com wrote:
On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote:
Ralph,
Please note the following report:
WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)
Thanks for the reference. Do you have an easy
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John
Levine
Sent: Wednesday, November 30, 2011 6:04 PM
To: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
The problem described in the draft is that CPEs use 1918 space *and that
many of them can't deal with the fact that there might be addresses on
the outside interface that are the same as on the inside interface*. The
claim was made by Randy, among others, that only 192.168/16 space was
On 12/1/11 12:48 AM, Randy Bush wrote:
The problem described in the draft is that CPEs use 1918 space *and that
many of them can't deal with the fact that there might be addresses on
the outside interface that are the same as on the inside interface*. The
claim was made by Randy, among others,
On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote:
As the draft says, the point is to make the idea available and see if it sticks
to anyone or anything. If the bulk senders (or receivers) do decide they
collectively want this, there's something for them to try and report back.
if one
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Wednesday, November 30, 2011 11:16 PM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
I'd be fine
The IESG has approved the following document:
- 'Using MAC-authenticated Encryption in the Cryptographic Message Syntax
(CMS)'
(draft-gutmann-cms-hmac-enc-06.txt) as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG
52 matches
Mail list logo
