> > the point is that the host implementation is almost the worst possible > > place to override that default. the app knows what kind of > > addresses > > it needs, so it is in a good position to make such decisions. the > > user understands his own need for privacy, but he probably doesn't > > understand the implications of such a decision for his apps, > > so he's not in the best position. the host implementor knows > > even less than the user - unless you are talking about > > appliance hosts cannot be programmed by the user. in the > > latter situation the app implementor and the host implementor > > can be considered the same, and it's as easy for the app to > > select the proper kind of address than for the host > > implementor to do so. > > I agree that the app is in the best position - hence the change in 08 to > require the API to give the app the tools to make a decision. It sounds > like you agree with that.
yes. > The question is what to do when the app hasn't made a decision. the host has no way of knowing that, since the way that apps have traditionally (for the past 20 years) asked for a stable address was by listening on a port or establishing a connection - because stable addresses were (until recently) all that was available. > There's > more than one kind of bug. Having an app break because it chose an > address that expires in a week is a bug. Having an app compromise a > user's privacy is also a bug. right, but surely you're familiar with the phenomenon that a significant percentage of bug fixes cause multiple bugs, often because the "fix" makes unwarranted assumptions. to fix the bugs in apps that compromise users' privacy without creating lots of new bugs in the process you have to fix those apps. you can't do it in the host. > The implementor must consider what kind of > bug is more important to their user community, how many apps are not > using the API to make a decision, what are the relative likelihoods of a > problem, etc. the host implementor is generally not in a good position to consider such issues or to make such decisions. this is particularly true for a host implementation that is used for diverse purposes. > > as you say, the SHOULD clause already allows an escape in the > > case where the host implementor clearly understands the > > implications of the decision - though that tends to require > > the host implementor to understand what apps will be run on > > the host, since the implications will vary from one app to another. > > > > on the other hand the MAY clause doesn't require the host > > implementor to understand those implications. it would > > therefore be better to > > remove the MAY clause entirely. > > The MAY clause is not intended to let implementors prefer temporary > addresses without understanding the implications. The paragraph > containing the MAY discusses the implications. Perhaps you would be more > comfortable if it were "may" instead of "MAY"? no, because the MAY (or may) clause incorrectly implies that host implementors are in a good position to make such a decision. they're not. 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] --------------------------------------------------------------------
