Re: [Dime] AD review draft-ietf-dime-app-design-guide
Benoit Claise <bclaise@cisco.com> Wed, 14 May 2014 16:39 UTC
Return-Path: <bclaise@cisco.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 D3FF41A02C6 for <dime@ietfa.amsl.com>; Wed, 14 May 2014 09:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 G40Bl7QNm09h for <dime@ietfa.amsl.com>; Wed, 14 May 2014 09:39:45 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DB82F1A02B2 for <dime@ietf.org>; Wed, 14 May 2014 09:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7580; q=dns/txt; s=iport; t=1400085578; x=1401295178; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tgEWs83uCDF1Gbw586vuVCY4aVx64stp7YSHSkJe6iE=; b=SKaTZZfm4QXlcl1pFA6o1fwb6JuAH4Q4HrnZl5KJ12LauC+0oWhsR6VD OXEW0fW523F0/i8qVUhBJDwaMxlKluflRIjSZ6AKinKcAsVAnOXFMHshp 4h8EAt1dEzY0rWBQvSXBEUJ3hag1d9v5J8L4quCLsu1yUvBWaoCvYUTZQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAECbc1OtJV2Q/2dsb2JhbABZgwZPvwyHOwGBIxZ0giUBAQEDAQEBAS8BBTYKAQULCyEWCAcJAwIBAgEPBh8RBgEMAQUCAQEQiBkDCQgNylQNhjoTBIw5gSgLEQFLBQeEQAEDl16Bc4ZphkGFaoM4OzCBCg
X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="324870535"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 14 May 2014 16:39:38 +0000
Received: from [10.21.94.78] (sjc-vpn5-1614.cisco.com [10.21.94.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4EGdbUc018630; Wed, 14 May 2014 16:39:37 GMT
Message-ID: <53739C48.9000709@cisco.com>
Date: Wed, 14 May 2014 18:39:36 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: lionel.morand@orange.com, Jouni Korhonen <jouni.nospam@gmail.com>, "draft-ietf-dime-app-design-guide.all@tools.ietf.org" <draft-ietf-dime-app-design-guide@tools.ietf.org>
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> <7656_1399962480_5371BB70_7656_3268_1_6B7134B31289DC4FAF731D844122B36E59FE4D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53722C6C.4000405@gmail.com> <21032_1400081845_53738DB5_21032_16360_1_6B7134B31289DC4FAF731D844122B36E5A4181@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <21032_1400081845_53738DB5_21032_16360_1_6B7134B31289DC4FAF731D844122B36E5A4181@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kBze1abc_HDE5d_Ib5SbR7v8uCI
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: Wed, 14 May 2014 16:39:47 -0000
Hi Lionel, If this works for the WG, that would work for me. I was uneasy with the verb in "When reusing AVPs in a new application, the M-bit flag setting MUST be re-evaluated for a new Diameter application", along with the MUST. Possible answer: "I MUST re-evaluate the M-bit. Yeah, I did evaluate it, and I don't care, but I'm compliant". :-) Regards, Benoit > Hi Benoit, > > Would you be happy with the following rewording? > > OLD: > > 4.4.1. Setting of the AVP Flags > > When reusing AVPs in a new application, the M-bit flag setting MUST > be re-evaluated for a new Diameter application and, if necessary, > even for every command within the application. In general, for AVPs > defined outside of the Diameter base protocol, the characteristics of > an AVP are tied to its role within a given application and the > commands used in this application. > > All other AVP flags (V-bit, P-bit, reserved bits) MUST remain > unchanged. > > NEW: > > 4.4.1. Setting of the AVP Flags > > When reusing existing AVPs in a new application, application designers > MUST specify the setting of the M-bit flag for a new Diameter application > and, if necessary, even for every command within the application. > In general, for AVPs defined outside of the Diameter base protocol, the > characteristics of an AVP are tied to its role within a given application > and the commands used in this application. > > All other AVP flags (V-bit, P-bit, reserved bits) MUST remain > unchanged. > > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Envoyé : mardi 13 mai 2014 16:30 > À : MORAND Lionel IMT/OLN; Benoit Claise; 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 > > > I think the change Lionel made is a good one. Diameter allows us, even > if not too much recommended, to change M-bits for existing AVP per > application. Emphasizing the "sanity check" is a good practise imho. > > - Jouni > > 5/13/2014 9:27 AM, lionel.morand@orange.com kirjoitti: >> 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. >> >> >> 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. >> >> >> >> _______________________________________________ >> DiME mailing list >> 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. > > . >
- [Dime] AD review draft-ietf-dime-app-design-guide Benoit Claise
- [Dime] Diameter Guidelines as BCP? (was: AD revie… lionel.morand
- Re: [Dime] AD review draft-ietf-dime-app-design-g… lionel.morand
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise
- Re: [Dime] Diameter Guidelines as BCP? Benoit Claise
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Heather Flanagan (RFC Series Editor)
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Jouni
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise
- Re: [Dime] AD review draft-ietf-dime-app-design-g… lionel.morand
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Jouni Korhonen
- Re: [Dime] AD review draft-ietf-dime-app-design-g… lionel.morand
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise
- Re: [Dime] AD review draft-ietf-dime-app-design-g… Benoit Claise