From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
In Section 1:
more efficiently than waiting until someone sends an email to the
xxattend...@ietf.org list in the days leading up to the meeting.
The XX is ambiguous.
[WEG] Well, it was intended to be generic
On 10 Feb 2012, at 22:12, Chris Grundemann wrote:
Are you volunteering to buy everyone on earth a new CPE? If not, who
do you suggest will?
I suggest the ISPs, they are charging for the service, right?
My bet is that no one is willing to drop the
billions of dollars required -
[RM] The intention is to use this method only for environments with native
security mechanisms, such as the Broadband Access network. You are right it
is not clearly said in the document I can add the following sentence at the
end of the introduction in order to clarify this point:
This
John C Klensin wrote:
Arturo Servin wrote:
Chris Grundemann wrote:
Are you volunteering to buy everyone on earth a new CPE? If
not, who do you suggest will?
I suggest the ISPs, they are charging for the service, right?
...
if they were, we could just sign
everyone up for IPv6
From: Arturo Servin arturo.ser...@gmail.com
Are you volunteering to buy everyone on earth a new CPE? If not, who
do you suggest will?
I suggest the ISPs, they are charging for the service, right?
Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our
--On Monday, February 13, 2012 17:11 +0100 Martin Rex
m...@sap.com wrote:
John C Klensin wrote:
Arturo Servin wrote:
Chris Grundemann wrote:
Are you volunteering to buy everyone on earth a new CPE? If
not, who do you suggest will?
I suggest the ISPs, they are charging for the
Hi,
At 07:22 13-02-2012, George, Wes wrote:
[WEG] Well, it was intended to be generic (a variable to represent
multiple numbers). Are you saying ambiguous as in this intent is
unclear, use a different method to represent this generically or
you should use a specific number as an example, e.g.
Wes,
As an additional example of what can be done and has been done you
might want to point to http://hiroshima-info.info which is an example
of a volunteer-contributed website (for IETF 76) which gives travel
info from (I must admit) a geek perspective and from someone who has
attended a lot
On 2012-02-14 05:51, Noel Chiappa wrote:
From: Arturo Servin arturo.ser...@gmail.com
Are you volunteering to buy everyone on earth a new CPE? If not, who
do you suggest will?
I suggest the ISPs, they are charging for the service, right?
Lots of CPE is actually owned
On 02/12/2012 13:34, Noel Chiappa wrote:
From: Nilsson mansa...@besserwisser.org
there _is_ a cost, the cost of not being able to allocate unique
address space when there is a more legitimate need than the proposed
wasting of an entire /10 to please those who did not do
From: Doug Barton do...@dougbarton.us
If the RIRs do not deny these requests there is likely to be a revolt.
On what grounds? The ISPs will come along and say 'I have X new customers,
please give me more space for them'. The former being true, on what ground can
the RIRs refuse (modulo
On Feb 13, 2012, at 12:34 PM, Doug Barton wrote:
If an ISP can't use a shared block, they'll go ask their RIR for a block -
and given that they demonstrably have the need (lots of customers), they
will get it. Multiply than by N providers.
If the RIRs do not deny these requests there is
Brian E Carpenter wrote:
On 2012-02-14 05:51, Noel Chiappa wrote:
From: Arturo Servin arturo.ser...@gmail.com
Are you volunteering to buy everyone on earth a new CPE? If not, who
do you suggest will?
I suggest the ISPs, they are charging for the service, right?
On 02/13/2012 12:45, David Conrad wrote:
On Feb 13, 2012, at 12:34 PM, Doug Barton wrote:
If an ISP can't use a shared block, they'll go ask their RIR for
a block - and given that they demonstrably have the need (lots of
customers), they will get it. Multiply than by N providers.
If the
On Mon, Feb 13, 2012 at 9:34 PM, Doug Barton do...@dougbarton.us wrote:
On 02/12/2012 13:34, Noel Chiappa wrote:
From: Nilsson mansa...@besserwisser.org
there _is_ a cost, the cost of not being able to allocate unique
address space when there is a more legitimate need than the
From: Doug Barton do...@dougbarton.us
I haven't kept up to date on all of the RIRs' policies for granting
requests, but I don't recall seeing give me a huge block so that I
can do CGN as one of the established criteria.
An ISP needs a block of size X for CGN only if it has X
Martin Rex wrote:
The problem of ISP not newly shipping CPE that is not IPv6 capable
needs to be addressed by regulatory power (legistation),
That's how OSI failed.
rather than by ignorance of the part of the IETF.
So will be IPv6 by IETF as a regulatory power to prohibit
address space
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
In message 201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp, Martin Rex writes
:
Brian E Carpenter wrote:
On 2012-02-14 05:51, Noel Chiappa wrote:
From: Arturo Servin arturo.ser...@gmail.com
Are you volunteering to buy everyone on earth a new CPE? If not, w
ho
do
On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews ma...@isc.org wrote:
In message 201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp, Martin Rex
writes
:
Brian E Carpenter wrote:
On 2012-02-14 05:51, Noel Chiappa wrote:
From: Arturo Servin arturo.ser...@gmail.com
Are you
Hi, all,
One additional transport suggestion:
- it would be useful to include recommended configurations for TCP
connections. Given these are multi-byte request/response exchanges,
Nagle should be disabled, e.g.
Joe
On 2/13/2012 2:00 PM, Joe Touch wrote:
Hi, all,
I've reviewed this
On Mon, Feb 13, 2012 at 03:42:58PM -0500, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
If the RIRs do not deny these requests there is likely to be a revolt.
On what grounds? The ISPs will come along and say 'I have X new customers,
please give me more space for
Hi Noel,
At 12:42 13-02-2012, Noel Chiappa wrote:
On what grounds? The ISPs will come along and say 'I have X new customers,
please give me more space for them'. The former being true, on what ground can
the RIRs refuse (modulo cases like RIPE)?
If you have X new customers and you ask a RIR to
On 02/13/2012 13:46, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
I haven't kept up to date on all of the RIRs' policies for granting
requests, but I don't recall seeing give me a huge block so that I
can do CGN as one of the established criteria.
An ISP
Mans,
On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote:
To sum things up, we are at the stage where a /10 is a laughable
proposition.
Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs
can confirm.
It is either 10/8 or squat. No other alternatives exist. I'd
On Mon, Feb 13, 2012 at 02:36:34PM -0800, David Conrad wrote:
Mans,
On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote:
To sum things up, we are at the stage where a /10 is a laughable
proposition.
Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs
can
In message CAD6AjGS1SQz9ns0epA+ysiwHO4EG=xzhh-xzasvn_vxapcw...@mail.gmail.com
, Cameron Byrne writes:
On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews ma...@isc.org wrote:
In message 201202132046.q1dkk1hn020...@fs4113.wdf.sap.corp, Martin Rex =
writes
:
Brian E Carpenter wrote:
On
Martin Rex wrote:
...
It was the IETFs very own decision to build IPv6 in a fashion that it is
not transparently backwards compatible with IPv4. If the is anyone to
blame for the current situation, than it is the IETF, not the consumers
or the ISPs (except for those folks at ISPs who
On 2/13/2012 4:17 PM, Brian E Carpenter wrote:
People say this from time to time, but it's a complete myth.
well, not completely...
IPv4 provides no mechanism whatever for addresses greater than 32 bits.
Therefore, mathematically, there is no possible design for an IP with
bigger
On 2012-02-14 13:32, Dave CROCKER wrote:
On 2/13/2012 4:17 PM, Brian E Carpenter wrote:
People say this from time to time, but it's a complete myth.
well, not completely...
IPv4 provides no mechanism whatever for addresses greater than 32 bits.
Therefore, mathematically, there is no
On 2/13/2012 4:38 PM, Brian E Carpenter wrote:
There were very specific reasons why this was not done.
Is there a useful citation that covers this strategic decision?
Given that that decision was an essential part of what caused a roughly 15 year
delay, it would be helpful to have it
IPv4 provides no mechanism whatever for addresses greater than 32 bits.
Therefore, mathematically, there is no possible design for an IP with
bigger addresses that is transparently backwards compatible. We've known
that since at least 1992.
i guess you forget the discussion of variable
On 2012-02-14 13:42, Dave CROCKER wrote:
On 2/13/2012 4:38 PM, Brian E Carpenter wrote:
There were very specific reasons why this was not done.
Is there a useful citation that covers this strategic decision?
You may recall that at the time, we were very concerned about the
pre-CIDR
Brian E Carpenter wrote:
Dave CROCKER wrote:
Brian E Carpenter wrote:
There were very specific reasons why this was not done.
Is there a useful citation that covers this strategic decision?
You may recall that at the time, we were very concerned about the
pre-CIDR growth rate in BGP
From: Brian E Carpenter brian.e.carpen...@gmail.com
The design error was made in the late 1970s, when Louis Pouzin's advice
that catenet addresses should be variable length, with a format prefix,
was not taken during the design of IPv4.
Ironically, TCP/IP had variable length
Brian E Carpenter wrote:
There were very specific reasons why this was not done. And it doesn't
change the fact that an old-IP-only host cannot talk to a new-IP-only host
without a translator. It is that fact that causes our difficulties today.
The fact is that an old-IP-only host can talk to
Brian E Carpenter wrote:
Sure, that's very common, but these devices are consumer electronics and
will get gradually replaced by IPv6-supporting boxes as time goes on.
The problem is that IPv6 specification is still broken in
several ways to be not operational that existing boxes must
be
The IESG has received a request from the Port Control Protocol WG (pcp)
to consider the following document:
- 'Port Control Protocol (PCP)'
draft-ietf-pcp-base-23.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'MANET Cryptographical Signature TLV Definition'
draft-ietf-manet-packetbb-sec-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 the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Simplified Multicast Forwarding'
draft-ietf-manet-smf-13.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has approved the following document:
- 'Locator/ID Separation Protocol (LISP)'
(draft-ietf-lisp-22.txt) as an Experimental RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL of this
A new Request for Comments is now available in online RFC libraries.
RFC 6506
Title: Supporting Authentication Trailer for OSPFv3
Author: M. Bhatia, V. Manral, A. Lindem
Status: Standards Track
Stream: IETF
Date:
42 matches
Mail list logo
