Peter, Thank you again for your feedback. Alex Peter Tam wrote: > > > Alex: > > I can live with your clarifications. Thanks ...Peter > > -----Original Message----- > From: Alex Conta [SMTP:[EMAIL PROTECTED]] > Sent: Monday, July 10, 2000 6:43 PM > To: Tam, Peter [NORSE:6L73:EXCH] > Cc: [EMAIL PROTECTED] > Subject: Re: W.G. Last Call on "Extensions to IPv6 > Neighbor Discovery for Inverse Discovery Specification" > > 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] > > ------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
