On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli joe...@bogus.com wrote:
The queue for dicussion of this point is closed. If there needs to be an
appeal on this point now or in the future, then I'll be happy to help
someone write it, but I consider that dicussion settled for the purposes
of a
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote:
Having consent form all vendors is valuable but I'm afraid this is not the
goal of this document.
If not all vendors, then what about some vendors? Is it a goal of this
document to have consensus from some implementors? Or
On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.com wrote:
*
NEW:*
* *
NOTE WELL: This document is not a standard, and conformance with
it is not required in order to claim conformance with IETF
standards for IPv6. It uses the normative keywords
On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.com wrote:
I have considered that Lorenzo. “is not required to deploy IPv6” would be
accurate if this document is dealing only with dual-stack, but this is not
true for the IPv6-only mode. The set of SHOULD recommendations are
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote:
How can we ensure every implementers will agree with this list? For
instance we have two detailed technical reviewers
Are reviews still appropriate? I think there are a lot of things left to
say about this document beyond
On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.com wrote:
I really don’t see how you can have a phone that “make a phone that works
perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP
context
You don't need to support IPV4V6 if all you need to do is work on an
On Tue, Sep 10, 2013 at 8:12 PM, mohamed.boucad...@orange.com wrote:
*[Med] No. no, no the document indicates the language for each feature:
there are MUST, SHOULD, etc. This is not the first time a document makes
such classification of the features.*
Sorry - what I meant is: most of the text
On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland d...@cridland.net wrote:
I'm not sure the consensus requirement you're suggesting actually exists.
This is aiming at Informational, and as such:
An Informational specification is published for the general
information of the Internet
On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote:
The document explicitly says “This document is not a standard.” since
version -00.
** **
What additional statement you would like to see added?
I think the high-order points are:
1. The text This document defines an IPv6
On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.com wrote:
it is about ** a ** profile for mobile devices.
But wait... if it's just *a* profile, then why is the IETF publishing this
particular profile, and not any other profile? Is this an IETF recommended
profile? If, so then the
On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.com wrote:
**
But wait... if it's just *a* profile, then why is the IETF publishing this
particular profile, and not any other profile? Is this an IETF recommended
profile? If, so then the document should state why. If not, then the
On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.com wrote:
Ok. So maybe you can put in the draft that this profile is a profile
supported by several operators, but not necessarily endorsed by the IETF?
**
*[Med] The document followed the IETF procedures and was benefited from
the
On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.org wrote:
This document specifies an IPv6 profile for 3GPP mobile devices. It
lists the set of features a 3GPP mobile device is to be compliant
with to connect to an IPv6-only or dual-stack wireless network
On Thu, Feb 16, 2012 at 00:52, Livingood, Jason
jason_living...@cable.comcast.com wrote:
To be more specific, at least section 5.5 (it is unclear
how implementers will judge when the network conditions will have
changed sufficiently to justify turning off DNS Resolver Whitelisting
On Thu, Feb 9, 2012 at 00:36, Joel jaeggli joe...@bogus.com wrote:
Ops is not marketing.
And if I were looking for a marketing venue, a standards body that produces
ASCII text documents read by a handful of engineers would not be high on my
list. This is not about marketing.
If you're
On Sat, Feb 4, 2012 at 01:35, Fred Baker f...@cisco.com wrote:
The IESG again decided it needed a revised draft, and that draft - in
large part, a rewrite - arrived in October. v6ops had a second WGLC, in
which you again declined to comment, although you may have seen Lorenzo's
comments,
On Thu, Jul 28, 2011 at 01:30, james woodyatt j...@apple.com wrote:
http://www.pam2010.ethz.ch/papers/full-length/15.pdf
Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig
3); about 90% MacOS hits is 6to4, which possibly means (to me) that this
piece of 6to4 MacOS
On Thu, Jul 28, 2011 at 16:51, Michel Py mic...@arneill-py.sacramento.ca.us
wrote:
Clarification: in your stats, is AS12322's traffic classified as native
or as 6to4/teredo?
As the webpage says: The Total IPv6 graph shows IPv6 users with any type of
connectivity, while the Native IPv6 graph
On Wed, Jul 27, 2011 at 14:18, Keith Moore mo...@network-heretics.comwrote:
So essentially, the argument that 6to4 damages the Internet, is
tantamount to having multiple addresses for hosts damages the Internet.
*And this is an explicitly chosen architectural feature of IPv6.*
Having
I support this proposal, for the following reasons:
1. Google's public IPv6 adoption data [1] shows that from the perspective of
a website, 6to4 is a tiny and decreasing percentage of IPv6 clients.
2. Geoff Huston's data, presented at v6ops in Prague, shows that 6to4
failure rate when connecting
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote:
- In order for the new draft to be published, it must achieve both V6OPS WG
and IETF consensus
If anyone objects to this course of action, please speak up soon.
Great, back to square one.
Is the reasoning behind the
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
We know it can operate correctly and reliably if it
is configured correctly.
... and in networks where there are public IP addresses and no firewalling,
and... etc. etc.
But we already had
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.comwrote:
Is the reasoning behind the decision explained somewhere? My reading of
the threads on the subject in v6ops was that the opposition to 6to4-historic
was a small but vocal minority, and I thought that qualified as
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote:
I think there is pretty much complete consensus that i) 6to4 doesn't work
in several very common environments (behind a NAT, etc, etc), and that
therefore, ii) at the very least, it should be disabled by default (and
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.comwrote:
And who says that rough consensus of the entire IETF community is that
this draft should not be published? Were there public discussions to that
effect that came to this conclusion?
There's clearly a lack of
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
Declaring 6to4 to be historic might encourage native IPv6 deployment,
but I think it will also make trialing IPv6 much harder.
We don't need to trial the IPv6 protocol. There are hundreds of
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
I don't object to what has been proposed, yet I object to
6to4-historic because I'm an extremely happy anycast 6to4 user
It works for me, so there's obviously no problem. When you think of
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
I don't know if it is intentional, however if I use Google's public
8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4
(via /etc/gai.conf under Linux/glibc), it seems that the
On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrote:
That said, I would argue that most or all 6to4 traffic could just as well
use IPv4, since both parties to the communication obviously have access to a
public IPv4 address. What is the advantage of using 6to4 over
On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote:
... about 80% of the time.
Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's
*automatic* 6to4.
No, because you often end up being dependent on the whims of BGP and
third-party relays for your
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote:
Very few of the people using 6to4 in this way will show up in Google's user
behavior analysis, of course, because Google doesn't run its own 6to4
return-path relay as I-D.ietf-v6ops-6to4-advisory recommends.
We would not
On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote:
Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure
rate when connecting to dual-stack servers than Mac OS 10.6.5 - and
the
only change is to not use 6to4 by default.
...
So
On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt j...@apple.com wrote:
I don't want anybody to be misled by this statement. I think what Lorenzo
meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the
policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore mo...@network-heretics.comwrote:
Indeed, that is one of its main virtues. 6to4 decouples application
deployment of v6 from network deployment of v6, and helps reduce the
chicken or egg problem.
No, it does not - in fact, it is the opposite.
On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore mo...@network-heretics.comwrote:
Why are you trying to make life harder for developers of IPv6 applications?
There's no reason at all that an application developer should have to set
up a special-purpose network just to test an IPv6 application.
On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore mo...@network-heretics.comwrote:
Again, 40-something percent of the IPv6 traffic that is observed on the net
today uses 6to4.
Please point at the data behind that assertion. In many cases in the past,
such assertions have comes from networks that do
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.comwrote:
So the existence of 6to4 is in itself a significant barrier for IPv6
deployment for server operators and content providers.
non sequitur. Existing server operators and content providers can easily
provide 6to4
On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore mo...@network-heretics.comwrote:
I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP
then.
Seriously, the argument that 6to4 should be trashed because ISPs are
blocking tunnels has the flavor of don't solve the problem, but
On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that
the answer will be that much fewer users have configured tunnels than
6to4,
and that the failure rate is much lower.
Er, I'm
On Tue, May 31, 2011 at 6:17 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
While you have not contributed text per se (by sending it directly), I
try to be a good listener and items you and other Googlers have raised have
been included in the document around motivations and
On Mon, May 30, 2011 at 8:48 AM, Gert Doering g...@space.net wrote:
I have no idea what a v6 DNS ACL should be, except maybe an ACL that
protects which IPv6 clients are allowed to talk to a DNS server.
ACL is the wrong term. Saying it's an ACL makes it easy to make the argument
that whoever
On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli joe...@bogus.com wrote:
But you've contributed to this document, so have others from that list.
I don't want to contribute to the document because - in my opinion, and
speaking only for myself - I don't think it can be made into a balanced
42 matches
Mail list logo
