> 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
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 signature
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
5.93%
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 mai
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
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 su
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 Publicatio
> 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 th
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
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 proble
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
> > > m
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 yo
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 obse
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 declar
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 deci
On Jul 28, 2011 5:28 PM, "Martin Rex" 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 syst
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
consideratio
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
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
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,
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 th
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 dec
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
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 c
On Thu, Jul 28, 2011 at 7:10 PM, Eric Burger
wrote:
> +$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 like overlap with previo
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 audio
... 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
+$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
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
>>>
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 t
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 o
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 Ne
On Thu, Jul 28, 2011 at 16:51, Michel Py 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 excludes users using 6to4 or
Tere
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 bit
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
https://ww
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 a
> 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 Thu, Jul 28, 2011 at 01:30, james woodyatt 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 software of
> -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.
>
>
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
d
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
general
Original Message -
From: "Sean Turner"
To:
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 list email from m
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 RF
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
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 suc
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.
Ac
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 o
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' solu
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 publi
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
> nig
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 dev
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 m
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 ho
+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
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
> "Gonzalo" == Gonzalo Camarillo 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 know well are ha
[ 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 you
> From: Cameron Byrne
> 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
On Jul 28, 2011 1:08 AM, "Philip Homburg" 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 precisely that. P
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
> so
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 need
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
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 win
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 d
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 disclosure.
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
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 poin
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
>
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 that
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 r
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
https://www.ietf.org/mailman/l
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) ar
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 recen
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
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 t
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
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 ye
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
78 matches
Mail list logo
