[15:59:52] stefan.winter joins the room [16:00:28] Alan DeKok joins the room [16:00:29] Hi, I'm the Jabber scribe for today. [16:09:15] david.mark.jones joins the room [16:09:31] david.mark.jones leaves the room [16:17:12] slduan joins the room [16:18:14] Next up: Diameter ERP (see slides) [16:19:07] Slide: Summary IETF76 [16:19:14] Slide: Changes from -02 [16:19:42] Slide: About HOKEY arch [16:20:20] Slide: Remaining Work [16:21:33] Slide: Remaining (2) [16:23:27] Mic: Glen Zorn: there was no decision WRT "local handovers not visible to home domain" confirmed on the list [16:23:53] Hannes: Also no remember of decision; proposed way has advantages and disadvantages [16:24:12] Hannes: Home domain might want to know where user is, for accounting purposes etc. [16:24:41] Glen Zorn: has purely a process question - there was no decision [16:25:04] N.N.: talk in Hiroshima was that authorisation might provide the missing link [16:26:00] Scott Brim joins the room [16:26:08] Lionel Morand: how to fix the problem in the first place? Any need to see the handovers? [16:27:13] Glen: since there is still discussion on the topic, it is obvious that the issue was not confirmed on the list. [16:27:19] Lionel: will take it to the list [16:28:15] Hannes: how is the feeling in the room? Who is not asleep, who understands the issue, who cares about the issue? [16:29:31] Hannes explains hokey reauth, and that its point is that not every reauth goes to home domain. [16:29:45] chris liljenstolpe joins the room [16:29:49] ... but then home domain doesn't know about re-location of user any more. [16:30:37] Alan DeKok: could be done in Accounting stream. [16:30:49] Hannes: Auth/Acct could be different servers [16:31:15] amuhanna joins the room [16:32:22] Mark Jones: would not want to mandate that its visible to home servers, but there are cases where it makes sense to [16:33:56] Glen: makes process more complicated. Home domain shouldn't know that reauth happened. [16:34:56] Glen: it's only about EAP not going to home domain. Diameter itself could still contact home domain to inform of change - but transparent to the user device. [16:40:08] discussion stopped, as it's leading nowhere. Will be further discussed on ML. [16:40:43] Next up: Realm-Based Redirect (see slides) [16:40:58] Slide: IPR from Huawei [16:41:05] Slide: List Activity [16:42:05] Tom recaps the reported issues [16:44:49] Slide: Follow-Up [16:45:57] Dave Mitton joins the room [16:47:48] Jouni: basic problem is: if you defined your own application, need to re-define it for the new AVPs [16:48:57] Tom: yes, that makes it harder to deploy, but solves the technical issue. [16:49:07] - Presentation ended - [16:49:36] Next up: Diameter extended NAPTR [16:49:43] (MArk Jones) [16:49:58] Slide: I-D in a nutshell [16:51:04] Slide: NAPTR & 3588 [16:52:14] Slide: Proposed fix [16:53:31] Slide: App IDs in S-NAPTR [16:56:31] Stefan: AAA+AP1 suggests generic "AAA applications" but there are only Diameter Applications - other AAA protocols use different constructs. Semantics doesn't look right. [16:56:52] Slide: Open Issues [16:57:27] Lionel: What recommendations could we give for the vendor-specific space? [16:57:36] Mark: don't know yet. [16:58:42] Lionel: Guidelines for x- usage? [17:04:25] Dan Romascanu: specification required would not necessarily need to be an *RFC* specification. [17:04:51] Offline: RFC3958 extends "specification required" to "RFC required" instead, so it is a special case. [17:05:12] Yes need RFC, but it could just be a request for IANA action and a reference to the other SDO specification [17:05:37] Quoting 3958, section 7.3: [17:05:49] All other application service and protocol tags are registered based on the "specification required" option defined in [7], with the further stipulation that the "specification" is an RFC (of any category) [17:06:08] So the authors made it quite explicit that they want an RFC (for whatever reason) [17:08:13] Next up: IKEv2 PSK [17:08:29] Slide: Diameter IKEv2 PSK [17:09:26] Slide: Status Update [17:11:32] Dan Romascanu: updates 5778, needs to be mentioned in document [17:11:47] marco.liebsch joins the room [17:11:55] Violeta: will look into that [17:12:17] Next up: Diameter Support for Proxy Mobile IPv6... [17:12:38] Correction: PMIP MObility (Glen Zorn) is next [17:12:44] SLide: Status [17:14:09] Slide: Issues #1 [17:14:59] Slide: Issue #2 [17:16:20] marco.liebsch leaves the room [17:16:38] Slide: Issue #3 [17:18:36] Slide: Proposal 1 from Ed [17:19:09] Slide: Proposal 2 from Author MArco [17:19:13] amuhanna leaves the room [17:19:43] Slide: Proposal 3 from Marco (other prop) [17:20:22] Glen: side-remarks that there are too many graphics in the document ("comic book") [17:20:28] Asks for opinions on list [17:21:12] Sllide: Moving forward [17:21:45] Dan: figures could indeed be collapsed significantly [17:22:26] Discuss the three proposals... [17:22:54] Jouni: Q, does the content of this I-D imply changes in the work of netext [17:23:11] Glen: probably not, but will have to see [17:23:45] Next up: Diameter Priority Attribute Values Pairs [17:23:52] (Tom Taylor) [17:23:59] Slide: Draft Contents [17:24:57] Slide: Status [17:25:53] Ken Coburg(?): last call was right before IETF, not the best moment. [17:26:08] Other parties have been asked to comment, will ping for replies. [17:30:13] david.mark.jones joins the room [17:30:22] david.mark.jones leaves the room [17:31:43] Hello? [17:31:51] life? [17:32:30] it seems to be back. [17:32:39] Aha! [17:32:52] Dave Mitton leaves the room [17:32:52] Just in time for my battery to run dry. [17:32:52] I have about 10 mins left [17:33:53] Dave Mitton joins the room [17:34:07] Next up: Parameter Query [17:34:11] [17:34:45] Slide: The problem [17:34:45] stefan.winter leaves the room [17:36:14] stefan.winter joins the room [17:36:38] Slide: Examples [17:38:03] Slide: DIrection [17:39:56] Glen: criticism on "The problem" slide. There is a database with network information - query it. Don't use Diameter for that purpose. [17:41:11] Glen: Design a way to access the database in a interoperable way. Keep it out of Diameter (it would screw up Diameter) [17:41:25] Alan: Agrees with Glen. [17:41:59] Alan: would need to create a generic querying language in Diameter! Maybe not useful. [17:42:59] Alan: IF-MAP could be used, is a standard in TCG. [17:44:11] another ACK on the mic. [17:44:38] Alan DeKok leaves the room [17:44:52] If 3GPP really wants this, specify your own Diameter application to do this non-AAA stuff. [17:46:09] Lionel: we know that there are other protocols; but current data access model might be too limited if new things need to be queried. Not sure that Diameter could help here. [17:47:17] Dan: draft not very well written, particularly unclear what the role of Diameter is. [17:47:40] Dan: working on this would need serious rechartering. [17:48:24] asdf [17:49:13] Jouni: specific timeline to have results? [17:49:29] James: "any day now" [17:49:52] otherwise, operators might go off and build their own - proprietary [17:50:35] Alan DeKok joins the room [17:51:38] Wolfgang Scheinwald: there is more than one database in the network. Need a protocol to query all these. Diameter would be a good idea as protocol for this. [17:52:04] Wolfgang: would be similar like querying for home locator. [17:53:16] Glen: databases are not a Diameter problem, unspecified in this protocol. [17:53:26] Glen: VSAs exist - use them. [17:54:09] Dan: regarding Wolfgang: AAA context is our charter - and this is not a AAA problem. [17:56:17] Tina TSOU joins the room [17:56:39] Lionel: it's possible to use Diameter for this. But difficult to do in IETF, because needs to be very generic. Better to do it per-SDO: they have well-defined structures. [17:57:06] I'm in WG core, not able to go to dime. But, I don't like the idea add general database query capability to Diameter [18:00:28] Tina TSOU leaves the room [18:01:00] (proxied Tina's statement) [18:01:51] N.N. : Maybe specify a BCP for deisgn patterns of database structures, but that's all. [18:03:15] Dan: There is a mechanism for this: break up I-D into multiple pieces, some of which might fit the WG scope - and send off rest to others. [18:03:52] Wolfgang: some queries make sense in Diameter, like: IP to user-name mapping. [18:04:08] Alan DeKok leaves the room [18:04:27] Dan: AAA server might know this mapping, yes, but is Diameter the protocol to extract this info? [18:05:16] Mark Jones: parallel to DHCP lease query. Proposed queries are very limited, *not* intended to be a generic query language. [18:05:45] Moving on to next item... [18:06:01] Next up: Diameter PCN Data Collection [18:06:15] Slide: Status [18:06:56] Alan DeKok joins the room [18:07:12] Slide: Current Reqs [18:10:02] Work continues now; was held back by PCN being fluid. [18:10:19] Next up: RADIA (Glen Zorn) [18:10:42] Does anybody care about RADIUS -> Diameter any more? [18:11:01] Dan: Should be discussed in AAA doctors meeting. [18:11:43] Dan: AAA doctors in Mezzanine 1 11:30 [18:12:08] Alan DeKok leaves the room [18:12:17] Meeting adjourned. [18:12:21] stefan.winter leaves the room [18:15:20] Scott Brim leaves the room [18:24:38] Dave Mitton leaves the room [18:26:15] chris liljenstolpe leaves the room