[Dime] Draft IETF#84 meeting minutes

[jouni korhonen <[e-mail]>]

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.