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
--------------------------------------------------------------------
