DIME session meeting minutes Session 2010-11-11 1520-1720: Jade 1 ==================================== Chairs: Jouni Korhonen, Lionel Morand Note takers: Sebastien Decugis, Win Wu (thanks!) Note well Agenda Glen: 15 minutes for individual drafts is not enough Lionel: We'll see. Many completed WGLC Violetta : IKEv2 PSK: 1 review during the WGLC, then additional ones were received. 3 docs waiting for proto write-up several in IESG queue 3588bis: returned to WGLC because of IPR Mark : Can you explain what was said "last time" on the IPR? Lionel: I heard in RADSEC on the same IPR. The IPR is here, please comment as needed. Glen Zorn: Other comment: some complaints from IANA about IANA assignement section (refer 3588 or 3588bis?) MIBs: Glen: this seems not a priority for Cisco. Dan's comments addressed when understood, forwarded to co-authors otherwise. Dan: There was a kind of ultimatum on this, the answer was yes we must do it at the time. Keeping the item on the charter without progress does not help -- nor harm... Glen: somebody else can help on this document. Dan: ready to clarify my comments Glen: OK, let's do that! Dan: OK let's do that through Skype someday after we are back. Milestones cleaned after IETF78. Charter is full for the moment. Diameter ERP progress: Sebastien: Status Report Lionel: how to resolve peer handover issue Sebastien: Post to HOkey mailing list call for comments and feedback\ Glen: NAS can cache authoz atrribute somewhere how to do that exactly Glen: It is not necessary to wait for hokey architecture. DIME can give guideline on progressing this work and move this work foward. Not necessary to lock one draft to another. Sebatien: Clarification:Peer handover does not rely on Hokey architecture Glen: fixed in Diameter server rather than EAP server. Whether ER server collacted with Diameter Sever does not matter. Maybe do memoring sharing, this is implementation issue rather than Diamerer Server problem. Extended NAPTR: Mark: Introduction S-NAPTR registry requires an RFC of any category. Dan: The specfication must be an RFC from any category. But all RFC are not specifications. The shortest path involves. Specification can belong to another SDO, not RFC. Mark: it is written explicitely that an RFC is required. Tom: we got the same problem in AVT and could fix the issue very easily to relax the requirement. Lionel: the relax would concern only Diameter-related things or all NAPTR registrations? Mark: the problem is: Diameter appl Glen: idea: update S-NAPTR saying "for Diameter, you need only a specification (any SDO)" with our RFC and see who complains. Lionel: agreed Tom: has anyone talked with relevant chairs? Lionel: not yet, maybe jouni (Note: Jouni will initiate discussion with relevant DNS folks). Dan: technically possible (in principle) but a little unusual to do this. Probably better to do it in consensus with authors. What's next? Lionel: only stopper is IANA policy. We can agree on a final version and check any feedback. IKEv2 PSK (Violeta): Violeta:Status update 1st issue (use AUTHORIZE_ONLY) Lionel: OK with resolution, provided there is a WG consensus. Glen: The DIAMETER_INVALID_AVP_VALUE might be wrong, it would actually be a protocol error Glen: the point is, it is a permanent error, it should not tell to retry with different value Violeta: The error code seems valid. I don't see what is the problem. Lionel: Bring the issue on the mailing-list. 2nd issue (offline -- Keying-Material is mandatory inside Key AVP): Sebastien: seems straightforward to send SPI as separate AVP if there is no corrolated information sent. Glen: seems reasonable to use the Key-SPI outside Key AVP Glen: So we can request a key with Diameter ? Hum... NAT control: Frank: address several issue during WGLC Jouni: comment on tickets: only reporter can close it. What is the next step? Another LC? Jouni: Try to find someone from NAT community (e.g. PCP) to have a look at this. I'll take care of it. You can consider it is in the queue after this. Priority AVPs: Ken: reference 3gpp techs in introduction. Lionel: seems the right way to do it. Local Key Transfer: Glen: status update. waiting for proto write-up Lionel: I do protocol writeup PMIPv6 support for Local Routing: waiting for netext issues 1. Any comment? Marco: issue is actually on the server. It cannot differenciate the messages. Qin: will add some text to clarify. Wait for netext? Marco: should not wait for them. it is general enough. Regarding reviews, we should ask people from mobility RFC4005bis: nothing new. Lionel: what is expected next? Glen: waiting for people to complain about it (get any feedback). Sebastien: we are talking about removing translation? it was actually mentioned on the list. Lionel: the goal is to remove translation from this draft. It can be re-done somewhere else, should it be useful. Dan: the explicit charter/scope of the revision was to take out the translation mechanism. This milestone was reached. The comment is not fair for the draft. If the agreement has changed about it, let's reopen the charter discussion. General purpose session: (individual draft) Marco: second version draft updated Frank: There are other applications that solve the same problem by not using Session-Id but a different identifier. Marco: We are doing this work for the applications that do use the Session Id. Mark: I like the concept & use case, but I don't like overloading the existing commands for this. Jonson: overload command.. Lionel: maybe need some clarifications (separate doc, or at least on ml) about relationships between application, session, and user. Glen: DiME is not good place to talk about this kind of things. The proposal is not related to AAA as I understand it. In addition, you cannot change existing applications that use Session-Id as first AVP in any case. The change in semantics is illegal. Today there is a bar bof about Operational Uses of Diameter. This would be in the scope there. Lionel: Put to mailing list for discussion SCTP (& DTLS) clarifications for Diameter. (Victor) Victor Pascual gives a problem statement regarding TLS over SCTP and proposes a solution using DTLS over SCTP. Glen Zorn: What in SCTP with only 1 stream is better than TCP? Victor: because we have undordered delivery. it prevents head-of-the-line blocking. Sebastien: support the proposal. Jouni: next step, integrate to 3588bis, or additional doc? Mark: what is the proposal? remove TLS / SCTP, or ? sebastien: no real difference between integrating in rfc3588bis or having a separate doc, cause rfc3588bis does not talk about this. Victor: True for TLS/SCTP, not true for streams usage guideline. Lionel: better to include in 3588bis, but the other way would be fine too. Mark: also don't want to delay. remove what would conflict from rfc3588bis, and work in a separate document Frank: propose some text and let's discuss before end of LC next week. Dan: Because of particular history, we will need a 3rd WGLC & LC. It won't be in next week IESG meeting anyway. - Timeout - Lionel: Remaining stuff will be on mailing-list. ====================================