[14:47:03] -- is this thing on? [15:02:59] mccap joins the room [15:03:05] vifajardo1 joins the room [15:03:13] Dave Nelson joins the room [15:03:25] HannesTschofenig joins the room [15:03:45] David Frascone crosses his finger for a scribe too :) [15:04:24] mark.jones joins the room [15:04:42] pete is going to be the jabber scribe [15:04:49] Does anyone here need a blow-by-blow of what happens in the meeting? [15:05:09] I think as long as audio stays up, and people use mic's we should be ok [15:05:14] alandekok joins the room [15:05:19] The streaming audio is delayed about 5 seconds [15:06:43] davem joins the room [15:07:22] i'm on the audio bridge and it is working fine [15:07:46] Going over agenda now [15:07:55] davem leaves the room [15:09:12] Milestone and charter update [15:11:18] which document was missed? [15:11:24] Diameter API last call from Victor [15:11:33] Status update [15:11:59] Didn't catch it sorry [15:12:52] You can often "re-sync" teh delayed streaming audio by existing the player app and re-connecting. [15:14:33] err.. 'exiting". [15:14:48] 3588bis issues from Victor [15:20:21] davem joins the room [15:21:33] lion joins the room [15:21:45] davem, lion, are you guys on the audio stream? [15:22:09] I'm not [15:22:14] histerrier joins the room [15:22:38] Yes, but my side of the connection (a cell phone tether) occasionally goes out on me, so I'll be randomly go away - I just came back [15:22:54] Ok. I'll start with a bit more detail now. [15:23:06] We are discussing the CER/CEA TLS issue [15:23:40] Need to run TLS first, before CER/CEA [15:24:02] Proposal number 3: either add a separate port or a new command to start TLS [15:24:20] Issue #2: MAY column on the M-bit [15:24:49] Nice: Due to the delay, your comments are very real-time with the audio stream. Keep it up! [15:24:54] Proposal to take it out; it is confusing [15:25:12] agreed. lots of confusion on this. [15:25:18] what agenda item are we on? [15:25:28] We are on 3588bis issues [15:25:54] Another proposal: keep it in, but explain it better [15:26:17] is the audio bridge 2-way? [15:26:18] davem leaves the room [15:26:25] For extensibility, others might want to set it. [15:26:41] No, audio stream is one-way. But, Hannes has a conference bridge [15:27:25] davem joins the room [15:27:42] Mark on conference bridge: setting M-bit is design time, not run time [15:27:44] davem leaves the room [15:28:02] And, I'm sure our scribe would be happy to ask questions for us, if we had them :) [15:28:07] Sure. [15:28:37] Hannes: setting needs to be done in spec of command code, not AVP [15:28:54] If M-bit is "MAY", then you can decide at run time [15:29:30] Mark jones: no, specification time issue. Column is way too confusing. [15:30:30] Comment at mic: M-bit should be set in a spec, define for each AVP in a spec [15:30:57] Keep it, specify where M-bit is set, describe per-command how M-bit is set for the specification. It is a documentation issue. [15:31:35] Conclusion of ext DT was to decide per-spec, per-command. Then there is no unclear issue for how to set it. [15:32:07] Bernard: we created too many degrees of freedom here. M-bit, ABNF, negotiation is way too much. At least one of those things was unnecessary. [15:32:12] and 3GPP has a Supported-Features AVP :) [15:32:42] ABNF tells you behavior, then we added the M-bit [15:32:58] And we said have to create another application [15:33:35] Hannes: ABNF is for sender, M-bit is for receiver [15:34:09] Bernard: then we don't need additional application option [15:34:21] Hannes: so maybe it's time to get rid of one of these [15:35:05] DaveN: Some confusion: MAY means is not optional/userchoice/runtime, it is specification. Conditional MUST. [15:35:33] yes...conditional MUST and the specification SHALL specifiy the conditions [15:35:34] Hannes: some think it is conditional MUST, others think that it is optional. [15:36:39] kill it...just look at the confuision in the room... [15:37:04] Lionel: according to previous agreement, meaning of MAY was to require it if AVP is present, otherwise not. [15:37:19] Mark, let me know if you want me to relay some comments [15:37:25] But I think you are on the conference bridge [15:38:07] Mic: if we need conditional MUST we should introduce this wording to make it more clear [15:38:07] (sorry, i will speak up on audiobridge) [15:38:19] Dan R: conditional MUST is closer to SHOULD [15:38:37] Lionel: need to explain clearly the MAY column and how to use it. [15:38:52] Hannes: 2 choices: 1. describe what it does. 2. deprecate it. [15:39:17] Lionel: for a given AVP, M-bit will be same for all applications, all commands? [15:39:28] Hannes: no, need to describe setting for each command. [15:39:35] Lionel: table per command [15:39:52] DanR: go with removal of MAY column [15:40:09] Hannes: prefer to remove column yes/no? [15:40:12] avri joins the room [15:40:14] about 10/12 for yes [15:40:19] No objections [15:40:47] Issue #3: cleanup issues for peer discovery [15:41:23] Need to deprecate A-records using underscores. That was the fallback when NAPTR records were not found. [15:41:29] Should use SRV instead. [15:41:51] Hannes: this is part that isn't implemented, so it is possible to change. [15:42:06] Mic: we would like to use it [15:42:21] Same thing in RADEXT going on now. Should be identical. [15:42:29] Hannes: nowadays use UNAPTR [15:43:03] GlenZorn: RADIUS = DIAMETER is evil, making them the same will lead us to certain death [15:43:14] Hannes: we like to be evil. [15:43:24] ha [15:43:35] Issue #4: downgrade SCTP MUST supported by servers. [15:44:00] Hannes: TCP is what most people implemented, SCTP was not implemented/not very good [15:44:14] We had 1 implementing TLS for SCTP, supported only one stream [15:44:26] Victor: if no one objects... [15:44:40] Issue #5: raised by Mark [15:45:14] redirect-host AVP. 6.12 SHOULD BE used for all messages, then says default is don't cache. [15:45:19] Seems like a contradiction. [15:45:49] Fix is required in 6.12 and 6.13 [15:46:04] Default should be all-session [15:46:16] But, open to input on what would be the impact [15:47:08] Victor: picking all-session as default could impair routing behavior. If default is all-sessions, router has to do a lot more work. [15:47:18] Don't cache default would keep things simple. [15:47:36] behcet.sarikaya joins the room [15:47:41] But last mail from Mark said there was some 3GPP spec implications. [15:48:40] Victor: but which one is default? [15:48:53] Glen: so default for both would be dont-cache? [15:49:14] Victor: don't cache would be simpler [15:49:39] Glen: issue is these things don't match? Change one, don't want to change redirect-host-usage? What about auth-session state? [15:49:50] Victor: no-state maintained. Any objections? [15:50:01] didn't catch that...did Victor say Auth-Session-State default would change too? [15:50:25] Yes, need to change it to NO-STATE_MAINTAINED [15:50:41] Hannes: take resolution to the list. [15:51:15] Mark: there is a contradiction here needs to be fixed. [15:51:26] Victor: yes, we need to establish consistent default behavior. [15:52:01] DanR: if we are done with these 5 issues, strawman proposals in next few days, urge WG to make this document highest priority [15:52:53] This document is very much expected by IETF and other SDOs. It is blocking whole process of requests from other organizations. [15:53:25] Hannes: schedule a conf call for next week to see if there are any other questions [15:53:44] conf call or no conf call...missed the conclussion [15:54:00] I think he says we will do one. [15:54:05] k thanks [15:54:26] mark, no-state-maintained as a default is ok with you ? [15:54:48] so u proposed changing the default of Auth-Session-State too [15:54:56] Bernard: Urge that WG members read the RADIUS extensions documents [15:55:09] to keep it aligned as per your concern [15:55:14] Some issues with 3588bis and Diameter-NASREQ if there is one [15:55:31] One issue: assumption made that RADIUS VSAs had particular format. That assumption is incorrect. [15:55:51] One of the assumptions in NASREQ was an 8-bit type code and that RADIUS VSAs use 2865 format. [15:56:18] RADIUS extended attribute is now not compatible with 2865 format. This will not pass from Diameter, as specified in current NASREQ document. [15:56:29] Another issue: grouping/tagging interworking between RADIUS and Diameter [15:56:52] Once document completes will be assigning extended attributes, don't want Diameter to lose that functionality [15:57:02] Will happen in next couple of months. You should read it. [15:57:13] Question: Wasn't diameter supposed to be a superset of radius? [15:57:25] GlenZ: confused. Extended attributes were designed to be compatible. [15:57:43] Should I relay your question David? [15:57:48] please [15:58:57] are you on the bridge? [15:59:12] davem joins the room [15:59:27] test [15:59:32] Yes, I was [15:59:42] Alan DeKok: extended attributes are VSAs? Is this for old equip that hasn't been updated? [15:59:51] I was disconnected and off [15:59:55] Bernard: doc now says they get translated to Diameter VSAs [16:00:09] But I was listening to the stream -- it is easier to hear other mics on stream. But, it's so far delayed from the bridge . . .hehe [16:00:24] Changes that Dave Mitton proposed are there: however, that's never been approved by dime [16:00:32] has been around 2 years, good proposal. [16:00:43] Just take stuff across as-is, then it becomes very simple [16:01:19] GlenZ: forgotten how it is done in 3588. Incomprehensible why Diameter GW would look that deep into a packet (into an AVP) [16:01:55] DaveNelson: VSA is a general purpose extension mech. Assumption that it is vendor specific and can be ignored. [16:02:24] Using extended attribute with VSAs was a way to get something backwards compatible, but now it might be IETF standard. [16:02:39] Bernard: when you write ABNF, there might be a VSA with IETF vendor code [16:03:06] it was draft-mitton-diameter-radius-vsas-01.txt [16:03:28] GlenZ: that can happen, but it is kind of silly to set the MUST bit on these things, RADIUS=Diameter evil-ments. Diameter is compatible with RADIUS as it existed at the time it was forked. [16:03:43] Would be a really big mess to try to make Diameter compatible with every RADIUS extension in the future. [16:04:00] Bernard: that's a decision for dime WG to make. You will be left with implications. [16:04:30] what presentation are we on? [16:04:38] Charles Perkings now presenting mip6-integrated [16:04:42] Perkins [16:04:45] behcet.sarikaya leaves the room [16:05:33] Currently in IESG, some comments "raided" by three ADs [16:05:42] Several changes from -09 to -10 [16:05:56] 1. Removed all example commands (it is not an application) [16:06:20] 2. Upgrade to allow DS-MIP deployments, both IPv6 and IPv4 address [16:06:32] 3. Updating to more recent RFC for IANA allocation rules. [16:06:57] DISCUSS comments in IESG: they are mainly editorial [16:08:06] Diameter-RADIUS interop by using small-numbered AVPs [16:08:46] Hannes: Pasi's comments triggered some discussion among authors/chairs/IESG. One of issues with AVP allocation, make sure that we don't reserve two different AVP codes one for RADIUS one for Diameter [16:09:06] We didn't do that. This document has a few "simple" AVPs, codes are reserved from RADIUS space [16:09:38] One complex nested AVP that would rely on RADIUS extended attributes, but we don't want to create a dependency [16:09:54] GlenZ: RADIUS = Diameter is evil (again) [16:10:06] This is nonsense to have a Diameter document defining RADIUS attributes. [16:10:42] We fought for years over the AVP formant, is insane to go back to stilted and limited RADIUS attribute encoding. [16:11:18] Hannes: doesn't make sense to reserve a different number if functionality is the same. In this specific case, the goal is 100% alignment for those AVPs that are impacted. [16:11:49] GlennZ: makes no technical sense, no sense from IANA PoV, they are 2 separate protocols. Diameter is not a leg grafted onto RADIUS [16:12:11] CharlesP: what if there was a dev team responsible for both RADIUS and DIameter, want to simplify their life [16:12:36] Hannes: basically, you have the dictionary, would point a specific number to an AVP, you can have the same number or a different number. [16:12:48] Charles: so this is not a hard problem, it is just a convenience [16:12:53] GlennZ: it is silly. [16:13:29] DanR: sub-protocol of SNMP did same thing for implementers convenience [16:13:50] DanR: we need to discuss with ADs even though comments are raided... [16:14:16] Pasi thought there was just a waste of managed space, this was the intent of his comment. Shouldn't allocate 2 values in same space for similar things. [16:15:03] More complex problem: (on agenda of AAA-doctors team): may need to clarify when tranlsation works, when dictionary is available. [16:15:32] Usually Diameter came after RADIUS. We have Diameter considerations in RADIUS documents, but not the other way [16:15:45] CharlieP: that would not be a part of this document [16:15:52] DanR: right we are not holding this up. [16:16:11] DaveN: compatibility is supposed to be upward from RADIUS to Diameter, not the other way. [16:16:45] Elena joins the room [16:17:14] It is ok to do upwards compatibility when defining RADIUS attributes, not the other way [16:17:33] Bernard: analysis of the needs of this application was one of the justifications for creating Diameter. [16:18:23] One of the arguments with doing this application is revisiting that decision. Did another requirements document for the RADIUS application. Now IESG comes along and says these have to be merged. That is completely unacceptable. [16:18:41] If you carried this through with every Diameter application RADIUS space would be completely exhausted. [16:18:48] Charles: So ADs expect us to push back. [16:19:05] Hannes: it was a compromise that we only have a couple of Diameter AVPs are allocated from RADIUS space. [16:19:30] But what I hear from the group is that you want us to keep spaces separate. [16:19:57] Bernard: there is a very long process that got us to this point. If authors/chairs decide that it was a mistake, then we can change it. [16:20:10] But IESG doesn't have the right to impose this given all the process that has taken place. [16:20:29] Hannes: there is a lot of dependency from outside the IETF, Discuss puts pressure on us. [16:20:48] Bernard: DISCUSS is just invalid. It overturns 10 years of process. [16:21:24] If they do this, they could take out the entire RADIUS attribute space, patching together protocols, it would shut down usability of RADIUS [16:21:33] CharlieP: let's see what the room thinks. [16:22:14] Hannes: we are running out of time. Let me ask: "Should we try to restore the state we had previously, namely: this document has IANA considerations to request a couple of Diameter AVP codes and not reserve anything from RADIUS attribute space"? [16:22:28] davem leaves the room: Replaced by new connection [16:22:29] Should we go back to IESG again instead of asking for mish-mash. [16:22:30] davem joins the room [16:22:38] about 10 in favor. [16:22:49] Who thinks we should go forward based on compromise? [16:22:51] No one. [16:23:22] GlennZ: reiteration: evil theme. Cannot compromise with evil. It's a bad idea we have to tell them. [16:23:47] AhmadM: Charlie made a good point, AD is probably not aware of past discussion. [16:24:02] CharlieP: these are different ADs than ones that chartered AAA WG, they weren't there. [16:24:37] Sorry, I got cutoff again - I will review the meeting notes for later comments - Dave Mitton [16:24:37] DanR: process right now is that revised id will be out, 2 of 3 DISCUSSes will be cleared easily, need someone from the WG and editorial team to put together the case for clearing the 3rd. [16:24:54] Elena leaves the room: Replaced by new connection [16:24:54] Elena joins the room [16:25:11] Hannes: glen if you can help that would be great. [16:25:45] GlenZ: many DISCUSSes from ADs come from ADs that are not technically competent. Process for recusing selves from ADs, not used often enough. [16:26:02] Now discussing mip6-split document, Hannes presenting [16:26:06] We had a WGLC [16:26:15] Folded in feedback at last IETF meeting that simplified the document. [16:26:33] Next steps: [16:26:59] Split functions on feature bits into a new document, draft-korhonen-dime-mip6-feature-bits-00.txt [16:28:03] Will submit document to IESG since WGLC was passed. [16:28:37] alandekok leaves the room [16:28:39] Now discussing Diameter QoS Parameters [16:29:08] We structured : diameter QoS application, passed last call, no issues [16:29:29] Diameter qos attributes: will be presented . We got a number of comments on that document [16:29:46] 3rd document: qos parameters document which just provides description of QoS information [16:29:53] re-used work from NSIS [16:30:06] They took work from transport area and other previous work. [16:30:21] As a side-effect, we inherited their encoding. DIdn't seem a problem duing WGLC. [16:30:39] Group favored custom encoding at that time. However, IETF last call, 2 comments came: [16:30:45] 1. Describe QoS parameters more [16:31:02] 2. Choice for encoding right? Switch between RADIUS, Diameter, or custom? [16:31:09] 3. Do we need all these QoS parameters? [16:31:13] alandekok joins the room [16:31:24] Don't expect during this meeting to make decision on editorials or QoS parameters themselves. [16:31:44] Dan suggested to remove one parameter move it into attribute document. [16:31:51] Would like to discuss the encoding of these parameters [16:32:21] GlenZ: Goes back to the same old thing. Look at values being sent back, fall very naturally into Diameter AVPs. But the AVP functionality is not being used. [16:32:34] If there is any set of AVPs that should be encoded in classic Diameter format, this is them. [16:33:10] Hannes: ask the group. QoS parameters as an example describes token bucket, etc. What type of encoding would you like to see being used? [16:33:15] Three choices: [16:33:33] 1. Diameter based encoding, 2. RADIUS based encoding, 3. Custom encoding. [16:33:42] me [16:33:46] 1. 6 people [16:33:54] 2. none [16:33:55] 3. none. [16:34:02] David Frascone is for diameter based [16:34:42] Decision is to prepare an updated document for Diameter. [16:34:53] davem leaves the room: Replaced by new connection [16:35:51] davem joins the room [16:36:38] Mayutan now presenting Dime QoS attributes document [16:36:46] Changes from version i7 to version 8 [16:36:49] Elena leaves the room: Replaced by new connection [16:36:49] Elena joins the room [16:37:03] Main changes: VLAN-ID-Range into ETH-Option [16:37:14] S-VID-Start AVP [16:37:20] C-VID based on IEEE802.1q [16:37:26] S-VID IEEE 802.1ad [16:37:40] Time of day condition [16:38:02] e.g., 9am to 5pm Mon through Fri, encode start time/end time/days of week [16:38:08] Changes in next version: [16:38:12] 1. QoS Profile template [16:38:16] 2. Excess Treatment [16:38:46] Hannes: briefly mentioned previously: Dan AD review of QoS parameter document, ran into one that didn't quite fit: Excess Treatment. [16:39:34] Additional changes in next version: [16:39:39] IP-version [16:39:40] Elena leaves the room: Replaced by new connection [16:39:40] Elena joins the room [16:40:07] Hannes: borrowed from IP-Filter-Rules, didn't cover IPv6 [16:40:22] Issues: [16:40:37] shift the excess treatment action from QoS Parameters to this document. [16:40:43] Actions: drop/shape/re-mark. [16:40:43] jounikor@gmail.com joins the room [16:41:12] Other issues: [16:41:16] 1. IPv6 [16:41:24] 2. only TCP/UDP what about SCTP DCCP? [16:42:42] there's protocol type already.. and port information. so SCTP & DCCP can be classified [16:42:46] to some extent [16:43:48] davem leaves the room: Replaced by new connection [16:43:50] There is something missing. [16:44:17] Report about Design Team on Diameter Routing [16:44:21] Glen Zorn [16:44:29] davem joins the room [16:44:44] Progress or lack thereof on the Diameter routing Design Team [16:44:52] Tina, Victor, Jouni, Tolga... [16:45:00] Elena leaves the room: Replaced by new connection [16:45:01] Elena joins the room [16:45:29] Issues have to do with source routing, network selection. How to select the first network? [16:45:50] Presumed answer: decorated NAI, pre-configured. [16:46:28] behcet.sarikaya joins the room [16:46:29] Subsequent messages: is it needed outside some pre-existing (flawed) architectures? [16:46:51] Policy is sitting inside the network, all Diameter messages need to be routed through the same places over time. [16:47:05] 3 options here. [16:47:16] 1. Zero change to Diameter itself, is simply a policy choice [16:47:38] (architecture in question also requires shutdown of session in case Diameter peer disappears.) [16:48:15] make all Diameter peers stateful proxies [16:48:53] Arguably, this is too anal about the whole thing. [16:49:06] Maybe we want loose source routing [16:49:43] Bernard: one of the other ways is by sticking state on the client. Then you can give state to new proxy. [16:49:53] GlenZ: client has no idea about the state [16:50:01] Bernard: dump state on client like a cookie. [16:50:28] GlenZ: this is somebody else's architecture, we can't change it or tell them to fix it. [16:50:44] behcet.sarikaya leaves the room [16:50:50] AlanDekok: some of that state is correcting implementationi issues on either end of the network. Client has absolutely no idea. [16:51:03] GlenZ: don't want to go into a big discussion about this architecture. [16:51:12] 2. Loose routing, has same problems with failover [16:51:20] Fewer problems with load balancing [16:51:41] DT has not reached a deciision on this one. [16:52:05] Third problem: application and realm based routing. [16:53:12] Glen: don't understand this one [16:54:11] Dave from bridge: no sure either. same way as NAI routing, only depend on application [16:54:28] TomT: specific party in the DT suggested it. [16:54:51] Hannes: problem 1 is covered by Jouni's document [16:55:03] Real issue is: do we need record route, loose/strict routing in Diameter? [16:55:49] Hannes: do you understand why strict/loose routing would be needed? [16:56:23] Bernard: for the same reason that decorated NAI would be needed. You only need it in a couple of circumstances outlined in 5113. [16:56:58] Hannes: issue is that decorated NAI is used for network selection. [16:57:07] Bernard: just do whatever it says in the NAI [16:57:30] GlenZ: how strict does routing need to be? Domain based? Seems to fall out naturally. [16:57:48] Hannes: end-host selects something, then constructs NAI. [16:58:19] Hannes: difference proposed, is that info would not be provided by end-host, have some Diameter nodes somewhere in the network, they require that all further messages for same session traverse same nodes. [16:58:22] lion leaves the room: Computer went to sleep [16:58:31] They would know that locally and then they would attach state information. [16:58:38] Is a slightly different problem space. [16:59:20] Bernard: 2 approaches described in 5113. 1. Have network figure it out. Decorated NAI, we didn't think network had the info. In the long term you don't want to do that. Move to more network-based. [16:59:30] 2. Source routing. Should do one or the other. [17:00:02] AlanD: on the RADIUS side, doing global roaming, they are terrified of decorated NAI. There is a lot more interest in allowing the network to do the routing. [17:00:23] There has to be some kind of standard for exchanging/sharing information. Lot of politics. [17:00:56] Bernard: 5113: situations with multiple possible routes. We have no routing mettric. That's what gets you into the problem. [17:01:10] Right long term solution is to have metrics and a real routing table. [17:01:17] Glen: doesn't solve this problem. [17:01:28] lion joins the room [17:01:43] Alan: some overlap. Some of the AAA routing discussions are paying attention to routing research from 25 years ago. [17:01:55] GlenZ: problem is policy info in the network [17:02:16] Alan: there is overlap. The ones looking at routing protocols are the ones defining policy in the network. That's what I'm seeing. [17:03:10] mic: similar things in Diameter: redirect agent, can enforce some policy. [17:03:31] not specified what to do when peer is down. [17:03:40] Glenz: actually there is, just find another peer. [17:04:10] Hannes: if you have a redirect, get entry to that destination, then if that entity goes down, do you go back to redirect agent to figure out where to go next? [17:04:25] GlenZ: local policy. Go back to the table, try again. Any kind of source routing defeats that mechanism. [17:04:54] Lionel: from 3GPP PoV is not about state, as soon as you have some dynamic path established, all of the other requests need to follow that path. [17:05:24] Hannes: why would you assume Diameter nodes would randomly send destinations in the first place? [17:05:38] davem leaves the room [17:05:44] GlenZ: if you get "too busy" you'd have to tear down the session. [17:06:37] Hannes: we need to dig into more details. We are not yet there. [17:07:44] Lionel: it is possible to do it like this, but if one of the nodes fail, too busy: [17:08:03] Hannes: we will have to provide an approach in that case, most people have a better understanding of problem statement. [17:09:38] GlenZ: maybe we should throw the problem back at 3GPP [17:09:50] TomT: let 3GPP define this? [17:10:01] GlenZ: wouldn't be the first time. [17:10:14] Linoel: goal of DT is to decide whether it is a core Diameter issue. [17:10:48] DanR: type of issue why both 3588bis and Diameter API are still out there. We need to define what is in scope/out of scope. [17:11:46] Now Lionel presenting "Diameter User-Name and Realm based Request routing" [17:11:56] Clarify handling of Decorated NAI. [17:11:58] mark.jones leaves the room [17:12:30] Intermediaries re-writing User-Name and Destination-Realm. [17:12:47] base protocol didn't take this into account. [17:13:39] Impacts Diameter proxy, examines user-name to see if a decorated NAI is there. [17:14:43] Working group document? [17:14:54] Hannes: Need to get new charter proposal out there [17:15:16] Now Lionel presenting "Command codes for 3GPP" [17:15:35] Request allocation of new Command Code values, IANA policies require a document to allocate new command codes. [17:15:51] 3GPP currently defining a new network, with new applications [17:16:06] New set of commands for S6a application and S13 application. [17:16:20] There is no specification, just referencing 3GPP spec. [17:16:47] This draft is on the 3GPP/IETF dependency list. Proposed Individual submission as Informational RFC? Sponsored by AD with expert review? [17:17:12] Hannes: this request is the reason why we need 3588bis to be published soon, don't want these kinds of requests coming keeping Dan busy. [17:17:31] DanR: willing to shepherd this one, under gentleman's agreement with WG. [17:17:43] We will be sending this back to the WG for expert review. [17:17:50] Elena leaves the room: Replaced by new connection [17:17:50] Elena joins the room [17:18:44] DanR: please send me a request to take this on as an AD sponsored document. Fill in shepherd write-up. [17:19:09] Now Alan Dekok is presenting "RFC4282" oops, i18n [17:19:50] Currently problems with NAI handling. [17:20:03] Specifies filtering of non-mapped characters. [17:20:16] We need to internationalize discussion of NAI. [17:20:46] not many implementations will have to change that much, need for a document that documents what people do. [17:20:53] lion leaves the room: Computer went to sleep [17:21:00] Bernard: Diameter bake-offs, did anyone test internationalized NAIs? [17:21:04] Hannes: no. [17:21:21] What makes Diameter/RADIUS different is dynamic discovery with DNS, and also have to do matching [17:21:27] Bernard: right, needs to be in certs. [17:21:43] Hannes: interop test didn't specify that [17:22:32] Alan: these are the issues that overlap radext, emu, dime. Even going back to routing, discussion seems to indicate Realm portion is an opaque token, so long as the home network can hand token to everyone that needs it, they can do binary comparisons and everything works. [17:23:07] Elena leaves the room: Replaced by new connection [17:23:07] Elena joins the room [17:23:41] Normalization requirements are not complete - need to provide both a realm name and a DNS name. [17:23:59] Hannes: issue requires further investigation. [17:24:08] Alan: most people seem to be interoperable, [17:24:21] Hannes: everyone uses ASCII, no one uses dynamic peer discovery. [17:24:37] Bernard: search for work ASCII, see if you require it. ASCII is a bad word. [17:25:14] Hannes: probably need to reach out to folks with experties [17:25:19] Alan: idna folks. [17:26:03] e-mail folks are defining everything interpreted by home domain. A lot of the username issues go away. As long as no one else is allowed to interpret it. [17:26:40] DanR: ignoring is not a good option. OTOH, problem may have a lot of things in common with other things such as dnsops, etc. Maybe try to get together at one of the next IETF meetings. [17:27:51] mccap leaves the room [17:27:58] Dave Nelson leaves the room [17:28:03] jounikor@gmail.com leaves the room [17:28:13] histerrier leaves the room [17:28:19] alandekok leaves the room [17:28:30] Elena leaves the room: Replaced by new connection [17:28:31] Elena joins the room [17:34:46] avri leaves the room [17:48:59] Elena leaves the room [17:51:54] vifajardo1 leaves the room [18:04:45] alandekok joins the room [18:09:04] alandekok leaves the room [18:09:07] David Frascone leaves the room [18:31:21] HannesTschofenig leaves the room