DIME met in Palos Verdes 9:00-11:30 Thursday March 25 Jouni Korhonen and Lionel Morand chaired the meeting. NOTE WELL was presented. 1. Agenda and Status ==================== Jouni, charts RFC3588bis: Hannes promised Victor to do PROTO writeup. Dan suggested not to do it now because of open issues. There is a small issue with DNS that is discussed today, apart for this it should be ready (Hannes). An editor *will* be needed at time of IESG review (Tom). Can Victor still do it? Hannes says Victor will still act as the editor. He has only given up co-chair work. 2. NAPT control =============== Frank Brockners, charts Clarifications added. Terminology: Manager-agent rather than client-server because it is not clear which is which in the flow of messages. Authors ask if group ready for last call, and for detailed reviews. Jouni: The document seems ready, will have a look at it, and if OK issue the WGLC. Expect for reviews. Not many people read it in the room (5 people have read it). 3) Diameter Support for EAP Re-authentication Protocol ====================================================== Sebastien Decugis, charts Glen Zorn noted that a decision at the IETF76 meeting that local handovers would not be visible from the home domain had not been confirmed on the list. Hannes stated that it would be desirable to have such visibility. Tom Taylor recalled that it was suggested that authorization would provide the necessary visibility. Lionel: Will raise issue on the list. Hannes asked who understood the issue. He restated it, then asked if this would be desirable. Mark Jones suggested a mechanism for notifying the home domain should be provided but not mandated. xxxx suggested the requirement would be deployment-dependent. Glen Zorn suggested that while EAP/ERP messages would not go back to the homne domain, Diameter operations could be happening in the background that do. Hannes: summary, leave status as is (handover not visible to home domain) and leave it to deployment to provide an alternative. No apparent agreement, either with this position or with requiring the document to provide a mechanism. Lionel: Continue discussion on list, see where we get. 4) Realm-Based Redirection In Diameter ====================================== Tom Taylor, charts IPR from Huawei has been finally declared. 2 reviews received, however comments not yet addressed. Agreed that the resolution of the application problem is to specify this like the capability update, as an increment that can be incorporated into a new application. Jouni: I don't remember well, the outcome could be to define a mechanism, and people who want to support it have to use a new app (making use of the new mechanism) Tom: ok, it resolves the issue... Mention of the caching time should be deleted. 5) Diameter Extended NAPTR ========================== Mark Jones, charts Some discussion re "aaa" tag, no change - distinction of Diameter vs. RADIUS. Some discussion of procedures for vendor-specific application service tags. Mark will bring proposal to the list -- inclined to require RFC (individual, Informational). Lionel: Reprise of aaa+ issue. Not well specified in 3588 -- don't need carry on with this in 3588bis. Will review text on list -- issue of obsoleting 3588 stuff. Stefan: "aaa+ap1" too generic, use "Diameter+ap1"-like instead. Mark: OK. Lionel: What is the role of the "x-" tags? Mark: For applications defined in documents not in RFC series, they cannot be created in the registry otherwise. (clarifying discussion) Followed discussion on RFC3958 about rules for IANA attributions with Dan. Follow-up on this: Mark bring discussion to the list about RFC3588bis update. Lionel: Why do we want to keep what is in the 3588? Do we need backward compatibility? To be checked on the mailing list... General query: Is there any current deployment on (3588)-NAPTR dynamic discovery? So far no one has stated they have implemented it. 6) Diameter IKEv2 PSK ===================== http://www.ietf.org/id/draft-ietf-dime-ikev2-psk-diameter-02.txt o Presenter: Violeta Cakulev Hannes done a review. 2 new revisions since then. Dan: The document updates 5778, it must be specified in the header. Violeta: I am not sure it updates the document, have to check. 7) Diameter Support for Proxy Mobile IPv6 Localized Routing =========================================================== http://www.ietf.org/id/draft-ietf-dime-pmip6-lr-00.txt o Presenter: Glen Zorn, charts Glen commented on excessive number of figures. Dan: do need the figures to hang the text on. Jouni: how likely this document will match what Netext WG is doing? Glen: looks pretty good at the moment. (on proposal 3) Dan: the original draft text sounds like everything is needed... The proposed change might be useful. Conclusion - Request WG feedback on the proposals, encourage more feedback. (will be done on the mailing list, everybody is sleeping in the room... ;) 8) Diameter Priority Attribute Value Pairs ========================================== http://www.ietf.org/id/draft-ietf-dime-priority-avps-00.txt o Presenter: Tom Taylor, charts Need some confirmation on the list requesting publication. WGLC ended without any comment => problem. Ken Carlberg has asked a couple of companies to look and comment. Karl: the WGLC was just before IETF, everybody is quite busy. I asked reviews but got no feedback in this period. Jouni: Chairs will renew or extend LC after the meeting. Glen: There can only be 1 "last" call :-) Please make sure there is only one. 9) Diameter Attribute-Value Pairs for Cryptographic Key Transport ================================================================= http://www.ietf.org/id/draft-ietf-dime-local-keytran-02.txt o Presenter: Glen Zorn, charts No comments. And Jabber also died meanwhile ;) 10) Diameter Capabilities Update Application ============================================ http://www.ietf.org/id/draft-ietf-dime-capablities-update-03.txt o Presenter: Glen Zorn, no charts Believes it is ready to be last-called. No activity to report. Dan: this WG has a lot of docs in progress. Problem is that very little feedback from participants other than authors. If you want more progress on *your* draft, please review *others* as well. ====================== ====================== Jouni: Now considering individual drafts. No room for new milestones until existing work done. Dan: but can still develop drafts as individual drafts. 11) Diameter Parameter Query ============================ http://tools.ietf.org/id/draft-winterbottom-dime-param-query-01.txt o Presenter: James Winterbottom, charts Glen Zorn: this is a database access problem, not a Diameter problem. Nothing prevents anyone from querying the database using a suitable protocol. Alan: supports Glen's view. Diameter does AAA, the cost to add queries is small, but you end doing SQL-like in Diameter, which is not good. Hannes: so what mechanism would you use?. Alan: Trusted computing group (TCG) working on exactly this problem. TCG has a standard (TNC IF-MAP Binding for SOAP Specification) to access database with SOAP, for what happens in the network. It is quite new, no not much deployed, but they solve exactly this problem. Frank: individual SDOs will create their own Diameter applications, but generic solution very difficult. Lionel: not sure Diameter is well-suited for the necessary notifications. Dan: impression in Hiroshima and now the same. Document needs further development, perhaps breaking up to focus on specific problems. Lionel: We had this discussion in several places, we cannot really come to a standard solution. Dan: the context of this draft is probably not related to DiME work. This work would require a serious rechartering. Cleanup, split the document, then come back with parts that fit. Jouni: you referenced several SDO. Do you have a timeline? Wolfgang: I am in favor of the proposal. Diameter is a good protocol for this purpose. Glen: what is the problem with different SDOs doing the job differently. Each is dealing with a different database structure. James: then why caring for Diameter at all? Dan: this does not solve any problems related to access. Sees little chance for this to be accepted as a DIME work item. If you want to do it you may need to charter another WG Lionel: problem with doing it here is how to be generic enough to solve everyone's needs. Individual SDOs can provide more targetted solutions. Only value added would be to have standard values for AVPs. James: it is already in the draft: we require explicitly what information we want. Lionel: How do you standardize what to query? It will be different in each context. Martin Thompson: problem needs to be recast in different perspective. Query is: what was in such-and-such AAA request, and what was the content of the response? More like an accounting record query. Jabber: no support for database query. xxxx: perhaps define a design pattern, so SDOs can do things in a way that does least damage to Diameter. Dan: the mechanism is there in Diameter. But the problem is not only out of scope of DIME, it is outside the domain of expertise of the WG. Wolfgang: How do we query "who owns the IP address XXX" ? Diameter is a logical interface for this. Dan: this is philosophical. Mark: we are querying very specific attributes, not anything generic. We want to know AAA-network access information. If clarified in the draft, it can be considered. Jouni: can work on draft, but cannot expect early action on it. And time's up... 12) Diameter PreCongestion Notification (PCN) Data Collection Application ========================================================================= http://tools.ietf.org/id/draft-huang-dime-pcn-collection-02.txt o Presenter: Tom Taylor, charts Status report, no comments. 13) The RADIUS-Diameter Gateway (RADIA) Application =================================================== http://tools.ietf.org/id/draft-zorn-dime-radia-gate-01.txt o Presenter: Glen Zorn, no charts Not sure if anybody cares about the topic anymore. Will be considered by AAA directorate. Jouni & Lionel: Meeting concluded.