Ralph,
> The host behavior when the M/O flags transition from set to unset is a
> little less clear. In the case of the O flag, the host will stop using
> DHCPv6 for other configuration information. Should it also stop using the
> configuration information it received through DHCPv6?
>
> Simila
> On Mon, 17 May 2004 15:04:17 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
>> > 3. (optionally) make a separate document (standard or BCP) on how to
>> >interact the protocols with these flags
> Can you give some examples of what conditions or interactions might be
> included in s
> On Mon, 17 May 2004 14:34:47 -0500,
> [EMAIL PROTECTED] said:
> I agree that we should not try to remove already
> documented features in recycling work if it is
> not causing any harm.
Before making detailed discussions, I'd repeat my position to avoid
confusion. I can live with eit
> I think Jinmei-san suggested deleting the whole notion of an
> internal-to-the-implementation ManagedFlag and OtherConfigFlag. I
> extrapolated from that suggestion that the host would (in a stateless way)
> base its behavior on the most recently received values for M/O (which, I
> guess, means
Jinmei,
I agree that we should not try to remove already
documented features in recycling work if it is
not causing any harm.
But the current RFC says "If the node has more than one
unicast address, it must choose the Source Address of the
message as follows:". It is not MUST in all caps but
I think Jinmei-san suggested deleting the whole notion of an
internal-to-the-implementation ManagedFlag and OtherConfigFlag. I
extrapolated from that suggestion that the host would (in a stateless way)
base its behavior on the most recently received values for M/O (which, I
guess, means the implem
I am basically in agreement with your approach; here are a couple of
specific comments:
> 1. clarify (change) the meaning of the M/O flags; they are just hints
>of availability of the corresponding services, not triggers for
>invoking the protocols under a certain level of requirement
Rat
> >> Explicit support or objections are highly appreciated. If the list is
> >> still silent, I'll start revising the document anyway.
> > I support all of your proposed changes.
>
> Same here.
Me too
-- Christian Huitema
--
On May 17, 2004, at 2:09 AM, Christian Strauf (JOIN) wrote:
Jinmei,
Explicit support or objections are highly appreciated. If the list is
still silent, I'll start revising the document anyway.
I support all of your proposed changes.
Same here.
- Alain.
-
Overall your proposal is good.
> - remove "requirement" sentences like the following one
> If the value of ManagedFlag changes from FALSE to TRUE,
> and the host is not already running the stateful address
> autoconfiguration protocol, the host should invoke the stateful
> ad
Hi all,
Based upon some discussion regarding a DISCUSS during IESG review, I am
updating section 5.2 DNS
Current text says:
DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
and [RFC-3596] MAY be supported. Not all nodes will need to resolve
names. All nodes that nee
On Mon, May 17, 2004 at 08:17:04PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> Please let me check: are you suggesting to replace the "should"s with
> "may"s instead of removing these sentences (which is my proposal)?
Yes. I suspect implementations may do both, thus rather than impl
> On Mon, 17 May 2004 10:01:44 +0100,
> Tim Chown <[EMAIL PROTECTED]> said:
>> Explicit support or objections are highly appreciated. If the list is
>> still silent, I'll start revising the document anyway.
> I agree with the changes, though...
>> > - remove "requirement" sentences l
Jinmei,
> Explicit support or objections are highly appreciated. If the list is
> still silent, I'll start revising the document anyway.
I support all of your proposed changes.
Christian
IETF IPv6 working group mailing list
On Mon, May 17, 2004 at 05:42:29PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> Explicit support or objections are highly appreciated. If the list is
> still silent, I'll start revising the document anyway.
I agree with the changes, though...
> > - remove "requirement" sentences l
Are folks happy with the following approach? I've not seen any
objections (or any agreements either), but I'm not sure if I can start
editing based on the proposal, considering the fact that this is quite
a big set of changes.
Explicit support or objections are highly appreciated. If the list is
> On Thu, 13 May 2004 14:54:23 -0500,
> [EMAIL PROTECTED] said:
> Pekka raised a concern about the usability of one of the
> methods (section 2.2 (c)) to select the source address
> of the ICMPv3 packet. I want to know if anyone has
> implemented it ? or how useful and practical this
17 matches
Mail list logo
