Peter,
Thanks for a more detailed list of comments. Your reviewing is going to
be acknowledged in the I-D.
As I am preparing the text for a new version of the draft, my thoughts
related to your comments are:
Regarding your first suggestion, whose ramifications I understand now
better than before:
> >...
>
> >> Currently, the draft does not restrict the types of addresses
> within the Source/Target Address Lists in the IND
> Solicitation/Advertisement messages. Thus, it implies that both
> unicast and multicast addresses are legitimate. This address
> information is used to build the Neighbor cache, which I believe
> can contain only unicast addresses.If unicast-only addresses are
> imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should
> discard IND messages containing multicast addresses, so that they
> will not be entered into the cache. After all, resolution should
> be between link layer addresses and unicast network addresses.
>
the text in the current draft is aligned with the original intentions in
specifying the protocol:
- do not make strong implementation requirements
the I-D specifies that the Neighbor Discovery Cache MAY be
populated with address information acquired via IND. Which is
to say strongly that the Protocol for populating the ND cache
is and remains ND.
- allow a certain level of generality and flexibility to the address
discovery mechanism, which may be useful for the type of links to which
the protocol applies.
for links that do not have an algorithmic mapping of IP
multicast addresses into link addresses, there is - I think -
a need for storing/caching the address information used in
resolution. What is, or how the place for storing multicast
address information is called, is an implementation issue. A
mechanism to convey the information used in resolution is also
useful . In saying this, as I did in the I-D, I am trying to
stay away though from making implementation suggestions.
As I still do not see any particular bad side effects, I think the
original goals as followed by the text are worth maintaining, In that
sense, I think, RFC 2390 sets also an example.
> >....
>
> > 1. Appendix A: Frame Relay (FR) as a link-layer address. But
> it
> > should have a note up front that the DLCI applies to the
> member
> > DLCI in the case of a Multi-link Frame Relay.
> >
>
> The appendix was intended to contain one simple example to
> illustrate
> the use of the protocol. Some particular details of the link in
> the
> example were considered out of scope.
> >> Out-of/in scope is an artificial line. In this case, all it
> takes is only 1 line of clarification.
>
Let me rephrase my thoughts on this:
the example in Appendix A is not a Multi-link Frame Relay example, and
Multi-link Frame Relay is not mentioned at all. If Multi-link would have
been mentioned, in one way or another, then I could have better seen a
reason for confusion, and a need for clarification, but without that,
this is a way to not extend the scope beyond what was intended, and also
minimize the number of words or sentences.
Thanks again for your input.
and regards,
Alex
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
