Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-15.txt

From: [email-masked]
Date: Thu, 11 Dec 2008 09:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

	Title           : Diameter Base Protocol
	Author(s)       : V. Fajardo, et al.
	Filename        : draft-ietf-dime-rfc3588bis-15.txt
	Pages           : 160
	Date            : 2008-12-11

The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility.  Diameter is also intended to work in
both local Authentication, Authorization & Accounting and roaming
situations.  This document specifies the message format, transport,
error reporting, accounting and security services to be used by all
Diameter applications.  The Diameter base application needs to be
supported by all Diameter implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Dec 2008 12:37:57 -0500

Changes in this revision includes:

- CER/CEA protection via TLS. See ML thread on "Options for securing 
CER/CEA"
   * Also updated peer discovery for peers that support TLS ports.

- Additional text on processing answers with errors (from AAA-DOCTORS 
discussion)

- Reverted Auth-Session-State default to STATE_MAINTAINED. (Discussion 
on draft-14 changes)

Open issues:

- There maybe a need to increment the version number in the diameter 
header. Any comments ?

regards,
victor

> ------------------------------------------------------------------------
>

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 12 Dec 2008 10:56:43 +0900

Hello Victor,

I have a couple of remarks on the new version, if you don't mind:

1) Sorry, I am not very familiar with NAPTR mechanism, but the following
change in section 5.2 seems odd to me:

This specification defines
          D2T for TCP and *TCP,* D2S for SCTP. *SCTP and D2L for TLS.* 

Because I believe that TLS runs over SCTP or TCP, I believe you would
need two different records? Or do you assume that TLS is only run over
TCP? In that case the clarification is needed.

Remark: the same problem appears in next paragraph with
**'_diameter._tls'.realm

**Remark: the IANA requirement section (11.5 and 11.6) also considers
TLS as a transport protocol at the same level as TCP and SCTP, whereas
TLS runs over TCP or SCTP.

2) This is not important, there are some typo in the new paragraph about
7. Error Handling

Thank you,

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Dec 2008 21:22:56 -0500

Hi Sebastien,

> TCP?

Only TCP for practical reasons. We can clarify this.

>  In that case the clarification is needed.
>

At the moment, we want to consider TLS/TCP as a separate secured 
transport since we are proposing a new secured port specifically for it.

> 2) This is not important, there are some typo in the new paragraph about

Thanks. pls send me specifics and we should fix those.

-- victor

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 12 Dec 2008 11:55:31 +0900

Thank you for your quick answer.

> Only TCP for practical reasons. We can clarify this.
Thank you for the reply. I believe it is worth stating this clearly in
the document, but maybe it is only me.
Anyway in case a some point later TLS/SCTP is needed (or maybe S-SCTP),
I still believe the references to this new port should include "TCP" in
addition to "TLS".

> transport since we are proposing a new secured port specifically for it.
Right, my point was just it should say "TLS/TCP" and not just "TLS" in
the document, IMHO.

> Thanks. pls send me specifics and we should fix those.
I am not native English so maybe I am mistaking, so please discard my
comments in that case ^^.

   In the case where the answer message itself contain an error(s), any
                                                    ^^^
                                               contains
   related session SHOULD be terminated by sending an STR or ASR
   message.  The Termination-Cause AVP in the STR MAY be filled with the
   appropriate value to inidcate the cause of the error.  An application
                          ^^
                        indicate
   MAY also send an application specific request instead of STR or ASR
   to signal the error in the case where no state is maintained or to
   allow for some form of error recovery with the corresponding Diameter
   entity.

Thanks,
Sebastien.