> > => So based on 1) and 2) I suggest that people who want to continue
> > this discussion, despite the chairs' recommendation should
> limit the
> > discussion to the M flag. If there are implementations that support
> > the O flag then removing it should be out of the question.
>
> Fair enough, in that this is the chair's recommendation.
>
> But please note that these implementations assume what is not
> described in RFC2462; they assume the protocol corresponding to the O
> flag is stateless DHCPv6 (RFC3736). So, *if* we need to remove the M
> flag due to the lack of implementation process-wise but we can keep
> the M flag because of these implementations, the description in
> rfc2462bis regarding the O flag should be consistent with the
> assumption, as a logical consequence. We should probably clarify in
> rfc2462bis that the protocol for the O flag is RFC3736, and nothing
> else. (For that matter, I'm happy with it.)
=> I'm happy with that too. Associating the O flag with stateless DHCP
is ok because that's all we have today. If later other options come up then
the RA can be extended further. But we don't need to worry about this now
for 2461/2 bis.
> We do not have an implementation on some part of RFC2462. Can we
> still recycle rfc2462bis as DS (process-wise), keeping that part,
> despite the lack of implementation?
>
> If the answer is yes, we can concentrate on technical aspects of the
> discussion for both the M and O flags.
>
> If the answer is no, we need to somehow deprecate/remove the M flag,
> and then concentrate on issues about the O flag (as you suggested
> above).
>
> I simply do not understand the answer to the general question, and I
> think it's too early to suggest something at the moment, assuming the
> answer is "no". (I'm not intending to say this as a deal for
> "killing" the O flag as well. Rather, I'm saying this because we can
> even keep both flags if the answer is "yes".)
>
> Again, I'd really like to hear the answer to the general question
> from someone familiar with the process. Thanks,
=> I guess that's outside my job description ;) this is something for the
chairs/ADs. I saw one email from the chairs on this.
Hesham
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center,
> Toshiba Corp.
> [EMAIL PROTECTED]
>
========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
========================================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
