IETF 72 - Dime Meeting Minutes: July 28, 2008 Dublin Ireland Document Status --------------- * draft-ietf-dime-diameter-api-06.txt - In last call - No major revision needed, only comments * draft-ietf-dime-mip6-integrated-09.txt - Comments Hannes : Provide more text in certain sections and whether it can be used in a safe manner Another IPR issue , suggested to remove some and do a separate doc Q : Ignore feedback reg patent or separate some functionality so that main doc is not impacted Jouni : lets keep the doc as it is now and not split it now ... Dave : It would be difficult to choose an option now Hannes : Choosing and option on how to deal with patents will take years Dave : Splite the document and try to guess the IPR Hannes : Ok, we can also add security and then post new stuff. We also mentions that the changes were from wimax and other SDO feedbacks. * draft-ietf-dime-qos-parameters-06.txt - Comments Dan : Document is still using older WLAN templates, 802.11 has been extended a long time back. The document should be updated to reflect latest template and revise the AVP. Hannes : Reveiwers, Eric Gray Q : Do you have any specific SDOs that will provide a review Hannes : A couple, Wimax, 3GPP/PP2 and maybe TISPAN Mark : 3GPP is planning a last call on the latest rev around Sept. DIME re-chartering ------------------ * draft-asveren-dime-cong-03.txt (Diameter Congestion signalling): Hannes : TA similar efforts on SIP overload Dan : Its a host congestion and not network congestion Hannes : Make decision later Victor : it is early now, if some other group needs it then we can see .. his take is we can discard it now Hannes : Is it a specific prob to Diameter or applicable to Radius Stephan : Not yet, no practical experience but we could face it Steve : Possibly too early now, lets wait till it is floated in tispan for some time ... Hannes : Leave it for now * draft-zorn-dime-diameter-base-protocol-mib: Hannes : Some volunteers are there to read and get in touch with operators. Glen have you spoken to some operators reg operator char on configuring Diameter node using MIBs Dan : Not sure of getting feedback but somebody needs to write a MIB .. someone needs to use it. No hard requirement for MIB ..use three minutes in ietf to raise this question .. Dan : Clarification plannery meeting. The trend is that WG needs to provide info. Writing the mib need not be the only way .. if you have diff op model then use it but document it ... Glenn : snmp is not the only way to manage a network or mib is the only way .. mib is just a way to manage it and the way ietf has standardized .. but other methods does not have a standard ... so does not make sense to use other op model.. cos it is not standardized ... Hannes : postpone this disc to ops area meeting. Any review volunteers ??? Dan : this discussion is already taking place ... so join .. Hannes : So we have to do more homework on this topic Dan : Talk to operators and how conf is done .. sata model and etc .. Hannes : Glenn willing to do i t??? Glenn : I suppose so, i have done it before (though it failed) Mark : Radius did not have mib for long time .. but once it was done operators wanted it to be standardized fast ... some volunterred to read it ... * draft-zorn-dime-diameter-cc-appl-mib : Hannes : Many said they will review it Dan : Saw both the mib doc and are in reasonable shape in current status, enough time to clean them , ok for this phase have to look at where would it be used, what can operators do , sense from operation point of view * draft-tsou-dime-capabilities-update-problem-statement : Huawei : Can i explain it .... i want a short statement ... Glenn : I am not altogether convinced of the approach taken in the doc .. but convinced that a section is not clear. Hannes : Would suggest auth to improve .. the text. Glenn : Section screwe. Throw it and rewrite it so that other s can understand it Avi : I agree with that ... Victor : Cannot understand diff between what is there already .. in Diameter base protocol extension Glenn : draft not understandable. Requires a key exchange though only ones cap is changed but all sides wud have to send the capability Hannes : It shouldn't happen frequently Glenn : It cud happen every day. Since we are changin it we should make it better Victor : The existng draft already covers the part Hannes : Explain better in Diameter ext Avi : What happens when C is downgraded Hannes : Lets discuss in mailing list .. and maybe rewrite a section in Diameter-base ext Hannes : Surpried that this never came up in discussion or interop Dave : some editorial as to be done and then evaluate if tech changes are needed * dime grid accounting application : Hannes : Has anyone read it - No * Auditing functionality in dime (req from tispan) Hannes : What do we do ?? Steve : others have changed, and i lack interest in this. Hannes : Discontinue the work * Dime state recovery considerations * draft-dondeti-dime-erp-diameter Hannes : Hokey needs AAA support for the solution , did i understand it .. Glenn : yes, although radius in more important Hannes : thank you .. Glenn : Would be nice to have it in both and yes it is required Jouni willing to input Hannes : Have to see if a new app or new avp * Dime mipv4 spec Hannes : fixes bugs and is a small effort. Is it worth time fixing bugs or leave it. Missing avps and registration Avi : Don't know what to do Hannes : it would be a bis document Avi : I will take a look at it .. if no interest then we can leave it Hannes : No one interested , Avi volunteered to review * Problem statement and req for dime and radius prefix : Sarikaya : We need application support ..this is a prob statement .. i will have to propose the solution Hannes : Interests ??? Jullein was hesitant to say this is a issue and Hannes thinks so too Avi : Do other SDOs face this ? Stephan : Currently no porb in wimax that requires this solution * draft-stupar-dime-mos-options (Diameter extensions for MoS) : Hannes : Postpones till IESG wants it * draft-neumann-dime-webauth Hannes : SIP has application support, there is some excitement there and in digest is also doing something .. wud it be useful to have digest support Avi : SDOs that I work with 3gpp2 and wimax.. we don't but this is not in our domain .. Steve : Is this the WG to do it ? Hannes : Yes since it involves Diameter * Diameter user name and realm based request routing clarifications Hannes : Lists people wanted independent doc and not fixing it Jouni : We had a meeting (victor too) that it has to be a diff doc Avi : We make an assumption that Diameter wud do it .. strange that it is not. Therefore I will support and review Victor : I will too Stephan : I will too * draft-korhonen-dime-pmip6 (by netlmm): Hannes : Interest in the lis. Issues need to be investigated but so far it looks good Lot of interests .... very positive * draft-korhonen-dime-nai-routing : Victor : Jounis draft has a better problem statement.. therefore good to roll it into it Hannes : This is a diff PS Avi : There is a diff. There are issues ..but useful to see how far can we go with it. Jouni : There are some common issues ... so lets split the problem Dave : I have an issue with the failover ... people using the solution can get to a network that is not in use. Steve : Doing this could be useful in Uk, in virtual operator case because other operator traffic not coming to our network Mark : I have problem too with the explicit route. Step back and see if this is still a prob that needs a solution. Glenn : It break load balancing and other stuff. I know it is popular but not convinced Avi : issue is what is the granularity of the route Glenn : Why do we need to maintain state all over the network ? Hannes : What was the motivation. Only a email from a 3gpp .. who uses this Avi : I wanted to write one myself if this is not there, you leave it to chance and you never know the path of packets. Global routing group might need something like this. Sure if i ask them they will want it. Hannes : What about doing NAI and then look at this later Avi : NAI doesn't solve all prob Dave : This is like (intserv) .. set states Steve : Lets work on the scenarios and then see. Hannes : I agree * Misc Q : There was draft that ahmed had for mipv4 application. You forgot to put it in the list Hannes : Ahmed basically used Diameter mipv4 done similar to mipv6 Diameter , the difference is that Diameter isnt used for it Avi : Doing this work in wimax. Pete wants us to solve the exactly same prob that RFC4004 does. We can do it without key bootstrapping. Hannes : Lets discuss it in the list