I am basically in agreement with your approach; here are a couple of
specific comments:
> 1. clarify (change) the meaning of the M/O flags; they are just hints
> of availability of the corresponding services, not triggers for
> invoking the protocols under a certain level of requirement
Rather than "hints", the M/O flags explicitly indicate that the
corresponding service is intended to be available (note that the service
might not be available due to some network or system failure).
> 2. remove "requirements" regarding these flags according to the above
> change
Agreed.
> 3. (optionally) make a separate document (standard or BCP) on how to
> interact the protocols with these flags
Can you give some examples of what conditions or interactions might be
included in such a document?
I agree that we are in consensus about your three basic assumptions:
> - we should clearly specify the corresponding protocols for the M/O
> flags
> - the protocol for the M flag is DHCPv6 (RFC3315)
> - the protocol for the O flag is the "stateless" subset of DHCPv6
> (RFC3736)
Considering your specific examples:
> For 1, I'd revise the following sentence of RFC2462 Section 4 (page
> 9):
> A "managed address configuration" flag indicates whether hosts
> should use stateful autoconfiguration to obtain addresses.
> to:
> A "managed address configuration" flag indicates whether DHCPv6 is
> available for hosts to obtain addresses.
Agreed.
> For 2,
> - remove the notion of the ManagedFlag and OtherConfigFlag
> (conceptual) variables defined in Section 5.2, since these flags
> will become meaningless if we do not mandate invoking particular
> protocols by the RA M/O flags.
Agreed.
> - remove "requirement" sentences like the following one
> If the value of ManagedFlag changes from FALSE to TRUE,
> and the host is not already running the stateful address
> autoconfiguration protocol, the host should invoke the stateful
> address autoconfiguration protocol, requesting both address
> information and other information.
> (Section 5.5.3 of RFC2462)
This particular sentence would go away because of the previous bullet
(removing ManagedFlag and OtherConfigFlag)? In general, editing out
requirements sentences sounds like the right thing to do.
As an aside, thinking about legacy implementations, I think the idea of
making the M/O flags indicators rather than triggers will avoid backward
compatibility problems. For example, if an implementation uses an
OtherConfigFlag according to the current RFCs, it will use DHCPv6 for other
configuration when the O flag first transitions to the set state, and
continue to use DHCPv6 regardless of subsequent transitions. Such behavior
seems to be compatible with the proposed changes (both practically and
because the proposed changes make no requirements on client behavior).
What about the situation if the 'M' flag transitions from set to not set? I
don't have a good answer off the top of my hear...perhaps this situation is
an example of what should go into the BCP document you suggest?
> - remove Section 5.5.2 of RFC2462 (that mandates performing the
> "stateful" protocol when no RAs)
Yeah, I guess this would fall under the general recommendation that M/O are
indicators and not triggers, and the client behavior if no RAs are received
might be discussed in the BCP doc...
- Ralph
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
