Re: [Dime] AD review draft-ietf-dime-app-design-guide

<lionel.morand@orange.com> Tue, 13 May 2014 06:28 UTC

Return-Path: <lionel.morand@orange.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 E76141A0848 for <dime@ietfa.amsl.com>; Mon, 12 May 2014 23:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 QUxRF3gDR-uW for <dime@ietfa.amsl.com>; Mon, 12 May 2014 23:28:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B93131A0849 for <dime@ietf.org>; Mon, 12 May 2014 23:28:07 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B22E93B41A7; Tue, 13 May 2014 08:28:00 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 97297238048; Tue, 13 May 2014 08:28:00 +0200 (CEST)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 13 May 2014 08:28:00 +0200
From: <lionel.morand@orange.com>
To: Benoit Claise <bclaise@cisco.com>, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" <draft-ietf-dime-app-design-guide@tools.ietf.org>
Thread-Topic: [Dime] AD review draft-ietf-dime-app-design-guide
Thread-Index: AQHPbi++E4riv750cUaQ20hH69uIP5s+Bfrw
Date: Tue, 13 May 2014 06:27:59 +0000
Message-ID: <7656_1399962480_5371BB70_7656_3268_1_6B7134B31289DC4FAF731D844122B36E59FE4D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53514D73.3090006@cisco.com> <53714817.8020100@cisco.com>
In-Reply-To: <53714817.8020100@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.4]
Content-Type: multipart/related; boundary="_004_6B7134B31289DC4FAF731D844122B36E59FE4DPEXCVZYM13corpora_"; type="multipart/alternative"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.11220
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/setqsa-LPOL7Hut9AWHX2CbSXm0
Cc: dime mailing list <dime@ietf.org>
Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide
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: Tue, 13 May 2014 06:28:11 -0000

Hi Benoit,

The "MUST" is maybe not required.
But this will cause interoperability issues if you just say "re-use AVP 1" without saying exactly how to set the M-bit. Some may decide to set the M-bit as initially defined, others may decide to change it.
So the idea was to provide an absolute recommendation for designers and then a MUST/REQUIRED/SHALL for all the AVP flags:
- The M-bit flag MUST be re-evaluated
- Other AVP flags MUST remain unchanged.

If not valid, no problem to revert the change.

Regards,

Lionel


De : Benoit Claise [mailto:bclaise@cisco.com]
Envoyé : mardi 13 mai 2014 00:16
À : MORAND Lionel IMT/OLN; draft-ietf-dime-app-design-guide.all@tools.ietf.org
Cc : dime mailing list
Objet : Re: [Dime] AD review draft-ietf-dime-app-design-guide

Hi Lionel,

Thanks for the new version 23.

One question regarding the attached picture.
[cid:image001.png@01CF6E82.6C602D80]

What does it mean "MUST be re-evaluated" with a RFC 2119 keyword.
RFC 2119 keywords are useful for interoperability, and I don't see why it's used here.

Regards, Benoit.
Hi Lionel,

Thanks for the new version.
See in line


- When I read the document, it looked to me as a BCP.
BCP definition from RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs



   The BCP subseries of the RFC series is designed to be a way to

   standardize practices and the results of community deliberations.
Interestingly, the charter mentions:
May 2012, Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document
[LM] discussed in another email thread.

If you go to BCP, don't forget to update the abstract, and the writeup.
Abstract:


   It is meant as a guidelines document and

   therefore as informative in nature.



I would remove this sentence. Informative and BCP don't go along very well.



Jouni, don't forget to update the writeup.


- Editorial in section 5.7
OLD:

Destination- Realm



NEW:

Destination-Realm


Still there.





- Section 5.9

 Applications that do not understand these AVPs can discard

   them upon receipt.
Generic comment: Each time there is a sentence like this one above, we should mention RFC 6733 as the reference.
This document is not an extension/deviation to RFC 6733.
[LM] ok
Still there.


Regards, Benoit




_______________________________________________

DiME mailing list

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

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


_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.