IPv6 WG,
This begins a 1-week Working Group Last Call on advancing:
Title : Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s) : D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-02.txt
Pages : 20
Date:
Hi,
I warmly support moving forward with this document as this is useful piece of
work. I don't have bigger issues with the current draft.
BR,
-Juha W.-
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
ext Brian Haberman
Sent: 24 May, 2005 14:40
I have a process-related concern with draft-ietf-ipv6-ndproxy-02.txt
that I would like to discuss on this list to see what others think...
I haven't reached the point (yet) where I have a fully-formed
objection, but I have a strong enough concern that I thought it would
be worth some
Hi all,
I submitted an updated revision of 2461bis which includes
the resolutions that were agreed on by the WG in the last meeting
(the SLLAO thread). It also includes fixes for the comments Tatuya
raised on the last version.
I think this draft is now ready for the IESG.
Thanks,
Hesham
I wonder if there is key question here that the community has simply
not agreed on (yet), and that that question is at the heart of all
this confusion.
Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sys
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
[EMAIL PROTECTED] writes:
If we respect both the original sense of RFC2462 and our consensus
about the semantics separation of the M/O flags, I believe the right
solution is the following:
I think we should be careful NOT
Brian and authors,
My response below. Thus I cannot support this going to the IESG without
further discussion as my input. I also support Margaret's request for
this to be checked by RTSP persons, and I realize Dave T. clearly has
this expertise but it is a good logic check. Unless we want to
Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sys admin to signal to client whether DHC is to be
invoked?
yes.
Second, is it important that such a signal be honored by clients?
(That is, if
Thomas/Jim:
I believe that most of us are in agreement on the main points -- the
bit(s) are useful and SHOULD be acted on by clients accordingly.
I believe were there are issues are in the details about what each bit
means and how they interact and what happens if they're not set
correctly.
Bernie, I think your honing down to valid points. I view m bit set
implying o bit use too. but that is not stated.
/jim
-Original Message-
From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 11:36 AM
To: Bound, Jim; Thomas Narten; ipv6@ietf.org;
Resending. I did not see it come back to me. Sorry for duplicates if
that is the case.
/jim
-Original Message-
From: Bound, Jim
Sent: Tuesday, May 24, 2005 10:45 AM
To: 'Brian Haberman'; IPv6 WG
Cc: Bob Hinden
Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt
Brian and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename
Hi Margaret,
Thanks for the comments and the text. I have submitted version -04 of
the draft with the suggested changes. Let me know if you have any more
issues you would like me to address.
Cheers
Suresh
On Fri, 13 May 2005, Margaret Wasserman wrote:
At 10:15 AM -0400 5/11/05, Suresh
On Tue, 24 May 2005 10:45:19 -0400,
Thomas Narten [EMAIL PROTECTED] said:
Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sys admin to signal to client whether DHC is to be
invoked?
In my
On Tue, 24 May 2005 10:46:06 -0400,
Thomas Narten [EMAIL PROTECTED] said:
If we respect both the original sense of RFC2462 and our consensus
about the semantics separation of the M/O flags, I believe the right
solution is the following:
I think we should be careful NOT to get hung up on
On Tue, 24 May 2005 11:35:41 -0400,
Bernie Volz (volz) [EMAIL PROTECTED] said:
I believe were there are issues are in the details about what each bit
means and how they interact and what happens if they're not set
correctly.
Personally I think the last issue should be a non-issue since
But if the client supports both (really this means it is a full 3315
client), does it do both in parallel, initiate stateful (Solicits) and
failover to stateless at some point (and does it continue to
do stateful in the background), or? These areas that are not well
documented in the DHCPv6
I don't have any issues if we wanted to keep 2 bits - just figured
simpler is better.
Note that if we drop one of those bits, we would not want to reuse if
for another purpose for a long time -- that would allow backward
compatibility for those environments that need it.
But again, I really
Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sys admin to signal to client whether DHC is to be
invoked?
YES
Second, is it important that such a signal be honored by clients?
(That is, if
Regarding breaking backward compatibility - this compatibility affects
only clients, right? Can we answer the question: exactly how would
existing clients (and I'll bet we can enumerate all the available
clients) be affected by a change in definition? How would the observed
behavior of the
On Tue, 24 May 2005 22:39:41 -0400,
Ralph Droms [EMAIL PROTECTED] said:
Regarding breaking backward compatibility - this compatibility affects
only clients, right? Can we answer the question: exactly how would
existing clients (and I'll bet we can enumerate all the available
clients) be
21 matches
Mail list logo
