Subject: [v6ops] forwarded on behalf of Tony Hain: Commnets on draft-lee-v4v6tran-problem-02

From: Joel Jaeggli <[email-masked]>
Date: Tue, 28 Sep 2010 00:35:44 -0700

From: "Tony Hain" <[email-masked]>
To: <[email-masked]>
Subject: Commnets on draft-lee-v4v6tran-problem-02
Date: Mon, 27 Sep 2010 17:09:13 -0700
Message-ID: <02c301cb5ea1$8605e530$9211af90$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActeoSxvfB1QUQ4uTBiOM4x5kL4xVw==
Content-Language: en-us
x-cr-hashedpuzzle: A+Rp BJGi BRW7 BfYn CM0S CPok Cx3M Dwf8 EAkI FIff
GGTk HISz HcsP JfX3 Ji5i
KAnW;1;dgA2AG8AcABzAEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcA;Sosha1_v1;7;{3D9DD792-0D98-46C2-8F90-F169D17F61E1};YQBsAGgALQBpAGUAdABmAEAAdABuAGQAaAAuAG4AZQB0AA==;Tue,
28 Sep 2010 00:07:43
GMT;QwBvAG0AbQBuAGUAdABzACAAbwBuACAAZAByAGEAZgB0AC0AbABlAGUALQB2ADQAdgA2AHQAcgBhAG4ALQBwAHIAbwBiAGwAZQBtAC0AMAAyAA==
x-cr-puzzleid: {3D9DD792-0D98-46C2-8F90-F169D17F61E1}

Intro
The first paragraph will not be accurate by the time this thing gets out the
door, and makes unsubstantiated claim that IPv6 uptake will be slow.
Completely ignores the point that the only gating factor is application
availability and DNS entries.

The entire second paragraph is filler verbiage with no value.

The third paragraph makes the problematic conclusion that non-operators at
the IETF would have more clue than those looking for help. Completely
overlooks real cause of delay in that people refused to leave their state of
denial, and for the few that did, they refused to take the long term view of
costs, preferring to wait until the last minute and pump the 'next quarter'
profits.

2.1 FUD intended to pump the value of this document ... questions are
reasonable though

2.2 finally starting to make some sense

2.3  well, then again it resorts to FUD. The 'vast experience' is in reality
a new thing, and what this needs to talk about are demanding the same
functionality from their vendors.

2.4 (sp) probably -> properly

3.0 confused discussion, mixing technical and business decisions, completely
ignoring the wan side provisioning, and spending way too much time on the
customer side network that the ISP doesn't manage. There needs to be a
discussion about enabling innovation in the home network by not constraining
it to braindead historic perspectives of a single broadcast lan, but beyond
that the home network is not an ISP problem.

4.0  there is something here, but over use of the qualitative 'best way'
exposes the continuing belief that the IETF can somehow tell people how to
run their networks. Listing the approaches and trade-offs is all this
document should do.

5.0 is way off the wall. Given the paragraph I expected bullet points
related to mixed environment of *-only devices and making snmp be the
arbiter. The last bullet point belongs in 4.0, and the ones about IPv4 don't
belong in this document since overloading endpoint addresses has nothing to
do with customer prefixes. The logging thing could be a network management
point, but not the specific one listed.

6.0 value? Where is the discussion about new functionality that provides
additional layers of security like SEND or ULAs for internal-only functions.

Overall, I don't see that this is a v6ops doc. With a **lot** of work, it
might someday be an IPv6 Forum white paper, but there is virtually no meat,
and what there is comes out jumbled amongst the FUD and business issues.

Tony