MIF Working Group Meeting (IETF 84) The MIF working group was held at IETF 84 Vancouver at Wednesday, August 1 at 13:00 in the Regency E room. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl Williams - Jabber scribe: Behcet Sarikaya - Agenda Margaret: goes over the agenda and the status of working group documents. 2 Document status (Chairs, 5 min) draft-ietf-mif-dns-server-selection-04 (IESG review) Margaret stated that the dns server selection document is in IESG review with 2 discusses and the authors are working to undertand them and workout with AD. draft-ietf-mif-dhcpv6-route-option-04 (in WG LC) Margaret stated that the dhcpv6 route option is not being presented at this meeting. Resolve of issues will be handled on the list and at IETF 85. The effort will be focused on modifying the working group draft to match consensus of the working, if any. Document was discussed at length at the last meeting. Margaret reminded us that the consensus in IETF 83 was strong to continue to work on this problem. There was not strong consensus of what the solution should be. Margaret stated in that we agreed to refer it to our Area Directors to get their help of how to go forward. Ralph has come forward to with suggestion/help. IESG has been looking into how to solve these sorts of problems. We are in formative stages of how to figure out this approach. But he current plan is to get all the issues on this document into the issue tracker. An IETF sponsor tracker for our MIF working group and try to resolve the issues on the list then in Atlanta (IETF 85) and figure out how to go forward. Our effort is to focus on modifying our current working group draft and not on entertaining new drafts on the subject. Margaret stating that coming up with new proposals in the area is not going to help. We want to determine if there is a set of stuff we have common consensus on or not. And we are going to go through a process to do that between now and Atlanta (IETF 85). Watch this space on the mailing list because we haven＊t figure out all the details yet. Alex: why avoid other solutions drafts in this space? Margaret: because we have a working group document and it finished working group last call. We need to figure out what we are doing with that draft before we consider entertaining new solution competing drafts. Just accepting new drafts that solve this problem space won＊t address the fundamental questions if we want to work in this space; do we want to have a dhcp option to solve this problem; that sort of stuff. Alex: what is status of this document? Margaret: It is a working group document that completed a round of working group last call. After working group last call new issues were raised on the document. Alex: I mean the intended status 每 informational, proposed standard, etc. Margaret: At the last time we talked it was proposed standard. One approach to the problem is to publish it a different way. I don＊t know. If have to figure out what we have consensus to do. When we sent it to working group last call it was for proposed standard. Lorenzo Colitti: I read in minutes from last meeting and there was consensus was that this solution was not the one we were going to use. I agree on the problem but not this solution. Margaret: There were three things last meeting: (1) do we want to continue to work on this problem and the consensus was strong that we do; (2) the second one was do we want this solution or another one and there was no strong consensus 每 there was no specific solution that we were talking about. When we were talking about solutions we weren＊t talking about solution with a different combination of fields. Some people were talking about quite different solutions to this problem. Lorenzo: If we had at the last meeting a 2 to 1 split that people don＊t favor this solution, why are we now saying that we aren＊t not going to entertain new solutions because we want to figure out this one first. It sounds like reading the minutes that a majority of people dont support this solution. I am confused of why we are taking this solution and not entertain other ones. Margaret: First there is a question of who the people are. At any given meeting the people in this room don＊t represent the majority of people on the MIF working group list. Lorenzo: Was a call for consensus carried out on the mailing list? Margaret: There was no consensus so there was no consensus call to make on the list. Margaret: It depends on what you mean by solution. If somebody has a proposal to solve this problem 每 and they better list what they think the problem is at the top of their draft 每 that doesn＊t involve a DHCP route option please send it to the list. Margaret: But entertaining multiple proposals for different types of DHCP route options with different fields in different places is not going to solve the problem do we want to have a DHCP route option or do we not. Lorenzo: I understand now. I thought you were saying that we can＊t have any other ideas. But what you are saying is that we don＊t want any other solutions that are essentially the same. Margaret: Yes. If the working group decides it wants a dhcp option and only does default route or doesn＊t do default route or has what is in this draft plus it wants the mac address in every entry or the metric needs to be in roman numerals we will change this document to reflect that consensus. Lorenzo: I understand. Some side discussion on the use of the issue tracker ensued that was triggered by Alex. Margaret stated that the issue tracker won＊t force us to agree. But it can allow us to determine what those things are that we don＊t agree and step through them and try to reach agreement. Margaret: I don＊t have another plan to reach agreement on this document and/or to reach agreement not to publish it. If you have a better way to do that then please send a suggestion to the chair. Costas: I am new and not familiar but followed a bit on the list. There seems to be a feeling in the room that this is not the appropriate working group document 每 Is there a formal procedure to withdraw this draft. Margaret: The route option was chartered as a work item after discussion on mailing list and working group. The working group document was adopted as a working group document after consensus in the room and confirming that consensus on the mailing list. Margaret: It is conceivable that you could reach consensus to withdrawal the document as a working group document. We haven＊t reached that consensus yet. We have to clear some larger issues about this concept (address by this draft). Exchanges between Margaret and Costa went back and forth about if there are technical issues or non-technical issues holding up the document. Margaret stated that there were technical issues and that is why we will proceed with issue tracker. Ted: We understand the way forward and this discussion is not progressing and should be stopped. What the chairs said is to make a list of the issues and the working group talk about those issues and determine if we can agree on them or if not why we can＊t agree on them. If the end result is that we can＊t come to any consensus then we need to something else. We must do that first. Ted: We worked on document for 2 years. Working group last call and passed working group last call and the post WGLC these issues were raised. So the situation is unique here and we are bending backwards to accommodate those issues. Margaret: When issues are raised after WGLC we still consider them. And that is the state we are with this document right now. We need to figure out how to close out those issues. We need to figure out the answer to those issues whatever they are. We need to do mechanics to setup the queue for IETF tracker for this document. We will add Dave issues and you can add all the issues. Juan Carlos is up now. ------------------------------------ 2. Discussion of IEEE 802.21 MIH SAP (Juan Carlos, 10 min) Carlos stated that multi-mode terminals pose new challenges to mobility management. He stated that in order to address some of these challenges, the IEEE is currently working on a new specification on Media Independent Handover services (IEEE 802.21 MIH). Carlos provided a current status of the IEEE 802.21 specification. We want to show ways IEEE and IETF can collaborate as well. Carlos stated that from the OMA-MIF workshop at IETF 83 that are: (1)discussion to extend current MIF API to add additional messages for notifications; (2) write a draft to define requirements for an abstract notifications API. (3) write an informational draft that provides recommendations about using the MIF API in order to handle interface changes. Carlos provided the recommendation for IETF MIF working group. Carlos stated: (1) IETF MIF can take advantage of the work that 802.21 has already done Carlos stated that 802.21 defines a Media Independent Services SAP (e.g. API) that provides some of the functionalities that MIF is looking for 802.21 also defines low level Media Specific SAPs for the underlying access technologies (lower level) (2) IETF MIF should make a list of MIF-specific requirements and should reference MIH SAP primitives when appropriate Carlos states that this would mean to take advantage of lessons learned to avoid incompatibilities If non-existing functionalities are identified both MIF and 802.21 should work together to define them Carlos provided straw man proposal and listed key discussion points from it. a) Should MIF API propose abstract messages and simply explain that a specific instantiation of some of them is described in the MIH SAP? b) Should MIF API expose different primitives and translate to MIH_SAP or expose directly MIH_SAP or use the same name? Costa: Recommended that the lines on the strawman diagrams has names. Ted: MIF is trying to solve the problem that the IEEE was trying to solve (MIH spec) 每 not exactly same problem but they are related. Goal in MIF working group is to come up with laundry list of all things we want in the API and we are hoping to gain insights and help from some of the work that the IEEE did MIHF. If you have solved the same problem we are solving we don＊t want to go through that process again and learn from what you did. Secondly if we are doing the same thing the IEEE is doing than we should make sure we are compatible. We don＊t want to end up with an API that suddenly doesn＊t work. We were hoping to produce our laundry list and work with you that we haven＊t made any mistakes and to learn the lessons that we need to learn. What will come out of that is the document we are working on now 每 describes the abstract API. And then a second document that describes the relationship of the MIF API and the IEEE API. We may come up with other documents that are similar to that of how this API work within other contexts. Idea is take advantage of work that has been done and produce other documents. Q: Are the MIF API and IEEE MIFH API encompassing the same thing. Ted: Answer is that we are trying to solve slightly two different problems. Yes, there will be a good amount in common. But there not the same thing. Dave Thaler: I agree with Ted said and I would argue to put into same document. I think that given what the two groups (IEEE & IETF) are doing then there is a difference between strawman proposal 1 an strawman proposal 2. IEEE 每 uses API by connection manager. IETF 每 uses API by applications. Downward arrows we are trying to do and for IEEE they are doing the left/right arrows. Juan pointed out that there is lot of overlap in the communication space. There are things out side of the overlap area 每 connection manager needs the ability to do control 每 I want to force interface to come up and down 每 things that normal applications may not be permitted to do. These other 2 categories (IEEE) that may not be appropriate for applications to do. And there may be things in the high-level box that applications do that may not be appropriate for the other one. Dave: Big overlap but what I see as the difference between them 每 that is 每 between proposal 1 and 2 每 proposal 1 每that the parts that are in the overlap space are the parts in MIHF that are in the overlap space and not a separate thing. As opposed to 2 每 where there are 2 APIs where one is a wrapper over the other one. And this one would make sense if and only if the MIF API box provided a value added on top of the one that it is wrapping. My point is that this one 每 any value added that it could have done could be up on the high-level API box 每 without changing the picture of the first. I don＊t think there is any value added that you can standardized because if there was it would have been the case that 802.21 would have done and it should be in side the MIHF. So I can think of things that can be in the high-level API box and I can think of things that should be in the MIHF box. But I can＊t think of anything in the overlap space 每 somewhere in between. That is why I would argue for strawman proposal 1 where in the regular document these are things that we require and for the sort of things that the application require are present in there reference those in 802.21. And the ones it doesn＊t provide 每 then get them to agree that this is something connection manager should do 每 then it is something that the application does and it is part of MIF API and not MIHF and that is great. Margaret: talks about a little more what it means to be media independent. 802.21 document is media independent. It as 3 IEEE media type supports. If we refer to the MIHF for all mif stuff then we need to understand how the MIHF maps at the bottom layer 每 at least that it can conceptionly map at the bottom layer - things like VPN tunnel, 3GPP interface＃ and in whos scope. They asked 3GPP to adopt this and they didn＊t and they must have had some reason. I am worried about marrying something that may not be suitable for 3GPP when the whole wifi-3GPP use case is one of our major use cases. Juan: It wasn＊t this part that wasn＊t accepted by 3GPP. 802.21 try to propose as the candidate solutionfor 3GPP ANDSF, that has been refused. Ted: If you wish to have help flushing out lower layer issues we can help but at same time we can＊t have tight coupling. IEEE and IETF have separate processes. The goal here is that we don＊t prevent you (IEEE) from succeeding by defining something incompatible with what you are doing. We need to be in sync. Some of the functions in MIF API will have to be supported by a connection manager. Lars: what are the deployment realities for this Juan: Work in progress 每 from a connection manager point of view 每 there is desire. Hui: MIF API is abstract api. Some of function has already existed in most today mobile handset implementtaion, but 802.21 still wait for the opportunity to be supported. Recommend that we take Dave recommendation and do what he suggested in future. Next presentation MIF API. --------------------------------- 3. draft-ietf-mif-api-extension-00 (Ted, 10 min) Ted stated MIF API is a laundry list 每 a number of different APIs 每 goal is to tease out what is MIF and write spec to say what those things are. MIF is message API 每 not procedure API. Assume people in room read document. Didn＊t update document since Paris. Dave: graceful disconnect 每 not hard disconnect. You have last call to send out any packets before go away. That type of thing is useful. Erik: On interface coming up 每 is it carrier link up versus logical link up. Ted: Link up can mean a number of things. It could mean we powered on the interface. It could mean we have a carrier. It could mean we heard from many APs 每 it could mean that we have chosen one. Which of those should be in this API spec. It is not an API for the connection manager but maybe an API for a special intelligent application. ------------------------------------ 4. draft-ietf-mif-happy-eyeballs-extension (Dan, 15 min) Happy Eyeballs is there for when one of two problems occurs 每 the wrong interface was selected 每 packets were trying to go out of an interface that isn＊t going to work or that the path on that network path is broken. Happy Eyeballs is to workaround this in a way that is fast so that a user is happy. Happy Eyeballs (using the APIs) is about sorting these interfaces into what we want to use, pick the best one and what Happy Eyeballs is doing this part on left of diagram that Dan presented 每 how quickly we timeout and try the new interface. One of the open issues that the authors have for the spec 每 is what to do with that timeout. Something as aggressive we are recommending in the existing Happy Eyeballs RFC (couple 100 milliseconds) 每 implemented in firefox and Crome 每 is probable too aggressive 每 75 seconds (normal OS defaults) is not aggressive enough. Looking for feedback on mailing list for better choices here. This can be more specific 每 for example if behavior on one interface was going well then is suddenly not than that may be time to try other interfaces. We may have different timers for paid or free interfaces. Want feedback to what to put in the spec. Simon: what happens if you have filters from users or operators that conflict 每 is that possible? Dan: that is good question. Simon: I prefer that users have all the power. Dan: I agree. If operators are subsidizing the phone they tend to instill their own preferences. CJ: DNS processing is to follow the MIF DNS draft. What happens if the options in that draft don＊t become available will happy eyeballs handle that. Dan: don＊t have any thoughts on that. There are 2 problems 每 one is that we can have a split-horizon DNS where asking on corporate wifi gives us different answers than asking on 3G 每 that is one problem. We could have v6 we could have v4 - on one interface and not on the other interface 每 one will behave nice and return As and AAAAs but the other one may not. DNS is not suppose to act that way but then again it is a split-horizon DNS problem. So without that extension this becomes more of a challenge. Ideally we want to follow that extension 每 ask on the interface we are going to use because if we ask on the interface we are not going to use we may get the wrong answer and then again use the wrong interface. What do you do when you get multiple answers that differ 每 that is the big problem. Answers are different 每 due to split-horizon DNS or whatever other reason. Lars: When I hummed for happy eyeballs I didn＊t hum for happy balance sheets 每 so user preference should over-ride. When you ask time-out like 3G or 2G the delays you see may vary quite a lot. So you should be careful to make a decision that this interface doesn＊t work at all versus that this interface is not very fast. You may end up to a wifi captive portal that you have no credentials to and the other one is 3G that is very slow. So you don＊t discard the 3G link because it is very slow and try the other link then really neither of these really works. Dan: we should use past experience to determine what to do. Tero: Question on use of priority related to RFC 3484 and ordering of addresses. Dan: Kick that back to working group. How to order those addresses. We just take order that OS gives us Hui: I don＊t think you gave sufficient answer but we will continue. ------------------------------------ 5. draft-deng-mif-api-session-continuity-guide (Suresh, 15 min) Document name is: Guide for application developers on session continuity by using MIF API The presentation incuded discussion on generic guidelines for writing applications to handle issues such as new interfaces becoming available or unavailable to the application. Document was quickly put together based on informal discussions of the authors. The document is skeleton and was quickly thrown together based on what the authors had at this very moment. Suresh states that the goal is to determine if the working group is interested or not in working on a document like this or not. If we don＊t want to do it then no point in adding in more meat or not. Suresh discussed that mobile nodes have multiple interfaces that have different qualities and costs of connectivity＊s. We published as a recommendation. Lars: What if the applications disagree on the interface that they want to use? Suresh: It is per application. The application isn＊t going to turn anything off. The application can free itself of the interface so something in the system can turn the interface off (no one needs). Similar steps for interface becoming unavailable. There may be other use cases 每 handle mobility, make-before-break, etc. We can add them. Suresh went over comments from several other people and says that he intends to do further improvements in draft if there is interest. Suresh says feel free to send more comments on the document. SRI: So Android and SDKs do have this kind of interface today essentially. So you can register the stack to say that if any of the network properties change you can get a notification 每 so you may want to look at what is already there and you may want to align with that interface. It is good work. Suresh: You make a good point but this is based on the MIF API. The alignment you are talking about should happen with the MIF API and current implementations. We are basing on abstract API that MIF is defining. While I agree with you I am not sure what this document can do. This document is more like a style guide for lack of better term. Ted: The whole thing with MIF API is not to tell the platform guys you have to make a bunch of messages to look like this 每 it is basically to make sure the functionality is available. We are not trying to dictate to platform implementers precisely how their platforms should operate. If you want to support the kinds of applications that operate in MIF environment this is what you need to provide to the applications. Similarly with style (as in this doc) it is same idea. Lars: it would be good to talk about stuff we talk about all the time but gets forgotten like for example an application really know all the characteristics of the path are until you get to the interface and start using it. Just knowing type of interface may give you an upperbound of what is achievable but it is not going to be realistic in all cases (example wifi always better than 3G) 每 it would be good to debunk some of those things. Common use case and it is guide. Letters to developers 每 so you want to write a MIF application what do you do. It is not specification. It doesn＊t fit into architecture work. Margaret: it will be informational document. Architecture will be Happy Eyeballs, and MIF API. Happy Eyeballs explains its architecture. In this doc is what should application developer do with that information. Dave: decent work. Slightly tweak audience 每 to the implementers that this document will be relevant towards. In order for this to be relevant they would have to have in front of them the mapping between the MIF API, abstract API and the specific API (because they are doing it in language X or Y). So this is best done by those doing the concrete API 每 whether it a platform specific thing or a standard thing or POSIX. The community you have here this may be more relevant to an application protocol designer. If I am going to write the spec for the way you write applications then here are the considerations that may be applicable. If we focus this document to the application protocol designer then it will have a bigger effect. Margaret: Distinguish is a little funny 每 only tiny fractions of applications in the world have a specification for their protocol. Dave: And the ones that don＊t 每 don＊t read RFCs like this. Margaret: But they do 每 because they use STUN. All gaming programmers use STUN to get around the NATS and they read the RFC. I know the biggest gaming developers in the world. Dave: They read STUN library and the STUN man pages from whoever developed that STUN library. Margaret: Maybe someone will write man pages from reading this document 每 I don＊t know. Dave: You are proving my point. The target audience of this is whoever is writing those man pages. Margaret: Defining an application comes from perspective. If you are UDP, DNS is an application. Dave: DNS is a protocol and a specific DNS resolver is an application. Margaret: That is true. It is likely that there will be libraries for this stuff. Margaret: Is the working group interesting in pursuing this item. How many people feel it is interesting work to be done in MIF working group: 8 people raised hands. How many people will do work such as review and provide text: 6 people. How many people don＊t think that this is not interesting work: no one raised hands. Let us move on now to next presentation. ------------------------------------ 5. draft-mglt-mif-security-requirements-01 (Daniel, 20 min) It was stated that MIF Node may use their Multiple Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes may also manage traffic between these Multiple Interfaces. Daniel stated that because IPsec has not been designed for Multiple Interfaces, MIF Nodes have difficulties to benefit from MIF features with IPsec protected communications. provides use cases where IPsec protected communications would take advantage of MIF features. It was stated that frrom these uses cases, we can identify the different IPsec features MIF Nodes would require. Then, we expose the limitations of the IPsec related protocols IKEv2 and MOBIKE regarding to these MIF features before listing the MIF IPsec Security Requirements. Lars: Clarification question 每 IPSEC can＊t do this but TLS can? Daniel: TLS is over TCP so yes. Yes it works with TLS. Costa: This reads more like requirements and not features. Daniel: This is what we want to do at a high-level. Lars: Forget about he no packet lost requirement because if this is over TCP then TCP is going to see a hipcup even if you lose packets or not. Don＊t make it hard on yourself. Comment 2: you can do this with IPSEC 每I fail to see what is needed. Daniel: if you are losing too many packets with IPSEC then you are out of the window and you have to setup connection again. Lars: What you mean by window 每 it depends how you set your SA. Daniel: If you are losing too many packets 每 IPSec can discard the packets. Lars: You are going to see the reaction even if no packets are lost (i.e., tcp congestion control kicks in). Daniel: But another thing you can do is to use both paths. Costa: This implies you have two different paths. Just a delay spike doesn＊t mean that it will time-out. Lars: It is not time-out 每 it is the congestion response. Hui: Take to list. Tero: you can do with MOBIKE. This standard stuff from MOBIKE that has been there since 2008. Load balance between those interfaces is out of scope for MOBIKE. Margaret: We will ask questions to see if there is interest? How many people in room have enough knowledge of IKE or IPSEC or security to deal with this topic? 7 people (that is good). How many people feel it is interesting work and the MIF working group should be working on? 7 or 8 people? Lars: What is overlap of those 2 sets of people. Margaret: There was overlap? Margaret: How many people feel it is not good to do? Few hands. Some comments were made perhaps not in this working group but not sure. We need to say to authors 每 take feedback of things that do work and flesh that out and better refine what actual problems are (even if that means convincing those people that they don＊t work, etc). Come back after that process if there are things that you think that still need to be documented. Does anyone object to that path forward? No one objected. ------------------------------------ 6. draft-sarikaya-mif-6man-ra-route-01 (Behcet, 5 min) Only had 1 minute to present. Lorenzo: This document should be discussed in 6man working group. It is applicable for single interface not just multiple. Margaret: Not in charter 每 you can take up on list. Margaret: meeting is over. See you at IETF 85.