Yeah. I have to agree with James and Brian: in retrospect, the M/O bits are
useless and further discussion at this point is even more useless.
- Ralph
On 11/29/06 4:58 AM, Brian E Carpenter [EMAIL PROTECTED] wrote:
The MO bits were
defined long before we had DHCPv6 in place.
And they
; Thomas Narten
Cc: Brian Haberman; Bob Hinden; William Allen Simpson; General Area
Review Team; Erik Nordmark; ipv6@ietf.org; Soliman,Hesham
Subject: Re: [Gen-art] Re: gen-art review of
draft-ietf-ipv6-2461bis-09.txt
Yeah. I have to agree with James and Brian: in retrospect, the M/O
bits
@ietf.org
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt
4.2 router advertisement
- Note: If neither M nor O flags are set this indicates that no
information is available via DHCPv6.
This means that the responding router always knows if DHCPv6 is
definitely
Ralph Droms (rdroms) writes:
-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
[...]
4.2 router advertisement
- Note: If neither M nor O flags are set this indicates that no
information is available via DHCPv6.
This means that the responding
Soliman, Hesham [EMAIL PROTECTED] writes:
I'll start with my protocol question:
7.2.7 Anycast neighbor announcements
- Second, the Override flag in Neighbor Advertisements SHOULD be
set to 0, so that when multiple advertisements are
received, the
I only have one question left. Are anycast addresses taken from a
special pool? I didn't think so. Is it possible for me to first be
told about a prefix by router A, and then an anycast address that is
within that prefix by router B? Since anycast addresses have the
override flag set to 0,
Thanks, Brian. That's the sort of thing I was hoping to see. If the
principles ever have time I am still curious about the technical
questions in the review (which the SHOULD brouhaha buried).
swb
___
Gen-art mailing list
Gen-art@ietf.org
On 11/25/2006 12:01 PM, Hesham Soliman allegedly wrote:
Hi Scott,
Are you referring to comments other than the SHOULD issue? I responded to
all of your comments in my first email. If there is anything unclear please
let us know.
Hesham
OK. I'll take it offline for the moment. Thanks.
Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for. I
didn't say examples, I said explanations. See below ...
On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
Scott W Brim [EMAIL PROTECTED] writes:
I
Hi Spencer,
It's not that specifications need to explain all possible
reasons for not
following a SHOULD - I agree with your statement that
successful protocols
are used in amazing ways - but I do think listing ONE
possible reason as
justification for a SHOULD instead of a
Scott W Brim [EMAIL PROTECTED] writes:
I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity. Many of them have to do with the use
Bob Hinden wrote:
Gentlemen,
This document is being recycled at Draft standard. It has been
previously reviewed, IESG approved, RFC-Editor edited, and published
at Proposed and Draft Standard. It is very widely deployed. Any
issues regarding the meaning of SHOULD, MUST, etc. have been
12 matches
Mail list logo
