kre, I agree of course that the document isn't trying to define an API in any kind of detail, nor (mostly) does it describe what an API needs to do. I'm arguing that it *should* be written in those terms, because there's no right address selection algorithm that works for all cases, and any assumptions about what constitues the majority of cases are fairly dubious.
Also, the big issue about e.g. privacy/temporary addresses vs. stable addresses is best looked at as a backward compatibility issue - new or revised apps can be encouraged to specify which they want in any case, but we can't change existing binaries. > It isn't a protocol issue, in the sense that things will break if you > don't pick the "right" addresses, no more than there is a protocol issue > in the sense that things will break if you don't do a random delay before > sending a RS packet - but doing these kinds of things properly improves > the overall operation of the net, using the right addresses can get > packets though better. It may be true now that nothing much in this > doc will actually achieve that, but if we know which addresses will be > selected by apps, we can engineer things so those work best. I don't think it's reasonable to expect apps in general to be predictable in that way - the needs of apps vary from one app to another and the behavior of a typical app (if there is such a thing) will vary over time and from one place to another. Or to put it another way, if you try to engineer the network by first defining how apps behave w.r.t address selection and then basing other design/configuration decisions on that, you end up making the network design/configuration favor that kind of apps (and penalize others) - without any regard for whether this is a reasonable or desirable compromise. e.g. the inability of the network to support distributed apps, or apps that run for a long time, or apps that need privacy (to give three examples of potential outcomes) becomes an 'unintended consequence'. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
