Peter, Thank you for your comments, which are important for the improving of this specification. For the first comment, I need more clarification, but it is probably better if I take the comments and answer them one by one, so please see bellow: Peter Tam wrote: > > > Bob: > > This is the 1st time I read this draft. Apology if the following have > been discussed before: > > 1. Must the Target Address List option in the Inverse Neighbor > Discovery Advertisement (InvNDA) message not contain unicast IPv6 > addresses only? I think it must. Then it will affect section > 4.3.2 on the validation procedures. > Would you please elaborate? > 1. Should it not also support unsolicited InvNDA, when 1 or more of > an inteface's IP addresses have been changed? It should, and > should also enforce to re-advertise all the addresses on that > interface. Otherwise, it is not possible to cover the scenario > where an IP address on the interface was deleted. > The motivations to the present text in the specification were the following: 1. Minimizing and possibly eliminating unsolicited messages is a good thing. 2. The scenario in which one or more new IPv6 address are added to an existent VC can be solved by having the node adding such addresses send IND Solicitation(s). 3. The scenario in which one ore more IPv6 addresses associated with a VC are deleted while the VC and DLCI remain was envisaged to happen seldom - more often, the VC and DLCI would be torn down as well - and be resolved through the IPv6 address deprecation. > 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. > 1. Why is there a preference of FR to ATM in Appendix A? Should also > include the case for ATM as a link-layer technology. > > As said previously, the appendix contains just one example, to illustrate simply and briefly the use of the protocol. Although it is mentioned that it may apply to other link technologies, it was not intended to cover more or all possible link technologies. > > > Regards... Peter Tam, > Nortel Networks, Ottawa Thank you, Alex Conta Transwitch Corporation, Shelton, CT > > > -----Original Message----- > From: Bob Hinden [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, June 22, 2000 4:27 PM > To: [EMAIL PROTECTED] > Subject: W.G. Last Call on "Extensions to IPv6 Neighbor > Discovery for Inverse Discovery Specification" > > This is a IPng working group last call for comments on advancing > the > following document as a Proposed Standard: > > Title : Extensions to IPv6 Neighbor Discovery > for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-03.txt > Pages : 22 > Date : 27-Oct-99 > > Please send substantive comments to the ipng mailing list, and > minor > editorial comments to the author. This last call period will end > two > week from today on July 6, 2000. > > Bob Hinden / Steve Deering > > > ------------------------------------------------------------------- > > 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] --------------------------------------------------------------------
