Hello, Ralph and all. I would like to insert another option into the following list. draft-ietf-ipv6-ra-mo-flags-01.txt I am not clear why this WG document failed to proceed. However, I view this document as nice base docuement since I think that it seems that we do not have clear reason to deprecate M&O bits and it is more desirable to let host's local policy override M&O bits in received RA.
One thing I would like to point is that our draft "draft-cha-ipv6-ra-mo-00.txt" just aims to clarify old specifications(RFC2461/2462) and provide better guidance to implementors. So, I would say that our draft can be merged with "draft-ietf-ipv6-ra-mo-flags-01.txt" or extended to contain the whole framework w.r.t processing the bits. Joseph > 2. NO: How does the IETF want to change this consensus and how should the > change process be conducted? > > There have been some suggestions for changes to the current consensus > behavior: > > * Deprecate the M/O flags; require that future DHCPv6 clients ignore > the M/O flags; require that routers send RAs with M/O flags set to 1 > * Revert to previous definitions and behaviors in RFC 286* > * draft-cha-ipv6-ra-mo-00.txt 2008/10/17 Ralph Droms <[EMAIL PROTECTED]>: > I've been tracking this discussion about the M/O flags, which seems to be > going in several different directions. I thought it might be useful to try > to get some agreement on what needs to be done so we can focus on coming to > consensus on a course of action. It also seems like a small group of > participants has gone pretty deep into some technical details, which might > be irrelevant depending on the consensus of the IETF. > > Here's a quick, informal survey to assess consensus about how to proceed. > Please reply to the list so we can focus our discussion. Thanks. > > 1. Is the following text an accurate summary of the previous IETF > consensus on the definition and use of M/O bits: > > The M/O flags indicate the availability of DHCPv6 service for > address assignment and other configuration information, > respectively. The IPv6 specifications make no requirements on the > behavior of DHCPv6 clients in response to the values of the M/O > flags received in RAs. > > 2. Does the IETF choose to continue to accept this consensus or should > the definition of client behavior in response to the M/O flags be > revisited? > > 2. YES: Is that consensus adequately described in the IPv6 RFCs or should > the IPv6 RFCs be revised in some way to describe the consensus > requirements? > > 2. NO: How does the IETF want to change this consensus and how should the > change process be conducted? > > There have been some suggestions for changes to the current consensus > behavior: > > * Deprecate the M/O flags; require that future DHCPv6 clients ignore > the M/O flags; require that routers send RAs with M/O flags set to 1 > * Revert to previous definitions and behaviors in RFC 286* > * draft-cha-ipv6-ra-mo-00.txt > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
