Hesham - thanks for all your hard work on the doc... - Ralph
On 1/5/07 6:37 AM, "Hesham Soliman" <[EMAIL PROTECTED]> wrote: >> >> 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 --------------------------------------------------------------------
