RE: IPv6 traffic distribution

[Michel Py]

> 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 and the same MTU
issues than 6to4 as the core mechanism is based on 6to4 tunneling, or
encapsulation, or whatever else you want to call it.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DKIM Signatures now being applied to IETF Email

[John R. Levine]

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 on 
your message.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

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% |   20 |  6.21% |   143702 | brian.e.carpen...@gmail.com
  4.75% |   16 |  5.58% |   129160 | mo...@network-heretics.com
  4.45% |   15 |  3.32% |76837 | mo...@necom830.hpcl.titech.ac.jp
  3.56% |   12 |  3.38% |78258 | i...@aliax.net
  2.08% |7 |  2.34% |54169 | cb.li...@gmail.com
  2.37% |8 |  1.83% |42401 | mic...@arneill-py.sacramento.ca.us
  1.78% |6 |  2.09% |48459 | evniki...@gmail.com
  2.08% |7 |  1.55% |35786 | m...@sap.com
  1.78% |6 |  1.65% |38072 | d...@cridland.net
  1.48% |5 |  1.74% |40327 | t...@ecs.soton.ac.uk
  1.19% |4 |  1.88% |43505 | lore...@google.com
  1.48% |5 |  1.57% |36246 | d...@dcrocker.net
  1.78% |6 |  1.21% |27925 | stpe...@stpeter.im
  1.48% |5 |  1.21% |27913 | s...@resistor.net
  1.48% |5 |  1.14% |26454 | m...@sandelman.ca
  1.19% |4 |  1.22% |28162 | daedu...@btconnect.com
  1.19% |4 |  1.02% |23714 | pch-i...@u-1.phicoh.com
  0.89% |3 |  1.26% |29124 | dendic...@gmail.com
  0.89% |3 |  1.08% |24873 | jer...@unfix.org
  0.89% |3 |  1.05% |24378 | alexandru.petre...@gmail.com
  0.89% |3 |  1.05% |24357 | j...@google.com
  1.19% |4 |  0.73% |16876 | j...@mercury.lcs.mit.edu
  0.89% |3 |  1.02% |23588 | field...@gbiv.com
  0.89% |3 |  0.99% |22885 | j...@apple.com
  0.89% |3 |  0.92% |21192 | rbon...@juniper.net
  0.89% |3 |  0.86% |19823 | kivi...@iki.fi
  0.89% |3 |  0.83% |19211 | hsan...@isdg.net
  0.89% |3 |  0.83% |19188 | eburge...@standardstrack.com
  0.59% |2 |  1.02% |23704 | lars.egg...@nokia.com
  0.89% |3 |  0.69% |15954 | amor...@amsl.com
  0.89% |3 |  0.65% |15017 | hannes.tschofe...@gmx.net
  0.59% |2 |  0.92% |21294 | br...@callenish.com
  0.59% |2 |  0.89% |20564 | marshall.euba...@gmail.com
  0.30% |1 |  1.16% |26786 | trej...@gmail.com
  0.59% |2 |  0.80% |18532 | lionel.mor...@orange-ftgroup.com
  0.59% |2 |  0.79% |18196 | sha...@juniper.net
  0.59% |2 |  0.68% |15710 | m...@cloudmark.com
  0.59% |2 |  0.67% |15446 | joe...@bogus.com
  0.59% |2 |  0.62% |14328 | carlb...@g11.org.uk
  0.59% |2 |  0.56% |13019 | dw...@cisco.com
  0.59% |2 |  0.54% |12493 | me...@globetel.com.ph
  0.59% |2 |  0.53% |12288 | rog...@gmail.com
  0.59% |2 |  0.52% |12019 | a...@anvilwalrusden.com
  0.59% |2 |  0.52% |11944 | gonzalo.camari...@ericsson.com
  0.59% |2 |  0.50% |11502 | despres.r...@laposte.net
  0.59% |2 |  0.49% |11451 | ves...@tana.it
  0.30% |1 |  0.79% |18300 | david.bl...@emc.com
  0.59% |2 |  0.49% |11251 | do...@mail-abuse.org
  0.59% |2 |  0.48% |11215 | scott.b...@gmail.com
  0.59% |2 |  0.48% |11106 | i.g...@comcast.net
  0.59% |2 |  0.47% |10921 | ggm+i...@apnic.net
  0.59% |2 |  0.47% |10805 | gr...@intalio.com
  0.59% |2 |  0.46% |10649 | war...@kumari.net
  0.59% |2 |  0.46% |10555 | samirs.li...@gmail.com
  0.59% |2 |  0.45% |10465 | pch-v6...@u-1.phicoh.com
  0.59% |2 |  0.45% |10402 | randy_pres...@mindspring.com
  0.30% |1 |  0.66% |15374 | kathleen.moria...@emc.com
  0.30% |1 |  0.56% |12865 | john_brzozow...@cable.comcast.com
  0.30% |1 |  0.52% |12030 | ted.i...@gmail.com
  0.30% |1 |  0.51% |11825 | phbern...@gmail.com
  0.30% |1 |  0.50% |11648 | thierry.er...@inria.fr
  0.30% |1 |  0.49% |11371 | yaronf.i...@gmail.com
  0.30% |1 |  0.43% |10027 | tramm...@tik.ee.ethz.ch
  0.30% |1 |  0.40% | 9213 | sprom...@unina.it
  0.30% |1 |  0.39% | 9121 | dhark...@lounge.org
  0.30% |1 |  0.38% | 8902 | o...@nlnetlabs.nl
  0.30% |1 |  0.38% | 8808 | gabriel.montene...@microsoft.com
  0.30% |1 |  0.38% | 8766 | nar...@us.ibm.com
  0.30% |1 |  0.37% | 8668 | rbar...@bbn.com
  0.30% |1 |  0.37% | 8647 | john.m...@monash.edu
  0.30% |1 |  0.37% | 8640 | rich...@shockey.us
  0.30% |1 |  0.35% | 7994 | sidialima...@yahoo.fr
  0.30% |1 |  0.33% | 7697 | j...@jlc.net
  0.30% |1 |  0.33% | 7677 | ted.le...@nominum.com
  0.30% |1 |  0.32% | 7451 | y...@checkpoint.com
  0.30% |1 |  0.32% | 7416 | paul.hoff...@vpnc.org
  0.30% |1 |  0.32% | 7336 | j...@wide.ad.jp
  0.30% |1 |  0.30% | 7039 | fred.l.temp...@boeing.com
  0.30% |1 |  0.30% | 6905 | d...@virtualized.org
  0.30% |1 |  0.30% | 6828 | dwor...@avaya.com
  0.30% |1 |  0.29% | 6769 | hous...@v

Re: IPv6 traffic distribution

[Joel Jaeggli]

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 list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Eric Burger]

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 be
> done. The main purpose of a BOF is to present. Information to the
> community so they can decide if the IETF should adopt the work.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Joel M. Halpern]

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 such evaluation would have to icnlude the various area reviews which 
occur during last call, but which are supported by the possibility of a 
discuss if they are ignored and the AD decides they matter.

Yes, I have a gut feel on the matter.  So does everyone in the discussion.

But you asked that we go beyond that.  How?

Yours,
Joel

On 7/28/2011 9:53 PM, 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 beyond cliche's and personal anecdotes into
consideration of tradeoffs. That is, I pointedly asked you /not/ to
repeat yourself.

Please engage in the substance of such balanced analysis comparing
benefits against costs. It's not as if that's an unusual approach for
evaluating expensive activities of questioned value...



Have you seen a pattern of having a Discuss cite the criterion that
justifies it? I haven't. It might be interesting to attempt an audit
of Discusses, against the criteria...


It might, and at the time when the IESG had a large backlog of unresolved
DISCUSSes and the current criteria were being developed (I'm talking
about 2005/2006), the IESG did indeed end up looking at all the old
DISCUSSes against the criteria, and held dedicated conference calls


I do not recall seeing this analysis made public. The point behind my
suggestion was to prmit transparent consideration of the use of Discuss.
So whatever was done, it was not transparent to the community.

Further, my suggestion was for /current/ patterns, not in the past.



to talk through many of those DISCUSSes and in many cases persuade the AD
concerned to drop them, or rewrite them in an actionable format. In my
recollection, Allison Mankin was the leader of the charge on this.

But these are all judgment calls, so I don't think there can be an
objective audit.


I don't recall requiring it to be "objective". In fact, audits are often
subjective. That's ok as long as:

a) the auditor gives thought to using reasonable criteria

b) the criteria are made public

c) they are applied consistently

Let's try to refrain from throwing up artificial barriers, as an excuse
not to hold the process accountable.



There could be an audit of how many DISCUSSes take
more than N months to clear, or something like that. There were tools
around for that some years ago, but I don't know if they exist for the
modern version of the tracker.


That's nice, but not all that useful. In contrast, looking at the
substance of Discusses against the criteria that are supposed to be used
for justifying them is directly relevant.

(Note that you replaced a focus on core substance and clear import, with
something superficial and with a very ambiguous semantic. In particular,
longer-vs-shorter holding times have no obvious implication about the
/appropriateness/ of the Discusses.)



Herein lies the real problem: As with many process and structure
discussions in the IETF, folk often see only a simplistic, binary choice
between whatever they prefer, versus something akin to chaos.

The world is more nuanced than that, and the choices more rich.

Here is a small counter-example to your sole alternatives of status quo
or rubber stamp:

Imagine a process which requires a range of reviews and requires
ADs to take note of the reviews and the community support-vs-objection.

Imagine that the job of the ADs is to assess these and to block
proposals that have had major, unresolved problems uncovered or that
lack support, and to approve ones that have support and lack known,
major deficiencies as documented by the reviews.


The only difference between that and what I see happening today is that
the ADs actually verify the reviews by looking at the drafts themselves.


You are factually wrong. AD's do their own reviews. ADs formulate their
own lists of issues and requirements. AD's assert them as the basis for
a Discuss.

They often do pay attention to other reviews -- sometimes quite
mechanically, rather than from an informed basis -- but the exemplar I
put forward is a fundamentally different model of AD behavior and
responsibility. I can't guess how you can misunderstand the difference.



And why do they do that? Because they aren't going to take the
responsibility for approving a document that they haven't read. Nobody
would, I hope.


Therein lies a core problem with the model: It hinges on personal
investment by the AD, and a lack of trust in the community process,
using the excuse that the process is not perfect, as if the AD's own
evaluation process is...

d/

__

Re: Why the IESG needs to review everything...

[Andrew Sullivan]

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 Requested called Review Requested,

I hereby propose that every single I-D adopted by every working group
go into Review Requested state.  Oh.  Right.

In my opinion, this thread would be a lot better motivated if we (and
I emphatically include myself) did a lot more review, and did it a lot
more carefully.  As a WG chair, I have faced a number of occasions in
which plain embarrassing flaws in documents made it past my own review
(which means "through WGLC") and up to the IESG.  As a participant, I
have noticed more than once that my failure to review something I
should have made it all the way to the IESG before someone said, "Uh,
hey, there's an issue."

Once frivolous DISCUSSes way outnumber serious ones, I'll feel like
there's a problem.  We're all busy, and by the grace of some power who
doesn't explain itself to me some employers are willing to subsidize
the Bulwark Panel of Final Review.  Given my own experience of what I
regard as mistaken or frivolous DISCUSSes, when every document has 5
or 6 really high quality reviews both in WGLC and IETF LC, I'll feel
that we can start throwing stones.  But today, not so much: most
DISCUSSes are in fact attempts to discuss unclear or -- sometimes --
seriously mistaken parts of drafts.  Maybe in others' corner of the
IETF it's different, but I feel that I need to pick up my end of the
log before telling other people to haul their end.

Best,

A
-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPv6 traffic distribution

[Michel Py]

> 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 the key. Validate the sample (the trace). To be
meaningful, that is. Collecting IPv6 stats somewhere close to someone
heavily involved in IPv6 deployment is meaningless. Among other things,
Tim's numbers. Tim, we have met a few times; as I recall, you are the
one who convinced me of the inevitability of IPv6 NAT. Your numbers are
meaningless; not because you don't collect them right or anything
involving your skills or competence, but because you're too close to the
problem. That's the geek syndrome.

IMHO, the only valid stats we can gather are either from a large content
provider (which is why Lorenzo's numbers are so interesting) or from a
large eyeball ISP. Cisco, Juniper, Apple, the academia, the IETF, etc
are NOT valid places to collect data.


> George Michaelson wrote:
> you may like to look at
> http://labs.apnic.net/dns-measurement/

Same remarks as above, plus I don't see there anything that separates
6rd.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [hybi] Last Call:

[Mark Andrews]

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
> > > > to the next address while continuing with the first.  If you have
> > > > more that 2 address you do something similar for the next one
> > > 
> > > Happy eyeballs means that a clients reaction to congestion is
> > > to perform an DoS attack, flood the network with additional
> > > connection requests and hammer the server with many additional
> > > half-open connections that will never actually get used.
> > 
> > It is not a DoS attack.  The client is almost certainly going to
> > make those connection attempts anyway if the path is congested
> > enough to cause the first connection attempt to fail.  The only
> > difference is the application gives up in 30 seconds rather than
> > 60 or 90 seconds by doing the attempts serially.
> 
> 150...250ms  ?!

Yes, that small.  For most people, most connections are "in country"
or "in continent" however there are always exceptions to this.
The times are driven by human delay tolerances.

> For a satellite link you already have started 3 parallel connects
> in non-congested(!) situations. 

Indeed.  However only one will have data sent over it.  The three
way handshake won't even complete for two of them in many cases.
For those that do complete the server won't be woken up in many
cases as no data gets sent.

> just some random IPv4 pings from my office (in germany)
> _without_congestion_:
> 
>ping  www.asus.com.tw300-380ms
>ping  south-america.pool.ntp.org 280-370ms
>ping  oceania.pool.ntp.org   340-420ms
>ping  www.eff.org160-170ms
>ping  www.ietf79.cn  330-450ms
>ping  www.ietf76.jp  270-370ms
> 
> So your approach is already hurting the network without congestion!

Only if you think a could of extra TCP connection attemps to servers
on the other side of the world is hurting the network. 
 
B.T.W. I'm well aware of speed of light issues.  Look at my signature.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re:

[Masataka Ohta]

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, because IPv6 was designed to be able to
handle multiple addresses properly with a single interface.

>> It would be so much easier if hosts on the public internet could
>> use one single IPv6 address that contains both, the IPv6 network prefix
>> and the IPv4 host address, and then let the network figure out whether
>> the connect goes through as IPv4 or IPv6 (for IPv6 clients).

> This is largely (not entirely)  achieved with nat64 / dns64.

Assuming NAT, we don't need IPv6.

Moreover, unlike nat64, nat44 can be fully transparent end to end.

So, why do we have to be bothered by 6to4?

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [hybi] Last Call:

[Martin Rex]

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 you do something similar for the next one
> > 
> > Happy eyeballs means that a clients reaction to congestion is
> > to perform an DoS attack, flood the network with additional
> > connection requests and hammer the server with many additional
> > half-open connections that will never actually get used.
> 
> It is not a DoS attack.  The client is almost certainly going to
> make those connection attempts anyway if the path is congested
> enough to cause the first connection attempt to fail.  The only
> difference is the application gives up in 30 seconds rather than
> 60 or 90 seconds by doing the attempts serially.

150...250ms  ?!

For a satellite link you already have started 3 parallel connects
in non-congested(!) situations. 

just some random IPv4 pings from my office (in germany)
_without_congestion_:

   ping  www.asus.com.tw300-380ms
   ping  south-america.pool.ntp.org 280-370ms
   ping  oceania.pool.ntp.org   340-420ms
   ping  www.eff.org160-170ms
   ping  www.ietf79.cn  330-450ms
   ping  www.ietf76.jp  270-370ms

So your approach is already hurting the network without congestion!

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Brian E Carpenter]

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 beyond cliche's and personal anecdotes into
> consideration of tradeoffs.  That is, I pointedly asked you /not/ to
> repeat yourself.
> 
> Please engage in the substance of such balanced analysis comparing
> benefits against costs.  It's not as if that's an unusual approach for
> evaluating expensive activities of questioned value...

May argument is that if we move the cost (that of final review prior
to committing the text to the RFC Editor), we do not remove the
problem (of the final review being exhaustive and time consuming),
unless we also lower the implied standard of quality.

To my mind it's implicit in RFC 3935 that the present quality standard
is not lowered - especially, that in addition to verifying that
a specification is valid in itself, we verify that it does not damage
other aspects of the Internet. That makes final review by a cross-area
team essential, and today that team is the IESG.

I wouldn't mind moving the responsibility to some other cross-area
team, but it seems like a zero-sum game to me.

> 
>>> Have you seen a pattern of having a Discuss cite the criterion that
>>> justifies it?  I haven't.  It might be interesting to attempt an audit
>>> of Discusses, against the criteria...
>>
>> It might, and at the time when the IESG had a large backlog of unresolved
>> DISCUSSes and the current criteria were being developed (I'm talking
>> about 2005/2006), the IESG did indeed end up looking at all the old
>> DISCUSSes against the criteria, and held dedicated conference calls
> 
> I do not recall seeing this analysis made public.

It was a dynamic process, but I wouldn't be surprised if Allison or
Bill Fenner or somebody did post data at some stage; but that's ancient
history now.

The point behind my
> suggestion was to prmit transparent consideration of the use of Discuss.
> So whatever was done, it was not transparent to the community.
> 
> Further, my suggestion was for /current/ patterns, not in the past.

And all the data is in the tracker these days; it's very easy to
find the DISCUSSes against any draft.

>> to talk through many of those DISCUSSes and in many cases persuade the AD
>> concerned to drop them, or rewrite them in an actionable format. In my
>> recollection, Allison Mankin was the leader of the charge on this.
>>
>> But these are all judgment calls, so I don't think there can be an
>> objective audit.
> 
> I don't recall requiring it to be "objective".  In fact, audits are
> often subjective.  That's ok as long as:
> 
>a) the auditor gives thought to using reasonable criteria
> 
>b) the criteria are made public
> 
>c) they are applied consistently

That is the judgment part.

> 
> Let's try to refrain from throwing up artificial barriers, as an excuse
> not to hold the process accountable.
> 
> 
>> There could be an audit of how many DISCUSSes take
>> more than N months to clear, or something like that. There were tools
>> around for that some years ago, but I don't know if they exist for the
>> modern version of the tracker.
> 
> That's nice, but not all that useful.  In contrast, looking at the
> substance of Discusses against the criteria that are supposed to be used
> for justifying them is directly relevant.
> 
> (Note that you replaced a focus on core substance and clear import, with
> something superficial and with a very ambiguous semantic.  In
> particular, longer-vs-shorter holding times have no obvious implication
> about the /appropriateness/ of the Discusses.)

I think that a long holding time clearly implies one of two causes:

1. A fumble by the shepherd; in fact it was to avoid this sort of problem that
   the shepherding process was carefully defined. Again, credit to Allison.

2. A failed dialogue between the DISCUSSing AD and the authors and/or WG.
   I would assert that most of those are due to non-actionable DISCUSSes.
   There was a lot of analysis of real cases of serious delay behind the
   section on "DISCUSS non-criteria" in
   http://www.ietf.org/iesg/statement/discuss-criteria.html

The fact that we're having this conversation several years later
tells me that human nature hasn't changed much recently. ADs *do*
need to look at those criteria and it's absolutely in order for the
community to complain when they don't.

>>> Herein lies the real problem:  As with many process and structure
>>> discussions in the IETF, folk often see only a simplistic, binary choice
>>> between whatever they prefer, versus something akin to chaos.
>>>
>>> The world is more nuanced than that, and the choices more rich.
>>>
>>> Here is a small counter-example to your sole alternatives of status quo
>>> or rubber stamp:
>>>
>>>   Imagine a process

Re: IPv6 traffic distribution

[Keith Moore]

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 observation, and explains why operators really need
> to try to run a decent 6to4 relay service as long as so many
> such clients are observed. Which is why disabling 6to4 in clients
> has to be the priority; it's far too soon to decommission the
> relays.

Actually, it's why making hosts prefer IPv4 over 6to4 is the priority.   
There's absolutely nothing wrong with using 6to4 if it's the best connectivity 
to the destination that you have.

Also,  this isn't a contest, we're on the same team, and we shouldn't be 
competing against one another.  The entire purpose of 6to4 is to allow people 
to use IPv6 before they have native IPv6 connectivity, because we recognize 
that the latter is in some cases very difficult to achieve end-to-end and faces 
numerous barriers that vary from one situation to the next.  That's why we have 
so many technologies for layering IPv6 over IPv4.

IOW, 6to4's purpose is to be a gateway drug for native IPv6.   And it can serve 
that purpose even if at any given time only 1% are using it.  The main thing is 
to make sure that people who do try 6to4 find it attractive enough that they 
want to upgrade to native IPv6.   That means not using 6to4 in cases where it 
will degrade performance compared to what people get already with IPv4, but it 
doesn't mean disabling 6to4 entirely.  It also means that DoS attacks on 6to4 
are counterproductive.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Kevin's second byte question

[Brian E Carpenter]

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 reserved, but without
> conclusion.

Nevertheless, the words in RFC 2474 don't say that. They say that
DS Field refers to the entire octet, including the (then unused)
ECN bits.

We knew ECN was coming when this was published.

Brian
> 
> 
> 
> On Jul 28, 2011, at 16:58, Brian E Carpenter
>  wrote:
> 
>> 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 referred to as ECN ("ECN field" according to RFC 3168).  Same 
>>> applies for what was formerly the IPv6 traffic class byte.
>>>
>>> That said, RFC 3260 is Informational, yet claims to update standards-track 
>>> RFCs 2474 and 2597.  I'm not quite sure what sort of status that
>>> leaves us with. [?]
>> It can't. That claim shouldn't have been published IMHO. (And yes, I was 
>> co-chair
>> of the diffserv WG at the time). However, it invokes BCP 37 = RFC 2780
>> which is normative, so probably supersedes RFC 2474. 2780 doesn't answer your
>> question though, since it refers to the 6-bit DS field and not to the whole
>> byte or octet except as "superseded".
>>
>> I think you will need to add a complicated footnote on this.
>>
>> On 2011-07-29 01:10, Thomson, Martin wrote:
>>
>>> 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.
>> Good one :-)
>>
>>Brian
>>
>>
>>
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Scott Brim]

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 decide if the IETF should adopt the work.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re:

[Cameron Byrne]

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 systems. To make the end to end principle
> >effectively work, the end systems must have all the available
> >knowledge to make decisions by the end systems themselves.
> >
> >With regard to multihoming, when an end system want to communicate
> >with a multihomed end system, the end system must be able to select
> >most appropriate (based on the local information) destination address
> >of the multihomed end system.
>
>
> 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 would be so much easier if hosts on the public internet could
> use one single IPv6 address that contains both, the IPv6 network prefix
> and the IPv4 host address, and then let the network figure out whether
> the connect goes through as IPv4 or IPv6 (for IPv6 clients).
>

This is largely (not entirely)  achieved with nat64 / dns64.

Cb.
> -Martin
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Dave CROCKER]

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 
consideration of tradeoffs.  That is, I pointedly asked you /not/ to repeat 
yourself.


Please engage in the substance of such balanced analysis comparing benefits 
against costs.  It's not as if that's an unusual approach for evaluating 
expensive activities of questioned value...




Have you seen a pattern of having a Discuss cite the criterion that
justifies it?  I haven't.  It might be interesting to attempt an audit
of Discusses, against the criteria...


It might, and at the time when the IESG had a large backlog of unresolved
DISCUSSes and the current criteria were being developed (I'm talking
about 2005/2006), the IESG did indeed end up looking at all the old
DISCUSSes against the criteria, and held dedicated conference calls


I do not recall seeing this analysis made public.  The point behind my 
suggestion was to prmit transparent consideration of the use of Discuss. So 
whatever was done, it was not transparent to the community.


Further, my suggestion was for /current/ patterns, not in the past.



to talk through many of those DISCUSSes and in many cases persuade the AD
concerned to drop them, or rewrite them in an actionable format. In my
recollection, Allison Mankin was the leader of the charge on this.

But these are all judgment calls, so I don't think there can be an
objective audit.


I don't recall requiring it to be "objective".  In fact, audits are often 
subjective.  That's ok as long as:


   a) the auditor gives thought to using reasonable criteria

   b) the criteria are made public

   c) they are applied consistently

Let's try to refrain from throwing up artificial barriers, as an excuse not to 
hold the process accountable.




There could be an audit of how many DISCUSSes take
more than N months to clear, or something like that. There were tools
around for that some years ago, but I don't know if they exist for the
modern version of the tracker.


That's nice, but not all that useful.  In contrast, looking at the substance of 
Discusses against the criteria that are supposed to be used for justifying them 
is directly relevant.


(Note that you replaced a focus on core substance and clear import, with 
something superficial and with a very ambiguous semantic.  In particular, 
longer-vs-shorter holding times have no obvious implication about the 
/appropriateness/ of the Discusses.)




Herein lies the real problem:  As with many process and structure
discussions in the IETF, folk often see only a simplistic, binary choice
between whatever they prefer, versus something akin to chaos.

The world is more nuanced than that, and the choices more rich.

Here is a small counter-example to your sole alternatives of status quo
or rubber stamp:

  Imagine a process which requires a range of reviews and requires
ADs to take note of the reviews and the community support-vs-objection.

  Imagine that the job of the ADs is to assess these and to block
proposals that have had major, unresolved problems uncovered or that
lack support, and to approve ones that have support and lack known,
major deficiencies as documented by the reviews.


The only difference between that and what I see happening today is that
the ADs actually verify the reviews by looking at the drafts themselves.


You are factually wrong.  AD's do their own reviews.  ADs formulate their own 
lists of issues and requirements.  AD's assert them as the basis for a Discuss.


They often do pay attention to other reviews -- sometimes quite mechanically, 
rather than from an informed basis -- but the exemplar I put forward is a 
fundamentally different model of AD behavior and responsibility.  I can't guess 
how you can misunderstand the difference.




And why do they do that? Because they aren't going to take the
responsibility for approving a document that they haven't read. Nobody
would, I hope.


Therein lies a core problem with the model:  It hinges on personal investment by 
the AD, and a lack of trust in the community process, using the excuse that the 
process is not perfect, as if the AD's own evaluation process is...


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Kevin's second byte question

[Scott Brim]

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, 2011, at 16:58, Brian E Carpenter
 wrote:

> 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 referred to as ECN ("ECN field" according to RFC 3168).  Same 
>> applies for what was formerly the IPv6 traffic class byte.
>>
>> That said, RFC 3260 is Informational, yet claims to update standards-track 
>> RFCs 2474 and 2597.  I'm not quite sure what sort of status that
>> leaves us with. [?]
>
> It can't. That claim shouldn't have been published IMHO. (And yes, I was 
> co-chair
> of the diffserv WG at the time). However, it invokes BCP 37 = RFC 2780
> which is normative, so probably supersedes RFC 2474. 2780 doesn't answer your
> question though, since it refers to the 6-bit DS field and not to the whole
> byte or octet except as "superseded".
>
> I think you will need to add a complicated footnote on this.
>
> On 2011-07-29 01:10, Thomson, Martin wrote:
>
>> 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.
>
> Good one :-)
>
>Brian
>
>
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[George Michaelson]

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

Re: "6to4 damages the Internet" (was Re:

[Martin Rex]

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 systems must have all the available
>knowledge to make decisions by the end systems themselves.
> 
>With regard to multihoming, when an end system want to communicate
>with a multihomed end system, the end system must be able to select
>most appropriate (based on the local information) destination address
>of the multihomed end system.


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 would be so much easier if hosts on the public internet could
use one single IPv6 address that contains both, the IPv6 network prefix
and the IPv4 host address, and then let the network figure out whether
the connect goes through as IPv4 or IPv6 (for IPv6 clients).

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[SM]

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 the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by
   the Internet Engineering Steering Group (IESG)."

Although it is, by definition, correct until RFC 2026 is updated, RFC 
5741 is currently being used for the boilerplate in RFCs.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[Brian E Carpenter]

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 decent 6to4 relay service as long as so many
such clients are observed. Which is why disabling 6to4 in clients
has to be the priority; it's far too soon to decommission the
relays.

Regards
   Brian Carpenter

On 2011-07-29 09:12, Tim Chown wrote:
> 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 logs of the most recent flows 
> attempting to traverse our enterprise border and this showed:
> 
> 2002::/16 (6to4):
> Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 
> 
> 2001::/32 (Teredo):
> Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M
> 
> Other:
> Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M
> 
> Teredo appears skewed by one host's behaviour which I'll be looking into, 
> otherwise it's about what I'd expect with around 1% by volume being 6to4.
> 
> Tim
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Brian E Carpenter]

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 consensus or recommendation.  [...]
> 
> The above is incorrect.

Er, no. By definition, it's correct until we update RFC 2026.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Brian E Carpenter]

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 criterion that
> justifies it?  I haven't.  It might be interesting to attempt an audit
> of Discusses, against the criteria...

It might, and at the time when the IESG had a large backlog of unresolved
DISCUSSes and the current criteria were being developed (I'm talking
about 2005/2006), the IESG did indeed end up looking at all the old
DISCUSSes against the criteria, and held dedicated conference calls
to talk through many of those DISCUSSes and in many cases persuade the AD
concerned to drop them, or rewrite them in an actionable format. In my
recollection, Allison Mankin was the leader of the charge on this.

But these are all judgment calls, so I don't think there can be an
objective audit. There could be an audit of how many DISCUSSes take
more than N months to clear, or something like that. There were tools
around for that some years ago, but I don't know if they exist for the
modern version of the tracker.

>>> It well might be true that omitting the AD reviews would increase the
>>> number. By how much?  To what effect?
>>
>> Hard to tell. But it would amount to giving the IESG secretary a large
>> rubber stamp *unless* the final responsibility was explicitly moved
>> elsewhere.
> 
> Herein lies the real problem:  As with many process and structure
> discussions in the IETF, folk often see only a simplistic, binary choice
> between whatever they prefer, versus something akin to chaos.
> 
> The world is more nuanced than that, and the choices more rich.
> 
> Here is a small counter-example to your sole alternatives of status quo
> or rubber stamp:
> 
>  Imagine a process which requires a range of reviews and requires
> ADs to take note of the reviews and the community support-vs-objection.
> 
>  Imagine that the job of the ADs is to assess these and to block
> proposals that have had major, unresolved problems uncovered or that
> lack support, and to approve ones that have support and lack known,
> major deficiencies as documented by the reviews.

The only difference between that and what I see happening today is that
the ADs actually verify the reviews by looking at the drafts themselves.
And why do they do that? Because they aren't going to take the
responsibility for approving a document that they haven't read. Nobody
would, I hope.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Marshall Eubanks]

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 previous work in the IETF or some other SDO.

Regards
Marshall


> 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
> >> 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 responsible ADs need to request larger rooms
> > for BoFs. After the REPUTE BOF, I talked with the Secretariat
> > (specifically Wanda Lo, who does an amazing job with the schedule!)
> > about poking the chairs and ADs when they request BoF rooms to make sure
> > that we don't assign small rooms to BoFs, at least without careful
> > consideration.
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Reminder: Remote Participation Support for Admin Plenary Tonight

[Hadriel Kaplan]

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 quality, the 
meetecho HTML5 recordings had the video, audio, presentation slides and jabber 
all synchronized and I could skip forward forward/back for all of those which 
was sweet.

Then when I found out they were doing this on their own dime without IETF 
paying for it, I was shocked.

Kudos to them.

-hadriel


On Jul 27, 2011, at 8:53 PM, Brian E Carpenter wrote:

> Thanks Alexa!
> 
> And certainly the Meetecho service has its value - although those of us
> on the end of a very long, thin glass fibre in the South Pacific may
> not be able to get the full benefit.
> 
> Regards
>   Brian Carpenter
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Mark Nottingham]

... 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:
> 
>> 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 responsible ADs need to request larger rooms
>> for BoFs. After the REPUTE BOF, I talked with the Secretariat
>> (specifically Wanda Lo, who does an amazing job with the schedule!)
>> about poking the chairs and ADs when they request BoF rooms to make sure
>> that we don't assign small rooms to BoFs, at least without careful
>> consideration.
>> 
>> Peter
>> 
>> -- 
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

--
Mark Nottingham   http://www.mnot.net/



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Eric Burger]

+$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
>> 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 responsible ADs need to request larger rooms
> for BoFs. After the REPUTE BOF, I talked with the Secretariat
> (specifically Wanda Lo, who does an amazing job with the schedule!)
> about poking the chairs and ADs when they request BoF rooms to make sure
> that we don't assign small rooms to BoFs, at least without careful
> consideration.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Brian E Carpenter]

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 baby step forward, and as such is worthwhile doing.
>> We are more closely aligning our documentation with our organizational
>> running code. All other things being equal, that's a good thing.
> 
> Hmm.  I've long believed that :
> 
> - trying to document existing practice
> - trying to document desirable practice
> 
> are both worthwhile endeavors, as long as you don't try to do both at the 
> same time.  When you try to do both at the same time, there is a conflict.
> 
> If someone wants to write a document that says we generally follow RFC 2026, 
> except that:

Been there, done that, it sank like a stone.

Let's just make this baby step and stop worrying about it.

   Brian

> - drafts hardly ever advance to Draft Standard and even more rarely to Full 
> Standard, unless there is significant use of the protocol and there are bugs 
> that need to be fixed (in which case the ability to advance can sometimes 
> serve as an incentive of sorts)
> - we have never been serious about periodic review of standards and we don't 
> have enough time/energy to do that
> - we've never really nailed down what Historic meant, and when it was 
> appropriate to use it
> 
> etc.
> 
> that would be a fine thing.
> 
> And real changes to the process, say to bring in formal cross review earlier, 
> to clarify the nature of community consensus and the need for it, etc. might 
> also be a fine thing.  Unfortunately, such discussions are always contentious 
> and difficult, because they affect the whole community, but they also attract 
> a lot of interests from individuals with particularly unique axes to grind.  
> So we keep trying to fix the substantive problems with incremental changes.  
> I forget who it was who said yesterday that we can't really do that, but I 
> certainly agree with him.
> 
> Meanwhile, it's not clear to me that simply changing from one document that 
> we don't strictly follow, to another document that we won't follow much 
> better, is helpful.  And I don't think IETF's problems with standards quality 
> or process can be addressed merely by changes to the number of maturity 
> levels.  That strikes me as a bit like rearranging deck chairs...it might 
> make people feel better but is of little consequence.
> 
> 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.  And yet we keep flogging this 
> idea...
> 
> Keith
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

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 every host a
> complete copy of the DFZ routing table...

With RFC2374, DFZ of IPv6 has at most 8192 entries.

> That still would leave a lot of issues open...
> 1) End-to-end latency. Maybe some future generation BGP provides that, but
> that doesn't help now.

Your requirement can be fair, only with a routing protocol
supporting latency based routing for *an* address with
*multiple* paths to its destination.

There is no point to have a latency based selection of
multiple paths to the destination, only if the destination
has multiple addresses.

> 2) For 6to4, the use of anycase. You probably need a link-state routing
> protocol to allow a host to figure out which relays are going to be used 
> on
> a give path.

With anycast, you can use only a single relay. Instead, you can
compare metrics between IPv4 and IPv6 addresses of a host.

> 3) Filters in firewalls. I'd love to see a routing protocol that reports the
> settings of all firewalls in the world :-)

Are you saying filtering of firewalls can be disabled by proper
address selection?

> 4) Other performance metrics, like jitter, packets loss, etc.

See 1).

> Maybe you can do some experiments and report on how well your draft works for
> deciding when to prefer a 6to4 address over IPv4.

A problem is that there is no point to stick to IPv6 broken
so much.

But, it's not my problem.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPv6 traffic distribution

[Michel Py]

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 connectivity, while the Native
> IPv6 graph excludes users using 6to4 or Teredo".

How is 6rd traffic classified? as native or as 6to4/teredo?
I expect that the bulk of traffic from AS12322 is 6rd.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[Tim Chown]

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 logs of the most recent flows 
attempting to traverse our enterprise border and this showed:

2002::/16 (6to4):
Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 

2001::/32 (Teredo):
Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M

Other:
Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M

Teredo appears skewed by one host's behaviour which I'll be looking into, 
otherwise it's about what I'd expect with around 1% by volume being 6to4.

Tim___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[Lorenzo Colitti]

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
Teredo".
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Kevin's second byte question

[Brian E Carpenter]

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 referred to as ECN ("ECN field" according to RFC 3168).  Same 
> applies for what was formerly the IPv6 traffic class byte.
> 
> That said, RFC 3260 is Informational, yet claims to update standards-track 
> RFCs 2474 and 2597.  I'm not quite sure what sort of status that
> leaves us with. [?]

It can't. That claim shouldn't have been published IMHO. (And yes, I was 
co-chair
of the diffserv WG at the time). However, it invokes BCP 37 = RFC 2780
which is normative, so probably supersedes RFC 2474. 2780 doesn't answer your
question though, since it refers to the 6-bit DS field and not to the whole
byte or octet except as "superseded".

I think you will need to add a complicated footnote on this.

On 2011-07-29 01:10, Thomson, Martin wrote:

> 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.

Good one :-)

Brian




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPv6 traffic distribution

[Michel Py]

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://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Peter Saint-Andre]

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 responsible ADs need to request larger rooms
for BoFs. After the REPUTE BOF, I talked with the Secretariat
(specifically Wanda Lo, who does an amazing job with the schedule!)
about poking the chairs and ADs when they request BoF rooms to make sure
that we don't assign small rooms to BoFs, at least without careful
consideration.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: On attending BoFs

[Barry Leiba]

> 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 attention, I want them there.
Lots of people don't know whether they're going to commit to doing
work until the end of the BoF, after they've heard all the stuff about
problem statement, work scope, and proposed work items.

I'd rather just make sure we have rooms that are big enough, and leave
it at that.  BoFs tend to be artificially busy because people like
those tchotchkes -- people are interested in seeing what the new
proposals are about.  Let's not discourage that, but feed it.

Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[Lorenzo Colitti]

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 yours represents a third of global IPv6
> > traffic.
> >
> > Would you care to comment on the numbers?
>
> p1.  Those numbers are badly outdated.
>

Speaking as one of the authors of that paper: correct, the numbers are badly
outdated. You can find the more recent numbers resulting from those
measurements at:

http://www.google.com/intl/en/ipv6/statistics/

You will see that 6to4 now accounts for approximately 10% of total IPv6
traffic as measured using that methodology, and is steadily declining
(modulo seasonal variations like the French going on holiday).
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: On attending BoFs

[Dan Wing]

> -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 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 determine the level of commitment to do the work,
> which includes things like counting people willing to review and
> comment on documents, people willing to act as editors, potential
> implementers, and perhaps potential co-chairs.
> 
> 
> 
> 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.  As a result, the BoF room is packed.  But when it's packed
> with what have come to be known as "tourists", those people that could
> be counted as committed to the work can't even get into the room, which
> jeopardizes the creation of an otherwise viable working group.  I
> suspect I can safely say Dave Crocker would categorize this as an
> unintentional denial-of-service attack on the new work.
> 
> 
> 
> And it's certainly not friendly to the work that's trying to get
> started by filling a seat in a room "because it's warm."
> 
> 
> 
> Perhaps in the future this should be mentioned to BoF attendees before
> the meeting really gets going.  I certainly plan to do so for future
> BoFs that I run or at which I present.

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.

BoFs are IETF's tchotchkes.  People like new things.  As an example,
Homenet is a new WG (not a BoF), and was well attended (every seat
filled, people sitting on the floor, and standing).

Let's just assign large enough rooms to BoFs and newly-formed WGs
so that the work can start in earnest.

-d


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

On attending BoFs

[Murray S. Kucherawy]

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 
determine the level of commitment to do the work, which includes things like 
counting people willing to review and comment on documents, people willing to 
act as editors, potential implementers, and perhaps potential co-chairs.

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.  As a 
result, the BoF room is packed.  But when it's packed with what have come to be 
known as "tourists", those people that could be counted as committed to the 
work can't even get into the room, which jeopardizes the creation of an 
otherwise viable working group.  I suspect I can safely say Dave Crocker would 
categorize this as an unintentional denial-of-service attack on the new work.

And it's certainly not friendly to the work that's trying to get started by 
filling a seat in a room "because it's warm."

Perhaps in the future this should be mentioned to BoF attendees before the 
meeting really gets going.  I certainly plan to do so for future BoFs that I 
run or at which I present.

Thanks,
-MSK
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Mykyta Yevstifeyev]

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 advice is useful.


The document says:


RFC 2026 [1] requires a report
that documents interoperability between at least two implementations
from different code bases as an interim step ("Draft Standard")
before a specification can be advanced further to the third and final
maturity level ("Standard") based on widespread deployment and use.
In contrast, this document measures interoperability through
widespread deployment of multiple implementations from different code
bases, thus condensing the two separate metrics into one.


which implies that no requirement for interoperability reports is set.  
RFC 5735 defines what the implementation report is; so I think retaining 
RFC 5735 as BCP will create confusion, as it will define procedures for 
the issue which no longer exists.





It should be
obsoleted and moved to Historic by your document, if IESG decides to
eliminate the requirement for interoperability documentation, which I am
opposed to (see my LC comments to -06).

I see no reason to move RFC 5657 to Historic.


See above.




Another issue is STD numbers.  Mentioning that they are still assigned
to ISs in Section 2.2 should be fine.

The STD issue is orthogonal.


Also, Section 3.3:


 (2) At any time after two years from the approval of this document as
 a BCP, the IESG may choose to reclassify any Draft Standard
 document as Proposed Standard.

Won't such action be allowed after 2 years from approval?

That's what the text says, no?


Yes, I misunderstood the statement.  I thought that before 2 years come, 
DS->PS may be OK while after these 2 years this won't be OK, while it's 
vice versa.


Mykyta



Peter



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DKIM Signatures now being applied to IETF Email

[t.petch]

 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 mailman.
> >
> >
> > I'll be presumptuous and speak on behalf of the DKIM operations
> > community, rather than just myself:
> >
> > Cool! Thanks.
>
> +1 to that!

-100

The minor point is that e-mails have just got yet bigger.  They are now 100-150%
bigger than when first I started following the IETF and it is not that people
have more to say, but that the junk at the front has expanded out of all
recognition.  This costs, transmission time, processing storage etc.  The
transmission time is significant (I imagine) because of POP3 which seems to take
2n+ messages, n round trips, before starting to download anything out of n
e-mails.

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.

Tom Petch

> Personally, I like it when we eat our own dog food ;)
>
> spt
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Kevin's second byte question

[Kevin Fall]

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 3168).  Same 
applies for what was formerly the IPv6 traffic class byte.

That said, RFC 3260 is Informational, yet claims to update standards-track RFCs 
2474 and 2597.  I'm not quite sure what sort of status that
leaves us with. [?]

(normally this wouldn't really concern me all that much, but I'm writing some 
introductory material and want to ensure the proper current terminology is 
being used.  The thing that caused me to really notice this was RFC 6145... esp 
section 5.1).

thx,
- K


On Jul 27, 2011, at Jul 273:03 PMPDT, Brian E Carpenter wrote:

> The second byte in an IPv4 header is called the Differentiated Services Field.
> 
> Quoting RFC 2474:
> 
> 2.  Terminology Used in This Document
> ...
>   Differentiated Services Field: the IPv4 header TOS octet or the IPv6
>   Traffic Class octet when interpreted in conformance with the
>   definition given in this document.  Also DS field.
> 
> It's a historical accident that the ECN bits were shoehorned into this octet.
> 
> -- 
> Regards
>   Brian Carpenter
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Nico Williams]

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

Re: [v6ops] 6to4v2 (as in ripv2)?

[Gert Doering]

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 sucked into this again).

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Tero Kivinen]

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.

Actually there is currently only one draft, draft-shin-augmented-pake,
which follows my negotiation process. The
draft-harkins-ipsecme-spsk-auth author did say he is going to change
his draft, but the draft is not yet there, and then there is
draft-kuegler-ipsecme-pace-ikev2 (which you are co-author) which is
doing negotiation differently and I do not know whether that is going
to change to use same way than others.

> I believe the other justifications for this draft, including the
> preservation of IANA IKEv2 namespaces, are bogus.

As an IANA Expert for the registries in question I strongly disagree.

If you want to delay this fight to the IANA allocation time, that is
fine by me, but I will point it out already now that I will be against
allocating separate code points for each protocol as there is no need
for that.

> Adopting the rest of the framework would be a useless exercise.

Keeping the IANA registries clean is important for me, in addition to
make it easy to implement multiple methods in the same implementation.
I do not consider them as useless resons. Especially as it only causes
very small changes to the actual protocol drafts (I would expect less
than an one hour of work).
-- 
kivi...@iki.fi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Tero Kivinen]

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.
> 
> Is this true? Because each has it's own way to negotiate its use,
> one should be able to implement multiple of the competing proposals
> as-is, yes? 

Before I proposed my common way to negotiate only one of the proposed
protocols included any kind of support for indicating which version is
used. The other two just assumed that initiator selects the method and
responder supports it without any negotiation, meaning there was no
way to make initiator version which supports multiple methods without
trying the first method, if that failed, then starting IKE_SA_INIT
from the beginning and trying second method etc...

This has already been changing as one of the drafts is already changed
to support what I have described in my draft, and another author
has said he will update his. The third one already had negotiation
altough done bit differently to compared what I proposed.

As an implementor I myself I want to keep this problem concentrated in
my code, meaning I do not want to make three completely differently
done implementations for the same thing, when I can instead make
generic changes to common code once, and separate the secure password
method related processing in one module taking care as any methods
needed to be implemented.

> > At least this drafts gives you that option to implement multiple of
> > them if you want. This draft only provides instructions for those
> > other draft authors so they can at least common methods to negotiate
> > the feature and use common method to trasmit data between peers.
> 
> True, but it is still punting the problem of us having just one.

Yes, but there is nothing I can do to that. I cannot fix the problem
that all 3 drafts were sent forward and most likely will be published.
If someone will decided only one of them will go forward (and there
will not be any other ever) then my draft will be mostly unneeded as
all of my draft can be put inside that one protocol draft going
forward just like draft-shin-augmented-pake has already done.

If there is no need to make sure multiple drafts make the negotiation
and common payload things similarly as there is only one draft, then
this draft is not needed.

I am also the IANA expert for the IKEv2 registries, and that was the
main reason I wanted to have common way to do things instead of doing
dozen new allocations to the registries just to support 3 bit
different ways to do same thing (when 3 allocations is enough). I
wanted to point this out to the draft authors as early as possible, so
it will not come as suprise to the authors that I do not support their
way of allocating that many codepoints from the registries.
-- 
kivi...@iki.fi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

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' solution to the problems that they are solving.

As such there tend to be a combo of:
 - static proto-41 tunnel
 - 6to4
 - 6rd
 - TSP => dynamic NATted addresses
 - proto-41 + heartbeat + TIC => dynamic public addresses
 - AYIYA + TIC => dynamic NATted addresses

TSP conveys configurartion information inline with the UDP packets.
TIC is solely for configuration information and does not do tunneling
but can be used for all proto-41/heartbeat/AYIYA protocols (and for
instance AVM chose to only do proto-41 + heartbeat as their devices
always have public IPv4 IPs).

Teredo is only for a single host thus is not useful for CPEs and thus
not included in them.

> One of the advantages of 6to4 anycast is that it is just needs a
> check box to turn on and off.  Everybody speaks the same thing.

Except that it does not work behind a NAT and most people do sit behind
a NAT.

Next to that those anycasts are even rarer around the world and on top
of that it is hard to figure out issues when they are there (although
some people have tricks to apparently debug them, the anycast on both
IPv4 and IPv6 requires one to contact a lot of folks).

The big advantage over a known tunnel endpoint is the known behavior of
that endpoint and the simple way of complaining when something is
broken. And people fortunately do complain when stuff is broken,
unfortunately not always with the proper details though, but I am to
blame for not finishing that program up...

> Another advantage of 6to4 is it doesn't require manual intervention
> on renumber events.  Manual tunnel don't pass muster.

I guess you are one of the lucky people to get a public static IPv4
address prefix at home that never renumbers? Guess what, most of the
world does not have that luxury, they get 1 dynamic address and for
instance in Germany they get a disconnect/force-renumber every 24 hours
(according to the ISPs because of 'accounting' reasons...)

Do realize that when you have that public IPv4 address, when it changes
you are renumbering your 2002:::/48 prefix everywhere. Fun...
(I hope you also like asking 6to4.nro.net everytime to change your reverse)

The tunnels above all have ISP-supplied prefixes and tend to be static
(I think TSP anonymous tunnels rotate addresses, but the majority just
keeps on returning the same static allocation, in the case of SixXS you
really get a fixed address, much easier on the PoP side and we can do
whois and store it in the relevant RIR registry)

> Another advantage of 6to4 is you don't have to register.  For most of
> the tunnel brokers you have to register.

I guess you also where able to anonymously sign up to your IPv4 ISP!? :)
Especially that static IPv4 address must be wonderful to get that way.

Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away.

Something with the amounts of abuse made us (SixXS) require that we
require valid address data. Next to that it is a RIPE requirement to
register /48 prefixes. Other Tunnelbrokers just started blocking things
like IRC and NNTP because there was too much abuse or traffic
We kill off accounts of people when they abuse, google my name and you
will find various people who where caught in the act and are quite mad
that they can't have funny vhosts on IRC anymore and attract 500mbit
DoSses and other such nonsense which are not the goal of providing IPv6.

Also, the registration means that people can just type in their
username/password (and optionally which tunnel they want to use out of
the multiple tunnels they might have) in their CPE and the CPE then uses
TIC or TSP to fetch this configuration and set it all up, and it will
just work(tm).

As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg
and
http://www.sixxs.net/wiki/Fritz!Box_7270

Next to that knowing where the user is and more importantly their
endpoint allows one to select a proper PoP for that user close to their
endpoint causing low latency and generally high throughput.

With anycast you are just hoping that that all will work.

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Philip Homburg]

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 a phase-out plan so that the
> current users of 6to4 can have fair warning before the relays go
> dark and forthcoming hardware/software upgrades rip the feature
> out from under them.

I would hope that big companies like Apple would actually do an impact
analysis before removing a feature. 

Big content providers can measure how much 6to4 is enabled, so they can
probably say something about trends. But that doesn't say much about how many
users actually care about 6to4. Vendors seem to be best equiped to analyse 
the users' need for 6to4.

I don't think relay operators have expressed a desire for a specific cut off 
date. So I guess they just figure out for themselves when to switch off the
relays.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Tero Kivinen]

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 for developers: since you can't know what method the peer
> will support, you have to implement all of them.  

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.

At least this drafts gives you that option to implement multiple of
them if you want. This draft only provides instructions for those
other draft authors so they can at least common methods to negotiate
the feature and use common method to trasmit data between peers.
-- 
kivi...@iki.fi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

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 and use new IPv6-specific 
>> apps, then either a broker or something like OpenWRT ought to meet their 
>> needs?
> 
> tunnel brokers suck if the tunnel endpoint isn't near your current network 
> location.

Let me rewrite that sentence for you:

 "transition mechanisms suck if the tunnel endpoint isn't near your
current network location"

It does not matter much if that mechanism is static proto-41 (6in4),
6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a
bit more latency if they are not directly next to you. Not much you can
do about except deploy more of them or

And this will always be the case unless you deploy enough of them in all
places possible. For SixXS we are at 48 boxes around the world,
Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and
then there are 4 others at other organizations and there are a couple of
other services out there which provide tunnels see:

 http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

> there are currently no universally applicable, or even widely applicable, 
> v6-over-v4 solutions.

For your set of requirements maybe but especially Tunnel Brokers are
working very well for a lot of people and if one sees the traffic stats
on Teredo and 6to4 nodes due to this little thing called NNTP I would
state that those are doing quite fine too for giving access to what
people need to get to.

Your major requirement seems to involve latency though, thus as such,
there is only one thing to do, get one of those boxes deployed locally
to your endpoint.

Do note to yourself that the next issue you will run into that the
service you are actually contacting will be far away, and you suddenly
understand that you need that Akamai content box and a Google one and
various other closeby too ;)

If you want to solve your problem though, I guess for HE you'll have to
give them connectivity to their network and space in a rack for a box,
gogo6 will sell you a box and for SixXS you provide the box+connectivity
and we'll set up the software for free for you and handle the tunneling
completely.

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard

[Willy Tarreau]

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 server.
> >>
> >> Happy eyeballs however does allow you to take a server out of  
> >production
> >> and not really notice it.  Note webbrowsers have had the ability  
> >to do
> >> this for as long as webbrowsers have existed.
> >
> >Mark, could you elaborate on this point ? Surely you're not talking  
> >about
> >the fact that a browser retries a failed connection, but I'm not  
> >not sure
> >what mechanism you're talking about.
> 
> Happy eyeballs - try everything as soon as you can, in parallel. Drop  
> everything else when one does.

This sensibly increases load on servers with useless connections, and
is counter-efficient in mobile networks where sending uplink packets
is the limiting factor !

Willy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Jeroen Massar]

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 hopefully soon I will
be releasing the next edition of AICCU which solves, at least in that
implementation, a couple of quirks that we have encountered in the
recent years.

> Please name
> CPE vendors that support tsp?  Please name CPE vendors that support
> tunnel re-configuration on re-number.

I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA
in some cases there are a variety of vendors, amongst which AVM
Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget
;) I unfortunately do not have an exact list of devices/models as I had
nothing to do with them, we just get users saying that they have a
device which supports it ;)

The fun part though with CPEs is that they tend to sit on the public IP
address, which is also the reason why the Fritz!Box only does TIC/heartbeat.

And of course every self respecting distribtion has support for it too
by just adding AICCU, that includes the various WRTs, pfSense, m0nowall,
Astaro and many many others.

As you said, everybody can decide themselves what options they add ;)

Greets,
 Jeroen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Lou Berger]

+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 performing a valuable and un-fun
> function...
> ...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Why the IESG needs to review everything...

[Murray S. Kucherawy]

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 can be annoying, I don't agree that the spurious DISCUSS 
problem is all that bad as long as the AD doing so is responsive to being 
called on it (and, as Barry mentioned during plenary, that's improved a lot 
lately).  There are only 15 people that can DISCUSS a document, but those of us 
producing broken documents seriously outnumber them.

Part of the problem with spurious DISCUSSes is psychological, and that's for a 
different conversation.  My only other remark there is that ADs could sometimes 
avoid a lot of heartache for themselves and their working groups with an 
inquisitive email prior to DISCUSSing something.
 
I have heard more than once during this meeting some hallway track chatter 
about ADs wishing they had invoked their available review resources 
(apps-review, the various directorates, etc.) earlier in the process.  So 
perhaps what's needed is an optional document state prior to Publication 
Requested called Review Requested, which triggers an early, informal review 
action by the AD and/or her/his review team prior to the formal start of the 
publication process.  Working group chairs would have to understand that it's 
an expensive request (i.e., not to be used frivolously), but still cheaper than 
letting a real disaster of a draft get up to the AD or the full IESG.

-MSK
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Reminder: Remote Participation Support for Admin Plenary Tonight

[Michael Richardson]

> "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 harder to recognise.

Gonzalo> one aspect to consider is that long play-out buffers
Gonzalo> increase the audio quality but also increase the
Gonzalo> delay. Many people have complained about not being able to
Gonzalo> effectively participate in the meetings remotely using the

huh? the major delay is the line up at the microphone, not the TCP
queue.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Warren Kumari]

[ 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…

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 performing a valuable and un-fun function...

Climbing off soapbox,
W


On Jul 27, 2011, at 6:12 PM, Brian E Carpenter wrote:

> Responding to Glen Zorn's question in plenary:
> 
> Firstly, not all ADs review all drafts - that's why you will see
> numerous "no objection" or missing ballot responses.
> 
> Secondly, the drafts are de facto reviewed by review teams
> these days (gen-art, security area, etc.). This serves to alert
> the ADs if a draft really needs careful review. The workload is
> more reasonable than it used to be.
> 
> Thirdly, when I was in the IESG, I was surprised quite often by
> *glaring* errors that had not been picked up before. Somebody has
> to be responsible for catching these, and today it's the IESG.
> 
> Fourthly, because of the exact same discussion that Glen raised in
> plenary, the IESG defined and published its criteria for DISCUSS
> several years ago. Sometimes there are inappropriate DISCUSSes
> and those need to be pointed out when they happen.
> 
> I hear the IESG members responding exactly right to this question.
> 
> -- 
> Regards
>   Brian Carpenter
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Noel Chiappa]

> 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Cameron Byrne]

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.  Please please please, if IETF
> > wants 6to4 to die, then publish a phase-out plan so that the
> > current users of 6to4 can have fair warning before the relays go
> > dark and forthcoming hardware/software upgrades rip the feature
> > out from under them.
>
> I would hope that big companies like Apple would actually do an impact
> analysis before removing a feature.
>

Like how Apple does not support Flash in iOS?

Just one example where a visionary drops an inferior solution to force a
better one.

This is also known as cracking some eggs to make an omelet.

Cb

> Big content providers can measure how much 6to4 is enabled, so they can
> probably say something about trends. But that doesn't say much about how
many
> users actually care about 6to4. Vendors seem to be best equiped to analyse
> the users' need for 6to4.
>
> I don't think relay operators have expressed a desire for a specific cut
off
> date. So I guess they just figure out for themselves when to switch off
the
> relays.
>
>
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Standards and patents

[Eric Burger]

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
> solution to carry unnecessary burden. e.g. I 'GUESS' pains of htonl
> etc are due to patents. IMHO we need to free human brain & cpu for
> more important issues. It is not fair for people who work on
> unpatented baselines specifications. What would have been situation if
> IP header was patented? Thx Samir
> 
> 
> On 7/27/11, Alessandro Vesely  wrote:
>> On 27/Jul/11 08:07, Samir Srivastava wrote:
>>> Standards are developed by community & for community. There is no
>>> role of patent hunters in that.
>> 
>> I agree, with the exception of "defensive" patents, some of which are
>> announced with very elegant disclosures.  Let's draw a veil over
>> incomprehensible and confused disclosures, for now.  For the rest,
>> what is the purpose of standardizing a private walled garden?
>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Standards and patents

[Samir Srivastava]

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 to free human brain & cpu for
more important issues. It is not fair for people who work on
unpatented baselines specifications. What would have been situation if
IP header was patented? Thx Samir


On 7/27/11, Alessandro Vesely  wrote:
> On 27/Jul/11 08:07, Samir Srivastava wrote:
>> Standards are developed by community & for community. There is no
>> role of patent hunters in that.
>
> I agree, with the exception of "defensive" patents, some of which are
> announced with very elegant disclosures.  Let's draw a veil over
> incomprehensible and confused disclosures, for now.  For the rest,
> what is the purpose of standardizing a private walled garden?
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Peter Saint-Andre]

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.

It would be good to start talking about the tough issues, but IMHO there
is some value in settling on two maturity levels as well.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 PCP demo in room 2000 D

[IETF Chair]

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 winner to shown 
up, if the person cannot be connected, a runner-up drawn at the same time will 
get the prize.

Good luck,
Russ


-Original Message-
From: 81all-boun...@ietf.org [mailto:81all-boun...@ietf.org] On Behalf Of 
xiaohong.d...@orange-ftgroup.com
Sent: Sunday, July 24, 2011 9:26 PM
To: adur...@juniper.net; 81...@ietf.org
Subject: Re: [81all] IPv6 PCP demo in room 2000 D

It will be a joint demo by ISC (software based), and Huawei -FT (device
based) on Monday and Wednesday morning.

FT-Huawei device based demo will be on site during the whole meeting
week, so you can drop by anytime at your convenience.

Our prize iPad 2, sponsored by Huawei, is ready now. Are you the lucky
winner? ;)

Xiaohong


> Hi folks,
> 
> During IETF 81, please come and see the Port Control 
> Protocol (PCP) demonstration in Room 2000 D. 
> 
> Leave your name and contact information by the Thursday 
> afternoon break to be entered into a drawing for an iPad 2. 
> Russ Housley will draw the winner during the break.
> 
> Check it out on our website at: http://130.129.48.23:35328/ 
>  . The lucky winner will be 
> announced on our Web site! 
> 
> Good Luck! 
> 
> Xiaohong Deng
> (xiaohong.d...@orange-ftgroup.com)

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Keith Moore]

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.
> 
> We are more closely aligning our documentation with our organizational
> running code. All other things being equal, that's a good thing.

Hmm.  I've long believed that :

- trying to document existing practice
- trying to document desirable practice

are both worthwhile endeavors, as long as you don't try to do both at the same 
time.  When you try to do both at the same time, there is a conflict.

If someone wants to write a document that says we generally follow RFC 2026, 
except that:

- drafts hardly ever advance to Draft Standard and even more rarely to Full 
Standard, unless there is significant use of the protocol and there are bugs 
that need to be fixed (in which case the ability to advance can sometimes serve 
as an incentive of sorts)
- we have never been serious about periodic review of standards and we don't 
have enough time/energy to do that
- we've never really nailed down what Historic meant, and when it was 
appropriate to use it

etc.

that would be a fine thing.

And real changes to the process, say to bring in formal cross review earlier, 
to clarify the nature of community consensus and the need for it, etc. might 
also be a fine thing.  Unfortunately, such discussions are always contentious 
and difficult, because they affect the whole community, but they also attract a 
lot of interests from individuals with particularly unique axes to grind.  So 
we keep trying to fix the substantive problems with incremental changes.  I 
forget who it was who said yesterday that we can't really do that, but I 
certainly agree with him.

Meanwhile, it's not clear to me that simply changing from one document that we 
don't strictly follow, to another document that we won't follow much better, is 
helpful.  And I don't think IETF's problems with standards quality or process 
can be addressed merely by changes to the number of maturity levels.  That 
strikes me as a bit like rearranging deck chairs...it might make people feel 
better but is of little consequence.

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.  And yet we keep flogging this 
idea...

Keith




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Concerns about the recent IPR Statement from Alcatel Lucent Related to RFC 6073

[Russ Housley]

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.  A 
"non-assert" license to all patents held by Alcatel Lucent necessary to 
implement RFC 6073 is available if requested before the end of 2011.  License 
to these same patents will be available after the end of the year with the 
possibility of a royalty or fee. 

Russ

On Jun 2, 2011, at 10:06 AM, Russ Housley wrote:

> I do not find any IPR disclosures against draft-ietf-pwe3-segmented-pw, the 
> Internet-Draft that became RFC 6073.  As a result, I am very concerned by the 
> extremely late notice of patents by Alcatel Lucent, especially since RFC 6073 
> and the patent have a common author.  This fact makes it very clear that 
> Alcatel Lucent was aware of the work that produced RFC 6073. This is clearly 
> a breach of IETF IPR policy as described in BCP 79.
> 
> Yesterday, I wrote to Alcatel Lucent about their recent IPR statement, and 
> asked them to consider a revised IPR disclosure to correct this situation.
> 
> I received a response today.  Alcatel Lucent confirmed that they take their 
> standards obligations very seriously.  They are investigating the situation, 
> and they promised to respond to my message soon.  I will report further when 
> I receive that response.
> 
> Russ
> 
> 
> On May 31, 2011, at 12:37 PM, IETF Secretariat wrote:
> 
>> Dear Mustapha Aissaoui, Florin Balus, Matthew Bocci, Michael Duckett, Luca 
>> Martini, Chris Metz, Thomas Nadeau:
>> 
>> An IPR disclosure that pertains to your RFC entitled "Segmented Pseudowire"
>> (RFC6073) was submitted to the IETF Secretariat on 2011-05-26 and has 
>> been posted on the "IETF Page of Intellectual Property Rights Disclosures"
>> (https://datatracker.ietf.org/ipr/1566/). The title of the IPR 
>> disclosure is "Alcatel Lucent's Statement of IPR Related to RFC 
>> 6073."");
>> 
>> The IETF Secretariat

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Peter Saint-Andre]

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 organizational
running code. All other things being equal, that's a good thing. That
doesn't imply that all of our organizatioal running code is bug-free. We
could have a broader conversation about the latter, but IMHO that's
outside the scope of this baby step forward.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Eric Burger]

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 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  communities that are serious 
> about producing and 
> refining protocols will be producing these reports anyhow.
> 
> RjS
> 
> On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:
> 
>> 
>> 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 the effort needed to
>> advance documents
>> 
>> 2/ one of the big issues with the PS->DS step is understanding what
>> documentation is needed to show that there are the interoperable
>> implementations and to list the unused features - it would help a lot to
>> provide some guidance (which I did not do in 2026 - as I have been
>> reminded a number of times :-) ) as to just what process is to be
>> followed
>> 
>> could be
>>  a spread sheet showing features & implementations
>>  an assertion by the person proposing the advancement that the
>> requirements have been met
>> or something in between
>> 
>> Scott
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Peter Saint-Andre]

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
> obsoleted and moved to Historic by your document, if IESG decides to
> eliminate the requirement for interoperability documentation, which I am
> opposed to (see my LC comments to -06).

I see no reason to move RFC 5657 to Historic.

> Another issue is STD numbers.  Mentioning that they are still assigned
> to ISs in Section 2.2 should be fine.

The STD issue is orthogonal.

> Also, Section 3.3:
> 
>> (2) At any time after two years from the approval of this document as
>> a BCP, the IESG may choose to reclassify any Draft Standard
>> document as Proposed Standard.
> 
> Won't such action be allowed after 2 years from approval?

That's what the text says, no?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Robert Sparks]

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  communities that are serious 
about producing and 
refining protocols will be producing these reports anyhow.

RjS

On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

> 
> 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 the effort needed to
> advance documents
> 
> 2/ one of the big issues with the PS->DS step is understanding what
> documentation is needed to show that there are the interoperable
> implementations and to list the unused features - it would help a lot to
> provide some guidance (which I did not do in 2026 - as I have been
> reminded a number of times :-) ) as to just what process is to be
> followed
> 
> could be
>   a spread sheet showing features & implementations
>   an assertion by the person proposing the advancement that the
> requirements have been met
> or something in between
> 
> Scott
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[Dave CROCKER]

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 real burden on people, and the discussion was 
about the actual burden.  The claim that ADs are expected to read all 
submissions has been consistent for some years, from many different folk 
including ADs.




I certainly never like ballotting NO OBJECTION unless I had at least
skimmed the draft and read at least one positive review. I'm sure I
never ballotted YES without a careful reading.


On matters of human behavior, one of the continuing challenges in the IETF is 
the pervasive tendency for a sole speaker to cite their own behavior as if it 
were representative of a broader population.  (The formal term is "sampling 
error", I believe.)


There is a basic difference between a single exemplar versus the aggregated 
behavior of a population.  The former is useful to demonstrate an existence 
proof, such as an exception.  It says nothing about the behavior of others in a 
group.


In other words Brian, you are a great guy.  You were diligent, reasonable and 
balanced when you held these positions and asserted your authority.  No one 
should consider criticizing any aspect of how you did the job.


Forgive me, but none of that matters for this discussion.  Your own behavior, 
back then, is irrelevant to this discussion, since no one said that all ADs have 
always behaved a certain way.


What is relevant is the /current/ demands on ADs.



Is all of this effort justified if exactly one minor error is found each
year? Two?  One major?  What is that /actual/ improvement that this
process produces?  What thresholds should apply?


It depends on what you mean by minor or major, but my experience as an
author is that I get valuable comments from the IESG that definitely
improve the document, even after all the comments one gets from
WGLC and IETF LC and the various review teams.


Brian, you missed the point motivating my questions:  I'm suggesting that 
demanding the retention of massive demands on ADs and the imposition of 
significant procedural burden on working groups and authors warrant analysis.


Do the analysis, please.  Make it balanced. Look at pros and cons.  Answer your 
own question, while formulating a serious case for a situation that creates 
chronic problems.  The complaints about the current arrangement are not new or 
isolated.  Unfortunately, the defense of the arrangement is typically in the 
style you are giving.


Besides the skewed perspective -- oh, we caught one error, two years ago, so 
it's worth burdening everyone all the time -- the perspective ignores two key 
points, observed by many folk:


   1.  We have many sources of reviews; the reviewing capabilities of an AD are 
likely to be good, but not better than many others.


   2.  In spite of all the wonderful reviewing done by ADs, errors still get 
through; so the fact that some ADs, sometimes, might catch an important error 
ignores all the others they miss.


Again, Brian:

   Offer a cost/benefit formula and then factor in the known, considerable, 
current costs and demonstrate that we are deriving the requisite benefit.  Try 
to explore real-world behaviors, rather than theoretical hopes.




Why? My guess is that it's because that the buck stops with the IESG - and


Except that it doesn't stop with the IESG.  (Actually, I don't really know what 
it means to claim it stops with the IESG, and I suspect there are valid claims 
that it stops in a variety of other places.)  Many conditions and actions, over 
a long period of time, are required to make a specification succeed.


It might be interesting for you to document examples of repercussions on the 
IESG for having approved a terrible specification.


At the least, please explain what your assertion means, exactly, and then 
explain what the repercussions are on the IESG when they make the egregious 
error of letting a serious error get published.


This sort of discussion calls for restraint from using comforting, Trumanesque 
catch-phrases.


There is, indeed, a current model that places the personal assessments of ADs on 
a pedestal of power.  It invites mere mortals to work under the myth that they, 
alone, carry the burden of keeping the Internet safe from bogus technologies. 
It's a silly myth, but it's the one that currently in force.


 A more tractable model is that ADs need a manageable workload and a modest 
set of responsibilities, balancing what is demanded of them with the practical 
benefit it provides and the costs to them (and us) that are incurred.


 Further, the model needs to be comfortable with having everyone make lots 
of errors, in spite of their being diligent.




that automatically makes people more conscientious. Everybody else can
; the f

RE: Kevin's second byte question

[Thomson, Martin]

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/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

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 systems. To make the end to end principle
>   effectively work, the end systems must have all the available
>   knowledge to make decisions by the end systems themselves.
>
>   With regard to multihoming, when an end system want to communicate
>   with a multihomed end system, the end system must be able to select
>   most appropriate (based on the local information) destination address
>   of the multihomed end system.
>
>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 every host a
complete copy of the DFZ routing table... That still would leave a lot of
issues open...
1) End-to-end latency. Maybe some future generation BGP provides that, but
   that doesn't help now.
2) For 6to4, the use of anycase. You probably need a link-state routing 
   protocol to allow a host to figure out which relays are going to be used on
   a give path.
3) Filters in firewalls. I'd love to see a routing protocol that reports the
   settings of all firewalls in the world :-)
4) Other performance metrics, like jitter, packets loss, etc.

Maybe you can do some experiments and report on how well your draft works for
deciding when to prefer a 6to4 address over IPv4.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

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
> been citing a different example of the same problem:  Imagine a
> future where hosts on a network have both v6 and legacy v4 through
> stateful NAT.  Because the v6 connection works well most of the
> time, hosts tend to choose v6 destinations, and sites reduce the
> capacity of their NATs over time.  Then the v6 connection fails,
> and suddenly everything falls back to v4, and the connections
> through NAT also fail for lack of sufficient capacity to handle
> the load.

I'm sure some manager will just require this to work. But I would say that
this is just supposed to fail.

If you had in the past just an IPv4 connection and it went down, there would
be no Internet access. Same thing in the future. If your IPv6 connection goes
down you don't have an Internet conenction.

It would be different if the NAT was there just to connect to a very specific
collection of legacy IPv4 sites. But that can be solved easily but just
routing those IPv4 prefixes to the NAT. 

If you want the NAT to provide full redundancy, then it has to be scaled to
accept full load. Otherwise, no IPv6 just means no Internet. Very simple.

> > We want large scale deployment of IPv6 today not some time in the future
> > when we finally figured out address selection. And that means that today we
> > have to make sure that users don't end up with unreliable IPv6 connections.
> 
> If you make the constraint that nobody can use IPv6 at all until
> the IPv6 connections work as well in all cases as the IPv4 connections,
> that creates a huge barrier to the universal deployment of IPv6 -
> which already has enough barriers as it is.

To some extent that is exactly the way it is. 

Suppose that a significant fraction of popular websites would have IPv6
addresses that don't actually work. Then essentially no ISP would enable IPv6
for their customers because their customers would suffer.

At the moment, most servers that do have IPv6 addresses seem to actually
support IPv6 so this doesn't seem to be a big problem.

But we don't know what the future might bring. If there would be a sudden
rush of servers that have PMTU problems, then we could have a very serious
problem. 

> A less onerous constraint is that less reliable IPv6 connections
> don't get used in preference to more reliable IPv4 connections.
> We're lucky in the case of 6to4 in that it has a well-known prefix
> that allows the traffic to be distinguished from other v6 traffic.
> But it's still necessary to manage expectations about IPv4 as a
> fallback path.

Happy Eyeballs can solve a lot of problems where a connection will fail
completely or have a high latency. But HE support is far from universal and
so far experience is limited to TCP.

But it doesn't do anything for PMTU problems. 

It also doesn't do anything for real-time streaming applications.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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 the effort needed to
advance documents

2/ one of the big issues with the PS->DS step is understanding what
documentation is needed to show that there are the interoperable
implementations and to list the unused features - it would help a lot to
provide some guidance (which I did not do in 2026 - as I have been
reminded a number of times :-) ) as to just what process is to be
followed

could be
a spread sheet showing features & implementations
an assertion by the person proposing the advancement that the
requirements have been met
or something in between

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Keith Moore]

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 'proper' address
> selection. It would be nice if 5 or 10 years ago there would have been a good
> standard to do address selection. Today, we are just in the stage of doing
> more experiments.
> 
> There is one thing that works well. And that is, you only assign global
> IPv6 addresses to a host if global IPv6 connectivity is at least as good as
> IPv4 connectivity.

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 been citing a 
different example of the same problem:  Imagine a future where hosts on a 
network have both v6 and legacy v4 through stateful NAT.  Because the v6 
connection works well most of the time, hosts tend to choose v6 destinations, 
and sites reduce the capacity of their NATs over time.  Then the v6 connection 
fails, and suddenly everything falls back to v4, and the connections through 
NAT also fail for lack of sufficient capacity to handle the load.

Note that in some sense this is a perceptual problem.   If instead of a v4 and 
a v6 address, each of those hosts had two v6 addresses and two different egress 
paths, the network engineers would be more likely to understand that both 
external connections needed to be of equal capacity - just like multihomed v4 
networks with a single prefix now.   And in some sense there's nothing wrong 
with having a v6 connection for most things and a small v4 NAT for connecting 
to legacy v4 services, as long as you don't think of the v4 path as a fallback 
- you're willing to accept that loss of the v6 connection is for practical 
purposes loss of external connectivity.   The problem is that if you think of 
the v4 NAT as a fallback for the v6 service, AND you don't drastically 
overprovision the NAT.

> We want large scale deployment of IPv6 today not some time in the future
> when we finally figured out address selection. And that means that today we
> have to make sure that users don't end up with unreliable IPv6 connections.

If you make the constraint that nobody can use IPv6 at all until the IPv6 
connections work as well in all cases as the IPv4 connections, that creates a 
huge barrier to the universal deployment of IPv6 - which already has enough 
barriers as it is.  

A less onerous constraint is that less reliable IPv6 connections don't get used 
in preference to more reliable IPv4 connections.  We're lucky in the case of 
6to4 in that it has a well-known prefix that allows the traffic to be 
distinguished from other v6 traffic.   But it's still necessary to manage 
expectations about IPv4 as a fallback path.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

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 wrote:

   End systems (hosts) are end systems. To make the end to end principle
   effectively work, the end systems must have all the available
   knowledge to make decisions by the end systems themselves.

   With regard to multihoming, when an end system want to communicate
   with a multihomed end system, the end system must be able to select
   most appropriate (based on the local information) destination address
   of the multihomed end system.

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.

The approach is totally against node/router separation of IPv6 to
make routers, the intermediate systems, a lot more intelligent
than nodes, the end systems, which is partly why IPv6 is hopeless.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

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 years ago there would have been a good
standard to do address selection. Today, we are just in the stage of doing
more experiments.

There is one thing that works well. And that is, you only assign global
IPv6 addresses to a host if global IPv6 connectivity is at least as good as
IPv4 connectivity.

We want large scale deployment of IPv6 today not some time in the future
when we finally figured out address selection. And that means that today we
have to make sure that users don't end up with unreliable IPv6 connections.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IESG needs to review everything...

[SM]

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 above is incorrect.

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf