[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 WG Call for Adoption:draft-daniel-ipv6-ra-mo-flags-01.txt



Just to clarify some things quickly:

>>>>> On Fri, 5 Nov 2004 23:19:46 +0200 (EET), 
>>>>> Pekka Savola <pekkas@xxxxxxxxxx> said:

>> Information Configuration Behaviour:
>> configuring other information excluding addresses through
>> Information-request and Reply exchanges

> For full clarity, I'd suggest s/Reply/Information-reply/ above, as I 
> think it was what you meant.

No, it's surely "Reply".  According to RFC3315, the response to
Information-request is also a Reply message, and there is no
Information-reply defined.

>> But your main point still stands, and I agree this is a problematic
>> case.  I'd first note I don't think it's a true-or-false thing; we're
>> just going to define the most reasonable behavior, and this is its
>> first step.  The background of this statement is the dependency
>> described in Section 6, which was originally stated in RFC2462, that
>> if we invoke Host Configuration Behaviour we basically should not
>> invoke Information Configuration Behaviour.

> I'm not sure if I followed this background statement.  My assumption 
> has always been that 'host configuration behaviour' would always also 
> include information config as well; a "less specific prefix" in a way 
> :).  But I may have missed some earlier consensus or did not read too 
> carefully.  (There would certainly be no way to stop Full DHCPv6 
> client from getting back all the ancillary information in addition to 
> the addresses, right?)

Your assumption is correct.  More clearly, when we exchange
Solicit/Advertise/Request/Reply messages, we usually get some IPv6
addresses allocated as well as other configuration information such as
recursive DNS server addresses.  In our draft we call it "Host
Configuration Behaviour".

On the other hand, when we exchange Information-request/Reply
messages, we only get "other" configuration information.  We call it
"Information Configuration Behaviour".

Are we synchronized so far?  If so, which part of the background
didn't you follow?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------