Just trying to catch up on email... a few comments below. I've already seen other people answering most questions in the same way I would, so (as another individual who supports this draft going forward) I'll concentrate on responding to other points.
Margaret writes: > I think that it should be required (a MUST) that nodes that > implement this specification provide a method to override the > default values manually. I support this suggestion. (Others might suggest removing the word "manually".) Pekka writes: > Options a) - c) should be sufficient to describe how the routing system > will get the information. Perhaps it should be reworded to be something > like: > d) Developing an "announcement" protocol [...] > [...]. However, the three first mechanisms should > cover the necessary techniques sufficiently for most cases. I would support this suggestion as well. Jonne writes (responding to Pekka): > I do not really see what harm would three addresses do. You may have > networks that would have only one DNS server (small business or a home > user with for a reason or another his own DNS server). However, in cases > like ISPs or bigger businesses there may be multiple DNS servers > configure. I believe this is the case even now. Correct. Three was chosen based on common practice in the many places in the industry. While it's true that if the first one fails, that it's unlikely the second one will succeed (due to there really being no DNS server at all), using multiple addresses is important so that when ones do exist, the host can fail over to a second server more quickly than routing converges. More on this below. Rob writes: > My main objection was and remains that this mechanism, if used, moves > state away from the endpoints and into the network in a way that cripples > the resolver's ability to keep track of which of the name servers it is > using are performing properly, since the binding between any particular > well-known-address and the name server behind it might change at any time > and since there is no mechanism by which the resolver can find out that > such a change has taken place. The above objection appears to be against anycast addresses. This draft is about *unicast* addresses, not anycast addresses. Hence, no such change can take place. The use of 3 unicast addresses is specifically to enable the resolver to keep track of which of the name servers it is using are performing properly. -Dave -------------------------------------------------------------------- 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] --------------------------------------------------------------------
