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

["Glen Zorn" <[e-mail]>]

Romascanu, Dan (Dan) [mailto:[e-mail]] writes:

> 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.

OK.

> 
> 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?

Um, TCP?  I guess that I don't understand the question.
 
> 
> 
> 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.

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.

> 
> Regards,
> 
> Dan