> > Hesham - you're suggested revisions are fine with me. => Ok, thanks!
> > One typo - in the text for the on-link flag, s/addresse/address/ => Done. > > And, at the risk of being overly picky, after searching > through the RFC for > occurrences of "autoconfiguration", it seems there is some > inconsistency in > the use of other related terms, like autoconfiguration and address > autoconfiguration (used for both SLAAC and DHCP). > > The definition in the terminology section seems OK: > > Address Autoconfiguration: How nodes automatically configure an > address for an interface. > > ...referring to both stateless address autoconfiguration and DHCP. > > Howvever, at the end of section 2.3: > > (e.g., while verifying an address is unused > during address autoconfiguration [ADDRCONF]) > > While this is not normative text, I use it as an example. > If, in this case, > "address autoconfiguration" refers to just SLAAC, it should > be "stateless > address autoconfiguration". On the other hand, if "address > autoconfiguration" is correct, then there should be a > reference to DHCPv6 > (RFC 3315) as well as [ADDRCONF]. > > As another example, at the end of section 4.2: > > Prefix Information > These options specify the prefixes that > are on-link > and/or are used for address autoconfiguration. > > Here, the reference should be to "stateless address > autoconfiguration"; the > prefix information is not used by a host using DHCP. => Understood. I'll do a search and change it where it needs to be changed, I'm assuming the above doesn't cover all places. > > I apologize for noticing this issue at the last minute. In > response to the > question about "stateless autoconfiguration" and "autonomous > autoconfiguration", I wanted to see if there were other phrases using > "autoconfiguration". That search lead to the discovery of > the inconsistent > uses of "autoconfiguration". => No problems, they're all good catches. Thanks for your feedback and quick response. I intend to submit the draft tomorrow. Hesham > > - Ralph > > > On 1/5/07 3:40 AM, "Hesham Soliman" <[EMAIL PROTECTED]> wrote: > > > Hello again, > > > > This is a follow up on the comments we discussed earlier. > Ralph, please let > > me know if you're ok with my suggestions below. The > document is waiting on > > your response! The rest of your comments are all in the document. > > > >>>> I think this is general advice to people thinking about > >>> how ND applies > >>>> to link layers other than, say, ethernet. Clearly, ND > >>> applies to all > >>>> specs, unless superceded by another spec for a particular link > >>>> layer. That is all that this section is (IMO) trying to > >>> say. I.e., to > >>>> suggest when another spec might be needed and where not. > >>> > >>> I think I understand the meaning the text is supposed to > >>> convey. But the > >>> text doesn't seem (to me, anyway) to convey that meaning > >>> very well; I note > >>> your interpretation is qualified with "IMO" and perhaps > >>> another reader might > >>> have a different opinion? > >>> > >>> To be more concrete, it appears that the section is > >>> describing how or which > >>> parts of ND should be implemented on links with certain > >>> attributes. But the > >>> last several entries don't seem to be very clear or precise. > >> > >> => Ok, does anyone object to removing that statement from > the spec? > >> The statemement I'm referring to is the one Ralph refers to above: > >> "Neighbor Discovery should be implemented as described in > >> this document." > >> It seems superfluous anyway. > > > > => So here is the text for the section in question: > > > > point-to-point - Neighbor Discovery handles such links just like > > multicast links. (Multicast can be trivially > > provided on point-to-point links, and interfaces > > can be assigned link-local addresses.) > > > > > > multicast - Neighbor Discovery supports multicast capable > > links as described in this document. > > > > > >>> Yeah, I agree the text means "don't draw any conclusions > >> about on- or > >>> off-link is L bit is not set". What are the ramifications > >>> of the L bit not > >>> being set; what other parts of this or other protocols > >> are affected? > >> > >> => If the L bit is not set a host cannot assume that an > >> address is on-link, therefore it will send all packets to > >> its Default router, unless a redirect is received for a > >> particular address. > > > > => I've clarified the definition a bit more: > > > > L 1-bit on-link flag. When set, indicates > that this > > prefix can be used for on-link > determination. When > > not set the advertisement makes no > statement about > > on-link or off-link properties of the prefix. In > > other words, if the L flag is not set a host MUST > > NOT assume that an addresse derived from > the prefix > > is on-link unless it is explicitly told > in another > > message (e.g. Redirect). For instance, the prefix > > might be used for address configuration with some > > of the addresses belonging to the prefix > being on- > > link and others being off-link. > > > > Any objections? > > > >>> Except for its use in supplying the initial for the 'A' > >> bit in prefix > >>> options... > >> > >> => I agree. So how about we state in the document that the > >> terms "stateless autoconfiguration" and "autonomous > >> autoconfiguration" are used interchangeably? People are > >> familiar with the meaning of the A flag and with the term > >> "stateless autoconfig", removing either one is probably > >> going to add more confusion than clarity. It might have to > >> be one of those imperfections of a doc that developed over a > >> long time. Is this ok? > > > > => Is this ok? > > > > > > Hesham > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
