Hello Ben,
Thanks for reviewing this document.
Please see answers inline [RM]
Best regards,
Roberta
-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com]
Sent: martedì 7 febbraio 2012 0.17
To: draft-ietf-dhc-forcerenew-nonce@tools.ietf.org
Cc: gen-...@ietf.org Review
On 2/9/12 3:40 PM, Mark Andrews ma...@isc.org wrote:
In message 6.2.5.6.2.20120209091221.082cb...@resistor.net, SM writes:
Hi Chris,
At 08:57 AM 2/9/2012, Chris Grundemann wrote:
http://www.apnic.net/publications/news/2011/final-8
I am aware of the APNIC announcement. That's one out of
--On Friday, February 10, 2012 08:47 -0700 Chris Donley
c.don...@cablelabs.com wrote:
...
Please remember that this draft is in support of ARIN Draft
Policy 2011-5. Should this draft become an RFC, and should
ARIN pony up the /10, ARIN's staff is likely to look askance
at requests for
On Fri, Feb 10, 2012 at 11:15, John C Klensin john-i...@jck.com wrote:
To follow up on an earlier comment, the rate at which ARIN (or
other RIRs) are running out of /10s (or /8s) is probably
irrelevant, as are hypotheses about what ARIN staff might do
about requests for allocation for CGN use
There has been some discussion on this list about
draft-farrresnickel-ipr-sanctions-00. Thanks for the input.
The conversation seems to be partitioned into:
- discussion of sanctions and how to apply them
- discussion of measures that can be taken to
help people to adhere to BCP79
-
--On Friday, February 10, 2012 11:22 -0700 Chris Grundemann
cgrundem...@gmail.com wrote:
On Fri, Feb 10, 2012 at 11:15, John C Klensin
john-i...@jck.com wrote:
To follow up on an earlier comment, the rate at which ARIN (or
other RIRs) are running out of /10s (or /8s) is probably
On 02/10/2012 07:47, Chris Donley wrote:
Please remember that this draft is in support of ARIN Draft Policy 2011-5.
Partially, sure. But RFCs apply to the whole Internet.
IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how
to allocate space;
I'm not going to parse the
Hi all,
Several people had asked for a summary of the Nomcom
selections, and the composition of the I* bodies after the
selected persons assume office. Here they are.
IESG Selection Summary and Composition
===
The Nomcom selected the following persons to
On 02/10/2012 10:22, Chris Grundemann wrote:
This is not about IPv4 life-support.
Seriously?
This is about providing the best answer to a difficult problem.
The best answer is to make sure that CPEs that will be doing CGN can
handle the same 1918 space inside the user network and at the CGN
On 2012-02-11 11:09, Doug Barton wrote:
On 02/10/2012 07:47, Chris Donley wrote:
Please remember that this draft is in support of ARIN Draft Policy 2011-5.
Partially, sure. But RFCs apply to the whole Internet.
Hear hear.
IMO, an IETF RFC is not the correct place to tell ARIN or other
On 2/9/12 10:47 PM, Doug Barton wrote:
As I (and many others) remain opposed to this entire concept I think
it's incredibly unfortunate that the IESG has decided to shift the topic
of conversation from whether this should happen to how it should
happen.
As an AD who is now comfortable
On 02/10/2012 15:42, Pete Resnick wrote:
On 2/9/12 10:47 PM, Doug Barton wrote:
As I (and many others) remain opposed to this entire concept I think
it's incredibly unfortunate that the IESG has decided to shift the topic
of conversation from whether this should happen to how it should
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote:
On 02/10/2012 10:22, Chris Grundemann wrote:
This is not about IPv4 life-support.
Seriously?
Seriously.
The birth of a shared CGN space in no significant way extends the life
of IPv4. It does provide the best possible
On 02/10/2012 16:12, Chris Grundemann wrote:
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote:
On 02/10/2012 10:22, Chris Grundemann wrote:
This is not about IPv4 life-support.
Seriously?
Seriously.
The birth of a shared CGN space in no significant way extends the
On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote:
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote:
On 02/10/2012 10:22, Chris Grundemann wrote:
This is not about IPv4 life-support.
Seriously?
Seriously.
The birth of a shared CGN space in no
Pete Resnick wrote:
and can be used by other
people who build sane equipment that understands shared addresses can
appear on two different interfaces.
With so complicated functionality of NAT today, the only
practical approach to build such equipment is to make it
a double NAT as:
On Feb 10, 2012 4:25 PM, Måns Nilsson mansa...@besserwisser.org wrote:
On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote:
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote:
On 02/10/2012 10:22, Chris Grundemann wrote:
This is not about IPv4 life-support.
From: =?iso-8859-1?Q?M=E5ns?= Nilsson mansa...@besserwisser.org
We do not need another reason for people to delay v6 deployment.
The last time this issue (CGNAT space) was discussed, we were asked not to
open this can of worms. I don't know if that request still holds, but
seriously,
On 2/10/12 3:57 PM, Doug Barton wrote:
On 02/10/2012 15:42, Pete Resnick wrote:
I expect there will be clarifications as per the earlier messages in
this thread: This is *not* to be used as additional 1918 space.
The following is not meant to be a snark
Not taken as such.
...I
On 2/10/12 6:38 PM, Masataka Ohta wrote:
Pete Resnick wrote:
and can be used by other
people who build sane equipment that understands shared addresses can
appear on two different interfaces.
With so complicated functionality of NAT today, the only
practical approach to build such
Thanks for your response, mine is below, with snipping.
On 02/10/2012 19:19, Pete Resnick wrote:
On 2/10/12 3:57 PM, Doug Barton wrote:
On 02/10/2012 15:42, Pete Resnick wrote:
I expect there will be clarifications as per the earlier messages in
this thread: This is *not* to be used as
From: Doug Barton do...@dougbarton.us
My point is that no matter how loudly you say, Don't use this as
1918 space! some users will do it anyway.
And if they do, any problem that results is _their_ problem.
That means that there is no reason to allocate this new block.
No.
On 02/10/2012 20:04, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
My point is that no matter how loudly you say, Don't use this as
1918 space! some users will do it anyway.
And if they do, any problem that results is _their_ problem.
You snipped the bit of the
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no
On 02/10/2012 20:44, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
Pete Resnick wrote:
and can be used by other
people who build sane equipment that understands shared addresses can
appear on two different interfaces.
With so complicated functionality of NAT today, the only
practical approach to build such equipment is to make it
a double NAT
Correct.
The IESG has approved the following document:
- 'RADIUS Support for Proxy Mobile IPv6'
(draft-ietf-netext-radius-pmip6-08.txt) as a Proposed Standard
This document is the product of the Network-Based Mobility Extensions
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A
Hi all,
Several people had asked for a summary of the Nomcom
selections, and the composition of the I* bodies after the
selected persons assume office. Here they are.
IESG Selection Summary and Composition
===
The Nomcom selected the following persons to
The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'FLUTE - File Delivery over Unidirectional Transport'
draft-ietf-rmt-flute-revised-13.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The Internet Society (ISOC) provides organizational and financial
support for the IETF. As part of the arrangements between ISOC and the
IETF, the IETF is called upon to name 3 Trustees to its Board (BoT),
with staggered 3 year terms. This requires that the IETF select one
Trustee each year.
30 matches
Mail list logo
