Subject: [Dime] rfc3588bis document update

From: Victor Fajardo <[email-masked]>
Date: Wed, 06 Jun 2007 07:58:18 -0400

Hi all,

The latest version of rfc3588bis is now available: 
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-04.txt

As a short summary, the change history of this document are as follows:

* 00 and rfc3588 are identical
* 01 incorporates the changes proposed in 
http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt
* 02 includes proposals for 32, 36, 44, 49, 41, 40, 31, 26
* 03 includes proposals for 28, 33, 37, 38, 51, 52, 50 (partially)
* 04 includes proposals for 34, 50, 54, 53
* Open issues remain: 35, 39

Suggested approaches for open issues:

#35 - Representation/Encoding of diameter identities (FQDN's). We may 
need to consult with DNS folks on how to properly support 
internationalization etc for FQDN names (if needed). This is in addition 
to the default ascii representation.

#39 - How to do TLS certificate validation against peer names. We may 
need to consult with security folks on how to properly support sanity 
checks on certificates; i.e, use of CN, SN etc against a diameter identity.

For easier reading the relevant diffs are:

* between 01 from 3588: 
http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01-from-rfc3588.diff.html
* between 02 from 01: 
http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02-from-1.diff.html
* between 03 from 02: 
http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03-from-2.diff.html
* between 04 from 03: 
http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-04-from-3.diff.html

The issue tracker can be found in: 
http://www.tschofenig.priv.at:8080/diameter-interop/index

regards,
victor

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

---

From: Rajith R <[email-masked]>
Date: Wed, 06 Jun 2007 17:50:27 +0530

I have some comments on RAR handling added to this draft:
Client is at liberty to / not to comply to an RAR (alike ASR). So I think
the behaviour of client sending an RAA with UNABLE_TO_COMPLY should be
similar to sending an ASA with similar result code i.e. client remains in
Open state where as Server State machine on receiving this RAA will change
to Idle state. 

I think the ASA with UNABLE_TO_COMPLY behaviour specifically addresses some
proxy initiated ASR scenario, though I am not sure how. Can any one throw
some light? May be same consideration should be applied to (stateful) proxy
initiated RARs also.

Regards

Rajith

>-----Original Message-----
>From: Victor Fajardo [mailto:[email-masked]] 
>Sent: Wednesday, June 06, 2007 5:28 PM
>To: [email-masked]
>Subject: [Dime] rfc3588bis document update
>
>Hi all,
>
>#35 - Representation/Encoding of diameter identities (FQDN's). 
>We may need to consult with DNS folks on how to properly 
>support internationalization etc for FQDN names (if needed). 
>This is in addition to the default ascii representation.
>
>#39 - How to do TLS certificate validation against peer names. 
>We may need to consult with security folks on how to properly 
>support sanity checks on certificates; i.e, use of CN, SN etc 
>against a diameter identity.
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 06 Jun 2007 08:40:07 -0400

Hi Rajith,

> Open state where as Server State machine on receiving this RAA will change

This maybe the case but I'm not sure. The semantics of aborting a 
sessions is different from a non-compliance of re-authorization so their 
repercussions are probably different. It maybe best if we get more 
opinion on this.

regards,
victor