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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 21 September 2010 13:15 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A52C3A6A1F for <dime@core3.amsl.com>; Tue, 21 Sep 2010 06:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.509
X-Spam-Level:
X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEX+7REQGvPx for <dime@core3.amsl.com>; Tue, 21 Sep 2010 06:15:41 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9DF1D3A691F for <dime@ietf.org>; Tue, 21 Sep 2010 06:15:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,399,1280721600"; d="scan'208";a="35601212"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Sep 2010 09:16:05 -0400
X-IronPort-AV: E=Sophos;i="4.56,399,1280721600"; d="scan'208";a="513841794"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Sep 2010 09:15:30 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 21 Sep 2010 15:15:28 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402570400@307622ANEX5.global.avaya.com>
In-Reply-To: <000001cb58dd$b6f53110$24df9330$@net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-dime-capablities-update-05
Thread-Index: ActYuNAHgWq9++BEQ7un4Mb4eDI9WgAAygEgADSdkVA=
References: <EDC652A26FB23C4EB6384A4584434A0402570160@307622ANEX5.global.avaya.com> <000001cb58dd$b6f53110$24df9330$@net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Glen Zorn <gwz@net-zen.net>
Cc: dime@ietf.org
Subject: Re: [Dime] AD review of draft-ietf-dime-capablities-update-05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Sep 2010 13:15:47 -0000

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

Regards,

Dan


> -----Original Message-----
> From: Glen Zorn [mailto:gwz@net-zen.net] 
> Sent: Monday, September 20, 2010 6:06 PM
> To: Romascanu, Dan (Dan)
> Cc: dime@ietf.org; kangjiao@huawei.com
> Subject: RE: AD review of draft-ietf-dime-capablities-update-05
> 
> Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes:
> 


...

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

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

Other opinions? What did people implement? 

...