Subject: [Dime] draft-tsou-dime-capabilities-update-problem-statement

From: Tina TSOU <[email-masked]>
Date: Wed, 16 Jul 2008 10:12:39 +0800

Comments are welcome:-)
It was submitted after -00 deadline, so I am not expected to be discussed in Dublin.
However, your comments are very welcome;-)

B. R.
Tina

Filename:    draft-tsou-dime-capabilities-update-problem-statement
Version:    00
Staging URL:    http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt
Title:    Capabilities Update Problem Statement
Creation_date:    2008-07-15
WG ID:    Indvidual Submission
Number_of_pages: 17
Abstract:
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis.  Capabilities update in OPEN state can reuse
commands CER/CEA commands for re-negotiation between Diameter peers
when one of them changes its capabilities.It is a very important
function in Diameter.

However, RFC 3588 has defined a mechanism of containing capabilities
list both in CER and CEA commands and the peer should update its
local database whenever it receives CER/CEA.  This makes the process
complex and redundant when they are used in OPEN state.  So this
draft proposes a simpler solution based on CER/CEA commands to deal
with this problem.

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Gil Shafran" <[email-masked]>
Date: Wed, 16 Jul 2008 16:09:56 +0300

Hi,

I think there is a backward compatibility issue with the 'update' CEA
defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains
some required AVPs of which the M bit must be set (e.g. Vendor-Id,
Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct
CEA parsing, based on the peer's state, is abit vague. Specially when peer
state machine implementations producing equivalent results are considered
compliant.

Best regards,
Gil

On Wed, Jul 16, 2008 at 5:12 AM, Tina TSOU <[email-masked]> wrote:

> Staging URL:
> http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt

---

From: Tina TSOU <[email-masked]>
Date: Thu, 17 Jul 2008 08:49:27 +0800

Hi Gil,
I think you have got a point. Having 2 ABNFs for CEA in 2 state is indeed a vague implementation (I should have thought of that when I proposed it :-( ). It is acceptable for me (& and I live with the redundant work of having to fill the mandatory AVPs of CEA in update scenario).

B. R.
Tina
  ----- Original Message ----- 
  From: Gil Shafran 
  To: Tina TSOU 
  Cc: [email-masked] 
  Sent: Wednesday, July 16, 2008 9:09 PM
  Subject: Re: [Dime] draft-tsou-dime-capabilities-update-problem-statement

  Hi, 

  I think there is a backward compatibility issue with the 'update' CEA defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains some required AVPs of which the M bit must be set (e.g. Vendor-Id, Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct CEA parsing, based on the peer's state, is abit vague. Specially when peer state machine implementations producing equivalent results are considered compliant.
  Best regards, 
  Gil

    Comments are welcome:-)

    B. R.
    Tina