Hi Jinmei, Sorry about the confusion.
----- Original Message ----- From: JINMEI Tatuya / ???? <[EMAIL PROTECTED]> Date: Thursday, August 5, 2004 7:31 am Subject: regarding some comments on the M&O draft > 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? I was worried about the SAA M and O flags having information available such that M could be used to invoke stateless configuration procedures on a host (since 2462's statement in 5.5.3 about getting addressing and other information). I talked to Dave Thaler about this after the session and (I think agreed) that if the M flag is only used for indicating that stateful address configuration is available, and the O is always set when non address configuration information is available, then the names are OK, and we only need to look each flag individually. I was concerned that M|O could be used to invoke DHCP information-requests (rather than just O). If we only mean 'managed addressing' with M, and Other config with O then each flag is aligned with a particular flag. 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. > 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.) Removing policy 1 may be an option, but it's may also be good to have a way to provide an override capability if needed. I think that hosts SHOULD NOT use policy 1 by default though. If they do, it should be by explicit configuration. > 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) The 'my' is just how I pronounce '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. I agree. > (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, I hope that there has been some clarifcation. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
