On Fri, 25 Aug 2006 06:13:17 -0400,
Ralph Droms [EMAIL PROTECTED] said:
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
On Fri, 25 Aug 2006 06:18:06 -0400,
Ralph Droms [EMAIL PROTECTED] said:
I recommend removing section 2.2 (as I did in the earlier post cited
by Suresh), as experience with IPv4 addressing has little bearing on
IPv6. This observation is bolstered by the text in section 2.3
describing the
Suresh - I think Jinmei-san and I have come to agreement on replacement text
in section 2.4 (see below).
- Ralph
On 8/31/06 2:21 AM, JINMEI Tatuya / 神明達哉
[EMAIL PROTECTED] wrote:
On Fri, 25 Aug 2006 06:13:17 -0400,
Ralph Droms [EMAIL PROTECTED] said:
I'm sorry for introducing other
On Thu, 31 Aug 2006, Ralph Droms wrote:
Suresh - I think Jinmei-san and I have come to agreement on replacement text
in section 2.4 (see below).
As a WG participant, if we want to go ahead with the change, I'd
expect WG chairs to issue a last call of some sort for the changes
(giving a good
Pekka - I would agree if the text in question were a key component of the
protocol specification. But, because this text is background material and
the discussion has been conducted on the WG mailing list, I don't think a
last call is warranted for this text.
Of course, there may be other
On Thu, 31 Aug 2006, Ralph Droms wrote:
Pekka - I would agree if the text in question were a key component of the
protocol specification. But, because this text is background material and
the discussion has been conducted on the WG mailing list, I don't think a
last call is warranted for this
Pekka - the discussion has already occurred on the ipv6 WG mailing list and
we have consensus on replacement text. I don't see a need to further waste
the WG's time with additional discussion in a WG last call now that the
interested parties have already come to consensus.
I didn't say the text
Pekka,
On Aug 31, 2006, at 6:18 AM, Pekka Savola wrote:
On Thu, 31 Aug 2006, Ralph Droms wrote:
Suresh - I think Jinmei-san and I have come to agreement on
replacement text
in section 2.4 (see below).
As a WG participant, if we want to go ahead with the change, I'd
expect WG chairs to
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
On Mon, 21 Aug 2006 14:45:55 -0700,
Bob Hinden [EMAIL PROTECTED] said:
In particular, the text of Section 2.4, paragraph 1 beginning:
But DHCPv6 will solve the privacy issue is new since RFC3041
and seems to make questionable statements about the use of DHCP
for generating temporary
Jinmei-san - in a private conversation, I made the following
recommendations:
After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I
think the Abstract is now fine. I would recommend changing the first
sentence of the Introduction to:
Stateless address autoconfiguration [ADDRCONF]
Fred,
This draft seems to link itself unnecessarily with Stateless
Address Autoconfiguration, since it seems that the same
mechanisms work under DHCPv6 - see: (RFC3315, Section 22.5).
Unless I am missing something, the only difference I see is
that the entity that generates the temporary
Fred correctly points out that this text from draft-ietf-ipv6-privacy-
addrs-v2-0.txt is inaccurate:
2.4 Possible Approaches
One way to avoid having a static non-changing address is to use
DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be
configured to hand out
Suresh,
[http://www.ietf.org/internet-drafts/draft-ietf-ipv6-privacy-addrs-v2-04
.txt]
This draft seems to link itself unnecessarily with Stateless
Address Autoconfiguration, since it seems that the same
mechanisms work under DHCPv6 - see: (RFC3315, Section 22.5).
Unless I am missing something,
15 matches
Mail list logo
