Subject: [Dime] AD review of draft-ietf-dime-capablities-update-05

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 20 Sep 2010 13:41:49 +0200

Please find below the AD review of
draft-ietf-dime-capablities-update-05. This document is ready for IETF
Last Call, and I will initiate the Last Call soon. Please consider the
comments below together with other comments that may be received during
the IETF LC. The comments are divided into Technical (T) and Editorial
(E). 

T1. While some parts of the specification are aligned with
[I-D.ietf-dime-rfc3588bis] (for example section 5 - Security
Considerations), other refer to 3588 (Section 6 - IANA Considerations).
We need consistency on this respect, and my suggestion is to align the
document with [I-D.ietf-dime-rfc3588bis] as we do have a normative
dependency on it anyway. 

T2. What happens if the receiver of a CUR does not return a
Capabilities-Update-Answer (CUA)? Is there any timeout or retransmission
strategy in place?

E1. I find this sentence at the end of the first paragraph in Section 4
to be imprecise: 

> This message allows the
   update of a peer's capabilities (supported Diameter applications,
   etc.).

What belongs to etc. must be defined clearly. Actually at this point
there is need to define precisely what capabilities are covered by the
message, and if there is a way to extend this list in the future. 

E2. Expand acronyms at first occurrence: AVP, SCTP

Regards,

Dan

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Sep 2010 23:05:52 +0700

> document with [I-D.ietf-dime-rfc3588bis] as we do have a normative

OK.

> Capabilities-Update-Answer (CUA)? Is there any timeout or retransmission

Um, TCP?  I guess that I don't understand the question.
 
> message, and if there is a way to extend this list in the future.

Unfortunately, I'm not sure that such a list exists (or has ever existed ),
even for the CER/CEA command pair; certainly, neither RFC 3588 nor 3588bis
include one.  Both say 

   When two Diameter peers establish a transport connection, they MUST
   exchange the Capabilities Exchange messages, as specified in the peer
   state machine (see Section 5.6).  This message allows the discovery
   of a peer's identity and its capabilities (protocol version number,
   supported Diameter applications, security mechanisms, etc.)

The CUR/CEA messages only contain a subset of the capabilities advertised
via the CER/CEA mechanism, so if it's really necessary to list them maybe
the first thing to do is create the master list in 3588bis.

> E2. Expand acronyms at first occurrence: AVP, SCTP

OK.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Sep 2010 15:15:28 +0200

Thanks for the answer. See in-line. OK parts deleted. 

Regards,

Dan

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]] 
> Sent: Monday, September 20, 2010 6:06 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: RE: AD review of draft-ietf-dime-capablities-update-05
> 

...

> > Capabilities-Update-Answer (CUA)? Is there any timeout or 
> > retransmission strategy in place?
> 

So the answer is that there is no mechanism for timeout / retransmission
at the application layer. 

>  
> > 
> > 
> > E1. I find this sentence at the end of the first paragraph 
> in Section 
> > 4 to be imprecise:
> > 
> > > This message allows the
> Unfortunately, I'm not sure that such a list exists (or has 
> ever existed ), even for the CER/CEA command pair; certainly, 
> neither RFC 3588 nor 3588bis include one.  Both say 
> 
> The CUR/CEA messages only contain a subset of the 
> capabilities advertised via the CER/CEA mechanism, so if it's 
> really necessary to list them maybe the first thing to do is 
> create the master list in 3588bis.
> 

Other opinions? What did people implement? 

...

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Sep 2010 22:35:28 +0700

> at the application layer.

I guess so.

...