Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

<> Wed, 12 September 2012 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F45221F866B for <>; Wed, 12 Sep 2012 10:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eyyLfhUlcPuu for <>; Wed, 12 Sep 2012 10:00:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79E6821F865F for <>; Wed, 12 Sep 2012 10:00:55 -0700 (PDT)
Received: from (unknown [xx.xx.xx.1]) by (ESMTP service) with ESMTP id 3D1932644F6; Wed, 12 Sep 2012 19:00:54 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 2363535C08F; Wed, 12 Sep 2012 19:00:54 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 19:00:53 +0200
From: <>
To: Ben Campbell <>
Thread-Topic: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15
Thread-Index: AQHNi5uu0n03DPqst0+L3ckUm0TZFpeG9Ofw
Date: Wed, 12 Sep 2012 17:00:53 +0000
Message-ID: <28577_1347469254_5050BFC6_28577_9048_1_6B7134B31289DC4FAF731D844122B36E0634A9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <> <3092_1346861420_5047796C_3092_8625_1_6B7134B31289DC4FAF731D844122B36E049B19@PEXCVZYM11.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2012.9.12.151515
Cc: "" <>
Subject: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Sep 2012 17:00:56 -0000

Hi Ben,

Please see below.



-----Message d'origine-----
De : Ben Campbell [] 
Envoyé : mercredi 5 septembre 2012 21:22
Cc :
Objet : Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

Thanks for the response! I've removed sections that appear to be resoved.



On Sep 5, 2012, at 11:10 AM, <>; wrote:
> -- 5.9
> Does the advice in this section open up an unmanaged extension vector? In the extreme case, would this encourage an external group to register a single application id for a highly extensible application, then bypass IETF extension processes by just adding more functions to the original application?
> [LM] in the vendor-specific space, IETF will have no control at all but it is exactly the principle of vendor-specific application. So this possibility exists. Anyway, as soon as interoperability with the external world is required, application designers will have to adopt common rules and this is the aim of this document.

I agree we can't control what people do in the vendor-specific space. We have so little control there that there is little point in saying much about it. My concern is still true for the IETF controlled space, which is controlled by IETF Review. My concern is that encouraging the use of AVPs to negotiation features could be used to invoke extensions that really should be treated as separate applications. The text here seems to condone that behavior, which could lead an expert reviewer to decide it was okay for all cases.

If we are going to encourage the use of AVPs to negotiation arbitrary features, we probably need some guidance for said expert reviewer. I realize this sort of thing would be case-by-case and fairly subjective, but it seems like we need more guidance than is there now.

[LM] it is true that the mechanism is not only used by external SDOs but also in IETF RFCs, such as RFC5447. I think that we can clarify the way these E2E negotiation AVPs are meant to be used. The idea is that you add a new feature to an existing application that can be supported by an optional AVP or when client and server can support new optional functions that was not initially part of the specification. In such a case, as it is purely optional, using E2E negotiation AVPs is helpful. The limit is if any single agent in the path needs be updated to support this new feature, that would the case for the definition of a new application. Would it be OK if the text is clarified in that sense?


> Editorial Comments:

> -- 4.3.1, 2nd bullet list, 3rd bullet:
> The second half of this bullet item seems redundant with the previous bullet.
> [LM] OK. I propose to just keep the "different number of roundtrips" 


> -- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms such as IPsec can also be deployed to secure connections between Diameter peers."
> Do you mean "IPSec can also be deployed...", or "Additional security mechanisms such as IPSec can also be deployed..."?
> [LM] Obviously, something needs to be fixed.

Do you have thoughts on whether this text is intended to allow just the use of IPSec (in addition to TLS and DTLS, of course) , or to allow the more generic "additional mechanisms such as IPSec"?

[LM] the whole text is only about IPsec. I will even change the title of the section to reflect this point.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.