MIF Monday 28.3.2011 1 Agenda bashing (Chairs, 5 min) 2 LC documents (Chairs, 10 min) >>draft-ietf-mif-problem-statement-05 Updated according to #79 discussions. New problems added: - On going session continuity, IP connectivity - TCP sessions break if host implements weak host model Jari Arkko: Discusses from other ADs. Are those addressed? Margaret: Will send mail and check whether all are addressed. Jari Arkko: Ralph Drom's discusses were pretty complicated. Dave Thaler: On the 1st problem. I do not understand the case. Interface change does not cause the connection to break but e.g. an ingress filtering. Margaret: We had a document on this in the last meting. One interface went down and other came up to as a backup. Dave Thaler: That is not about the weak host model. Margaret: Need to clarify the terms. Zhen Cao: Same problem with strong host model also. It is not only the weak host model. Dave Thaler: Asymmetric routing can cause the session go down but that is due filtering etc not the host model. Brian Carpenter: There's a architectural probelem that this document starts building a solution already. Ted Lemon: Two observations: the draft is already past WGLC thus little to do. Agree there is an architectural problem. Thomas: Seconds Brian. Architectural problem needs to be fixed before than doing other things in this space. Scott: Repeats.. get this document out and say these are the problems, and MIF is not probably the group to solve those (refers to architectural problems). Margaret: This group was to figure out some of those point solutions that are needed. The group is not currently chartered to solve the big (architectural) problem of all mif issues. Jari: We can try find an architecture that we should have. However, that does not seem to be optimistic. This document tries to describe these. Still OK to fix some of the known mif problems. Jari: Not always necessary to define new protocols but document existing stacks. That is also useful. Ted Lemon: Anybody here understand the architecture we try to describe? :) Thinks one more scenario is missing but the timing is bad to introduce anything new to the document. Jari: Yes it is.. Ted: In the last IETF I complained about one point solution because my architectural view does not match what others had in mind. Scott: Not a problem statement only for the MIF WG but a problem statement for the whole internet. Marc Blanchet: Next steps? Margaret: Not going to define the architecture in this document. Rather ask the 3 ADs whether the document can progress as it is now. Jari: Hoping to move it to LC. Deng Hui: Ted's issue/problem needs to be included? Jari: Do not know what problem he is referring. current document has a limited scope. If the scope gets widened all kinds of new issues show up. Address Ted's issues/problem later. Ted: About different trusted provisioning domains. Those should be explained. like DNS servers lie to you. You do not switch from a working to nonworking sandbox.. Marc: This is already described but not in these exact words. Jari: It is about there is one network that is more trusted than other.. and that scenario is already described. Ted: It is about that the host automatically connects to unauthenticated WLAN when one comes up. Whether the user wants or not. Other scenarios described on detail but not this. Margaret: Asks Ted to post his issues/problem/scenario to the list. ???: Points that 3484bis.. whether something has been missed regarding mif. Margaret: Not really a problem of this WG? More like 6MAN's that is working on 3484bis. >>draft-ietf-mif-current-practices-02 Apple section removed due lack of info. 3 Current Practice Analysis (5 min) >> draft-cao-mif-analysis-01 Margaret: Little feedback from the WG. Does the WG think we need to continue with this work? Ted: Analysis and current practices look the same.. confused.. Margaret: Should contains material that comes after current practices when looking identified issues through the problem statement. Brian: Contains blanks.. those need to be filled in. Asks for architectural analysis. The analysis that needs to be in context of better architecture and not point solutions. Someone needs to do an architectural analysis. Scott: Agrees with Brian. Need to fork the document. Need to contribute to the bigger architecture, which might be out of scope of this group. i.e. two documents. Ted: Thinks is ok. Jari: I am interested. One document though. Margaret: The WG interested to do this? -> reasonable number shows hands. Please volunteer. 4 Working Group Documents >> draft-ietf-mif-dns-server-selection-01 (Teemu, 10 min) Most changes due the comments from Ted Lemon. Andrew: Likes the improvements. Applications area said none of these (for DNSSEC) are deployed today. Need to have the revised text. Teemu: Would you contribute the text (I do not know DNSSEC and trust anchors in detail enough). Peter Koch: A bit concerned about the operational issues. Is the trust anchor used to distinguish which answer is a good one? Teemu: Explains the NXDOMAIN case with intra and extra DSN servers (both validates) Ted: Split horizon issue.. I don't know how to deal with this problem and that is the reason why this document was produced. Ted: Like the draft much more now. The draft bases on that the mobile node trusting some provisioning domain more to select the DNS server. I need to look more into this. Ted: How to distinguish between trusted domains? Dave: What about the case where the host does synthesis and other DNS server gives a native addresses? Which one to prefer. Andrew: Brings up validations and synthesis.. You are totally lost in that case. Teemu: How about IPv4? Any support needed for it? Ted: Did not even notice that (IPv4 being not addressed). Teemu: Multihoming with IPv4 is even more pain. We have serious problems there. Do we need to support for IPv4 or just stick with IPv6? Ted: Does not mind if it works only in IPv6. Teemu: Is ok not to support IPv4? Margaret: We should do both.. Ted: Do not put IPv4 addresses into DHCPv6. Margaret: If IPv4 needed -> do DHCPv4 solution. * general discussion different Mif models. IPv4 only WLAN, IPv4v6 (dual-stack) cellular.. in different domain. Dave: Says having IPv4 in DHCPv6 could be ok. Dave: What is the use case where you need different server per different name space that are delivered in the same DHCPv6 reply? Margaret: Explains the two interfaces cases, two DHCP servers and several domains through those. Ted: Brings up the case where DNS is configured using RAs (RFC6106). Then this solution is not applicable and one is tempted to use DHCPv4 options. Ted: So may different scenarios that are not thought in this document -> loads of standards work (DHCPv4, DHCPv6, ..) Dapeng: Need to support IPv4, maybe in a separate document. Andrew: We seem to be tempted to do split DNS work reliably, which is broken by definition. If you want to solve it in large, it won't work. scope it well. Thomas: Better scoping needed. Says only one DHCP response per interface and those have no conflict within an interface. Margaret: Trying to provide hints that there is no need to query all known DNS servers to get an answer. Thomas: Need better scoping. teemu: Move the discussion to the list. >> draft-ietf-mif-dhcpv6-route-option-01 (Woj, 20 min) Ted: Return nothing. (answer Woj's question). Margaret: Not in IESG yet, rtg area doing review in advance. 5 Re-charter, milestone discussion >> draft-liu-mif-api-extension-04 Note takes thinks most of these options are already provided most APIs like BSD ioctl()s. xyz: Why S_ADDR needed? Dapend: You need to do specify the source address. Margaret: Sockets API already allows you to do that. Marc: RFC3542..? Dave: Will send comments to list. Also discussion about abstract API. There was a WG consensus not to do concrete APIs. Margatet: Chartered to do abstract APIs. Dave: Austin Group owns the sockets API. For interface selection API there is no standard. We should look at what current OS APIs provide. Ted: Thinks the right way now is rewrite the whole document. Wants to be loop as he has lots of ideas here. Alan Ford: Seconds Dave. Points to mptcp astract API work and asks for collaboration. jabber: Asks why not using advanced API from RFC3542? >> draft-korhonen-mif-ra-offload-01 (Jouni, 10-15 min) Alexandru Petrescu: Question whether both networks have to be controlled by same administrator. Jouni: no, they don¡¯t have to. Ted Lemon: This document is more for addressing which network to prefer rather what address family to prefer. This approach could have some security implications (misuse). Additionally technical comment that shall be discussed offline. >> draft-chen-mif-happy-eyeballs-extension-00 (Chen, 10 min) 5.4 Multiple connections (Sri, if time allowed)