Sorry Noel but I choice to reply public to this one.
On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote:
IPv6 is The Key!
If you think denying a CGN block will do anything at all to help IPv6,
you're very confused.
quote out of context etc... but my change of
On Tue, Feb 14, 2012 at 5:51 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
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
The more serious problem is that IPv6 people in IETF do
not admit IPv6 broken, which makes it impossible to fix
IPv6.
Make a draft, gather your supporters and take that discussion on
6man wg. I'm sure there are people open to consider any arguments on
what's wrong/or not.
Now, I'm tired of
Hello Ted and Bell,
I tried to address both your comments by combining your proposals:
Basically I added the text suggested by Ted in the security considerations
section and then I slightly modified the introduction in order to clarify the
applicability.
I've just posted version -04 that
I support this updated draft, and I am keen for this to be published as a
BCP.
I believe the amendments in this revision clarify the usage and intended
purpose of the shared transition space.
Daryl
___
Ietf mailing list
Ietf@ietf.org
On 2/13/2012 7:09 PM, Brian E Carpenter wrote:
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,
From: Roger Jorgensen rog...@gmail.com
Sorry Noel but I choice to reply public to this one.
Ah, no, actually. Had you thought about it for a moment or two, you could
have realized that you could have made your point just as well without
publicly quoting my private email. But why am I
I also support this draft.
Donald
On Tuesday, February 14, 2012, Daryl Tanner daryl.tan...@blueyonder.co.uk
wrote:
I support this updated draft, and I am keen for this to be published as a
BCP.
I believe the amendments in this revision clarify the usage and intended
purpose of the shared
I support this updated draft, and I am keen for this to be published as a
BCP.
+1
I believe the amendments in this revision clarify the usage and intended
purpose of the shared transition space.
+1
Ned
___
Ietf
I support this draft as updated.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
+1. One point I would like to make regarding not being encourage to
move to IPv6, was increased when the RIRs established the new IPv4
request prove your need policies. It immediately strengthen the
notion that we must keep our existing IPv4 Class C network because if
we let it go, we might
I support draft-weil as revised. There is a vital need for this to move forward
and the IETF should stop standing in the way and let ARIN allocate the space
already.
Owen
On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote:
Fellow BDGKS Authors,
FYI: draft-weil is in another Last Call
Hi, thanks for the response. See additional comments inline. (I removed
sections for which no further comment seems necessary)
On Feb 10, 2012, at 7:52 AM, Maglione Roberta wrote:
[...]
-- I admit to not being a DHCP expert, but If I understand this draft
correctly, it proposes to send
On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote:
[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
On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
Do I infer correctly from your comment that the security properties of the
mechanism don't really matter? That is, if the attacker we care about can't
eavesdrop in the first place, does this really need to be an HMAC?
Hm, I thought about that a
On Feb 13, 2012, at 3:21 PM, Ted Lemon wrote:
On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
Do I infer correctly from your comment that the security properties of the
mechanism don't really matter? That is, if the attacker we care about can't
eavesdrop in the first place, does this
Hi Randy and Brian,
I am sure the discussion of the discussion has been had before, but:
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
On Feb 14, 2012, at 5:23 AM, Maglione Roberta wrote:
Please let me know if you have additional comments.
Thanks! I think you should change this text in the introduction:
The mandatory authentication was
originally motivated by a legitimate security concern whereby in some
network
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
+1
I support this draft!
Best Regards,
Hans
--
Hans Thienpondt
Technology Engineer
Converged Network Engineering
Telenet NV
Liersesteenweg 4 - box 52
T: +32 15 33 30 24
2800 Mechelen - Belgium
On 2/13/2012 7:53 PM, Noel Chiappa wrote:
From: Brian E Carpenterbrian.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
On 2/2/2012 3:05 PM, Chris Grundemann wrote:
Hides the screen, nervous, pays cash... Sounds to me like anyone
surfing pr0n at the Internet Cafe is now a suspected terrorist.z
You should go spend a week in the border towns in Israel before you make
such telling comments like that.
Todd
On
+1, I support this draft… Bill Check
On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote:
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
+1
I support this draft!
Best Regards,
Hans
--
Hans Thienpondt
Technology Engineer
Converged Network
On 2/12/2012 10:12 AM, Adrian Farrel wrote:
Hi SM,
So isnt the real issue that of informed consent? If you dont know that
someone else has already existing work is it their fault for not telling
the IETF?
If so then there would also need to be some form of process identical to
this for
Apologies for top posting rather than addressing specific
commentators, but there have been several misconceptions raised
several times that I felt should be addressed generically:
1) We are out of IPv4 space / There's no-where to get this /10 -
There is already a /10 reserved by the ARIN
+1.
Ross
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen
DeLong
Sent: Monday, February 13, 2012 2:06 PM
To: ietf@ietf.org
Cc: draft-bdgks-arin-shared-transition-space@tools. org
Subject: Re: Another last call for draft-weil
I support draft-weil as revised. There is
(not voting twice, my other address did not seem to work)
1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
1.
Ross
From:ietf-boun...@ietf.org[mailto:ietf-boun...@ietf.org]On
Behalf OfOwen DeLong
Sent:Monday, February 13, 2012 2:06 PM
To:ietf@ietf.org
The word alignment issue was very strong and the router people had considerably
more influence than the host folks. I tried to propose variable length
addressing using four bit nibbles in August 1974 and I got no traction at all.
Steve
Sent from my iPhone
On Feb 14, 2012, at 6:31 PM, Bob
in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not
Scott
Scott O Bradner
Senior TechnologyConsultant
Harvard University Information Technology
Innovation Architecture
(P) 1 (617) 495 3864
29 Oxford St. Rm 407
Cambridge,
To the addressed folks who's messages appear below:
I'm not sure I understand what you're saying. There was some objection
at the beginning of this thread by Wes George, Noel Chiappa, and Brian
Carpenter. I agreed that the document could be misunderstood as
encouraging the use of the space as
I'm curious: how is the IETF stopping ARIN from allocating the space?
Thanks,
-drc
On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote:
(not voting twice, my other address did not seem to work)
+1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
+1.
Ross
From:
the IAB advised ARIN that such assignments were in the purview of the IETF
Scott
Scott O Bradner
Senior TechnologyConsultant
Harvard University Information Technology
Innovation Architecture
(P) 1 (617) 495 3864
29 Oxford St. Rm 407
Cambridge, MA 02138
On Feb 14, 2012, at 1:49 PM,
On Tue, Feb 14, 2012 at 1:49 PM, David Conrad d...@virtualized.org wrote:
I'm curious: how is the IETF stopping ARIN from allocating the space?
+1
though honestly I'm not a fan of the process.
Thanks,
-drc
On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote:
(not voting twice, my other
To the addressed folks who's messages appear below:
I'm not sure I understand what you're saying. There was some objection
at the beginning of this thread by Wes George, Noel Chiappa, and Brian
Carpenter. I agreed that the document could be misunderstood as
encouraging the use of the space as
Pete Resnick wrote:
I'm not sure I understand what you're saying. There was some
objection at the beginning of this thread by Wes George, Noel
Chiappa, and Brian Carpenter. I agreed that the document
could be misunderstood as encouraging the use of the space as
1918 space and proposed
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote:
Are you now objecting to that replacement text and want -14 published as
is? Do you think the document should say that the new allocation can be
used as 1918 space? If so, please explain.
Not sure how a +1 to a statement saying I support
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote:
Are you now objecting to that replacement text and want -14 published as
is? Do you think the document should say that the new allocation can be
used as 1918 space? If so, please explain.
Not sure how a +1 to a statement saying I
Do you, or do you not, object to the proposed change that changes the
text from saying, This space may be used just as 1918 space to This
space has limitations and cannot be used as 1918 space?
what silliness. it will be used as rfc 1918 space no matter what the document
says.
nine years
This is a reminder that the IAOC is conducting a T-Shirt Design Contest to
develop a unique t-shirt for the Paris meeting. You have until this Friday, Feb
17 to submit your design for consideration. We've received two submissions so
far and you can see them here:
Randy Bush writes:
in response to Pete Resnick, who wrote:
Do you, or do you not, object to the proposed change that
changes the text from saying, This space may be used just
as 1918 space to This space has limitations and cannot be
used as 1918 space?
what silliness. it will be used as
On 2012-02-15 09:35, Randy Bush wrote:
Do you, or do you not, object to the proposed change that changes the
text from saying, This space may be used just as 1918 space to This
space has limitations and cannot be used as 1918 space?
what silliness. it will be used as rfc 1918 space no
In that I completely agree with what Randy is saying, the point
that needs to be made is that this should not be officially
sanctioned as RFC-1918 space -- no manufacturer or programmer
should treat this netblock the same.
If some fly-by-night company chooses to use it on their own,
well,
Todd,
You may or may not be right about whether an individual can make a decision to
disclose. In my experience they often can't, but do have the power to
request/implore their employer to disclose.
On the other hand, they *do* have the power to not participate.
BCP79 offers this choice and I
Randy Bush writes:
in response to me:
In that I completely agree with what Randy is saying, the point
that needs to be made is that this should not be officially
sanctioned as RFC-1918 space -- no manufacturer or programmer
should treat this netblock the same.
If some fly-by-night
I agree with Adrian. Individuals come to the IETF, not companies. Sure
they are employed by companies, but they also have to follow the rules stated
in BCP79. I am really tired of the myriad of excuses people have given in the
past about why they have not been able to comply. Its a
Bob Braden wrote:
Within the ARPA-funded Internet research program that designed IP and
TCP, Jon Postel and Danny Cohen argued strenuously for variable length
addresses. (This must have been around 1979. I cannot name most of the
other 10 people in the room, but I have a clear mental
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually worse than
an IPv4 NAT.
I'm sorry,
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually
In message 201202142245.q1emjaou019...@fs4113.wdf.sap.corp, Martin Rex writes
:
The necessary changes to applications would be minimal,
the happy eyeballs contortion completely unnecessary
and the security assessment for an IPv6 enabled network
*MUCH* simpler.
Happy eyeballs just points out
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make
Brian E Carpenter wrote:
I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
hosts that are numbered out of an address space greater than 32 bits
requires some form of address sharing,
Sure.
address mapping, and translation.
Not at all.
Realm Specific IP [RFC3102] is such
Mark Andrews wrote:
Happy eyeballs just points out problems with multi-homing in general.
IPv4 has the *same* problem and sites spend 1000's of dollars working
around the issue which could have been addressed with a couple of
extra lines of code on the client side in most cases.
It's Brian
Bradner, Scott wrote:
the IAB advised ARIN that such assignments were in the purview of the IETF
Then, isn't it enough for IETF to conclude let ARIN decide?
Are there any objections to conclude so?
Masataka Ohta
The deployment problem was not due to technical issues, it was because
the Internet changed to only deploy new technology that generated
revenue in the short term. After a lot of thought, I have come to the
conclusion that it wouldn't have mattered what the IETF did, we would
still be facing
Pete Resnick wrote:
Do you, or do you not, object to the proposed change that changes the
text from saying, This space may be used just as 1918 space to This
space has limitations and cannot be used as 1918 space? Nobody on the
list objected to that new text. That new text significantly
On 2/14/12 2:35 PM, Randy Bush wrote:
what silliness. it will be used as rfc 1918 space no matter what the document
says.
[...]
any thought that this is not just adding to rfc 1918 is pure bs.
Of course it will be used as 1918 space. That's not the point of the text.
The text is saying,
Randy Bush wrote:
what silliness. it will be used as rfc 1918 space no matter what the document
says.
The difference is on how future conflicts can be resolved.
nine years ago i was in bologna and did a traceroute out. i was surprised
to find that the isp was using un-announced us
On 12-02-14 3:49 PM, Randy Bush ra...@psg.com wrote:
In that I completely agree with what Randy is saying, the point
that needs to be made is that this should not be officially
sanctioned as RFC-1918 space -- no manufacturer or programmer
should treat this netblock the same.
If some
Support Draft as written +1.
Victor K
On 12-02-14 12:38 PM, William Check bch...@ncta.com wrote:
+1, I support this draft Bill Check
On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote:
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
+1
I support this draft!
On 2012-02-15 11:45, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4
On 02/14/2012 17:26, Pete Resnick wrote:
Of course it will be used as 1918 space. That's not the point of the text.
My first reply in this most recent version of the thread pointed out
that now that we're finally willing to admit that if a new block is
issued it will be used as 1918 space then
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated stacks. Many MIBs would have
needed to be updated. DHCP servers
On Feb 14, 2012 7:40 PM, Randy Bush ra...@psg.com wrote:
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated
Brian E Carpenter wrote:
With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would
Victor Kuarsingh wrote:
Randy Bush ra...@psg.com wrote:
In that I completely agree with what Randy is saying, the point
that needs to be made is that this should not be officially
sanctioned as RFC-1918 space -- no manufacturer or programmer
should treat this netblock the same.
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote:
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration
A new IETF non-working group email list has been created.
List address: s...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/sop/
To subscribe: https://www.ietf.org/mailman/listinfo/sop
Purpose: Cloud services need to interoperate across cloud providers, service
vendors and
Shortly, the IETF datatracker will go through a major change, one of the two
largest since it was first deployed more than 10 years ago. Hopefully no one
will notice.
The previous major change was in 2007, when we switched the public Datatracker
from Perl cgi-bin scripts to a much more
The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'CoRE Link Format'
draft-ietf-core-link-format-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
This is a reminder that the IAOC is conducting a T-Shirt Design Contest to
develop a unique t-shirt for the Paris meeting. You have until this Friday, Feb
17 to submit your design for consideration. We've received two submissions so
far and you can see them here:
A modified charter has been submitted for the Locator/ID Separation
Protocol (lisp) working group in the Internet Area of the IETF. The
IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your
comments to the IESG
The IESG has received a request from the ADSL MIB WG (adslmib) to
consider the following document:
- 'xDSL multi-pair bonding (G.Bond) MIB'
draft-ietf-adslmib-gbond-mib-09.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from the ADSL MIB WG (adslmib) to
consider the following document:
- 'ATM-Based xDSL Bonded Interfaces MIB'
draft-ietf-adslmib-gbond-atm-mib-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from the ADSL MIB WG (adslmib) to
consider the following document:
- 'xDSL multi-pair bonding using Time-Division Inverse Multiplexing
(G.Bond/TDIM) MIB'
draft-ietf-adslmib-gbond-tdim-mib-07.txt as a Proposed Standard
The IESG plans to make a decision in the
The IESG has received a request from the ADSL MIB WG (adslmib) to
consider the following document:
- 'Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB'
draft-ietf-adslmib-gbond-eth-mib-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
74 matches
Mail list logo
