DIME WG IETF 90 TUESDAY, July 22, 2014 0900-1130 Morning Session I (150 mins), Salon A 09:00 - 09:10, Preliminaries (10 minutes) ------------------------------------------ Presenters: Jouni Korhonen, Lionel Morand Note well and agenda presented Note Takers - Jean Mahoney Jabber scribe - Tom Taylor Jabber log: http://www.ietf.org/jabber/logs/dime/2014-07-22.html 09:10 - 09:30 Document Status (20 minutes) ------------------------------------------- draft-ietf-dime-app-design-guide-21 -> In IESG for pub. draft-ietf-dime-e2e-sec-req-01 -> Expired Jouni will try to update draft-ietf-dime-group-signaling-03 -> in WG draft-ietf-dime-ovli-04 -> in WG draft-ietf-dime-congestion-flow-attributes -> in WG draft-ietf-dime-pmip6-lr-18 -> RFC 7156 draft-ietf-dime-rfc4005bis-14 -> RFC 7155 Working Group I-Ds (10 minutes) ------------------------------- 09:30 - 09:40 Diameter Congestion And Filter Attributes Draft: draft-ietf-dime-congestion-flow-attributes Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-0.pptx Presenter: Brent Hirschman Brent presented slides. Marco had questions about reporting on flows and packets. Both can be handled. Lionel as an individual requested that the document cover how the AVPs are produced, used and consumed. As a chair, Lionel thought that from a technical point of view, the document is ready. After information on how to use the AVPs, the document can go to WGLC. ACTION: Authors to add information on when to produce and use AVPs. 09:35 - 09:40 Diameter Group Signaling Draft: draft-ietf-dime-group-signaling Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-5.ppt Presenter: Marco Liebsch Marco presented. Benoit Claise had questions about the permanence of groups. Mid-session assignment is an exception and group lifetimes span multiple commands. Jouni asked if group signaling would work for applications that don't maintain state. Ben volunteered to look at the draft to see if it could be used with DOIC. Matt Holdridge raised concerns about the empty Security Considerations section. Lionel said that applications using group signaling would provide more details for security considerations. ACTION: Authors to update draft with guidelines on handling session-based and stateless applications. ACTION: Ben and Steve to review draft from the perspective of using it with overload control. Diameter Overload discussion (80 minutes) ----------------------------------------- 09:40 - 11:00 Diameter Overload Indication Conveyance Draft: draft-ietf-dime-ovli restructuring Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-4.pptx Presenter: Steve Donovan Steve presented. Jouni encouraged the group to read the whole document from scratch, not just pick at sections. draft-ietf-dime-ovli open issues Draft: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-2.pptx Presenter: Steve Steve presented slides. Slides that covered agent issues were skipped to make time for the agent discussion later. Issue #23 DOIC behavior for realm overload Ben, Lionel, Steve discussed the terms realm report and realm-routed-request. Ben expressed a preference for the shorter term. Lionel and Ben pointed out that all requests start out realm routed until it reaches the node that selects the host. Issue #26 Overload Control Endpoints under specified Steve, Ben, Lionel, and Jouni agreed that the concept of association does not help DOIC and should be removed. Ben said to be cautious with the removal so that useful text is not also removed. Issue #35 additional report types are proposed Although there was agreement at the London meeting to not include single-client targets, JJ (not attending) has expressed the opinion that it needs to be in the base draft. Jouni said that we are not looking for 100% agreement. Dave asked how much knowledge an agent needed. An agent doesn't need application knowledge to handle OLRs, which was one of the requirements. There was also a discussion about whether DOIC updated 6733. Lionel said that the draft needed to be clear that it was defining new AVPs that can be implemented by existing or new applications, but DOIC was not extending the Diameter base protocol. Ben suggested that DOIC updates 6733. Issue #48 Setting M-bit gives wrong semantics Jouni said that new applications can set the M-bit. ACTION: Steve to make sure the wording is correct. Issue #55 Lack of overload control for realm overload condition Steve to close by addressing it in a future extension. Issue #57 Handling of "Realm-Routed" Overload report type Ben pointed out that related issues should be collapsed into one issue. Steve will change text to align with the other definition. Issue #58 multiple reporting nodes for realm-routed-request type reports Ben concurred with the proposal and said that the agent overload draft needs generic handling of this issue. ACTION: Steve to write a proposal to handle overload of a realm. Issue #66 non-supporting agent changing Origin-Host Steve said that we need to think through the impacts when an agent does topo-hiding. draft-donovan-doic-agent-cases Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-3.pdf Presenter: Ben Campbell Ben presented. The new terms of TC and TS in the presenation may or may not be introduced into DOIC. Figures in the presentation use older labels (server rather than TS). The term Diversion is also a new term, it had been called re-routing. There was an omission on the last bullet of slide 5 - it should apply only for realm-routed. N/A for destination host. Agents can determine realm overload out-of-band. The scenario in which the client does not understand overload requires the agent to send an error to the client. That error code is still an open issue. Lionel brought up the concern about how end-to-end security may impact the agent modifying OLRs. E2E security has broader impacts than just DOIC since proxies need to be able to modify messages. Ben pointed out the issue of a non-compliant agent pasing along unknown AVPs and that a upstream agent would not know that the first agent didn't support DOIC. This also violates trust if the messages travel through multiple domains. We may need an attribution mechanism. ACTION: Discuss error code selection on the list. ACTION: Chairs to propose regular conference calls and an interim meeting, best before the CT4 3GPP meeting in order to make the draft deadline. Individual & new work --------------------- 11:00 - 11:10 New derived Diameter datatypes (10 minutes) Draft: currently draft-zhou-dime-4over6-provisioning-03 Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-1.pdf Presenter: Tom Taylor Tom presented. Lionel suggested that to update 6733 a draft describing the new data type should be created. ACTION: Discuss new draft that updates RFC6733 to describe new data type. Wrap-up (10 minutes) -------------------- 11:10 - 11:20 Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps Steve asked about updating milestones with agent overload and rate specification. Jouni said that they could be added. Keith emphasized that he wanted the base DOIC through WGLC before focusing on agent overload. ************************************************************** More detailed minutes ************************************************************** DIME WG IETF 90 TUESDAY, July 22, 2014 0900-1130 Morning Session I (150 mins), Salon A 09:00 - 09:10, Preliminaries (10 minutes) ------------------------------------------ Presenters: Jouni Korhonen, Lionel Morand Note well and agenda presented Note Takers - Jean Mahoney Jabber scribe - Tom Taylor 09:10 - 09:30 Document Status (20 minutes) ------------------------------------------- draft-ietf-dime-app-design-guide-21 -> In IESG for pub. draft-ietf-dime-e2e-sec-req-01 -> Expired Jouni will try to update draft-ietf-dime-group-signaling-03 -> in WG draft-ietf-dime-ovli-04 -> in WG draft-ietf-dime-congestion-flow-attributes -> in WG draft-ietf-dime-pmip6-lr-18 -> RFC 7156 draft-ietf-dime-rfc4005bis-14 -> RFC 7155 Working Group I-Ds (10 minutes) ------------------------------- 09:30 - 09:40 Diameter Congestion And Filter Attributes Draft: draft-ietf-dime-congestion-flow-attributes Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-0.pptx Presenter: Brent Hirschman Brent presented slides. Slide 4: Progress since IETF89 Brent - ECE and CWR don't need support since it's covered elsewhere. Examples are in 5777. Received one response in agreement. Received a recent response that was editorial in nature. Feel that we've given the group lots of opportunity to respond. We assume that everyone is happy. Slide 5: Author's proposals Brent - Propose to progress to WGLC after this. Marco Liebsch - I've read it. It's short and clear, but I'm not clear on extensibility and procedure. I'll sent to list. It would be good to have some use cases. Are the filter rules enforced on per-session level? ECN marking is arbitrary, and not flow based. How to interpret when client reports ECN marks to a server? The routers set the flags on packets, not flows. Brent - With the AVPs, we can account and report separately. You can manage on packet basis. You may have a lot of flows through the router. Flows or packets may be congested. With flows, you can see if flows or sub-flows are congested. Trying to capture if it's a problem for one or all users. You treat a flow differently based on number of packets in a flow. If a video flow, which has lots of packets, is congested, it has a different congestion treatment than a browsing flow. Marco - Routers mark on a per-flow basis? Brent - They can. It's how you report it back. You have a congested packet, was it part of a flow - keep a congestion count on that flow. You can report on that. Jouni (as individual) - the filter rule can measure for IP traffic and ECN bits. Depends on how you define the rule. Brent - the filter rules are already in RFC5777. We're just adding ECN notification. Marco - We can work offline on details. Lionel (as individual) - we're just defining the AVPs, but we need to explain how to produce, use, consume them. What entities use the AVP? Need to know when the exchange is required and who would use the info. How to use the AVPs needs to be added to the draft. Lionel - from a technical point of view, the document is ready. From a document view, we should add examples on how to use AVPs. Then put the document in WGLC. ACTION: Authors to add information on when to produce and use AVPs. 09:35 - 09:40 Diameter Group Signaling Draft: draft-ietf-dime-group-signaling Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-5.ppt Presenter: Marco Liebsch Slide 2: Summary of 4th revision WG need to review the draft's direction. We solicit your review. We hope that it's still alive. Slide 3: Default permissions as per this spec. Benoit Claise - I need to talk to the chairs, whenever you mention mid-session group assignment - is the group temporary or is it more static? Lionel - Mid-session group assignment is the modification of the group. Benoit - Are the groups supposed to be permanent and the mid-session assignment is the exception? Lionel - If you want to move one session between groups, the mid-session assignment lets you modify rather than close the session. Benoit - so it's static, and the mid session is exceptional. Marco - the lifetime of a group is over multiple commands, but you can change groups. The draft if flexible. Jouni (as individual) - Will it work for cases where session state is not maintained? Can you use it for applications that don't maintain state? Marco - I think it's for stateful applications. Jouni - certain interfaces don't maintain session state, but would benefit from this. Lionel - you can use one ID to group a session. Concept of grouping could be used with 3GPP for some sessions. To send one command to impact multiple users. If you are dealing with stateful session management - need to modify the state machine. Using one group ID to impact multiple users, not necessarily sessions. Marco - it follows session ID. Any other user ID, you can use and group. If it's not per session, you can do that. Do we need to add another ID to this draft? Lionel - 2 aspects to draft - group id, how to create a group. How to handle the group ID. I think a stateless app could use it. In the draft, say how to manage the group, session-based and stateless. Marco - the protocol is clear on session grouping. Can add a use case and other kind of grouping guideline, not specification. ACTION: Authors to update draft with guidelines on handling session-based and stateless applications. Ben - the overload work had a concept reporting overload on a session group. It was removed because this work was ongoing. Steve and I will look at the draft to determine if we can we use it in the DOIC work? Not specify how to use it, just do a thought experiment - can the drafts work together as specified. ACTION: Ben and Steve to review draft from the perspective of using it with overload control. Lionel - Overload is a typical use case for this. We need your review and reviews from other people. Matt Holdridge - The Security Considerations section is a TODO. The overload scenario - I can imagine a big security review. and Stateless - that's another review. Lionel - The assumption is that if you are working with groups in your application, you need to determine the security considerations. Matt - Shouldn't security considerations be fundamental to how to work with groups? Lionel - No, overload is not related to session, it's related to server or client. User related management and session related management. See if it can be reused for a non-session application. Matt - From my outside perspective, defining what a group is and how to manage a group, security should be fundamental. Lionel - We should not define group security here. For the management, you would have to say have to a session, but it will be per application. Need to have reviews. Diameter Overload discussion (80 minutes) ----------------------------------------- 09:40 - 11:00 Diameter Overload Indication Conveyance Draft: draft-ietf-dime-ovli restructuring Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-4.pptx Presenter: Steve Donovan Steve presented. Jouni - I encourage people to read the whole document from scratch, not just pick at sections. draft-ietf-dime-ovli open issues Draft: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-2.pptx Presenter: Steve Steve presented slides. Slides that covered agent issues were skipped to make time for the agent discussion later. Slide 4: #23 DOIC behavior for realm overload Steve - I propose that realm report applies to realm-routed requests. In the future there will be a report that controls all traffic to realm, independent of the request type. I'm Ok calling it either realm report or realm-routed request Ben - I think realm report is easier to say and we seem to use that in emails. Lionel - Even if the host is specified, it's always realm routed. Steve - There are 2 types of requests - host routed, and requests that don't have destination-host specified. Then we have 2 report types. Ben - we're getting wrapped around what routing means. All requests are realm routed except for whatever node selects the host. I think we're talking about server-binding. I'm not saying that we should use that term. Steve - We just need to work on naming. Dave Dolson - I agree with your distinction. It comes down to what the application uses. For a session-based charging application, the client's reduction will impact new sessions. If the session exists, I want to look at the host. I like the distinction, but I wonder if it's application specific. Steve - An application can define how to use it. But the general behavior of reducing traffic is the same. Keith Drage - just pick a term and define it. Slide 6: #26 Overload Control Endpoints under specified Steve - I think the definition of association is still confusing. I think the concept of the association should be removed. Ben - I'm mixed on that. We're getting wrapped around where the associations live. We argue whether we have 1 or 2 associations, but no one is arguing about the behavior. I don't know if association is a useful concept to explain stuff. Steve - I think we should delay discussion until we get to the first use case in agent draft. Lionel - the notion of association doesn't bring anything into the solution space. It was in the beginning, but not now. Focus on what we have now, which is state and the information that you need to manage. Jouni - removing association text will cut some pages from the draft, too. Ben - I'm leaning towards agreeing, but I don't want to throw away baby with the bathwater. Steve - Slide 8: #35 additional report types are proposed Steve - JJ wants this in the base draft, but we don't have text yet. We should do same thing with agent overload. We want to get this draft done for release 12. Jouni - we had the agreement not to put it in this document. Steve - Had that agreement in the room, but not in the list. Jouni - I'm not looking for 100% agreement. Lionel - We need to reenforce for this draft that just one person disagreeing on principle shouldn't blow the work. Ben - I wish those who wanted this in the base were in the room - I'd say to them to send a draft. Steve - send text. Dave Dawson - If the diameter base is a different layer than the application, which layer is this feature? The AVPs? Would that impact the stack or the application layer? Steve - The stack - the semantics span the layers. Some of the work in 3gpp - how to make throttling decisions - that's application level. We haven't talked about it, but it's a base diameter capability. Dave - an agent that doesn't know applications should know this? Steve - yes, an agent should be able to implement without application knowledge. Dave - How an application backs off is application-specific. Steve - Without application knowledge, you would treat all messages equally. Dave - Each application may need to define the abatement algorithm. For Gy, if the realm is overloaded, don't create new sessions. An intermediary may not understand. Steve - that's the prioritization I'm talking about. Dave - but if it's application-specific, how does the intermediary know? Steve - it would have to have application knowledge in that case. Ben - The requirements document has the requirement to be able to act without application knowledge. You can deploy overload without everything needing to know the application. We tried hard to have demarcation on what needs application info and what does not. Our goal was not to cause the respecification of every application that would to use overload. I can make applications better if I do specify how to use overload. We can provide generic guidance about kinds of applications. Lionel (as individual) - Nothing in this draft is base. We're defining new AVPs that can be implemented in existing or new applications. Need to make that clear in the draft. Steve - We won't revise the base spec. I agree. But the behaviors we define are the same across applications. Lionel - Generic is good. We are not extending the base protocol. This draft should not cover everything. There would be too many details. Steve - hopefully all an application has to do is reference this doc and add wording on prioritization. Lionel - any implementation details here should be reusable, but it shouldn't block the draft. Just say that it's application-dependent. Dave - You will get the doc through quicker if you don't explain the approaches when you get the AVP. 4006 type applications - session-based applications. Here's one for stateless. Steve - we've defined a generic one. Ben - The term algorithm in the draft is more narrow - this number is a % and it's stateless. An application will do implement it according to priorities - can specify it. To Lionel's comment - I don't agree that this is not base. I would suggest this updates 6733. Other than some of the earliest applications, almost all applications have extensibility. Can pull these in. In the requirements doc, the implementer can implement without a new specification for the application. I could deploy on an agent today before the applications specify anything. Lionel - it's not about semantics. This is not base. There are some nodes that will never understand this. They are defined as part of a application. Need to be clear on that. Ben - then the doc needs an updates 6733. Lionel - need to ensure that it's clear for everyone. Ben - when we get to mixed AVPs where agents can change AVPs, how the AVPs are interpreted - may have impact here. Lionel - In the base protocol,there's is no guidance on agents. Only relays. Everything else is proxy and it's up to the application. Raise the discussion on the list. Relay doesn't modify. We shouldn't have different assumptions about what's in base. Ben - If an agent advertises relay only, can it implement DOIC? Lionel - Relays cannot do anything else. Relays do not support specific AVPs. My node could do MAP, and advertise relay. Slide 10: #48 Setting M-bit gives wrong semantics Jouni - if it's a new application, they can set the M bit. If it's an existing application, it's like hitting head on wall. ACTION: Steve to make sure the wording is correct. Slide 11: #55 Lack of overload control for realm overload condition Steve - closed by addressing it in a future extension. Slide 12: #57 Handling of "Realm-Routed" Overload report type Ben - we can collapse into single issues. Steve - need to change text with the other definition. Slide 13: #58 multiple reporting nodes for realm-routed-request type reports Ben - I concur on the proposal. If I have 2 different agents, and the reports disagree, I don't think the client can know that a second report came from the same. I don't think sequence numbers help. Steve - could change the sequence numbers to capture host info. Ben - a relay forwarding a OLR may need to reattribute it. Dave - What if there's more than one hop to deliver? If the next hop itself is overloaded? Steve - that's the agent overload case. This case is that the realm is overloaded independent of the number of hops. I'll write up a proposal for the list. ACTION: Steve to write a proposal to handle overload of a realm. Ben - there's a agent overload draft out there. Needs a generic handling. Slide 16: #66 non-supporting agent changing Origin-Host Steve - need to think through the impacts when an agent does topo-hiding. draft-donovan-doic-agent-cases Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-3.pdf Presenter: Ben Campbell Ben presented. Slide 3: New Terms Ben - New terms of TC and TS may or may not be introduced into DOIC. Figures in the presentation use older labels (server rather than TS). Slide 4: Abatement Techniques Ben - Diversion is a new term, had been calling it re-routing. Slide 5: Architectural Principles Ben - Last bullet should apply only for realm-routed. N/A for destination host. Slide 6: Simple Agent: Capabilities Announcement Lionel - OC-S-F? Ben - OC-Supported-Features AVP. Slide 7: Simple Agent: Report Handling Ben - there is some weird here - in this scenario, the agent determines realm overload out-of-band, maybe via local policy. If the agent throttles, it needs to send a new or clarified error code. No error code in RFC6733 really covers it. Slide 8: Simple Agent: Realm report Ben - This is different from previous - the agent doesn't throttle locally, but creates a realm report and sends it to the client. There are now 2 OLRs. Slide 9: Multiple Servers: Diversion Steve - question for the room - Do people understand why the client can't throttle realm-routed requests? It doesn't know about the servers. Slide 10: Multiple Servers: Realm reports Ben - If Agent has no knowledge of the realm, then it shouldn't send a realm report. Dave - What's the value to put in the realm report? Ben - We can give examples. We're assuming the agent has knowledge of the servers and their capacities. We need to look at it and provide guidance. Dave - is there an assumption that the agent comes from the same vendor as the server? Ben - We did not require that the agent and servers be from the same vendor Dave - This will be fun when they are elastic, virtual machines. Steve - Servers could also generate realm reports if they had full knowledge of the realm. Ben - There may be active/standby cases. Single vendor - the servers could have a bus to communicate load, and they could send reports. Slide 11: Simple Agents: DOIC impacts Steve - I want to emphasize the first bullet. This is where the association concept gets blurry. 1 reporting node/2 reacting nodes. Don't know how it maps to associations. If we remove the association concept, we're ok. Ben - Steve and I disagree on the number of associations here, but we agree on the behavior. Ben - the constraint given on the slide is already in the draft. Steve - on the error code, there are other cases where agents that throttle for non-supporting clients and the - Ben - I cover that later. Lionel - on last two points - With e2e security, how to introduce? This is not just related to overload. A proxy should be able to modify traffic and AVPs. Ben - The Diameter mechanism supports this. Slide 12: Mixed Capabilities Announcement Ben - Agent adds capabilities by either sending a modified message or a new one. Slide 14: Mixed Capabilities: DOIC Impacts Lionel (as individual) - What do you mean by "need" here, I'm good with what is presented. You may have configuration. Ben - I mean that this cfg should be allowed. These need to be allowed. DOIC should not prevent an agent from doing these things. On list, people think that agents must send back exactly what it received. Lionel - you will need more info - the name of the node that sent the info. Ben - These won't necessarily require change in what we've written. MUST NOT be prevented from doing this. Lionel - Agree Ben - Open issue - there's a section on guidance for agents that's not filled in. We need to talk non-normatively about what could happen. Steve - my goal is that those agent-specific sections go away. We want agreement with the concepts first. Once we have agreement, then we'll get normative text. Ben - I want to clarify disagreements. There are disagreements on the list, but those folks are not here. Lionel - We need to ensure that the AVPs and algorithm are clear. How they are used is application specific. Need a rough overview of how to be consumed and created. Ben -that's why it's a separate draft. Ulrich - if the agent throttles on behalf of C2 - Ben - on the next slide. Slide 15: Non-Supporting Client: Capabilities Ben - An agent rejects requests, it does not discard them. Need new error type. Agent has to respond, otherwise things will get worse because the client would just retry. Only time you would drop without response is if you are so overloaded that you're close to crashing anyway. Ulrich - I'm trying to understand what C2 would do if it gets an error code. Ben - it's an open issue, a non-compliant client won't support the new error code, either. If you have a suggestion? Steve - I asked the list a while back, I don't know what the client behavior is if it receives error code it doesn't' know. Lionel - The behavior is based on error type. Jouni - For protocol errors, terminate session. transit error - mingle around. Rough decisions. Steve - it wasn't clear to me what it would happen. We just don't want it to retry. Ben - make it an application error. Jouni - if it's a transit error - it assumes the problem is temporary and will retry. Ben - Need to look at the base behavior and figure out what to do. Steve - Sending a Too Busy may be the best we can do. Jouni - for new application, behavior will be clear. Lionel - since the agent is throttling for C2, need to expect that C2 will transmit. Could reuse TOO BUSY. Goal is to limit traffic to the server. Ben - we were hoping not to make the client retry. Lionel - UNABLE TO COMPLY. Need to work on this. Ben - take to the list. ACTION: Discuss error code selection on the list. Jouni - 10 more minutes. Slide 18: Non-Supporting Agent 1 Ben - May have an issue with the spec here. A1 can pass through the unknown AVPs (not necessarily true for proxies). A2 can't tell that A1 doesn't support DOIC. There is no attribution of DOIC supported features. We may need one. Slide 19: Non-Supporting Agent 2 Ben - This is a problem - only the node that does server selection can do diversion. We're limited to throttling, which is less optimal. Ulrich - You say avoid this in general but host routed should still work. Just realm routed scenarios won't. Ben - Need guidance, not normative language. This config can cause problems in some circumstances. The draft goes into detail. Dave - not prohibited, just not recommended. Ben - there are cases where it's not a problem. Just provide guidance. Diversion may be redundant if you have load balancing, for instance. Lionel - You need to take this into account when designing architecture. Ben - agree Slide 20: Non-Supporting Node: DOIC Impacts Dave - Do you mean MAY not MUST? Ben - it's a little "must". DOIC must not prevent an agent from doing these. Lionel - If the client finds that OL states are maintained by agent and server. This will be clarified when we clarify association. Slide 21: Inter Domain Trust Ben - Domain 1 trusts domain 2 but not domain 3. This is important for carriers. Goes back to knowing that the agent supports overload. Domain 2 is incrementally supporting DOIC. A2(b) just forwards AVPs, violating trust. And A1 can't tell that A2(b) doesn't support it if A3 has sent support info. Rest of slides skipped due to time. DOIC next steps and working procedure.. Jouni - We want DOIC out of the working before next IETF meeting. There have been discussions about holding an interim meeting. Lionel - propose on mailing list - conference call on regular basis. There's a 3gpp meeting in October could collocate. ACTION: Chairs to propose regular conference calls and an interim meeting, best before the CT4 3GPP meeting in order to make the draft deadline. Steve - the CT4 3gpp meeting - would miss the draft deadline if held after. Needs to be before. Individual & new work --------------------- 11:00 - 11:10 New derived Diameter datatypes (10 minutes) Draft: currently draft-zhou-dime-4over6-provisioning-03 Slides: http://www.ietf.org/proceedings/90/slides/slides-90-dime-1.pdf Presenter: Tom Taylor Tom presented Slide 3: Solution Alternatives Tom - Grouped AVPs are a pain to specify. Propose a new derived type - simplifies specification. Slide 4: Procedural Considerations Dave - I've seen this before? Jouni - It has been done in the past, people just define something on octetString, but don't declare a new data type. Dave - if it's been done in ad-hoc way, is it ok to adopt? Lionel - If we want to extend base protocol it would better to create a new document to update 6733 and just cover this data type in it. Tom - makes sense. Lionel - can discuss in mailing list. ACTION: Discuss new draft that updates RFC6733 to describe new data type. Wrap-up (10 minutes) -------------------- 11:10 - 11:20 Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps Lionel - We need more people outside the authors in the discussions. The more people we have, the easier it is to determine consensus. Same for any doc in the working group. We'll need to decide to maintain the working group. Need to be active if you want to keep it. Steve - from last meeting I thought that we would add agent overload and rate specification to the working group milestones. Jouni - we can add them. Keith - I'm not sure what the scope of agent overload is. I want the base overload doc out of WGLC before discussing this. Jouni - there's an agreement that we add milestone. Steve - there's no intent to interfere with schedule of base draft.