I disagree with this wording. In particular, the Solicit/...
exchange is *not* limites to address configuration. The
Information-Request/Reply message exchange is not
"Stateful DHCPv6". "the DHCPv6 Server" might be misleading
as there can be more than one DHCPv6 server.
I don't think the purpose
My suggestion:
M = ON means only address configuration is learned from the DHCPv6
Server via Solicit/Advertise/Request/Reply (or Solicit/Reply if Rapid
Commit is enabled) message exchanges which is assumed to be Stateful
DHCPv6.
O = ON means only configuration information (not requiring the
assi
On Fri, 20 Aug 2004, Brian Haberman wrote:
> > (f) Finally, an IPv6 node MUST limit the rate of ICMPv6 error
> > messages it originates in order to limit the processing at the
> > node and bandwidth and forwarding costs incurred on the
> > network by originating ICMPv6
(I tried to send this through the issue tracker, but it appears to
have failed...)
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a
(I tried to send this through the issue tracker, but it appears to
have failed...)
Proposed resolution:
- replace "multicast interface" with "multicast-capable interface" in
Section 5.1
- modify the definition of "link" in Section 2 a little bit like:
link - a communication facility or medium
(I tried to send this through the issue tracker, but it appears to
have failed...)
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyon
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a Multicast Listener Discovery (MLD) report message [RFC2710] for
the multica
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a Multicast Listener Discovery (MLD) report message [RFC2710] for
the multica
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a Multicast Listener Discovery (MLD) report message [RFC2710] for
the multica
Proposed Resolution:
- add a reference to RFC3810 as well as to RFC2710
- make a small modification to the 5th paragraph of section 5.4.2 to:
Note that when a node joins a multicast address, it typically sends
a Multicast Listener Discovery (MLD) report message [RFC2710] for
the multica
Proposed resolution:
- replace "multicast interface" with "multicast-capable interface" in
Section 5.1
- modify the definition of "link" in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immedia
Proposed resolution:
- replace "multicast interface" with "multicast-capable interface" in
Section 5.1
- modify the definition of "link" in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immedia
Proposed resolution:
- replace "multicast interface" with "multicast-capable interface" in
Section 5.1
- modify the definition of "link" in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immedia
Proposed resolution:
- replace "multicast interface" with "multicast-capable interface" in
Section 5.1
- modify the definition of "link" in Section 2 a little bit like:
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immedia
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
---
Tim Chown wrote:
On Fri, Aug 20, 2004 at 10:34:39AM +0300, [EMAIL PROTECTED] wrote:
Following the discussions, it isn't entirely clear to me why we
could need to open this issue. I think that there is concensus
for keeping it as is (as described in Christian's mail).
Am I missing something?
My im
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
---
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
---
I'm going to reject this issue.
See the following links for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03383.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03410.html
if anyone of you still have an objection, please speak up ASAP.
---
> On Thu, 19 Aug 2004 18:50:06 +0200,
> "Gerrit van Niekerk" <[EMAIL PROTECTED]> said:
>> Your suggestion looks basically fine, but I want to check one minor
>> point:
>>
>> > Note that when a node joins a multicast address, it typically sends a
>> > Multicast Listener Discovery (MLD) re
> On Fri, 20 Aug 2004 10:22:17 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
> Yes - there are 9 instances in the body and 1 in the abstract and non-local
> would be right for all these places I believe.
Hmm, the changes are not small and could make the resulting text a bit
vague, bu
Pekka Savola wrote:
On Wed, 18 Aug 2004 [EMAIL PROTECTED] wrote:
I think everyone agrees that per-interface configuration
would be a perfect solution and will provide a fine grained
control to the user. Is there anyone who disagrees with
this ? (Pekka ??)
I find it very useful.
My objection to t
On Thu, Aug 19, 2004 at 03:11:42PM -0400, Bound, Jim wrote:
> Hi Tim,
>
> Hints Node Reqs I agree. Hints in others I never agreed to at all.
> That does not mean that is not the case but lets be clear here people
> are running agendas and that is a fact. DHCPv6 will be used by users
> and requir
On Fri, Aug 20, 2004 at 10:34:39AM +0300, [EMAIL PROTECTED] wrote:
>
> Following the discussions, it isn't entirely clear to me why we
> could need to open this issue. I think that there is concensus
> for keeping it as is (as described in Christian's mail).
>
> Am I missing something?
My impre
> On Thu, 19 Aug 2004 08:10:07 -0400,
> "Bound, Jim" <[EMAIL PROTECTED]> said:
> It is relevant completely to users and implementation your wrong.
Just for some clarification since I was perhaps not very clear:
When I said
>> Fine, but please note that this particular point is not at
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
Yes - there are 9 instances in the body and 1 in the abstract and non-local would be right for all these places I believe.
Regards,
Elwyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 19
> Following the discussions, it isn't entirely clear to me why we
> could need to open this issue. I think that there is concensus
> for keeping it as is (as described in Christian's mail).
>
> Am I missing something?
Hi John, I don't think you are missing anything. Besides, I don't
have a hard
Daniel,
> (slightly changing the subject of this thread to follow up
> what we saying easily)
>
> As I indicated previous mail, original intent of M/O flags document
> is same as what Christian said. This intensity of this document was
> originally from the 2462-bis (IMO) and even Node Requirem
(slightly changing the subject of this thread to follow up what we saying easily)
As I indicated previous mail, original intent of M/O flags document
is same as what Christian said. This intensity of this document was
originally from the 2462-bis (IMO) and even Node Requirement as well.
But, as
29 matches
Mail list logo
