Agenda Bashing -------------- * Very full agenda * Two parts, WG documents that are to be completed and new work RFC3588Bis Work --------------- * All open issues are now closed * Version 09 is in LC * Version 10 will contain latest comments from reviewers * No open issues. WGLC under way. Need more reviews. A few recent issues resolved. Hannes : Asked for reviewers - Jouni, Mark, Lionel MIPv6: NAS-HAAA support ----------------------- * Changes from 0x -> 05: Big rewrite to support RFC4285bis * Changes from 05 -> 06: Fixes surrounding 4825bis again * RO support * Open issues - split the ID into two - Replay protection * WGLC Hannes : We not going to split, we pass one LC and people are happy with the doc Gerardo : Disagree, 4285 solution is all informational in the bis Hannes : This is not a problem. In proto writeup its a downward reference. Gerardo : Don't see a reason why standard track document refers to informational docs. Hannes : Some sections are informational or downward reference. Dan : Could have non-normative reference. MIPv6: HA-AAA support --------------------- * Changes from 05 -> 06: Fine tuning * Changes from 06 -> 07: - Home-link-prefix AVP - Correcting flags again to make it application independent - Provide clear examples how to use MPv6 feature * Submit to IESG ? Hannes : WG LC already on this document. Need to issue a short LC for one week before IESG Qos Attributes -------------- * Changes from 01->02: - Add Qos profiles - Add flow states and direction - Add Qos object types * Chnages 02 -> 03: Renaming of AVPs etc * ID extends diameter base * New AVPs convey Qos as part of the NAS * Qos maybe pre-provisioned or NAS * Next steps: - Error codes - Reviews for WGLC required Hannes : Still has WGLC. Document has been sent to other SDOs and had good feedback Qos Parameters -------------- * Issued WGLC early. Turned out to be good since we found conflicts with NSIS and TSVWG. * Resolution was that tsvwg-emergency-rsp will create IANA register then QSPEC and DIME documents will point to the registry Francois : Resoultion announcement did not make it to the list. Will resend. Diameter App Guidelines ----------------------- * Updates from reviewers - Added M-bit clarification - Added min count on optional AVP - Added Vendor specific command codes - Fixed accounting model that uses different app-ids in header and body Reviewers : Jouni, Lionel, Mark Proxy MIPv6 ----------- * NETLM WG is finalizing the PMIPv6 * ID aims to support: MAG (NAS) to AAA and LMA(HA) to AAA * Proposed solutions: extends MPv6 boostrapping which is not specific to PMIPv6 * Issues: - RADIUS internetworking - Accounting on MAG & LMA - Session mngt - etc * Adopt as a WG work item ? Hannes : New work classified into categories. One would be work related to other work being done from other WGs Gerardo : Normal procedure is that the related mobility WG give us requirement for the work before starting something. Is this a procedural issue ? Do we need some requirement ? Hannes : We have several documents to look at for new work. But we do not need formal requirements from other WG to start work. Gerardo : NETLMM has a lot of issue for bootstrapping MAG and LMA. Those things belong to the NETLMM WG. Should this work be there as well ? Bechet : Similar issues arise for draft with RADIUS for NETLMM. We need to support this work. Regarding NETLMM requirements, theres no official view on this Glen : Is it a good thing to throw over to NETLMM since they know what they want to do ? Hannes : Worth while idea Dimaeter Qos ------------ * Changes: Split the document into framework and protocol. Still not sure if this is good idea or not. It may slow us down. * Changes: - Editorials - New terms - Handle discovery and selection (for push mode) - etc Francois : This does not cover control of signaling proxy behavior, do we all agree that this will taken care of in the next rev ? Hannes : Yes. Additional details will be added in the doc. Are there any IPR related issue ? Francois : Not sure. Not aware of one. Hannes : Most documetns are making good progress in the group except maybe this document. ** Rechartering Discussion Hannes : What are the priority for MIPv4 dime application ? Can we hum for interest in this work ? ** Hum: not strong but seems no objection Gerardo : What is the scope of this work ? Which are we talking about ? MAG profiles or bootstrapping of security ? Hannes : Who has read MIPv6 application ? We can take the discussion to the list Auditing -------- * History: 2 drafts on the subject, requirements and state-recovery (expired). The second considers possible design approachs * Why include this work ? - Evidence of functionlity and the need for both soft and hard state storage * Drafts go into requirements in details * Next steps ? - Add to the charter and merge both drafts - Decide use of resource management Hannes : We have ask the group in the past if work in this area is need ? There was good response plus liason from TISPAN for this work Glen : There are bunch of requirments in that document but not sure what the problem they're trying to solve or why theres a need for box communication Speaker : In the use cases section, there's are explanations for reasons and what the document is trying to solve Glen : There where use cases but did not lay out the problem they are trying to solve Speaker : The second doc talks at lenght on why a protocol method is needed. Hannes : This can be an action item to sort this out in the list. Diameter MIPv4 application -------------------------- * This is an alternative approach to DIME MIPv4 - we highligthed performance issue with respect to radius * RFC4004 provies AAA and MSA allocation but does not rely on access auth for MIPv4 MSA allocation * MIPv4 RRQ/RRP are coupled with RFC4004 * 3GPP2 and WIMAX use EAP for access auth * HA in 3GPP2 and WiMAX need to fetch MN-HA secret key * Recommendations - New model for diameter MIPv4 must support new messages between HA and HAAA for MIPv4 authorization and MH-HA, FA-HA, MSA * Can approve a need for diameter MIPv4 Glen : 3GPP2 and WiMAX has taken standard IETF protocol and misuse it and now want us to change the standard to support them ? Ahmad : Old MIPv4 does not use access authentication. They still need diameter at the HA. Hannes : There are many details so lets take it to the list, Pete's going to talk about MIPv4 that has a different deployment model RFC4004bis ---------- * Changes: No major overhaul, just fixes a few bugs * Left out the AAA-SPI needed for 3957, MN-FA SPI is created by the FA but not being transfered in the AMR * MN-HA SPI is not needed in the MN-HA MSA AVP * Changed text in section 9.5 Hannes : Its not a competing type with the alternative dime MIPv4 apps. The document change is a small effort. Some of these issue came up with dime MIPv6 work as well. Alper : Is this going to be done in DIME. In WiMAX, we only discuss concept. We would like to separate signaling from diameter. We would like to bring this to idea to IETF. Hannes : We generally do not care where the idea came from. We will still review it. Diameter Classifier ------------------- * Document defines a grouped AVP which can be used to express and IP or L2 packet classifier * Benefits: more extensible than ASCII and decouples condition from action and in the filter rule * Propose this as a dime WG work item. Its straight-forward work and well-defined Hannes : Presented in last IETF. Came in the context of the RADEXT Hannes : Who has read the document ... only a few Prefix Delegation ----------------- * The LMA prefix managment in proxy MIPv6 * NEMO requires prefix manamagement * Diameter-PD vs DHCP-PD, both solutions are complementary with each other * operators can choose a solution * It is a natural extension to IP address manaanment * Proposals: put it into DIME re-charting Hannes : We can discuss this issue in the mobility working group, mext group Support for ERP --------------- * Support for ERP (EAP re-authentication) * Message needs to be carried over RADIUS/Diameter * Carry new EAP codes in diameter messages. Nas needs to copy the content of rikname-nai tlv, rmsk is sent via eap-master-sesison-key * dsrk request and delivery Hannes : Work in some other WG, some interaction with backend. Use next weeks to discuss different proposals. Who wants them and for whatever reasons. Claim the need for that work is justified. Speaker : Some discussion in the HOAKEY WG Dan : Criteria - Need to prove operational need for the doc. pool of reviewers for this doc.