on the technical merits of this draft remain unchanged from the last
time I offered them here, and I am basically in agreement with Lorenzo. This
draft seems unnecessary to me.
--
james woodyatt j...@apple.com
core os networking
* products that support a 6to4 tunnel router feature, that too is
unlikely ever to happen. (Note well: we don't comment publicly about the
features of unreleased products.)
Shorter james: this draft is a bad idea; please don't publish it.
--
james woodyatt j...@apple.com
member of technical staff
to
recount any of the stories I know about various famous technology sector
executives and their unhappy encounters with the laws of physics.]
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
code on the
Internet.
Shorter james: +1 for switching to TAI.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Nov 28, 2011, at 13:25 , Ronald Bonica wrote:
[…] I will submit the draft to the full IESG for its consideration at its
December 1 teleconference. The draft will be published as a BCP if a
sufficient number of IESG members ballot Yes or No Objection, and if no
IESG member ballots
On Dec 2, 2011, at 13:15 , Victor Kuarsingh wrote:
[…] I would like to point out that PMT has worked in a large production
network with much success (as ugly as one may think it is). The reality is
that it works, and works well […]
In order to retain a semblance of professional composure,
and forthcoming hardware/software upgrades rip the feature
out from under them.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
. Let me know if that changes anything noticeably
to the better for you. (On the plus side, it should spare you from suffering
any indignity at the hands of a 6to4-PMT service.)
--
james woodyatt j...@apple.com
member of technical staff, core os networking
of
destruction.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
up for a standard phase-out plan? Don't we want 6to4 users
to have any advanced notice that we plan to break their Internet? Or, is the
idea that we don't believe we can achieve a tactical victory over 6to4 users
unless we mount a surprise attack on them?
--
james woodyatt j...@apple.com
Keith Moore's proposal to reclassify RFC 3056
and RFC 3068 as Experimental.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to cut off from the Internet just yet.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
provocation at all. There is nothing about NAT or dynamic subscriber IP
assignment that provides any mitigation whatsoever of the risks entailed by
living in a regime like that.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
finally remove 2002::/16 from the default
policy table in the next revision of RFC 3484 on the grounds that 6to4 is
Historic now, just like 3ffe::/16 is... that would be *excellent*.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
forever. Because
it works for some people with legacy gear and they don't want to change.
Thanks ever so much, IESG!
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
-path relay as I-D.ietf-v6ops-6to4-advisory recommends.
The way to find these people is to crawl the BitTorrent networks. What's that
old maxim? You can't test what you don't measure. Do you measure the
BitTorrent networks?
--
james woodyatt j...@apple.com
member of technical staff, core os
10.6.4 and earlier will treat 6to4 prefixes
equivalently to any other IPv6 prefix when making address selection decisions.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https
On Jun 9, 2011, at 18:47 , Masataka Ohta wrote:
james woodyatt wrote:
I need *native* IPv6 into my home in San Francisco for my day job,
Really?
Very very very few people have day jobs that require native IPv6 service to
their home network today.
I'm an exception because I have
is inconsistent with the consensus in IETF that a
phase-out plan for 6to4 is unwarranted.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
-D.ietf-v6ops-6to4-to-historic
does.
In fact, I-D.ietf-v6ops-6to4-to-historic makes a more aggressive point on the
first item, and sends, at best, a very mixed message about the second.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
that we're not the target audience for the RFC. The draft
that matters is the companion advisory draft. It would be nice if the
6to4-to-historic draft could be spiked so as not to distract from its
companion, but I don't see that as a likely outcome. Alas and alack.
--
james woodyatt j
.
A couple days later, I heard back from the support person. We have no plans
to offer native IPv6.
Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations
have a working return path route to 2002::/16, i.e. they are complying with
I-D.ietf-v6ops-6to4-advisory now.
--
james
precedent.
I see no reason for IETF to avoid setting standards for layer-9 protocols.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
it.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
resources rather than serving them to the public DNS
horizon.
--
james woodyatt j...@apple.com
member of technical staff, core os networking
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
amplification. There are
probably other ways-- *better* ways-- but that's the historically proven way of
doing it.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https
-- while there are, today, more people than ever before taking
what are perceived to be enormous risks actually making the v4-v6 transition
start to happen?
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
managers, each with their own existential crises
officially assigned as my drop-everything ship-or-die top priority.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https
of merely Experimental nature...
BE IT HEREBY RESOLVED that IETF should create a new document category for
Disinformation, and that RFC 2516 should immediately and with extreme prejudice
be reclassified as such without further discussion.
--
james woodyatt j...@apple.com
member of technical staff
. Faster, please.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
they are open-source fits
into this picture.
Compared to the previous two issues, this one is just not so much
important.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
that discussion out of scope while we get on with talking about
archival formats: there is no reason to believe that expanding our
archival formats would further limit our future options for adopting
new working languages. (I'm thinking centuries into the future here.)
--
james woodyatt
. (Being an unpublishable wanker myself
still, I'm speaking from experience *and* close observation of my
peers.)
Shorter james: I'll need to be convinced that perception is fair
before I can join in the pillorying of our I-D submissions system
maintainers.
--
james woodyatt j...@apple.com
that I'd prefer to
observe from a very, very safe distance, i.e. one measured in parsecs.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
that. This message is about editorial process.)
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
feedback IETF participants can provide, and I can assure
everyone here that nobody at Apple feels their employment status
entitles them to any special consideration for their individual
contributions.
--
james woodyatt j...@apple.com
member of technical staff, communications engineering
of NAT66 have any
proposals for extending DNS appropriately to support the architecture
that NAT66 implies?
Do we really want to open the can of worms that multiple global DNS
horizons represents? I should hope not.
--
james woodyatt [EMAIL PROTECTED]
member of technical staff
with their
timely visa application to U.S. authorities? If so, then that might
be something worth investigating.
--
james woodyatt [EMAIL PROTECTED]
member of technical staff, communications engineering
___
Ietf mailing list
Ietf@ietf.org
https
On Wednesday, Jun 18, 2003, at 12:51 US/Pacific, Keith Moore wrote:
[I wrote:]
When customers of retail Internet service start demanding a NAT
standard, then that's when the IETF might want to think about
documenting the standard that the market seems to want.
here's the only thing that a NAT
everyone--
Here's a silly idea: let's try adding an option for hashcash to APEX.
(Or has someone already done that?)
If the problem with hashcash is that worms can steal CPU cycles to
generate hashcash, then let's attack the problem of worms separately
from the problem of spam suppression.
On Tuesday, Jun 10, 2003, at 22:12 US/Pacific, [EMAIL PROTECTED]
wrote:
[...]
There's a *large* number of people still in the 386 world, who are
financially unable to upgrade. That same hashcash request that will
not inconvenience my hardware will probably kill their box for the
better part of
friends--
As a statement of ideology, I generally like RFC 3271. However, I *do*
have a criticism to contribute... (I know. I should have known about
the draft and contributed my comments sooner.)
Vinton Cerf writes in RFC 3271:
Internet is for everyone - but it won't be if we are not
On Monday, April 15, 2002, at 10:34 PM, Harald Tveit Alvestrand wrote:
[...] I'd like to hear the IETF community's input on the topic. [...]
This is a matter of politics, philosophy and economics (PPE). Asking
engineers to comment on such things is nice-- we're so often left out of
such
On Friday, April 5, 2002, at 08:42 AM, [EMAIL PROTECTED] wrote:
[I wrote:]
Also, I think it would be helpful to know how commonly twice-NAT is
deployed, but I don't have any data there.
I believe (at least) twice-NAT is fairly common. I have a NATting router
between by cable access
On Friday, April 5, 2002, at 01:49 PM, Bill Strahm wrote:
[...] I believe AOL for one does this and it wouldn't surprise me if
most of the large cable providers do something silly like this at the
low end (You can always pay more for a real IP address)
I have also received several reports
On Thursday, April 4, 2002, at 05:53 PM, Keith Moore wrote:
[I wrote:]
[...]
I don't see how the presence of NA[P]T in a firewall substantially
alters these requirements.
[...]
but I think the IAB were trying to say that it's important to make
sure that measures used to circumvent NAT
On Friday, April 5, 2002, at 03:25 PM, james woodyatt wrote:
Another thing that springs to mind: the IAB should probably encourage--
in no uncertain terms-- that any UNSAF process specified for use with
IPv4 NAT should also be specified for use with RFC 2766 Network
Address Translation
friends--
I have some commentary to offer on draft-iab-unsaf-
considerations-01.txt, i.e. IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) which comes from my experience developing a
consumer network appliance that combines the functions of an 802.11b
access point with a NAT
everyone--
Come on, folks. It's time to get our oop in a group.
Read section 3. The text of S. 2048 is here:
http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html
If the CBDTPA passes (not terribly likely, but the possibility exists),
then the FCC (the U.S. regulatory
On Thursday, March 21, 2002, at 06:15 PM, [EMAIL PROTECTED] wrote:
Of course, there is the possibility that if they were totally honest,
and marketed their devices as Enabling appliances for selected Internet
services that they'd STILL make money (and then you'd have no one to
blame).
Please
everyone--
I know this is a frequent source of heated discussion, and that much has
already been said that doesn't need to be repeated here, but I *just*
*can't* *let* *this* *go* unchallenged.
-
On Tuesday, March 19, 2002, at 08:26 AM, Keith Moore wrote:
[...]
in a just world, the NAT
On Tuesday, March 19, 2002, at 01:10 PM, Keith Moore wrote:
[I wrote:]
The first thing I would suggest is to sit back and contemplate whether
the situation bears any resemblance to other problems in which the user
population engages in behavior that results in short-term personal
benefit in
On Friday, March 15, 2002, at 09:53 AM, Keith Moore wrote:
I dunno. I've received several complaints from people who've received
spam with my address in the From field. I don't know if I'm being
singled out by a spammer [...]
You are not. I've seen this tactic used by spammers to
53 matches
Mail list logo
