Ralph Droms a écrit : > Christian - I think address selection is part but not all of the problem. > > I would be happy to see a summary of current practice in dealing with > simultaneous attachment to multiple networks. How does an iPhone decide > between its WiFi and dell interfaces? How does an RG that can reach > multiple next hop routers on its WAN interface select which router to > forward to? How does a laptop choose between its WiFi and wired > interfaces? that is the purpose of draft-mrw-mif-current-practices... Some answers are already there. Marc. > > - Ralph > > On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote: > >> On Apr 22, 2009, Margaret Wasserman wrote: >> >>> This topic, address selection, is not currently handled by applications. >>> In many cases, it is handled entirely by the stack (through ordering of >>> the destination ddresses in DNS replies and source address selection in >>> the IP stack), and in other cases the application chooses a destination >>> address with the stack choosing a source address. There are certain >>> cases (sometimes in solutions to the problems that we are discussing >>> here) where applications do choose both the destination and sourece >>> address, but they are not common. >> >> >> Margaret - >> >> From a system perspective, you are certainly right: Applications >> typically do get help from the operating system in selecting their >> addresses. From an OSI layering perspective, though, address selection >> still is performed at application layer. In fact, if an application >> wants to do a complete job, especially a peer-to-peer application, it >> needs to select both source and destination address itself, possibly >> after running STUN, TURN, or ICE. >> >> My main point, though, was that we are talking about two orthogonal >> issues -- conflicting configuration and address selection. This holds >> independently of the fact that an application may let the operating >> system accomplish part or all of address selection. >> >> Whether we take this to mean that both issues should be tackled in the >> same working group is a different story. I personally don't see the >> orthogonality of the two issues as a reason not to tackle both issues in >> the same working group. We just ought to be aware that the issues are >> separate, and the charter should describe them as such. This said, >> there might be work-load- or work-scope-specific reasons that suggest >> splitting the work into separate working groups, like those brought up >> by Lars, Sam, and Scott. Those arguments should be discussed as well. >> >> - Christian >> >> >> >> _______________________________________________ >> mif mailing list >> mif@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ > mif mailing list > mif@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mif -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf