James,
If I remember correctly, you mentioned a bit ago that your job required
you had native IPv6 at home.
Question: Does an ISP providing you IPv6 out of the CPE box (meaning,
without any software other than dual-stack on the hosts) qualify as
native IPv6 if, behind the scenes, they use a
Hi Alexa,
At 04:51 PM 7/27/2011, Alexa Morris wrote:
First, I want to reassure you that there is no plan to discontinue the
regular audio streaming at meetings; indeed, there was every intention
Thanks.
Sorry for any inconvenience. Please also understand that the Meetecho
staff intended to
On Jul 28, 2011, at 1:30 AM, james woodyatt wrote:
I think the measurements we've all seen at the technical plenary show that
6to4 is a small percentage of the total world IPv6 traffic now, which again
is an embarrassingly small fraction of global Internet traffic.
What I saw from
Hi Martin,
At 04:13 PM 7/27/2011, Martin Rex wrote:
According to rfc2026:
4.2.2 Informational
An Informational specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. [...]
The
In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote:
PS - And in those cases, proper address selection is a much better solution
(IMHO) than hitting this screw with a hammer.
I think the problem is that we don't know how to do 'proper' address
selection. It would be nice if 5 or 10
Philip Homburg wrote:
I think the problem is that we don't know how to do 'proper' address
selection.
I know and it's trivially easy.
It would be nice if 5 or 10 years ago there would have been a good
standard to do address selection.
11 years ago in draft-ohta-e2e-multihoming-00.txt, I
On Jul 28, 2011, at 3:50 AM, Philip Homburg wrote:
In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote:
PS - And in those cases, proper address selection is a much better solution
(IMHO) than hitting this screw with a hammer.
I think the problem is that we don't know how to do
this is better than the last version but
1/ I still see no reason to think that this change will cause any
significant change in the percent of Proposed Standards that move up the
(shorter) standards track since the proposal does nothing to change the
underlying reasons that people do not expend
In your letter dated Thu, 28 Jul 2011 07:50:38 -0400 you wrote:
In general, all of a host's addresses (at least, those in the same
preference class in the address selection algorithm) need to work
equally well from everywhere.
But even that might not be sufficient. Fred Baker has recently
In your letter dated Thu, 28 Jul 2011 17:08:01 +0900 you wrote:
Philip Homburg wrote:
I think the problem is that we don't know how to do 'proper' address
selection.
I know and it's trivially easy.
11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:
End systems (hosts) are end
On 2011-07-27 at 18:03:13, Brian E Carpenter wrote:
The second byte in an IPv4 header is called the Differentiated
Services Field.
I believe that this has been obsoleted by RFC 5241.
___
Ietf mailing list
Ietf@ietf.org
Brian,
On 7/27/2011 8:50 PM, Brian E Carpenter wrote:
Expected is one thing; but even the IESG's own rules do not *require* this.
http://www.ietf.org/iesg/voting-procedures.html
First, the written rules do not matter much, if actual behavior runs contrary.
Second, expectations constitute a
Scott -
Didn't RFC 5657 address your point 2?
The current proposal no longer requires this report during advancement, but it
does not disallow it.
I hope it's obvious that I believe these reports are valuable, but I am willing
to accept the proposed
structure, with the hope and expectation
On 7/28/11 1:05 AM, Mykyta Yevstifeyev wrote:
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more.
Wrong. The *title* needs to be adjusted, but mutatis mutandis the
general advice is useful.
It should be
And the real question is, are we moving forward? I think that we are not moving
as far as we originally wanted. However, I offer we are moving a baby step
forward, and as such is worthwhile doing.
On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:
Scott -
Didn't RFC 5657 address your point
On 7/28/11 10:03 AM, Eric Burger wrote:
And the real question is, are we moving forward? I think that we are
not moving as far as we originally wanted. However, I offer we are
moving a baby step forward, and as such is worthwhile doing.
We are more closely aligning our documentation with our
I want to make the IETF community aware that Alcatel Lucent has withdrawn their
original IPR disclosure regarding RFC 6073, and Alcatel Lucent has submitted a
replacement statement: https://datatracker.ietf.org/ipr/1589/
I want to highlight one thing that is unique in this particular
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:
On 7/28/11 10:03 AM, Eric Burger wrote:
And the real question is, are we moving forward? I think that we are
not moving as far as we originally wanted. However, I offer we are
moving a baby step forward, and as such is worthwhile doing.
There has been a PCP Demo from during the week. Visitors of the Demo have
entered their cards and contacts in a raffle box to win a Huawei-sponsored
iPAD2. I have agreed to draw the winner during the first afternoon break today
in the terminal room (2000D). Two hours will be given to the
On 7/28/11 10:20 AM, Keith Moore wrote:
In other words, I'm not convinced that this change will do much harm,
but I'm also not convinced that it will help much.
I don't disagree.
And yet we keep
flogging this idea...
But we always flog the easy issues, rather than facing the tough ones.
Hi, Thx for your comments. Private walled garden creates lots of
interoperabilty issues. In the long term with deployments in the
field, even after the expiry of patents we end up for a workable
solution to carry unnecessary burden. e.g. I 'GUESS' pains of htonl
etc are due to patents. IMHO we
The patent would have expired by now?
On Jul 28, 2011, at 10:47 AM, Samir Srivastava wrote:
Hi, Thx for your comments. Private walled garden creates lots of
interoperabilty issues. In the long term with deployments in the
field, even after the expiry of patents we end up for a workable
On Jul 28, 2011 1:08 AM, Philip Homburg pch-v6...@u-1.phicoh.com wrote:
In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote:
In the absence of a coherent instruction from IETF for a phase-out
plan, declaring this protocol historic under the current proposed
language, will do
From: Cameron Byrne cb.li...@gmail.com
Like how Apple does not support Flash in iOS?
Just one example where a visionary drops an inferior solution to force
a better one.
Apple has enough market share to get away with that. IPv6 doesn't.
Noel
[ Top posting - meta comment ]
Every now and then I get a bee in my bonnet and decide to carefully review each
and every draft in LC. I hate to break it to y'all, but many drafts really
poorly written, and, even if you have very broad interests, many of them are
going to be really boring to
Gonzalo == Gonzalo Camarillo gonzalo.camari...@ericsson.com writes:
I don't know about the codecs, but there is a wireless hop. I'm
getting frequent very short drops as well as slightly buzzy sound
and less fidelity than the parallel session streaming. The voices
of people I
I think the IESG, or its various delegates, do need to review everything,
especially keeping in mind that review doesn't have to be some big
heavyweight thing each time. I share the same view as others that sometimes
some really broken stuff manages to get up to that level.
And, although it
+1
On 7/28/2011 11:22 AM, Warren Kumari wrote:
...
While not all ADs read all drafts, most read a large fraction of them
(and read them carefully and thoughtfully enough to catch a number of
large issues (and nits) *that were not caught in LC*) -- I think that
they deserve recognition for
On 2011-07-27 18:03 , Mark Andrews wrote:
[..]
b) use a tunnel broker - this works much better through NATs and with dynamic
IPv4 addresses
For which there is only experimental / ad-hoc code.
You call my code Experimental/ad-hoc? :)
Like a good whiskey it matured over the years and
On Wed, Jul 27, 2011 at 06:07:12PM +0100, Dave Cridland wrote:
On Wed Jul 27 06:25:49 2011, Willy Tarreau wrote:
On Wed, Jul 27, 2011 at 11:28:06AM +1000, Mark Andrews wrote:
SRV provides load-balancing and failover. I never said that SRV
is a
solution for temporaly put in maintenance a
On 2011-07-27 20:21 , Keith Moore wrote:
On Jul 27, 2011, at 11:35 AM, Tim Chown wrote:
I suspect, but have no proof, that the huge majority of 6to4 users don't use
it intentionally, and the content they are trying to reach is also available
over IPv4. But for people who want to develop
Yoav Nir writes:
This draft represents a total shirking of our responsibility. Rather
than decide on one protocol that is best or even arbitrarily
choosing one that is good enough, it proposes to build a framework
so that everyone and their dog can have their own method. This is a
nightmare
In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote:
In the absence of a coherent instruction from IETF for a phase-out
plan, declaring this protocol historic under the current proposed
language, will do precisely that. Please please please, if IETF
wants 6to4 to die, then publish
On 2011-07-28 01:36 , Mark Andrews wrote:
[..]
Is there *one* tunnel management protocol that they all support or
does a cpe vendor have to implement multiple ones to reach them
all? I'm pretty sure I know the answer to this question but I'd
love to be proved wrong.
There is no 'one'
Paul Hoffman writes:
Partially yes, but unfortunately all of the authors of those actual
protocols decided that they wanted to continue publishing those drafts
as individual RFCs, and each of them used different way to negotiate
them, so there was no way to even implement multiple of them.
Yaron Sheffer writes:
Back to the matter at hand: I am opposed to
draft-kivinen-ipsecme-secure-password-framework. It has served its
purpose when two of the proposals were changed to add method
negotiation, and thus enable IKE peers to implement none, one or more of
these methods.
Hi,
On Thu, Jul 28, 2011 at 11:20:18AM -0400, Noel Chiappa wrote:
Apple has enough market share to get away with that. IPv6 doesn't.
Just how much market share has 6to4, if we exclude those two users?
It's amazing how many human life cycles got wasted on this (and that
I can't refuse to be
I support an IKEv2 ZKPP method framework. I don't understand the
controversy -- i.e., I think it's much ado about nothing.
Nico
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Thanks for the quick response.
Here's what my reading revealed, and you can tell me if I'm in error or not...
RFC3260 tells us that the first six bits (not 8) are called the DS Field or
Differentiated Services Field, and the subsequent
two bits are referred to as ECN (ECN field according to RFC
Original Message -
From: Sean Turner turn...@ieca.com
To: ietf@ietf.org
Sent: Wednesday, July 27, 2011 2:09 PM
On 7/25/11 2:01 PM, Dave CROCKER wrote:
On 7/25/2011 1:17 PM, Glen wrote:
I am very pleased to report that the IETF is now applying DKIM signatures
to all outgoing
28.07.2011 16:52, Peter Saint-Andre wrote:
On 7/28/11 1:05 AM, Mykyta Yevstifeyev wrote:
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more.
Wrong. The *title* needs to be adjusted, but mutatis mutandis the
I've been encouraged to say this to a wider audience, so here I am.
A BoF is the IETF's tool for gauging interest in a new topic and a potential
working group charter. This doesn't just mean a showing of people that would
track this work if it were to begin, but really the main purpose is to
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Murray S. Kucherawy
Sent: Thursday, July 28, 2011 4:06 PM
To: IETF discussion list
Subject: On attending BoFs
I've been encouraged to say this to a wider audience, so here I am.
A BoF
On Thu, Jul 28, 2011 at 01:30, james woodyatt j...@apple.com wrote:
http://www.pam2010.ethz.ch/papers/full-length/15.pdf
Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig
3); about 90% MacOS hits is 6to4, which possibly means (to me) that this
piece of 6to4 MacOS
You're going to ask attendees to self-identify as tourists and leave
the room? Today's tourists may well become tomorrow's document
editors.
...
Let's just assign large enough rooms to BoFs and newly-formed WGs
so that the work can start in earnest.
I agree. If people are there paying
On 7/28/11 4:06 PM, Murray S. Kucherawy wrote:
When we ask for a BoF room, we need to give an indication of estimated
attendance. Sometimes it’s hard to make a good guess and so we
underestimate, intending to keep larger rooms available for groups that
need them.
I think the BoF chairs and
Lorenzo,
Lorenzo Colitti wrote:
http://www.google.com/intl/en/ipv6/statistics/
Thanks for the update.
Clarification: in your stats, is AS12322's traffic classified as native
or as 6to4/teredo?
Michel.
___
Ietf mailing list
Ietf@ietf.org
On 2011-07-28 16:49, Kevin Fall wrote:
Thanks for the quick response.
Here's what my reading revealed, and you can tell me if I'm in error or not...
RFC3260 tells us that the first six bits (not 8) are called the DS Field or
Differentiated Services Field, and the subsequent
two bits are
On Thu, Jul 28, 2011 at 16:51, Michel Py mic...@arneill-py.sacramento.ca.us
wrote:
Clarification: in your stats, is AS12322's traffic classified as native
or as 6to4/teredo?
As the webpage says: The Total IPv6 graph shows IPv6 users with any type of
connectivity, while the Native IPv6 graph
On 28 Jul 2011, at 21:51, Michel Py wrote:
Lorenzo,
Lorenzo Colitti wrote:
http://www.google.com/intl/en/ipv6/statistics/
Thanks for the update.
Clarification: in your stats, is AS12322's traffic classified as native
or as 6to4/teredo?
Hi,
I just ran a search through our Netflow
Bad question, I apologize for the imprecision. Please allow me to
rephrase.
Michel Py wrote:
Clarification: in your stats, is AS12322's traffic
classified as native or as 6to4/teredo?
Lorenzo Colitti wrote:
As the webpage says: The Total IPv6 graph shows IPv6
users with any type of
Philip Homburg wrote:
which means an end system should have a full routing table, IGP
metrics in which tell the end system what is the best address of
its multihomed peer. Full routing table should and can, of course,
be small.
Even in the unlikely case that it would be feasible to give
Keith,
On 2011-07-29 02:20, Keith Moore wrote:
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:
On 7/28/11 10:03 AM, Eric Burger wrote:
And the real question is, are we moving forward? I think that we are
not moving as far as we originally wanted. However, I offer we are
moving a
+$1.00
Have we ever had a BOF that looked under-attended? Not me: always standing room
only!
Big rooms = good BOF.
On Jul 28, 2011, at 4:37 PM, Peter Saint-Andre wrote:
On 7/28/11 4:06 PM, Murray S. Kucherawy wrote:
When we ask for a BoF room, we need to give an indication of estimated
... and if the room isn't full, that's interesting information too.
On 28/07/2011, at 4:10 PM, Eric Burger wrote:
+$1.00
Have we ever had a BOF that looked under-attended? Not me: always standing
room only!
Big rooms = good BOF.
On Jul 28, 2011, at 4:37 PM, Peter Saint-Andre wrote:
I don't know about the real-time remote participation aspects because I'm at
the IETF in QC, but I did use the meetecho recorded sessions for a couple WGs I
didn't attend this week and I have to say it was great - better than the mp3
recordings of previous IETFs. While the mp3 had better
On Thu, Jul 28, 2011 at 7:10 PM, Eric Burger
eburge...@standardstrack.comwrote:
+$1.00
Have we ever had a BOF that looked under-attended? Not me: always standing
room only!
I would also argue that you want BOF tourists. They might turn into
participants. They also might point out
things
Dave, we are shouting past each other so I will not repeat myself
on all points. However,
...
Of course, there can be cases where that is not so - in fact, that's
the main reason that the IESG defined the DISCUSS criteria a few years
ago.
Have you seen a pattern of having a Discuss cite the
On 2011-07-28 18:45, SM wrote:
Hi Martin,
At 04:13 PM 7/27/2011, Martin Rex wrote:
According to rfc2026:
4.2.2 Informational
An Informational specification is published for the general
information of the Internet community, and does not represent an
Internet community
Looking at a trace that I got from Geoff Huston a month or two ago,
there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source
address.
That's surprisingly high, showing that the answer depends greatly on
the point of observation, and explains why operators really need
to try to run a
Hi Brian,
At 04:24 PM 7/28/2011, Brian E Carpenter wrote:
Er, no. By definition, it's correct until we update RFC 2026.
Quoting the Status of this memo section from RFC 6305, RFC 6308, RFC
6319 and RFC 6331 which are Informational and from the IETF Stream:
This document is a product of
Masataka Ohta wrote:
It would be nice if 5 or 10 years ago there would have been a good
standard to do address selection.
11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:
End systems (hosts) are end systems. To make the end to end principle
effectively work, the end
you may like to look at
http://labs.apnic.net/dns-measurement/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Brian, I recall some pretty serious agreement almost at the beginning
that it was a diffserv field, only 6 bits, and that people who were
saying diffserv byte were wrong. I also recall some dithering over
whether the other two bits should be declared reserved, but without
conclusion.
On Jul 28,
On 7/28/2011 7:22 PM, Brian E Carpenter wrote:
Dave, we are shouting past each other so I will not repeat myself
on all points. However,
Brian,
I did not ask you to repeat anything -- and don't want you to.
Rather, I asked you to move beyond cliche's and personal anecdotes into
On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote:
Masataka Ohta wrote:
It would be nice if 5 or 10 years ago there would have been a good
standard to do address selection.
11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:
End systems (hosts) are end systems. To
And do you really only want people in the room who already know the
issues and have decided to be for or against it? If you already have
so many of them, you don't need a BOF at all, just take a hum and be
done. The main purpose of a BOF is to present. Information to the
community so they can
On 2011-07-29 13:52, Scott Brim wrote:
Brian, I recall some pretty serious agreement almost at the beginning
that it was a diffserv field, only 6 bits, and that people who were
saying diffserv byte were wrong. I also recall some dithering over
whether the other two bits should be declared
On Jul 28, 2011, at 7:41 PM, Brian E Carpenter wrote:
Looking at a trace that I got from Geoff Huston a month or two ago,
there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source
address.
That's surprisingly high, showing that the answer depends greatly on
the point of
Dave,
On 2011-07-29 13:53, Dave CROCKER wrote:
On 7/28/2011 7:22 PM, Brian E Carpenter wrote:
Dave, we are shouting past each other so I will not repeat myself
on all points. However,
Brian,
I did not ask you to repeat anything -- and don't want you to.
Rather, I asked you to move
Mark Andrews wrote:
Martin Rex writes:
Mark Andrews wrote:
More correctly it is try the first address and if that doesn't
connect in a short period (150...250ms) start a second connection
to the next address while continuing with the first. If you have
more that 2 address
Cameron Byrne wrote:
The primary reason why the IPv4 - IPv6 transition is so painful
is that it requires everyone one and everything to become multi-homed
and every software to perform multi-connect, even though most
devices actually just have a single interface.
It was not a problem,
In message 201107290238.p6t2cclu021...@fs4113.wdf.sap.corp, Martin Rex writes
:
Mark Andrews wrote:
Martin Rex writes:
Mark Andrews wrote:
More correctly it is try the first address and if that doesn't
connect in a short period (150...250ms) start a second connection
Brian E Carpenter wrote:
Looking at a trace that I got from Geoff Huston a month or
two ago, there are 25486 IPv6 TCP sessions of which 10748
have a 6to4 source address. That's surprisingly high,
Not to me.
showing that the answer depends greatly on the
point of observation
Indeed this is
Dear colleagues,
This is not to pick on Murray, who was not making the point I am
trying to draw out of his remarks. Sorry, Murray.
On Thu, Jul 28, 2011 at 08:45:41AM -0700, Murray S. Kucherawy wrote:
the process. So perhaps what's needed is an optional document state
prior to Publication
I think I understand your request taht we move beyond personal
anecdotes. In principle, I even agree with you.
However, when I try to act on that, I am stumped. I do not see any way
to evaluate say the last 2 years discusses to determine whether they
were more harmful or more helpful.
Any
Just for the record: we want big rooms!
On Jul 28, 2011, at 10:01 PM, Scott Brim wrote:
And do you really only want people in the room who already know the
issues and have decided to be for or against it? If you already have
so many of them, you don't need a BOF at all, just take a hum and
On Jul 28, 2011, at 11:41 PM, Michel Py wrote:
Same remarks as above, plus I don't see there anything that separates
6rd.
6rd is global unicast... there's nothing to discriminate it from any other
native range.
Michel.
___
Ietf mailing
Total of 337 messages in the last 7 days.
script run at: Fri Jul 29 00:53:02 EDT 2011
Messages | Bytes| Who
+--++--+
7.72% | 26 | 7.40% | 171189 | w...@1wt.eu
6.82% | 23 | 6.76% | 156358 | ma...@isc.org
But more importantly we have abolished the end-to-end principle. If I am going
to benefit from improved security on e-mail, I want to from the originator to
me, not some half-way house giving a spurious impression of accuracy.
I can't help but be baffled at the lack of a PGP or S/MIME
Joel Jaeggli wrote:
6rd is global unicast... there's nothing to discriminate
it from any other native range.
No. there is nothing in the current classification algorithm to
discriminate from any other native range. But it's not native, as it
has, among other things, the same reliance on IPv4
The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Runtime LMA Assignment Support for Proxy Mobile IPv6'
draft-ietf-netext-redirect-08.txt as a Proposed Standard
This is a second last call that was performed as the
82 matches
Mail list logo
