Hesham - you're suggested revisions are fine with me.
One typo - in the text for the on-link flag, s/addresse/address/
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.
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".
- 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
--------------------------------------------------------------------
