A side comment independent of the site-local discussion. > Thus spake "Keith Moore" <moore@cs.utk.edu> > > nope, the app. the stack doesn't know whether the app > prefers stability > > or efficiency, unless the app tells it which it prefers. > but at least > > the app probably has an idea which one is better. > > The app developer often doesn't know these things either -- > if the app > understands this new API at all, I think it'd most often end > up as a user > knob, meaning we could just call it a stack option and leave > the app out of > things entirely. > > > this is fundamentally different than expecting either the > host or the app > > to choose between multiple source or destination addresses, each > > pair imposing apparently (to the host and app) arbitrary > constraints > > on what the network will pass. > > Which is harder, having the stack give the app a list of source and > destination addresses and then expect the app to figure out > which to use, or > have the stack attempt various combinations of source and destination > addresses and just notify the application which one(s) worked? > => There is another option: _Abstract_ the API to the app to reflect the "benefits" or "meaning" of either option. For instance, if you compare the MIP home address and CoA, you can abstract the meaning of these addresses to indicate things like whether the connection needs to be "stable" or not. There are other cases where the stack might already know what a well-known app might need. So there maybe a need for both sides to provide input. And things get more complex of course when the app has many requirements. If we have to make a general rule then I'd prefer the app to decide. But I'm not sure that there is a need for a general rule here. Hesham > Something tells me the latter is both easier and more likely to be > implemented correctly. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > -------------------------------------------------------------------- > 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 majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >