IETF 71 DIME Meeting Minutes Status Update - Agenda 3588bis * Issues about extensibility - M-bit (SHOULD NOT/SHOULD does not make sense) when should it be set - Combination of features requires different App-Id hard to maintain (tree problem). * Discussions about tree problem Glen Zorn : Is this really needed Jari : Add x and y, x=>App1 y=>App2 x+y=>App3 y+x=>App4 (Mobility and QoS for example, when you merge new AppId) Glen : Maybe not necessary, AppID space is large, won't be exhausted, question of protocol complexity, is it really worth? Applications are atomic Jari : Could be O.K., but if people want to extend themselves, it needs to be brought to IETF Glen : Anyhow need new AppId in this case Jari : Could bring interoperarbility issues Glen : But that is the point of different AppIds and guidelines doc should provide info about when AppId necessary Jari : Maybe artificially forcing new AVPS with M-bit but may not be necessary all the time Glen : Need to define exactly the meaning of mandatory AVP. Newly mandatory things really need to have AppId Hannes : Mandatory as M-bit or in ABNF? Glen : Just define exactly Dan : Ask about command code allocation, whether first-come-first-serve or expert review. - Versioning of using AppId - not much support, new AppId necessary anyhow Consensus seems to be to keep things as it is - No consensus on command code allocation. Some folks in favor of FIFO * Optional non-M-bit AVPs - End-to-end capabilities, 3GPP has some ideas about end-to-end negotiation. Generic solution, should work through proxies as well - Discusstion Jari : hop-by-hop capability negotitation should do it if proxies advertise AppId but will it be really deployed in practice? Glen : Why shouldn't it work?If it doesn't just send the message to the next-hop, it will reject. Considering the existing routing logic, is end-to-end really necessary? Glen : Ends can change, things happen, two ends are not the same server not avialable after failure, how do you find out? ahmed muhanna : If new AppId advertised, does it mean that old one is supported? Hannes : Depends on application, no Diameter support for this, every Application is independent from Diameter perspective Ahmed : Node B supports new, then does it need advertise both old and new? Hannes : From Diameter perspective they are different ones Ahmed : Why should it have advertise both? Isn't is inconvenient? Hannes : There is no realtionship between these two applications Ahmed : Could be considered as complexity Dave : But new mandatory functionality Ahmed : But from coding perspective will seem a new application, complex Victor : If you run both, you need to advertise both Jari : What problems we may have about end-to-end capability issues regarding proxies. 0xFFFFFF advertisment from intermediary would have issues, what if v1, v2, v3 of the same app have issues. What do you do about crossing domains? Glen : Maybe real problem Hannes : We think more about optional extensions, shouldn't confuse the two Avi : What if application type changes, to prepaid for example - Concerns about IANA rules for AppId, current process handles allocation of appIds but maybe should change - When to set the M-bit: Depends on how apps define to use it. M-bit is set per application, not per AVP - Correlation between M-bit and ABNF; for fixed and {}, it needs to have M-bit set - Remove SHOULD/SHOULD NOT from M-bit table; MAY have some use for necessary to implement but optional to process - Relax intermediatiey rule about M-bit, MAY perform validation of M-bit - When ABNF changes for the command code significantly ==> new command Hannes : Changing the rules about request from other SDOs for new command codes, what should we do? Dan : Currently not big problem, concern about scalability of current solution, requires IETF draft by other SDO to be approved as informational RFC, may be an issue. Maybe a team performs sanity checks/review, then IESG can process it. Don't want to overload the WG Tina : TISPAN has a document pending the discussion for M-bit. when will M-bit be settled? Hannes : Depends on the feedback from the group. Feedback welcome. Need feedback for all documents, otherwise no progress Hannes : About command code allocation, appId space split in two, for vendor specific command code is expert review necessary? Some people even don't want that Dan : We need to avoid Diameter to turn into a universal protocol Hannes : There is expert review for command code but not for AppId, strange Avi : 3GPP asked for command codes without telling anything about the purpose, concerns about this practice Hannes : Seems like 3GPP hijacked these command codes and misused them Avi : Would it be just to ask IETF n command codes? Is this all? It is important for SDOs to create SDOP specific command codes Dan : For outsiders it isn't always easy to write IETF draft, expert review mitigates this.A middle ground, still will allow to express opinion about whether Diameter is suitablke for a specific purpose Hannes : What would expert review do? We shouldn't judge about contents about other applications. Maybe just to check against design guidelines. If we require draft for new command codes, people may misuse existing ones to bypass this, making things even worse - Command cOde IETF concsensus, not really practical, other SDOs won't come for comamnd code expert review Hannes : What about Application expert review? Do we have the manpower? Probably not Dan : Objection. - Design guidelines should provide enough information. That is the purpose of design guidelines doc, here is how to do it. We can;t really police other applications Glen : I kind of agree. Certain SDOs do really bad things with IETF protocols. We ignore them, they will ignore us. But it isn't also good for other people do this because it looks us look bad. Design guidelines could be a good idea, to blame them in case they screw up. Hannes : Vendor specific AppId, requires just informing IANA Hannes : Two issues : requesting new AppId, command code is different. That is the reason why Dan puts the expert review case by case. Jari : I don't hink it is IETFs role to be fool-expert for applications, we are experts on what is existing (if they invent something existing), doing something breaking base protocol mechanism, that could be the role of IETF Hannes : Maybe we should have expert review only from extensibility perspective, not for foo Jari : There are things, we can review, but we are not foo experts here Hannes : What is the process then? Jari : No answer Dan : From process perspective it is defined what is expert review Jari : That is generic RFC, we need to define the specifics Dan : Yes, need to decide Hannes : Shall we ask the group whether expert review for new vendor specific AppId? Shoudl we put this to bis? not content, just compatibility with diameter extensibility guidelines Ahmad : Could be good to maintain knowledge about all applications, at least high level understanding - Seems more people think no expert review for vendor specific appIds (9 people) Mark : Rules for expert review should be very clear and straightforward Avi : SDO spec cycle 6/12 months ; IETF cycles much longer Glen : Don't think expert review is very useful for those cases. Other problems : Who constitutes an expert on a given object? Sometimes people make a point without reading Ahmad : Glen's point seem to be different. SDOs are not immune to making mistakes Dong : Precise guideline is useful Hannes : Seems in the room people prefer not to have, let's get more feedback from mailing list Avi : For AppIds there are already rules, command codes are the issues Hannes : From routing func. encapsulation perspective, AppId is more important Avi : Not necessarily. Status quo is busted; Command codes hard to get so other SDOs break existing ones. For people outside of IETF, mandating new command code could provide some protection Dan : There should be a more balanced solution, including guidelines about what constitutes expert reviewers Hannes : Would be good to keep command code and AppId allocation similar. Will take the issue to the list Glen : A few other things: Existing rules cover actually external SDOs well. These things are not coming from IETF. Suggests an information RFC to be published just to make sure that people are aware what other SDOs are doing with IETF problems. Hannes : Recommendation to other SDOs to publish as informational RFC (not mandating) Diameter MIPv6 * Version 06-07 - clarified replay protection - CoA handling - Guidance - Auth/Authz handling - AVP corrections - ABNF corrections * Supported MN auth & authz - HA-AAA auth/authz (IKEv2 or BU))))))))))))))))))))))) is used - MIP6-Feature-Vector * Capabilities on this spec - RO_SUPPORTED - route optimization per subscription - USER_TRAFFIC_ENCRYPTION - (dis)allow MN-HA user traffic * Open issues - Clarify the authorization text - Define new application for 4285 - ID is now WGLC * Comments Glen : Can't really do end-to-end negotiation securely ? We don't have end-to-end security Hannes : Philosophical issue Glen : We have not needed end-to-end security because diameter is hop-by-hop Hannes : Reality is that we don't have end-to-end security even on other Glen : Not the same thing since we are trying to protect messages Hannes : We can write that in the security considerations Glen : Whether end-to-end security is possible with diameter is another issue. Point being made is that end-to-end security would be needed Frank : You want 4385 to support this document. This is an informational document. Jouni : Already discussed previously. Hannes : You need to indicate a down ref during last call Gerardo: Fine with keeping one draft for 4285 and IKEv2. Still the protocol approach is different for both. Would need separate application id. Ahmed : Same as Gerardo. Need to have separate application id. Jouni : Up to the group. Avi : Need to understand more of this scenario. Jouni : Same application but different command codes. Ahmed : Bother by clear cut technical issues needing voting. It's clear that applications are different. Why take a vote on this. Gerardo: I agree. Avi : I need to understand something. Do I need to implement all commands within an application. Ahmed : Of course. It breaks the model of capability exchange. Alper : Two separate app ids. and two separate documents. Gerardo: We can keep it in a single documents but we need two separate app ids. Hannes : Who believes we need different app ids for the apps ? Qos Attributes and Qos parameters * Status - Changes from 04-05 (attributes) - Cannot reveal the original intent of the AVP, so we decided to remove it - Changes from 02-03 (parameters) - AVP encoding does not follow diameter encoding. authors considering standard diameter encoding. - Classifiers: currently using text based filter rules. Request to use new classifier work. Hannes : Feedback on the issue of classifier. Need opinions. Mark : Overiview - Text rules are have condition and action. Combining them is not the best atomic component for reuse. Best is packet classifier. Hannes : If we make the change to diameter based classifier. is it ok for the group ? Jouni : How will it affect the sched of this document Hannes : Changing of encoding will not take too long. Folding in the text is also easy since it exist. Proposal is by next week. We need some review. Avi : Constantly asked to review the same document. Hannes : Document changes constantly Frank : Is there some deployment scenarios from this document. Hannes : Maybe a philosophical discussion Frank : From techinical perspective, this is different architecture that is different from operatros architecture. Makes the problem complicated. Hannes : Tough subject that goes beyond technical issues. More business decision than technical. Diameter Qos applications * Status - 05 version. some progress ince last meeting - Accounting de-coupled from Qos authz - clarification on the push and pull section - Next steps: reviewers then last call Hannes : Glen, you think this is ready for last call Glen : I'd like to make once last look through it. Have not read through it. Maybe a week. Hannes : Tina. What about you Tina : Yes go through the last call. Extensions for MoS discovery * MIHSHOP support for 802.21 protocol for IP level support. * Reqiures MOS support (Mobility service) - defineds AVP extensions - similar to integrated scenario - reuse existing application * Next steps - exmpale section - WG item ? Frank : You refer diameter to which network ? This a NAS. In 802.21 there is an IS where is it Jouni : There is the Mosv and Mosh in the home network. Hannes : Bunch of document available for group to look at. still need to finish current doc. Difficult to turn down request from other SDOs. Trade off needed. Send a couple of mails on the list; i.e. who need to author/edit docs then who reviews. Ask if people plan to use this operationally. Take this into consideration. Had presentations on other docs in prev meeting. Finish things first before other docs. Mark : extensibility is included in current charter ? Hannes : yes. Glen : Seems reasonable but may not be accurate. Not the same folks doing all the document. Hannes : We would be some time management. Dan : First of, needs editors. Second, need to have commited group of reviewers. Getting more documents on the plate will not help since reviewers are lacking. Serialize some of the work to help accelarte existing items. Avi : There are reasons for dime to go on. SDOs are looking for place where other SOD can get somethings done. Hannes : Still lacking reviewers. Avi : change the rules. can't come back to dime unless you have reiviews. force authors to chase after reviewers. Glen : If extensibility document don't reduce our workload then don't do that. Hannes : My expectation is it will.