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