I think we may need to understand what are the real problems that people/organizations (i.e. carriers, ISPs and vendors and users) have been currently struggling with in terms of simultaneous use of multiple networks. I think, Ralph seems to have clearly brought applicable practical use cases and/or criteria. So, with the use cases it might be worth to clarify if MIF will address and provide some recommendation for (at least) BCP which can answer to those use cases. If MIF does not (instead, only addresses partially, such as conflicting configurations and/or others), there may need other working group for focusing on BCP for the end-to-end practice of simultaneous use of multiple networks/interfaces. I believe that there is no working groups currently where can provide this kind of recommendation. They may be also willing to address partially from their perspective, similar with MIF if MIF want to tackle the problem partially. I think that we already know that simultaneous use of multiple networks is very crucial issue in various aspects by various organizations. Most of current carriers/ISPs/mobile device (including laptop) manufactures seems to be willing to hear about efficient, reliable and best common practice to handle the problem. Giyeong -----Original Message----- From: mif-bounces@xxxxxxxx [mailto:mif-bounces@xxxxxxxx] On Behalf Of Ralph Droms Sent: April 23, 2009 12:08 AM To: Christian Vogt Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins; Keith Moore; Hui Deng; IETF Discussion Subject: Re: [mif] WG Review: Multiple InterFaces (mif) 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? - 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf