Ralph, This simplification and use of language looks good.
As an aside: There is a minor discrepancy in text between 2461 and 2462 that could perhaps be clarified in the -bis work for those texts. This is regarding the M flag referring to addresses and other options, or just addresses. Three parts of the texts have different nuances: a) 2461 section 4.2 says M flag means hosts use the stateful protocol for address assigment, and O flag means hosts used the stateful protocol for other (non-address) information. b) Then in 2462 it says in Section 4 (p.9) and Section 5.2 (p.11) again that a "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses and an "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). c) But then in 5.5.3 of 2462 the RA processing text states what I expect most (all?) implementations actually do: "If the value of ManagedFlag changes from FALSE to TRUE ... the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information." (i.e. for both information) So the question is should the wording of (a) and (b) be changed to reflect the processing text of (c)? On their own, (a) and (b) suggest that to get the behaviour of (c) *both* the M and O bits should be set, but (c) states that only the M bit need be set for full stateful autoconfiguration. Tim On Thu, Dec 04, 2003 at 03:51:30PM -0500, Ralph Droms wrote: > Here are some comments and suggested text for > draft-ietf-ipv6-node-requirements-06.txt: > > > It would be good to use either DHCP or DHCPv6 (but not both) consistently > throughout the doc. > > > 5.3.1 Managed Address Configuration > > The first two paragraphs are sort of redundant relative to the second > paragraph in section 4.5.5. I suggest that the union of the information in > the two sources be put into section 4.5.5, and the first two paragraphs of > 5.3.1 be deleted. > > I suggest the following text for 5.3.1: > > Those IPv6 Nodes that use DHCP for address assignment initiate DHCP > to obtain IPv6 addresses and other configuration information upon > receipt of a Router Advertisement with the 'M' flag set, as > described in section 5.5.3 of RFC 2462. In addition, in the > absence of a router, those IPv6 Nodes that use DHCP for address > assignment MUST initiate DHCP to obtain IPv6 addresses and other > configuration information, as described in section 5.5.2 of RFC > 2462. Those IPv6 nodes that do not use DHCP for address assignment > can ignore the 'M' flag in Router Advertisements. > > > 5.3.2 Other configuration information > > I suggest changing the title of this section because the development of > DHCP has moved toward using a DHCP in a way that is typically known as > "stateless". I recognize the potential confusion with RFC 2462, in which > "stateful" is pretty deeply embedded. > > I think the first paragraph of 5.3.2 is redundant and should be merged in > with the text in 4.5.5. > > I suggest the following text for 5.3.2 > > Those IPv6 Nodes that use DHCP to obtain other configuration > information initiate DHCP for other configuration information upon > receipt of a Router Advertisement with the 'O' flag set, as > described in section 5.5.3 of RFC 2462. Those IPv6 nodes that do > not use DHCP for other configuration information can ignore the 'O' > flag in Router Advertisements. > > An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] > to obtain other configuration information. > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
