From: Jari Arkko [EMAIL PROTECTED]
Date: 2006/08/25 Fri AM 01:11:55 CDT
To: [EMAIL PROTECTED]
Cc: IETF IPv6 Mailing List ipv6@ietf.org
Subject: Re: Prefix Delegation using ICMPv6
Tim,
Its probably best if you now update your draft with a better description
of what scenario you are looking at,
I'm sorry for introducing other recommendations into your thread. I
forwarded comments from a private exchange about the draft. I'll separate
the other recommendations out into a different thread.
I don't have a strong opinion about your text, either and perhaps brevity is
a virtue. How about:
On 8/25/06 2:49 AM, JINMEI Tatuya / 神明達哉
[EMAIL PROTECTED] wrote:
On Thu, 24 Aug 2006 17:08:55 -0400,
Ralph Droms [EMAIL PROTECTED] said:
[...]
I'm not sure if we want to discuss the other recommendations right now
on this thread, but I'm going to provide short responses:
After
Tim,
Yes, I can certainly keep personal things off-list. One thing
I will correct though is that it was indeed you who contacted
me first.
Fred
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 24, 2006 6:06 PM
To: Templin,
Correcting somewhat what I said earlier, the proposal calls
for not only RS/RA modifications but also three new ICMPv6
error messages/codes, and one new notification message which
carrys prefixes using the PIO format.
But, as I said earlier, it is not just about RS/RA in its
current
[EMAIL PROTECTED] wrote:
Hi Tony, please see my in-line comments:
I think the questions should be is there merit in the
proposal?
That is true, but your section 3 does not establish that merit.
Hi Tony, just a reminder from an earlier e-mail that we will be seeking to
provide
On Aug 24, 2006, at 11:11 PM, ext Jari Arkko wrote:
Tim,
Its probably best if you now update your draft with a better
description
of what scenario you are looking at, details about the customers
requirements, justification of why new work is needed, and an analysis
of why existing
Just to be clear (and I know you're aware of this, Tony), lack of code is
a provably invalid argument in support of developing an alternative to
DHCPv6 PD. It is simply not true to say that DHCPv6 PD is not implemented
and has not been deployed. There are multiple server implementations
