ject: RE: [rfc2462bis] relationship between M/O flags and
> related protocols
>
> > Just checking. We do need the M bit for those wanting to use
> > stateful? Or do you not agree?
>
> I agree with the Jinmei's definition that the M bit indicates
> to the host that DHCPv
; [EMAIL PROTECTED]
> Subject: Re: [rfc2462bis] relationship between M/O flags and
> related protocols
>
> This text is fine with me, too.
>
> - Ralph
>
> At 09:43 AM 5/21/2004 -0700, Erik Nordmark wrote:
> > > Or, if you feel happier by mentioning
This text is fine with me, too.
- Ralph
At 09:43 AM 5/21/2004 -0700, Erik Nordmark wrote:
> Or, if you feel happier by mentioning changes of the M bit explicitly,
> we could alternatively say
>
> The details of how a host uses the M flag, including any use of
> the "on" and "off" transiti
> Or, if you feel happier by mentioning changes of the M bit explicitly,
> we could alternatively say
>
> The details of how a host uses the M flag, including any use of
> the "on" and "off" transitions for this flag, to control the use
> of DHCPv6 for address assignment will be des
On Thu, May 20, 2004 at 11:06:40PM -0700, Christian Huitema wrote:
> > Assuming it's okay for Christian to mention other documents on
> > details, can you live with the last proposal from Ralph?
> >
> >The details of how a host uses the M flag from a valid Router
> >Advertisement i
> Assuming it's okay for Christian to mention other documents on
(B> details, can you live with the last proposal from Ralph?
(B>
(B>The details of how a host uses the M flag from a valid Router
(B>Advertisement it receives will be described in a separate document.
(B
(BI can
> On Wed, 19 May 2004 10:56:39 -0700 (PDT),
> Erik Nordmark <[EMAIL PROTECTED]> said:
> So if you think that the existence of the ManagedFlag implies that there
> is an API (which I don't think FWIW) then shouldn't you argue that
> all existance of ManagedFlag (and OtherConfigFlag) should
> Just checking. We do need the M bit for those wanting to use stateful? Or
> do you not agree?
I agree with the Jinmei's definition that the M bit indicates to the host
that DHCPv6 for IP address configuration is available on the link.
With that definition it is possible to build hosts that in
an Huitema
> Cc: Erik Nordmark; Ralph Droms; JINMEI Tatuya / çæéå; [EMAIL PROTECTED]
> Subject: RE: [rfc2462bis] relationship between M/O flags and
> related protocols
>
> > > I'm certainly not implying any API.
> > > Why do you think the text with the f
> > I'm certainly not implying any API.
> > Why do you think the text with the forward reference to "a separate
> > document"
> > implies any API?
>
> The forward reference is asking the implementers to manage an extraneous
> state variable. As far as ND is concerned, the host can be entirely
> co
> On Tue, 18 May 2004 20:16:15 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> I share your concern about mandating the implementation of a possibly
> extraneous state variable. Perhaps replacing your suggested text:
> On receipt of a valid Router Advertisement (as defined in
>
I share your concern about mandating the implementation of a possibly
extraneous state variable. Perhaps replacing your suggested text:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag, which
(B
(BChristian Huitema wrote:
(B
(B>>> On receipt of a valid Router Advertisement (as defined in
(B>>> [DISCOVERY]), a host copies the value of the advertisement's M bit
(B>>> into ManagedFlag, which saves the mostly recently received value of
(B>>> the M bit. The details of how the host us
(B> I'm certainly not implying any API.
(B> Why do you think the text with the forward reference to "a separate
(B> document"
(B> implies any API?
(B
(BThe forward reference is asking the implementers to manage an extraneous state
(Bvariable. As far as ND is concerned, the host can be enti
> Well, I for one would rather leave the entire handling of the Managed flag
> to the to-be-written RFC. I see the point of assuming that the flag will be
> visible through some kind of API for the DHCPv6 process, but I would rather
> not build a dependency to another document.
I'm certainly not
> >Better. But how about also stating that it might be useful to detect
(B> >when the flag values change. For instance,
(B> > On receipt of a valid Router Advertisement (as defined in
(B> > [DISCOVERY]), a host copies the value of the advertisement's M bit
(B> > into ManagedFlag, wh
Erik - your proposed text looks good to me...
- Ralph
At 10:23 AM 5/18/2004 -0700, Erik Nordmark wrote:
Better. But how about also stating that it might be useful to detect
when the flag values change. For instance,
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a h
> > Loosing the above setence means that implementations might not
> ^^^ you meant "Losing" here, didn't you?
Yes.
(I'm assuming we'll have a separate document to describe the details.
But if we cannot agree on this path, we'll need to revise the proposed
text above accordingly.)
That assu
Regarding the last paragraph of suggested text:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag. If the value of ManagedFlag changes from FALSE to
TRUE, it indicates DHCPv6 becomes available fo
Your list of behaviors is a good starting point for a BCP document. As you
point out, if we know there is rough consensus in support of writing such a
doc, RFC 2462bis can proceed without explicit prescription of client behavior.
I remember (my memory, of course, may be faulty) that the behavior o
At 06:00 PM 5/17/2004 -0700, Erik Nordmark wrote:
> 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
> Let me check...this should apply to the current RFC2462, shouldn't it?
> I'm not sure why you are making this point in this context...
No, I was referring to your suggestion of writing a document (standard
or BCP) about the details of the protocol interaction which I believe is
a good idea becaus
> On Tue, 18 May 2004 09:09:16 +0200,
> "Christian Strauf (JOIN)" <[EMAIL PROTECTED]> said:
>> - how a host that implements DHCPv6 should behave. The host would
>> have an internal (conceptual) variable, controlling the policy about
>> autoconfiguration, which should have at least three
> - how a host that implements DHCPv6 should behave. The host would
> have an internal (conceptual) variable, controlling the policy about
> autoconfiguration, which should have at least three values:
> 1: it should invoke DHCPv6 for address autoconfiguration regardless
> of the content
> On Mon, 17 May 2004 09:18:23 -0700 (PDT),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> - 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 prot
> On Mon, 17 May 2004 18:00:48 -0700 (PDT),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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 statel
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
> 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
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
(B> >> still silent, I'll start revising the document anyway.
(B> > I support all of your proposed changes.
(B>
(B> Same here.
(B
(BMe too
(B
(B-- Christian Huitema
(B
(B--
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
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 09:05:33 -0700,
> "Christian Huitema" <[EMAIL PROTECTED]> said:
>> (In the followings, I'm assuming we have agreed that
>>
>> - we should clearly specify the corresponding protocols for the M/O
>> flags
>> - the protocol for the M flag is DHCPv6 (RFC3315)
>> - the p
> (In the followings, I'm assuming we have agreed that
(B>
(B> - we should clearly specify the corresponding protocols for the M/O
(B> flags
(B> - the protocol for the M flag is DHCPv6 (RFC3315)
(B> - the protocol for the O flag is the "stateless" subset of DHCPv6
(B> (RFC3736)
(B
(B > > => Stateless is a MUST according to the Node requirements.
(B > Now, if an
(B > > implementation
(B > > decided to use DHCP when the flags are set, then there are
(B > two cases to
(B > > consider:
(B >
(B > do you mean the case when the flags are NOT set? (I talked about th
Quick checks:
> On Thu, 13 May 2004 11:08:04 -0400,
> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> - what hosts should do if the M/O flags keep being cleared; e.g.,
>> does this mean the hosts should not invoke the protocols?
> => Stateless is a MUST according to the Node requirements.
Some answers below.
(B
(B > So far, many people seem to have (somehow) agreed on what Christian
(B > said (attached below): the M/O flags should just be hints of
(B > availability of the corresponding services (or protocols) rather than
(B > a trigger to invoke the protocols under a certain le
> On Thu, 13 May 2004 15:53:42 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Although his suggestion was apparently supported by several key
> players in this group, I'm afraid details on actual changes for
> rfc2462bis may still vary. So I'll soon throw concrete idea of the
> chang
Now I'd like to (re)start a bigger discussion about the M/O flags: how
we should describe the relationship between the M/O flags and the
related protocols.
So far, many people seem to have (somehow) agreed on what Christian
said (attached below): the M/O flags should just be hints of
availability
46 matches
Mail list logo
