Meeting : IETF88, Thursday 09 November 2013. 13:00 - 15:00 Location: Georgia B, Hyatt Regency, Vancouver, Canada Chairs : Hui Deng denghui02@hotmail.com (Magaret Wasserman mrw@lilacglade.org) Minutes : Ian Farrer Jabber : Peer Azmat Shah, Dave Thaler, Behcet Sarikaya ============================================================== Agenda 1 Agenda bashing (Chairs, 5 min) 2 MIF architecture (Tim Chown, 45 min) draft-anipko-mif-mpvd-arch-05 3 MIF Charter discussion (Chair, 45 min) 4 Proposed New Works 4.1 draft-kkb-mpvd-dhcp-support-00 (Suresh, 15 min) 4.2 draft-kk-mpvd-ndp-support-00 (Jouni, 15 min) Intro & Note well 2 - MIF Architecture - Tim Chown draft-anipko-mif-mpvd-arch-05 Slide 5: Sri Gundavelli (SG) - What is the difference between authenticating the access (WLAN) and the provisioning domain. Tim Chown (TC): Is that from a single or a separate provider? SG: Can I say that the PVD is like an interface? TC: No. SG: How do you tie all of this together? Suresh Krishnan (SK): there is an ID that ties all this together, it's many to many SG: How do you define consistency if I get different parameter TC: when you get multiple parameters, you can tie them together. You might have one PVD identifier per interface or more than one. SG: I'm not clear on what defines a Provisioning Domain. You take access parameters and call them a PD? Hui Deng (HD): This is based on a common PVID. Daipeng Liu (DL): Question about the HTTP proxy, can you combine this into the global config domain? TC: I don't understand the question. DL: You have a single HTTP proxy config in your browser. Dave Thaler (DT): You would not think of your browser as part of the provisioning domain. When you would consider it is if you had auto-detect, the browser then gets the config from the network. TC: Then it matters if the application is part of the provisioning domain. Ted Lemon (TL): Are you worried about whether you can trust the proxy or not, e.g. at work you trust it in Starbucks not? DL: That's another prob. I'm worried about how to combine the configurations. TL: Now, if you put an IP address into your Mac. If you go to another PD, then it breaks. DT: HTTP proxy is an example. I think the question is whether the application is part of the provisioning domain my answer is that it's not. TL: The app could be look for local config for this. DT: There could be local PVD. Mikael Abrahamsson (MA): I would see that there would be a local setting in the browser for setting the proxy. TC: The draft describes different levels of application awareness - 3 levels. Alper Yegan (AY): I see a PVD as a virtual network. Are we talking about having global identifiers for PVDs. TC: You might be in a public network that has no PVD info and a trusted link back to office with PVD info. SG: Can I make a relation to colorful prefix HD: If we have been authorised by 1 network, we have one PVD. SG: Can you give me an example? I go to one provider, I get config. TL: Do you mean the identifiers you give to the network? The PVD is what the network gives to you. SG: It's mutual. TL: If they are coming from 2 providers, it might make sense to combine - sometimes it makes sense for 2. TC: And this is in the draft? Dmitry Anipko (DA via Jabber): Host are allowed to augment PVD with other info it has - quotes draft - 3 possibilities mentioned. AY: We have to expose PVDs to the application for source address selection etc. TC: That's in the draft and in the charter. Slide 6 Brian Carpenter (BC): Now we have a broken scoping architecture. I think your PVD ID is going to be a subset of that. I had a suggestion in one of my drafts, but it wasn't human readable. The scope could be much wider. SG: Is there a namespace for managing the domains? SK: It's a label. If you want 2 labels, you can. We don't say how. SG: I assume we use something unique. DT: This is an arch with some requirements. One possible is to use hierarchy another is randomness. This document doesn't say which one. Another document will say which is the best to use. SK: to go further than dave, the current desc is all of the above. TC: this will come out in the later talks. Slide 7 TC: Any thoughts about the connectivity test? MA: There are some things that are being discussed in homenet - regarding more specific routes rather than default routes. TC: Would be nice to have. AY: How do you do the connectivity test? TC: It's vague at the moment. PE: Would you make the same recommendation if PVDs are not in use? Does having PVDs degrade not having PVDs. TC: There are approaches such as happy eyeballs that do this. HD: There is also VPN case - for TLS etc. TC: considerations for RA/RS and IKEv2 are included. TC: Please provide feedback on how it's progressing. DA: Connectivity tests are recommended as an input for which PVD to use. TC: That might be prior or during. TL: I'm really happy with the progress of this document. DT: I notice that the name doesn't have IETF in it? Shouldn't it be a workgroup. TL: That's the next question. TC: We need a recharter. MA: Are there more things that should be included in the scope. TC: This could be helpful e.g. with the homenet address selection. MA: the host might need to know more properties, what a prefix is used for, if it's capped. Policies. I don't have any answers. Is this the right time to put this in here or should we wait? TC: Good point, can the chairs steer? HD: When it's a WG draft, we can do that Gang Chen (GC): We have ongoing work to extend happy eyeballs for the MIF group. AY: I think that prefix properties are separate to the PVD. We should only do PVD work here. TC: I think we should avoid precluding things. SG: Prefix colouring is a set of labels and identifiers. That's what this is doing. SK: PVD is about more than prefix. Nothing stops prefix colouring from being in a PVD, but this is more holistic. You can't colour DNS. SG: This is a tag. It's a group tag. You're delivering this using 3 methods. Your keep SK: It's more than prefixes SG: It's a group property. SG: I'd like to see how this can be done with prefix properties. MA: If we're goin to have a new API, it needs to be flexible. We need to co-ordinate. It has the potential for how app devs interace with the world. HD: Thanks for the comments. We can tackle the questions after the draft is adopted. ------------- 3 - MIF Charter update proposal Slide 4: MA: It doesn't exclude their being an application connected to a PVD, but doens't include it TC: There's a point in the next slide that talks about the API MA: My corp email could have a connecting over a VPN - I only want the PVD when it's up. then, I want to print on my home lan DT: That's a question on the next slide. I have a comment about what's missing, but it can wait HD: Come back later. DA: Which covers the enterprise app case, but not explicitly. MA: This doesn't require a change to the API? This is a change to the host stack? TL: No, you could have the app understand the PVD. MA: Is there anything in the charter that prevents that? HD: Next slide... Slide 5: MA: The last sentence of point 3 solves my problem? TL: I think it does. As your AD I'm not going to stop you working on it. MA: OK AY: I assumed that the API would allow the app to select the PVD. Do you want to be so vague? TL: The API we wrote earlier would allow you to that. The API should be general. DT: A connection editor might want access to info like that. AY: I understood that this was to correlate by a single identifier. If you decompose it to each app, you lose that. HD: I think your recommendation is reasonable. TC: There may be reasons why you don't want to do that. Suggested (point 3): After element selection, you might say: 'or whether the application runs over the specific PVD' TC: I'll send an email with the wording. TL: It would be nice if we knew the text of the prop. charter today. Send the email today. TC: I can type it now if you think it's useful. TL: We don't need to add detail that's already covered. GC: Question: We're doing the happy eyeballs extension in MIF. Where does this fit into the charter? HD: That's in the arch. doc. I saw some disagreement of the happy eyeballs solution. Are you proposing that this should be in the conn. testing should be in the charter. GC: Can we have a new item to cover this topic? HD: If you would like to propose, you can do that. TC: You could approach this by updating no. 4 to include 'happy PVDs' or whatever that would make it more general. DT: Brian Carpenter's point - add an item for 'guidelines for generation and use of new PVDIDs'. How do you use it, do you have to validate it? Do I just trust it? DA: [missed point - absent from Jabber log] SK: For the authorisation part, do we have some text? How do we bind the ID to some form of trust? DT: This is a charter text discussion. Jouni Korhonen (JK): It's unclear if the solution space is in this workgroup or somewhere else. TL: Wasn't there a slide on deliverables earlier - slide 2 - requirements for protocol changes. DHC does the DHCP work. 6man does the IPv6 work, the RAs. AY: Why not have one group do the work. TL: Those groups have network work in their charters, we can't add it. You can do the work anywhere if there are people who will do the work. The usual suspects are in both rooms. Brian Haberman (BH): What about the mobility guys? I'm afraid we'll have a piece here and a piece there. There's 4 or 5 working groups. 1 or 2 wouldn't be a problem. TL: I don't have a problem here. DT: I agree with Ted. I see this as similar to the DHC thing. All WGs need to think about MIF. Work happens in other WGs and MIF reviews it. Same approach as DHC takes. The work isn't hosted here. BH: We need to make sure everyone is aware of this. SK: I have a concern with that. The PVD extensions to protocols need to be in sync. We should do the work here and get it reviewed to keep it consistent. TL: To Bernie Volz - this was the problem in the DHC working group. Why did you take the approach of reviewing other groups work? BV: It was because of stuff you said TL: I don't object to this work being done here, but it doesn't all have to be done here. It's an IETF consensus thing. If the IETF says it can't be done, tough luck. TL: Ted proposed change to add a new charter item allowing the development of changes to protocols based in accordance with defined requirements from item 2. DT: That's the one that I'll object to BH: One of the concerns is that if we do the work here, other groups may object to it. We should do the DHCP and RAs here for consistency so that there is consistency DT: Why I object to the new wording: There are some things that change the protocol without changing it's code e.g. a new DHCP option. There are some that do. I don't object to the first. I object to doing things that change the guts of a protocol. That's why I object. Can we scope this down? I wouldn't object to the use, I would object to the modification. BH: How about 'developing uses' rather than 'developing changes'. how about saying changes are not allowed? TL suggested wording for this. TL: Changed wording of 2 : A set .. .. Multi-way wordsmithing... .. .. TC: What are the initial goals in paragraph 1? TL: Previous MIF work. .. .. Wordsmithing TL: There's no doc that describes what a PVD looks like DT: Point 1 could cover that. TL: Guidelines are not specifications TL: I'd like it if item 6 was more of a specification than a guideline TC: Couldn't we say specification in item 6 TL: final paragraph is good TL: Does everyone understand. Hum? Loud hum for yes, none for no TL: Is everyone happy with the state of the charter and ready to propose it to the IETF. Hum? Loud hum for yes (weaker than before), none for no GC: Still no happy eyeballs TL: Last paragraph gives high level API TC suggested some wording that would include happy eyeballs. TL: I think that the last sentence in 4 covers this More wordsmithing... TL: Having modified the charter.... If you're happy with the new Tim Chown version, hum loud hum for yes, silence for no. TL: I would say that we have a charter that's ready for WGLC. ------ 4.1 Suresh Krishnan draft-kkb-mpvd-dhcp-support-00 (Suresh, 15 min) SK: It's a straw man proposal Slide 5 SK: there's a new container option, it can't contain other containers ???: (missed question) SK: You could come up with a new type and register it BV: Why did you decide to make it an option in an option? Why not put it in your main option? It avoids, what happens if it's missing? It's always there. BV: You can't use the option length. You have your desired information at the top SK: Perfect thanks AY: Why no extract this from the draft SK: We can't come to an agreement - we start with something and extend it . In a small group we couldn't agree. TL: Item 6 in the charter is that the draft should ref the requirement TL: You haven't done anything wrong. You just need to describe it in the requirements SK: Would this be a good initial point TL: This shouldn't be in this document SK: Fine - that's all I can say TL: One other way - Screw it, let's do one document with everything in there. The reason I'm arguing is that you have 2 docs. SG: IKEv2 extends it. JK: The registry would be like a set of options SK: The point that they don't want 2 docs. This needs to be abstracted out. AY: When discussing the types, we need to talk about uniqueness. DT: Another approach, rather than merging, everything after option length is one blob in the other document. The bits spec. would go in that document SK: It won't be the same for both RAs and DHCP BV: That shouldn't be a big deal. DT: They can use padding options. Padding can be protocol specific. Slide9 AY: Do you have any freshness in the option SK: There's a timestamp MA: Does all of this belong to the packet SK: It belongs to the container. AY: None of the parameters are signed, what's the value of signing the PVDID? SK: All of the params would be signed Slide 10 SK: DHCP only tells you that it hasn't been tampered with. TL: The problem is in a multi-homed network they send you a signed packets the local DHCP server combines them. Anything in those containers may contradict what's in the global scope of the packet. SK: We don't know the answer TL: We need to think about this SK: Dave had some really good thoughts about it. To paraphrase, you combine everything in a PVD. That's a bad idea. GC: We have to end there. SK: Thanks for the comments. BV: I'll send you some comments. SK: The RA based version that Jouni Korhonen would have presented is exactly the same.