Note Taker: Stuart Cheshire * draft-ietf-mif-problem-statement-05 Document in IESG review Comments received from Dan Romascanu, Lars Eggert, Ralph Droms, Adrian Farrel, Sean Turner (See mif-6.ppt) * draft-ietf-mif-current-practices-02 Review comments from AD: Marc Blanchet: I wrote Mac OS X section based on observed evidence, not from looking at the Darwin Open Source code Bernie H: Move information to appendix Jari: Delete if incomplete Andrew Sullivan: Partial information is better than none Marc Blanchet: I disagree. Incorrect information is worse than no information Margaret: The sections are really very weak. Was hoping to prompt vendor input. Andrew Sullivan: I still think partial information is better than none. In the DNS community we have documented various aspects of brokenness. Jari: Current text is currently not confusing and not very helpful. Margaret: How to improve it? Jari: State that text covers only some aspects of OS behavior, and not others. Margaret: Conclusion is we need to make text clear, or remove it. Ted Lemon: There's another draft from Nokia which describes behavior. A standardized template for the descriptions would make it clearer which information is missing for which OSes. * Split-DNS solution (Teemu, 10 min) Jari: Lack of "." entry means no "default resolver". What does lack of this DHCP option mean? Teemu: This is not Not deprecating the existing DHCP option Jari: Need to document how it interacts with existing DHCP option. What if packet has both? Neither? Dave Thaler: What if one interface gets old DHCP option and other interface gets this new DHCP option, how do they interact. Ted Lemon: This seems like a really bad idea. Security implications are mind boggling. Creates lots of opportunities for attacks without stating how to deal with them. Using this option should *require* DNSSEC. Teemu: Vulnerabilities are not new. Ted Lemon: But this allows more targetted vulnerability. Teemu: RFC 4191 Ted Lemon: This is the wrong way to solve problem. Should not be adopted by WG. If we want to add a new DHCP option we should add a new DHCP option saying "you're connected to a hot spot". This adds complexity with no benefit. Stuart Cheshire: Problem is conflicting info. When you have two interfaces, and two DHCP configurations, giving two DNS servers, and the two DNS servers give conflicting answers, what do you do. Ted: Public DNS server should simply drop packets asking about name that may exist in some other "private" server, instead of NXDOMAIN. Stuart Cheshire: Defining "silently drop" as response to query seems odd. Dave Thaler: Servers currently respond with NXDOMAIN for private internal names that don't exist externally. This WG is limited to defining client behavior in today's world, not mandating new behaviour for servers and operators. Olafur: When connected to multiple providers, may get better answers from some providers that others. E.g. On phone connected to China Mobile and IETF WiFi, may get different answers for "google.com" from each provider. I may consider the IETF WiFi answer "better", but not if I'm going to try to reach it over China Mobile. Andrew Sullivan: Arguments sound circular. How do we figure out what network context we are in? Gaetan Feige: Repeated Olafur's point. Andrew Sullivan: Hui Deng: Is this ready to adopt? Jari: Don't think this draft is ready to adopt as WG draft. Teemu: We talked about this in Maastricht, and no one commented on the mailing list that time. Don't want to wait until Prague to talk about this again. * DHCP Route Option draft, Wojciech Dec See mif-1.ppt Hui Deng: How many people have read draft? 20 Hui Deng: How many people think we should adopt as WG item? 15 Hui Deng: How many people think we should not adopt as WG item? 0 * MIF api (Juri, 10 min) TED Hardie: Session layer using DTLS. Want to be able to talk about groups of interfaces as well as individual interfaces. Not clear this API supports that. Ted Lemon: You've gone quite a long way down a path here. Not saying it's the wrong path, but I've seen no discussion of this on WG mailing list. What functionality does OS have to provide? Should propose some high-level API(s), and from those, work out what functionality does OS have to provide. Juri: This is intended to be a starting point, not far down a path or a final solution. Ted Lemon: Would like to see public discussion on WG mailing list. Juri: We plan to start implementing soon. Dave Thaler: We faced these problems. We use Scope ID and sockaddr. A Scope ID names set of interfaces. Dave Thaler: Should separate abstract API issues from concrete API issues. Concrete sockets API is owned by Austin group. * Connection manager requirements (Gaetan Feige , 10 min) Gaetan Feige: "Connection manager" may be a poor choice of name. Gabor Bajko: Some of these cases are annoying. When you have link layer connectivity but no IP connectivity until you authenticated. There is is ongoing work in the WiFi alliance. WiFi alliance covers both service provider space and enterprise space. Gaetan Feige: My understanding is that the WiFi alliance covers user authentication, but doesn't cover routing, DNS, etc. Gabor Bajko: WiFi alliance covers Problem Margaret W: WiFi alliance work tends to be WiFi-specific. Is WiFi alliance work covering ways of having Gabor Bajko: WiFi alliance work focuses on picking right WiFi network to join; still up to implementation to test if IP connecivity works. Margaret W: So WiFi alliance provides part of the answer but there are still problems that MIF needs to address. Yuri Ismailov: What kind of "session layer" are you talking about? Yuri Ismailov: Managing/configuring virtual interfaces? Virtual interfaces should be standardized and presented explicitly to the system. Gaetan Feige: Linux advanced routing has routing stack per interface. Yuri Ismailov: API should expose purpose of each virtual interface. Gaetan Feige: Don't want to burden every application with handling multiple interfaces. Want to try to make it automatic. Andrew Sullivan: Need to solve this for DNS too. This is exactly the circularity argument we were having earlier. * Holding the on-going sessions (Zhen, 5 min) Yuri Ismailov: When talking about solutions to this problem, do Mobile IP, HIP, SCTP, etc. already solve this problem? Zhen: With IP mobility sessions move to new interface Yuri Ismailov: Application session moves to new interface Zhen: Intention here is that when new interface becomes available, new sessions use that new interface but established sessions continue to use old interface. Dave Thaler: When you say "session" do you mean "TCP connection" or something higher layer? With strong host model this is not a problem, because TCP connection stays bound to one interface. Gaetan Feige: Windows has strong host model? Dave Thaler: Yes, everything later than XP uses strong host model for both IPv4 and IPv6. Gaetan Feige: Strong host model can mean that you have lots of bandwidth available that you're not using. Margaret: Does WG think we should extend problem statement to cover what to do with ongoing connections when network environment changes? Simon Perreault: Problem should be reformulated in terms of host models: Weak or Strong. Margaret: You mean we should state that if you use strong host model then you'll have these issues; if you use weak host model then you'll have these other issues. Juan-Carlos Zuniga: We still have some homework to do, but I belive these do belong in the problem statement. Ted Hardie: Has to be scoped carefully. If you're treating set of interfaces as a group, having interfaces join and leave the group is not the same as interface going up or down. Exposing when interfaces join and leave the group would be useful. How sessions handle that Margaret: Our analysis will include that applications will have different requirements. Applications need ways to influence behavior. Ted Hardie: Right, a web browser has different requirements to a jitter-sensitive application. Margaret: There may be multiple definitions of layer 3 connectivity too. Margaret: Should we expand the problem statement to cover this? 12-15 hands. Margaret: Should we not expand the problem statement to cover this? 0 hands. draft-cao-mif-analysis-01 See mif-3.pdf Margaret (as individual): I fee we should wait. Do analysis after we define problem(s).