IETF Logo Mail Archive

Re: [Dime] Proposed REQ 35 Text

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Wed, 27 March 2013 16:06 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7021F9274 for <dime@ietfa.amsl.com>; Wed, 27 Mar 2013 09:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eFUzN3E8iwA for <dime@ietfa.amsl.com>; Wed, 27 Mar 2013 09:06:38 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5C21F926D for <dime@ietf.org>; Wed, 27 Mar 2013 09:06:38 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2RG6a3F000782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Mar 2013 11:06:37 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2RG6V74017766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Mar 2013 12:06:36 -0400
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 27 Mar 2013 12:06:35 -0400
Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 27 Mar 2013 17:06:11 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: Ben Campbell <ben@nostrum.com>, "lionel.morand@orange.com" <lionel.morand@orange.com>
Thread-Topic: [Dime] Proposed REQ 35 Text
Thread-Index: AQHOKmDYS+DcvVurpkqLP2GHzogK35i5kKUAgAAJN4CAABn4UA==
Date: Wed, 27 Mar 2013 16:06:09 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D201077C36@FR712WXCHMBA10.zeu.alcatel-lucent.com>
References: <E11F7859-5062-4FF4-A731-4E5B6E2826C9@nostrum.com> <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <636561F1-0BED-4AB2-B359-FFE0633714D3@nostrum.com>
In-Reply-To: <636561F1-0BED-4AB2-B359-FFE0633714D3@nostrum.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.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 27 Mar 2013 16:06:40 -0000

Hi Lionel, Ben


I already  expressed my views for a MUST  on this REQ35 topic in previous mails.

As 3GPP will be a main user of the overlaod mechanism, and as 3GPP CT4 has a dedicated meeting on Diameter overlaod on April 9th 11th, where this toint will be discussed. I prefer to wait for the CT4 outputs before coming back to the DIME mail discussion.

Best regards

JJacques 

  
-----Message d'origine-----
De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mercredi 27 mars 2013 16:28
À : lionel.morand@orange.com
Cc : dime@ietf.org
Objet : Re: [Dime] Proposed REQ 35 Text

Hi Lionel,

On Mar 27, 2013, at 9:55 AM, lionel.morand@orange.com wrote:

> Hi,
>  
> Following the discussion in the meeting, here is my interpretation.
> I said during the meeting that a new application will only be able to go through existing relay and redirect agent and not through "legacy" proxies i.e. proxies not supporting/advertising the new application.
>  
> So the question is simple: in the requirement elaboration phase, are we sure that any solution based on a new App-id will be rejected?
>  
> If not: the "SHOULD" is meaningful in REQ35.
> If yes: this is a strong requirement and this must be stated somewhere in the draft.

For the record, the piggy-backed solution currently proposed also does not meet REQ35.

We don't necessarily try to prove feasibility in advance for all requirements. I'm not sure what the work group approach would be in handling a MUST level requirement that turns out to be infeasible. I suspect it would be to merely notate that we couldn't come up with a reasonable way to meet the requirement and move on. Making it a MUST means we need to try hard, though, and look for alternatives if none of our proposals meet it.

I'm also not convinced a MUST here automatically disallows an application-based approach. Other applications have to deal with relays that return just the relay app ID in the capabilities exchange. We also mentioned the possibility of a separate mechanism to handle the non-adjacent case.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

v2.23.0 | Report a Bug | By Email