DIME Meeting Minutes -------------------- Qos Attributes Mark: Qos Attributes Status, updated the doc for nits and references. status is publication requested. Dan: In a good position in the ADs queue Avi: Added QoS as reference in the wimax work. Schedule is ok for wimax ? Looking to get it publish on time. Dan: It can be possible in 4 months. There are some phases that really needs their own time. Some can be accelerated. MIPv6 HA<->AAA Server Jouni: Ended on WG LC, shipped to IESG. Hannes: Also on Dans plate. Discussed security concerns with the AD so should be expedited in the processes. Base Protocol Hannes: After virtual interim meeting, we indicate more clearly that there's a big change. That's why its version 2. Avi: We should have started doing 3588bis properly before going V2. I think this should be done as a separate exercises. May break backward compatibility but that's ok. What happens to V1. Going V2 has been very hasty. Dan: Sided with the last two(2) comments. There's much in the name in reving up V2. There puts a question mark on the stability of versioning. Needs to review other Lionel: Basically, the initial scope of the work was just for bug fixing. I would prefer to fix this version as a bis. Glenn: Seems a little bit silly to go now and separate into two(2) version. We've been working on this for years. Cannot see any reason not to use the version number. Avi: What is silly, is to make a decision to call this version 2. Going to the V2 at the last possible moment. Keep it at V1 and decide which features are breaking backward compatibility and start V2. Hannes: Re-evaluate the changes more carefully and discuss again. Mark: Victor post changes thats been introduced and discuss this in the list Dan: Spin out a separate document for IANA so as not to delay allocation of IANA ? Hannes: Lets do plan A for the end of april to finish this discussion and do plan B if we don't meet the deadline. Diameter ERP Glenn: Why are chaning applications in mid-stream ? Sebastien: We are talking about ERP bootstrapping. Glenn: It should work just fine because routing would work. Hokey is talking about re-chartering. Proposing a new hokey architecture document. So it maybe a good idea to slow down on this doc until the architecture doc is done. Hannes: For us diameter EAP and ERP are in one box. In that sense, its not that complicated for us. I don't want this document hanging around waiting the architecture document. Hannes: Some folks found a use case for source routing in hokey and causes confusion. Glenn: I agree. No use to let it hang around. We can move it up to a point and re-introduce at a later point. Avi: Your not defining any new command codes. No ABNF in the document, can I include this attributes in the DEA commands. Hannes: This stuff is directed towards different boxes. Lionel: Assumption in the document is that everything under the same EAP session. Issues on how some entities are spread in the network. The assumption is that it was a black box. But after this point there are now more confusion. Hannes: Let's do the following. Let's keep it in the charter and go forward as far as it goes. Dan: Taking it out of the charter is irelevant. Lionel: Is D-EAP enough to convey this information ? Glenn: There is running code and its running in places. The core idea is that D-EAP routing is different from D-ERP routing. Not sure about bootstrapping. Chin: Not sure whether bootstrapping can be view for re-authentication. Hannes: Different levels of re-authentication that happens. The bootstrapping can be re-authentication as well. I think this things can be captured better in the architecture document. Chin: The bootstrapping part is a little bit confusing Avi: It is an optional send for this attributes. Hannes: This is a second step to define the ABNF or new command code. Glenn: Were not there yet. Its premature to say. PMIP6 Jouni: Bunch of editorials and clarifications and aligning with SDOs wishing to use it. TBD: I-D should have signaling flows Hannes: Not to many comments during WGLC. Avi: Wimax is finish PMIPv6. Will review this document. Hannes: Avi, Marco and Frank will review. In two(2) weeks. NAI Routing Jouni: General consensus that we need this so pls don't re-iterate that discussion. Open issues: two solutions each with their own issues. Combination of both solution maybe ideal. Hannes: How will this look like. Avi: Putting it in the application layer. Some confusion was introduced because its commented to be added to bis. Now the discussion in the application layer. Keep it in the application layer. Dan: Backwards compatibility section. What happens if agents does not support this extension ? Jouni: If you want to be sure that this would work, you should define a new application. Glenn: Does'nt this kind of go back to the two vesions of bis. Hannes: The question is, the applicability statement; i.e. use this when you want to define a new application. Jouni: Same discussion everytime. But we do need also in version 3588. Avi: Why diameter never did NAI routing in the 1st place. Hannes: How is the next version going to look like ? Jouni: Looks like the application approach is the way to go. Keep the statement of beware what your doing Avi: If we did do this in the app layer, then we still would'nt change the destination realm. Jouni: You want to bypass some realms and sometimes you have to go through them. Mark: Maybe depends on the stack implementation. Kept a fairly clean separation on base routing logic. Avi: How do you deal with proxy then ? Mark: Idea of this functionality not being advertised as an application is not clear. The clean way is to create a new application. Mark: To send mail to the list of this topic. Diameter Capabilities Update Glen: Capabilities exchange in the open state. Roughly 10 people says to continue the work. Dan: Same questions as NAI routing ? Glen: Appropriate to put it in the separate document. Can exist as a separate feature. Changing the way the message routing is done is more fundamental. Diameter NAT Author: Add to the WG charter ? Avi: Read the document, should be added to the charter. Important to do so. Customers are planning to use carrier grade NATs to deal with V4 exhaust. Some things are missing. Need to a way to query the NAT to find out binding of a user. Author: Query is present. Lionel: Clarification, pre-existing implementation could fullfil the requirement. Wondering if could be an alternative to use this protocol to do the full set of functionality. Author: Overloading existing protocols was not the goal of this work. Lionel: In the end maybe we can deploy only one protocol to cover all functionality. Dan: New charter items, remind you of rules of engagement. Operational interest etc. Glenn: As for reviewers, I've reviewed the document once. Hannes: Some parts of the document too lengthly. Rule from IESG and IAB on the work on the NAT control protocols. Dan: The rule is a recommendation. Hannes: Three reviewers. In support of this document, 7 people. no objections. Steve: Are we defining what carrier grade NAT is. It did cause some confusion because some of the protocols are in the access network (comparison table). Hannes: This would be the edge router at the operators network; i.e. DSL providers. Lionel: Is there a description of these in the draft. Hannes: No. Author: The reason for having the table is because of questions on how it relates to other protocols. Lionel: What are the underlying requiremenst for NAT control. We need to have some reference just to be sure which feature we are trying to solve. Hannes: Glenn, Avi, Tom and Lionel will be contributing. Local mobility PMIPv6 Marco: Proposal to extend the PMIPv6 draft. Addition of info-request/reply plus parameters. Hannes: We are at the end-point for the PMIP documents so adding new features is not an options since the time dependencies of PMIP documents. Avi: Lots of examples for query mechanisms for the AAA. Maybe we can create a generalized query mechanism for AAA. Glenn: What does this have to do with AAA ? In-appropriate for a AAA protocol. Why not just use SQL. already ways to query information over the network. Avi: Sometimes we also want to query the NAS. And we are not talking about a data store. Hannes: For SQL, we also need to define schema and data structures. Diameter has already been used in a-typical ways. Avi: Does have something to do with AAA. Glenn: There are generalized protocols for querying data. Hannes: Could this be a proprietary interface protocol or not ? If its not then what type of information is exchanged. Having a generalized protocol still does not solve this issue. Glenn: Its not appropriate for DIME WG. Lionel: I agree. Additional question: do you have a example of inter-domain routing for this. Hannes: LMA1 and LMA2 are in the same domain. Marco: Preferebly the same administrative domain. Lionel: In that case you don't have to define anything. I don't see a problem and why use diameter. Hannes: Is this a useful thing that the mobility guys would like to work on Tom: The fundamental is that is this a problem ? It seriously detracts the protocol from what it was designed to be. Something you can do without. Proposal for generalization would just cluter up the protocol. Chin: Its not always the single AAA that stores data for a domain. Marco: This is just one example of what we want to solve. There's a diamter concept of a redirect agent to synchronize data in different AAA. Chin: How is the routing for this scenario ? Bechet: PMIP RO is a new thing. NETLM refuse to work on it. By itself, its a big problem. Maybe this could be part of the RO protocol. Too early to bring this up to dime. We can come back if it turns out the other way. Avi: AAA ultimately ends up in a data access technology. The reason for not using SQL is some of the things we do such as routing it and protecting the message. We see this over and over again and generalizing it would help. Dan: Protocol exists, people will define them here or other places. One, we look at functionlity being included in diameter. Is the solution part of the AAA space of functionility which is lately very liberal. Hannes: Let this document cook for a while. Glenn: This work does not have anything to do with AAA control. Its ok if we define diameter as a generalized protocol. Dan: This is the way the argument should be made. Diameter Base MIB Glenn: MIBs for Diameter base and DCC. Has been done for a few years now. Dan: There's only one vendor that we know about ? The can consider other path for moving this doc forward; AD sponsored etc .. no need to charter this in the WG. Ask this question on the list. Avi: We do use them. Dan: No problem with asking the question of who is interested in this work again. Glenn: First we need to ask who the operators are in this room. Steve: We have not using it because we don't have the MIBs. Avi: In RADEXT and RADIUS we always use MIBs Hannes: The question is would the other protocols be more appropriate Avi: Glenn's already done the work so why not finish it. Dan: Go ahead. Reviewers: Mark