Re: [Dime] Draft IETF#84 meeting minutes

[Ben Campbell <[e-mail]>]

The minutes look good to me. 

I can't help with the missing names, except to point out that the minute taker was "Jean" rather than "Jane" :-)

Thanks!

Ben.

On Aug 12, 2012, at 3:47 PM, jouni korhonen <[e-mail]> wrote:

> Folks,
> 
> Have a look at the draft minutes. There are few "???"s regarding who
> gave comments. It would be nice to have those filled with correct names.
> 
> Thanks a bunch to Jane for taking excellent minutes.
> 
> - JOuni
> 
> ----------------------------
> 
> Minutes of the DIME WG meeting at IETF 84
> Tuesday, July 31, 2012
> 1300-1500  Afternoon Session I, Georgia A
> 
> Administrivia =========================== 
> Presenters: Jouni Korhonen, Lionel Morand
> 
> - Note well presented
> - Note taker: Jean Mahoney
> - Jabber scribe: Tom Taylor
> 
> 
> == Working Group Status Update ==
> Presenters: Jouni Korhonen, Lionel Morand
> 
> WG Documents:
> - draft-ietf-dime-erp 
> 	- proto writeup  
> 	- another draft
> - draft-ietf-dime-app-design-guide 
> 	- if wg agrees, move to wglc
> - draft-ietf-dime-realm-based-redirect 
> 	- discuss here
> 	- reissue for wglc
> - draft-ietf-dime-group-signaling
> 	- at an early stage
> 
> A list of documents that have dependencies on draft-ietf-dime-rfc3588bis was 
> presented. 
> 
> Benoit Claise, OPS area director: A new version of draft-ietf-dime-pmip6-lr has 
>  been posted. One author has removed himself from the author list. However, 
>  there's a copyright issue and the author needs to be acknowledged. Marco, what 
>  do you want?
> 
> Marco Liebsch: If someone should be acknowledged, then add them to the 
>  Acknowledgement section. My name isn't in the latest, keep as-is.
> 
> Benoit: If the text that Marco contributed is gone, then we don't have an issue.
> 
> Marco: It has been removed.
> 
> Benoit: No issue then. It is to the main author (Glen Zorn) to acknowledge or 
>  not. 
> 
> 
> == Charter update ==
> 
> - Removed mib docs due to lack of interest.
> 
> 
> Realm based redirect================
> draft-ietf-dime-realm-based-redirect
> Presenter: Tom Taylor
> 
> == Issue: Redirect Agent versus Server ==
> 
> Redirect agents don't have application-specific behavior. Redirection must be 
> performed by the application at a server, and only a proxy or client can reroute 
> based on the response.
> 
> Does anyone have issues with changing from redirect agent to server?
> 
> Lionel: Clarify what a proxy can do. Clarify new requests versus redirect. This 
>  is on the right path, but more information needs to be added.
> 
> == Issue: handling of request with Destination-Host AVP ==
> 
> Destination-Host AVP is normally added to requests only subsequent to the 
> initial request of the session. The Destination-Host AVP is incompatable with 
> realm-based redirection. However, the Destination-Host will be there because you 
> are in the middle of the session rather than at the beginning. 
> 
> The application can specify that it only applies to initial requests, so it's 
> not disruptive to current requests.  
> 
> Lionel: Is there a use case where you would redirect midsession? If not, just 
>  remove info on the Destination-Host AVP. It's a blocking point.
> 
> <No comments from the room> 
> 
> ACTION to working group: Please comment on the mailing list on whether we need 
> to support mid-session realm-based redirection.
> 
> Tom Taylor took an action on himself to clean up the text about the proxy 
>  behavior.
> 
> Next version of the document will be out this week or next. 
> 
> 
> 
> Design Guidelines ==============
> draft-ietf-dime-app-design-guide
> Presenter: Lionel Morand
> 
> Lionel presented changes to the document since version -14.
> 
> Lionel feels that the document is finished, and is planning a WGLC in August.
> 
> ACTION to the working group: Please provide feedback.
> 
> Ben Campbell: RFC3588bis recommends TLS and DTLS, does providing IPsec 
>  recommendations violate that part of RFC3588bis? 
> 
> Lionel: The IPsec text was originally in RFC3588. It has been removed from 
>  RFC3588bis and added to the design guide. 
> 
> Ben: But isn't using IPsec a deployment decision?
> 
> Lionel: It's a design decision, you can specify the transport when you design 
>  the application. 
> 
> 
> 
> Group signaling ===============
> draft-ietf-dime-group-signaling
> Presenter: Marco Liebsch
> 
> Marco presented two different approaches to manipulating groups of sessions: 
> 	- Dedicated group commands
> 		- do not contain the same AVPs as their non-group
> 		  equivalents
> 		- new commands are defined for each group operation
> 		- new Application-Id
> 		- pros: straightforward, low-level of ambiguity
>                - cons: new commands and formats needed for all
> 		  bulk-enabled commands; proxy needs to be aware of 
> 		  the new application
> 	- Bulk operation command
> 		- a single Diameter command for bulk operations
> 		- applies to existing Diameter commands that handle
> 		  single sessions
> 		- pros: no new formats or codes needed
> 		- cons: Session-Id AVP needs to be ignored or used 
> 		  to carry group ID;  proxy needs to be aware of 
> 		  the new application; potential issue with mandatory
> 		  attributes in the body when they apply to a single 
>                  session
> 
> Lionel: There's no way to know that dedicated group commands are for a  group
> 
> Marco: There is a new application in the header, a new command code, and the 
>  Session-Group-Id AVP.
> 
> Lionel: For example, only thing that GRAR has in common with RAR is the 
>  Re-Auth-Request-Type. Except the name, there's nothing in common with the 
>  original command. There is nothing here that says you have to do something 
>  else here. 
> 
> Lionel: For the bulk operation command, the RAR command code is reused, you can 
>  rely on this to know what to do.
> 
> Marco: From an implementation perspective, it's not hard to link a new GRAR to 
>  the RAR state machine.
> 
> Lionel: Different state machines?
> 
> Marco: Yes, it varies.
> 
> Lionel: You'll have same command code but with different state machines and 
>  ABNF.
> 
> Marco: The mandatory fields differ.
> 
> Jouni: We're modifying current ABNF. Something is not clear and is against 
>  existing RFCs. 
> 
> Next steps:
> Soliciting input on  formatting, design update draft in August
> 
> Lionel: For a minimal impact on existing applications, just add group AVPs. The 
>  only new information is the two new AVPs (Session-Group-id, 
>  Session-Group-Action). What if we added these AVPs and created a new 
>  application? Can reuse for any command. 
> 
> Jouni: An optional AVP, but there's another issue - you don't know if the other 
>  end is supporting it. Need to negotiate capabilities. 
> 
> Lionel: Create a new application, have capabilities exchange. Or use optional 
>  AVP and advertise support. 
> 
> Adam: Capabilities exchange only works between adjacent nodes. Each node in path 
>  will have to support it. I would prefer not to define new applications. Work 
>  here can be reused for overload. 
> 
> Lionel: The only way to avoid new applications is to use optional AVPs.
> 
> Adam: Yes, I would prefer that. 
> 
> Glen: Capabilities are pair-wise, they don't go forward. It's just an 
>  advertisement, it's not negotiated. 
> 
> Adam: We're not creating groups and then adding sessions to them. We're adding 
>  existing sessions to groups. Right?
> 
> <missed Lionel's response>
> 
> Marco: Individual Session-Id is carried but ignored. 
> 
> ???: This could be a new session. Unless there's a reason to limit to existing 
>  sessions, it should apply to both. 
> 
> Mark Jones: (from the chat room) About end-end negotiation, groups are always 
>  assigned at session creation. 
> 
> ACTION to working group: discuss on the mailing list.
> 
> 
> Diameter Overload Control ==================
> Overload control justification and use cases
> Presenter: Martin Dolly
> 
> Martin Dolly presented reasons for Diameter overload control.
> 
> Glen Zorn asked for clarification of 3GPP terms since it shouldn't be assumed 
>  that participants are familiar with them. 
> 
> Benoit: What are you asking for with this presentation?
> 
> Martin: AT&T and other operators see a need to support a diameter overlaod 
>  mechanism to alleviate problems identified here.
> 
> Glen: I want to be convinced why this is the IETF's problem. Inadequate capacity 
>  or poor network planning is not our problem. 
> 
> Ben: The next presentation will say how this is a IETF problem. Peak loads are 
>  many orders of magnetude above regular load. If you provision for that, 
>  everyone pays more.
> 
> Adam: It's like saying that TCP congestion isn't a problem. It's bursty, it can 
>  pile up, the network will exceed capacity. Need to make sure it doesn't melt 
>  down. 
> 
> Martin: We need a resilient network. This is like SIP overload. AT&T initiated 
>  the SIP overload work. We want a generic solution across the diameter 
>  interfaces. 
> 
> ??: My company thinks the IETF has the expertise and wants the IETF to do this 
>  work.
> 
> Tom Taylor: Bursts happen. Something has to be done. 
> 
> Jouni: The operators have been kind enough to ask us to work on it.
> 
> Jin Rong, ATT: The problem is in the base protocol. Handling it in the protocol 
>  is the most efficient way to handle it. Otherwise we don't have a tool to 
>  solve this problem.
> 
> 
> 
> draft-mcmurry-dime-overload-reqs ============
> Presenter: Eric McMurry
> 
> Eric's presentation on Diameter overload control requirements was cut short due 
> to running out of time.
> 
> Eric: The point of the presentation is to get people interested, and it should 
>  be handled in the base protocol. There's a draft out there of requirements. We 
>  want to get agreement on that before working on a  mechanism. Next steps: is 
>  the problem real and worth working on? Does the work belong in dime?
> 
> Ben: We don't expect the doc to be perfect, don't know if the requirements are 
>  all there. Is the dime working group the right place?
> 
> Mark Jones: Yes, it's real, and worth working on. It fits the charter.
> 
> Martin: ATT supports this and would love to see this in the wg. 
> 
> Geller (??): We support this.
> 
> John Kaippallimalil from Huawei CRO (3gpp core network overload): We support 
>  this, too.
> 
> Tom Taylor: I support it. 
> 
> Lionel (as an individual): We see this problem in multiple protocols. We need to 
>  identify problems with the existing specification. What's missing, unclear? 
>  Have requirements to fill the gap. Extend the base protocol? Or create a new 
>  application?
> 
> Jouni (as an individual): This is a real problem, need to work on it (commented 
>  already few points on email earlier), need a solution.
> 
> Ben: We agree that requirements come first. It's been controversial for every 
>  working group that faces it. 
> 
> Benoit (as AD): I'm pleased that operators come here. I believe there's support. 
>  You might ask who opposes. Who will work on it?
> 
> Jouni: anyone against?
> 
> <silence>
> 
> Who will work on it: <multiple hands raised>
> 
> Benoit: There's support. Create a problem statement and then requirements?
> 
> Jouni (ind): Problem statements are waste of time. Add a paragraph in the 
>  requirements doc. 
> 
> Lionel: More than one paragraph. Have one document that explains what's missing 
>  in Diameter and provides a set of requirements. 
> 
> Jouni: Anyone aganist adoption? 
> 
> <silence>
> 
> ACTION for Jouni: To ask the working group about adoption. 
> 
> Ben: If the wg adopts, we'll adjust for consensus. 
> 
> Benoit: Don't have to hurry on deciding that it fits the charter. 
> 
> Lionel: We need to first agree that we will work on it. 
> 
> Martin: You need to hurry on deciding to work on it, otherwise ATT/VZW/TMO - 40% 
>  of LTE deployment - will ask our vendors to work on non-standard solutions. 
> 
> Lionel: This document is not blocked on whether it fits the charter. 
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime