> On Thu, 26 Aug 2004 12:50:26 +0530,
> Syam Madanapalli <[EMAIL PROTECTED]> said:
>> >> M has no impact on stateless autoconf. The existence
>> >> of prefixes in the RA marked as "autoconf from this
>> >> prefix" controls stateless autoconf. If M=0 and no
>> >> prefixes are advertised
> >> I disagree with the interpretation of M=0.
> >>
> >> M has no impact on stateless autoconf. The existence
> >> of prefixes in the RA marked as "autoconf from this
> >> prefix" controls stateless autoconf. If M=0 and no
> >> prefixes are advertised as autoconf-able, the host
> >> has no asser
> On Thu, 26 Aug 2004 09:25:00 +0530,
> Syam Madanapalli <[EMAIL PROTECTED]> said:
>> I disagree with the interpretation of M=0.
>>
>> M has no impact on stateless autoconf. The existence
>> of prefixes in the RA marked as "autoconf from this
>> prefix" controls stateless autoconf. If
Hi Ralph,
- Original Message -
From: "Ralph Droms" <[EMAIL PROTECTED]>
To: "Fred Templin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Stig Venaas" <[EMAIL PROTECTED]>
Sent: Wednesday, August 25, 2004 6:56 PM
Subject: Re:
I disagree with the interpretation of M=0.
M has no impact on stateless autoconf. The existence
of prefixes in the RA marked as "autoconf from this
prefix" controls stateless autoconf. If M=0 and no
prefixes are advertised as autoconf-able, the host
has no assertion that DHCP is available and no
age-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Monday, August 23, 2004 6:27 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Stateful != M , Stateless != O
>
> Tim &Jinmei,
>
&
Tim &Jinmei,
(B
(B> > But we need to be careful too in that the Node Requirements draft is
(B> > just coming out of the oven and was baked using a different
(B> recipe :)
(B>
(B> That's perhaps true, though I don't think there will be a big gap
(B> between the description of the node-req d
> On Thu, 19 Aug 2004 14:16:17 +0100,
> Tim Chown <[EMAIL PROTECTED]> said:
>> I'm (currently) leaning toward (2)
>>
>> 2. M=1 => Solicit/Advertise/Request/Reply is available
>> O=1 => Information-request/Reply is available
>>
>> As Ralph mentioned though, the idea of preventing configu
On Thu, Aug 19, 2004 at 11:10:54AM +1000, Greg Daley wrote:
>
> I'm (currently) leaning toward (2)
>
> 2. M=1 => Solicit/Advertise/Request/Reply is available
> O=1 => Information-request/Reply is available
>
> As Ralph mentioned though, the idea of preventing configuration
> combinations ma
> Sorry about all the cycling.
Not at all, I'd appreciate your effort on this issue..^.^
After considering several comments, a revised draft
as 01version will appear soon.
Thanks
- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 18 Aug 2004 10:52:45 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
I'd like to be sure that's what we're doing though, by
explicitly stating that in the draft (or at least documenting
behaviours in such a case).
Same here. Please refer to the next m
> On Wed, 18 Aug 2004 10:52:45 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> I'd like to be sure that's what we're doing though, by
> explicitly stating that in the draft (or at least documenting
> behaviours in such a case).
Same here. Please refer to the next message of mine
http:
Hi Jinmei,
JINMEI Tatuya / wrote:
On Fri, 13 Aug 2004 11:15:48 +0200,
Stig Venaas <[EMAIL PROTECTED]> said:
Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean
that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
available but Information Request is not? Perhap
(coming back to the root of this discussion...)
> On Wed, 11 Aug 2004 18:17:31 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> I think that's one of the issues.
> It leads to the idea that M|O = 1 can be used to invoke Information-Request.
> So in this case, the policy shouldn't be cal
> On Fri, 13 Aug 2004 11:15:48 +0200,
> Stig Venaas <[EMAIL PROTECTED]> said:
>> Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean
>> that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
>> available but Information Request is not? Perhaps this is
>> inconv
Hi Stig,
I think that some of the ideas which you present
are in accordance with some of the things I've been
thinking about.
I'm not strictly tied to one (M=3315/O=3736 or
M=Req,Renew.../O=Info Request) though. I think
that there are issues to be worked out based on
either course.
Stig Venaas wro
Title: RE: Stateful != M , Stateless != O
Having been reviewing the combined ICMPv6 drafts and following this thread, I would support Stig's ideas here.
The wording around 3315/3736 needs to be cleared up because a naive reader *would be* confused by the juxtaposition of 'state
On Fri, Aug 13, 2004 at 02:28:46PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
[...]
> Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean
> that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
> available but Information Request is not? Perhaps this is
> inco
> On Wed, 11 Aug 2004 18:17:31 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
>> Assume we have a "stateful" DHCPv6 server (that implements RFC3315)
>> running. The server should support both
>> Solicit/Advertise/Request/Reply(/and Renew) and
>> Information-request/Reply exchanges.
>>
>>
Hi Jinmei,
JINMEI Tatuya / wrote:
On Thu, 12 Aug 2004 15:23:23 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an implementation hint
Hi Ralph,
I was being imprecise (as usual).
I apologize for mis-representing the role of the RFC.
Ralph Droms wrote:
Greg - I have one minor disagreement with your explanation:
At 06:17 PM 8/11/2004 +1000, Greg Daley wrote:
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 14:16:03 +1000,
No responses yet; for myself, I consider this subject as a
thoroughly-whipped dead horse. (Others are welcome to
continue, of course...)
Thanks - Fred
[EMAIL PROTECTED]
Fred Templin wrote:
Stig Venaas wrote:
My thinking is:
M=0, O=0 stateless autoconf of addresses
M=0, O=1 stateless autoconf of add
Stig Venaas wrote:
My thinking is:
M=0, O=0 stateless autoconf of addresses
M=0, O=1 stateless autoconf of addresses + information-request
M=1, O=0 stateful autoconf of addresses
It seems from these discussions that a more precise
representation might be:
M=0, O=0 stateless autoconf of addresses
> If M is set(1), a client able to do stateful, does stateful (or full
3315)
> and ignores the O bit.
More precisely, the M bit indicates that a client wishing to do stateful
may do it, and the M=0 bit indicates that the client should not try.
If the router wants to not enable stateless, then th
et, a client able to do stateless (either full 3315 or
3736), does stateless.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ralph Droms
> Sent: Thursday, August 12, 2004 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Statefu
I also agree with this. I think this would be useful and there is no harm.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ralph Droms
> Sent: Thursday, August 12, 2004 9:26 AM
> To: [EMAIL PROTECTED]
> Subject:
> As Jinmei-san pointed out, RFC 3736 provides implementation
> guidelines for servers, relay agents and clients.
>
> After reading this thread, I think the text currently in RFC2461bis
> is headed in the right direction; that is, it explicitly
> references "a subset of DHCPv6" and cites RF
(B > > => Right, but there is no need to have the O flag off. To
(B > me RFC 3736 is
(B > > something useful for server vendors and should not be
(B > associated with
(B > > setting the O flag.
(B >
(B > You mean we can always set O flag ? I don't make sense why RFC3736
(B > should not
On Thu, Aug 12, 2004 at 09:26:02AM -0400, Ralph Droms wrote:
> Seems to me it would be useful to allow both M and O flag on.
>
> While, in theory, the support for the subset of DHCPv6 indicated
> by the O bit is implied by the support for all of DHCPv6
> indicated by the M bit, it seems there woul
Seems to me it would be useful to allow both M and O flag on.
While, in theory, the support for the subset of DHCPv6 indicated
by the O bit is implied by the support for all of DHCPv6
indicated by the M bit, it seems there would be little harm
in advertising both.
Some hosts may choose to use both
As Jinmei-san pointed out, RFC 3736 provides implementation
guidelines for servers, relay agents and clients.
After reading this thread, I think the text currently in RFC2461bis
is headed in the right direction; that is, it explicitly
references "a subset of DHCPv6" and cites RFC 3736 for the
defin
I believe there will be clients that implement only those messages
required to complete an Information-Request message exchange.
RFC 3736 gives implementation guidelines for implementing the parts
of RFC 3315 required for the Information-Request message exchange,
for clients, servers and relay agen
Greg - I have one minor disagreement with your explanation:
At 06:17 PM 8/11/2004 +1000, Greg Daley wrote:
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 14:16:03 +1000, Greg Daley
<[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures
> > Sorry, it doesn't clearly answer my question. So can I rephrase your
> > statement to "3736 is an implementation hint for DHCPv6 servers and
> > relays, not clients."?
> >
>
> Oh, sorry for the confusion.
>
> Yes I believe so.
That means there will not be any DHCPv6 Client that just implement
> On Thu, 12 Aug 2004 15:23:23 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> It's important to relize though that a host doesn't invoke
> RFC 3736 procedures though. The host only cares that it wants to
> do an Information-Request. 3736 is an implementation hint for
>
Hi Jinmei
JINMEI Tatuya / wrote:
On Thu, 12 Aug 2004 14:51:59 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an implementation hint f
> On Thu, 12 Aug 2004 14:51:59 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
>>> It's important to relize though that a host doesn't invoke
>>> RFC 3736 procedures though. The host only cares that it wants to
>>> do an Information-Request. 3736 is an implementation hint for
>>> DHCPv6 s
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 18:17:31 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an implementation hint
> On Thu, 12 Aug 2004 12:30:52 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> It's important to relize though that a host doesn't invoke
>> RFC 3736 procedures though. The host only cares that it wants to
>> do an Information-Request. 3736 is an implementation hint for
>> DHCPv6 se
> On Wed, 11 Aug 2004 18:17:31 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> It's important to relize though that a host doesn't invoke
> RFC 3736 procedures though. The host only cares that it wants to
> do an Information-Request. 3736 is an implementation hint for
> DHCPv6 servers a
Hi Daniel,
S. Daniel Park wrote:
=> Right, but there is no need to have the O flag off. To me RFC 3736 is
something useful for server vendors and should not be associated with
setting the O flag.
You mean we can always set O flag ? I don't make sense why RFC3736
should not be associated with sett
> => Right, but there is no need to have the O flag off. To me RFC 3736 is
(B> something useful for server vendors and should not be associated with
(B> setting the O flag.
(B
(BYou mean we can always set O flag ? I don't make sense why RFC3736
(Bshould not be associated with setting the O fl
Hi Daniel,
S. Daniel Park wrote:
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.
Not at all,,,Thanks your comments as well...:-)
At this stage, I think that the policy sec
> This is a bit of a rant.
> Please accept my apologies. I'm quite concerned by
> the form of the document at the moment, although I
> think that the function needs to be available.
Not at all,,,Thanks your comments as well...:-)
> At this stage, I think that the policy section is OK except
> for
I have a silly question below.
(B
(B
(B > I now feel I get understanding the point...to make it sure,
(B > let me try
(B > to rephrase that.
(B >
(B > Assume we have a "stateful" DHCPv6 server (that implements RFC3315)
(B > running. The server should support both
(B > Solicit/Advertise/
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 14:16:03 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.
No need t
> On Wed, 11 Aug 2004 14:16:03 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> This is a bit of a rant.
> Please accept my apologies. I'm quite concerned by
> the form of the document at the moment, although I
> think that the function needs to be available.
No need to apologize, I know
Hi Jinmei,
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.
I think that the problems with the draft are not
the policies themselves, but the distinction between
"Stateless D
48 matches
Mail list logo
