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? ...
- [Dime] AD review of draft-ietf-dime-capablities-u… Romascanu, Dan (Dan)
- Re: [Dime] AD review of draft-ietf-dime-capabliti… Glen Zorn
- Re: [Dime] AD review of draft-ietf-dime-capabliti… Romascanu, Dan (Dan)
- Re: [Dime] AD review of draft-ietf-dime-capabliti… Glen Zorn