Re: [Dime] Issue#29 proposed conclusion

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Fri, 21 March 2014 13:27 UTC

Return-Path: <jean-jacques.trottin@alcatel-lucent.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803CC1A0970 for <dime@ietfa.amsl.com>; Fri, 21 Mar 2014 06:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf3ylq8IFLD0 for <dime@ietfa.amsl.com>; Fri, 21 Mar 2014 06:27:14 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBD71A03E2 for <dime@ietf.org>; Fri, 21 Mar 2014 06:27:14 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2LDR1cv000480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Mar 2014 08:27:03 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2LDR0k1026454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 14:27:00 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 21 Mar 2014 14:27:00 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Issue#29 proposed conclusion
Thread-Index: AQHPQgot3XtrIF/JAkC849Kre38mZ5rre6EAgAARfMA=
Date: Fri, 21 Mar 2014 13:26:59 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D202671A3C@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com> <530BA310.4090100@usdonovans.com> <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com> <5327372B.1040600@usdonovans.com> <532C3C76.4050200@usdonovans.com>
In-Reply-To: <532C3C76.4050200@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202671A3CFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/N4I9_dpA85wrw8ww-xzEKvdiGe4
Subject: Re: [Dime] Issue#29 proposed conclusion
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 21 Mar 2014 13:27:18 -0000

Hi Steve

I agree on the proposal

Best regards

JJacques





De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : vendredi 21 mars 2014 14:20
À : dime@ietf.org
Objet : Re: [Dime] Issue#29 proposed conclusion

Having seen no additional discussion on this I will close the issue with the suggested text.

Regards,

Steve
On 3/17/14 12:55 PM, Steve Donovan wrote:
All,

I believe we have consensus on this ticket.

I had put the following into my issue status document:


Agreed - Removed OC-Sequence-Number from OC-Supported-Features AVP.
Agreed - The scope of an OC-Supported-Features AVP is a single transaction.
Agreed - Diameter nodes that support DOIC must include the OC-Supported-Features AVP in all requests.

I believe that this translates into the text changes outlined below.  If we have agreement on the text below we can close the issue and I'll update the text in the -02 draft accordingly.

Regards,

Steve

-----

Section 4.1:

Remove < OC-Sequence-Number >  from OC-Supported-Features syntax description.

Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

Section 4.4, Paragraph 1:

Remove reference to section 4.1.

Section 5.3.1, Paragraph 1:

Change:

It is RECOMMENDED that the

   request message initiating endpoint includes the capability

   announcement into every request regardless it has had prior message

   exchanges with the give remote endpoint.  In a case of a Diameter

   session maintaining application, sending the OC-Supported-Features

   AVP in every message is not really necessary after the initial

   capability announcement or until there is a change in supported

   features.



To:



The lifetime of a capability announcement is limited to a single transaction.  As a result, the reacting

node MUST include the capability announcement in all request messages.











On 2/24/14 5:02 PM, Ben Campbell wrote:

On Feb 24, 2014, at 1:52 PM, Steve Donovan <srdonovan@usdonovans.com><mailto:srdonovan@usdonovans.com> wrote:



I agree.



I also think that we agreed that the lifetime of the OC-Supported-Features AVP is a single transaction and that the OC-Supported-Features AVP must be included in all requests originated by a Diameter node supporting DOIC.

+1, and my previous agreement was based on that assumption.





Steve



On 2/20/14 4:31 PM, Ben Campbell wrote:

I concur with removing the sequence number from OC-Supported-Features.











_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime