Subject: regarding some comments on the M&O draft

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 16:31:30 +0900

Hello,

I'm not sure if I understand your comments on
draft-daniel-ipv6-ra-mo-flags-00.txt in the wg meeting.  (I've checked
the jabber log to be sure, but I'm still not 100% sure).  Would you
mind to repeat those?

To provide some answers at the moment:

As for the comment on policy 1 (always try DHCPv6/stateless-DHCPv6),
it's true that the policy might cause weird effects (but I'm not sure
if it's specific to mobile nodes).  So I agree that we should be
careful when taking this policy.  Also, we may even want to avoid
introducing the policy from the beginning.  (Please note that this is
the first attempt to provide the missing piece of the details usage
about the M/O flags as a result of the rfc2462bis discussion.  We'll
definitely need to discuss many technical details on the first
proposal.)

Regarding your second point, I'm even not sure about the point...from
the jabber log:

[18:28:54] <timchown> daley: m and o both indicate stateless info is available
[18:29:52] <timchown> daley: o and m policy names my be bad names. goals of original flags was different
[18:30:00] <timchown> (my = may)

If that's just a naming issue, that's fine.  I'm willing to rename
them if someone can offer better ones.   But I don't understand the
comment on the "original goals".  I'm even not sure what the "goals of
original flags" means, but, in my understanding, we are going to
describe the detailed and desired usage of the M/O flags as a BCP,
considering the latest standardization/deployment status.  In that
sense, it's not surprising that the result is different from the
"goals of original flags".  The important point is, IMO, that the
result makes sense and meets today's deployment scenario.

(Of course, since this is a (candidate of) derivative work from
rfc2462bis, we'll need to care about the "original intentions")

Thanks for your clarification in advance,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: PARK SOO HONG <[email-masked]>
Date: Fri, 06 Aug 2004 05:24:38 +0000 (GMT)

Greg, thanks your comments and see my comments (inline)

>I was concerned that M|O could be used to

>invoke DHCP information-requests

>(rather than just O).

rather than just O ?

This draft wrote as below;

[RFC3736] is just a subset of full DHCPv6.  So, a host

implementing [RFC3315] can do both or either Stateful DHCPv6 for

configuring the IPv6 address and Stateless DHCPv6 for the other

information.  A host implementing only [RFC3736] can only do

Stateless DHCPv6.

>If we only mean 'managed addressing' with M, and

>Other config with O  then each flag is aligned

>with a particular flag.

Also this draft wrote as below;

This document defines an internal (conceptual) variable for DHCPv6

policy.  The value of this variable in conjunction with the

"ManagedFlag" and the "OtherConfigFlag" of ND protocol
[RFC2461]

will be used for invoking the DHCPv6 for autoconfiguration.

And

Particularly, both "ManagedFlag" and "OtherConfigFlag"
which were

implementation-internal variables were removed during [2462bis]

work based on the WG consensus with ambiguous operational

experiences, thus new variables (or similar approaches) is

required to treat M/O flags of IPv6 RA on the host.

>If we have flags which can be used for both

>purposes (like if M=1,O=0 allows hosts to send

>information-requests) then our policy names need

>to be adjusted.

It depends on what configuration is configured. As I indicated above

host which is only available stateful DHCP at its network can configure

other configuration informations via stateful DHCP.

>I think that hosts SHOULD NOT use policy 1 by

>default though.  If they do, it should be by

>explicit configuration.

So, we tried to define the default values of the policies as below;

If the node implementes [RFC3315], the default value of M-Policy

is 2.  If the node does not implement [RFC3315], the default (and

only) policy value is 3.  When assuming [RFC3637] will be

implemented much wider that [RFC3315] in terms of other

configuration information, the default value of O-Policy is either

1 or 2.  Perhaps value 1 is better since this service might be

crucial for the node (i.e., there may be no alternative to get the

other configuration information.)

I believe above mention considers what you worry...

Hope this helps...

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics