From nobody Tue Jun 2 03:01:02 2015 Return-Path: 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 678361B2A3D; Tue, 2 Jun 2015 03:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 c9WEZ368yPGM; Tue, 2 Jun 2015 03:00:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CF41B2A0F; Tue, 2 Jun 2015 03:00:59 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id E736D1B82D4; Tue, 2 Jun 2015 12:00:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id A51A6180076; Tue, 2 Jun 2015 12:00:57 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Tue, 2 Jun 2015 12:00:57 +0200 From: To: "dime@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-dime-4over6-provisioning-00 Thread-Index: AdBtKy1XVNGa27alSqquHaQEoRv65wbdpW+wBR3oRqA= Date: Tue, 2 Jun 2015 10:00:56 +0000 Message-ID: <10443_1433239257_556D7ED9_10443_8032_1_6B7134B31289DC4FAF731D844122B36E01C3FAE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <10824_1427968607_551D125F_10824_867_1_6B7134B31289DC4FAF731D844122B36EF26487@PEXCVZYM13.corporate.adroot.infra.ftgroup> <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> In-Reply-To: <10543_1430988500_554B26D4_10543_477_1_417b420d-d78f-40e0-a1d6-a790092b32ec@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.90316 Archived-At: Cc: "dime-chairs@ietf.org" Subject: Re: [Dime] Start of WGLC for draft-ietf-dime-4over6-provisioning-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 10:01:01 -0000 Hi, After additional reviews, the chairs conclude that there is a WG consensus = on this document. Next Step:=20 - new version of the draft (-02) to take into comments raised after the WGL= C review. - Document shepherd assignment/Write-up - IESG Submission Regards, Lionel & Jouni -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Envoy=E9=A0: jeudi 7 mai 2015 10:48 =C0=A0: MORAND Lionel IMT/OLN; dime@ietf.org Cc=A0: dime-chairs@ietf.org Objet=A0: RE: Start of WGLC for draft-ietf-dime-4over6-provisioning-00=20 Hi, Except from the chairs and authors, we would need additional reviews to ass= ess that there is a WG consensus on its content and be able to move it forw= ard. The document is short and a feedback like "I read it and I support this doc= ument" would be enough. So please, review the document. For info, a minor updated version is available: http://tools.ietf.org/html/= draft-ietf-dime-4over6-provisioning-01 Regards, Lionel=20 -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Envoy=E9= =A0: jeudi 2 avril 2015 11:57 =C0=A0: dime@ietf.org Cc=A0: dime-chairs@ietf= .org Objet=A0: Start of WGLC for draft-ietf-dime-4over6-provisioning-00=20 During the Dime session at IETF92, it was conclude that the draft-ietf-dime= -4over6-provisioning-00 was stable enough to launch a Working Group Last Ca= ll. This email officially starts a Working Group Last Call for the following do= cument: http://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-00 Please respond to this email to support the document and/or send comments b= y 2015-04-16. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: * Are you personally aware of any IPR that applies to draft-ietf-dime-4over= 6-provisioning-00? If so, has this IPR been disclosed in compliance with IE= TF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) * If you are a document author or listed contributor on this document, plea= se reply to this email message regardless of whether or not you are persona= lly aware of any relevant IPR. We might not be able to advance this docume= nt to the next stage until we have received a reply from each author and li= sted contributor. * If you are on the DIME WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Tue Jun 2 03:59:24 2015 Return-Path: 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 A017B1A92E5 for ; Tue, 2 Jun 2015 03:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 P5wIIAirOuyM for ; Tue, 2 Jun 2015 03:59:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5931A92E2 for ; Tue, 2 Jun 2015 03:59:20 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 2A42019006F; Tue, 2 Jun 2015 12:59:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 0A22AC8058; Tue, 2 Jun 2015 12:59:16 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0235.001; Tue, 2 Jun 2015 12:59:15 +0200 From: To: "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Thread-Topic: draft-ietf-dime-ovli-08 Thread-Index: AdCS/04/LnvBNll7TbWAQdOnvL3vRwEzamIAABAz8NAAAA9T4AFER6QA Date: Tue, 2 Jun 2015 10:59:15 +0000 Message-ID: <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.100615 Archived-At: Subject: Re: [Dime] draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 10:59:22 -0000 Hi Ulrich, Steve, Ok in the principle. But we will have to work on the wording as there is no= thing about M-bit setting in this section and here we will have to make a s= tatement on the setting of the M-bit for OC related AVPs in the response wh= ereas there is nothing about the setting in the request and a general state= ment in sec. 7.8 saying: "As described in the Diameter base protocol [RFC6= 733], the M-bit usage for a given AVP in a given command may be defined by = the application." Regards, Lionel=20=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9=A0: mercredi 27 mai 2015 01:50 =C0=A0: dime@ietf.org Objet=A0: [Dime] FW: draft-ietf-dime-ovli-08 Dear all, please see below. Is there any objection to allow reporting nodes (while in overload) to unco= nditionally include OC specific AVPs with M-bit cleared to answer messages = even when the corresponding request did not indicate support of DOIC? Best regards Ulrich -----Original Message----- From: Wiehe, Ulrich (Nokia - DE/Munich) Sent: Wednesday, May 27, 2015 1:45 AM To: 'ext Steve Donovan' Subject: RE: draft-ietf-dime-ovli-08 Thank you Steve, I shall forward the question to the DIME list to see whether there are obje= ctions. Regards Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, May 26, 2015 8:00 PM To: Wiehe, Ulrich (Nokia - DE/Munich) Subject: Re: draft-ietf-dime-ovli-08 Ulrich, If I remember correctly the MUST NOT was inserted based on your input.=20= =20 I think it was related to constraining the number of OC-S-F AVPs received b= y reacting nodes. I don't have any objection to changing it if the rest of the DIME list agre= es. Steve On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > > > draft-ietf-dime-ovli-08.txt says in clause 5.1.2: > > A reporting node MUST NOT include the OC-Supported-Features AVP, OC- > OLR AVP or any other overload control AVPs defined in extension > drafts in response messages for transactions where the request > message does not include the OC-Supported-Features AVP. > > This requirement seems to be too strict. > Would it not be enough to demand not including OC-specific AVPs with M-bi= t set and allow including OC-specific AVPs with M-bit cleared? > > The reporting node, when in overload, may want to check only application = ID and Command Code before deciding that a negative response is returned. I= n this case parsing the complete message to detect presence of the OC-Suppo= rted-Features AVP unnecessarily consumes resources and an unconditional inc= lusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be a= cceptable. > > What do you think? > > Regards > Ulrich > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Tue Jun 2 04:57:09 2015 Return-Path: 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 6D31D1B2D75; Tue, 2 Jun 2015 04:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2GB4tF91MkV3; Tue, 2 Jun 2015 04:57:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0013D1B2D6F; Tue, 2 Jun 2015 04:57:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602115705.25805.36723.idtracker@ietfa.amsl.com> Date: Tue, 02 Jun 2015 04:57:05 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 11:57:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Authors : Cathy Zhou T. Taylor Qiong Sun M. Boucadair Filename : draft-ietf-dime-4over6-provisioning-02.txt Pages : 19 Date : 2015-06-02 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-4over6-provisioning-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 2 06:27:24 2015 Return-Path: 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 25A8D1A890A for ; Tue, 2 Jun 2015 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 c3maAaRKu9qF for ; Tue, 2 Jun 2015 06:27:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D39C1A898D for ; Tue, 2 Jun 2015 06:27:16 -0700 (PDT) Received: from BN3PR0501MB1569.namprd05.prod.outlook.com (25.161.217.147) by BN3PR0501MB1586.namprd05.prod.outlook.com (25.161.217.151) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 2 Jun 2015 13:27:14 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com (25.161.217.15) by BN3PR0501MB1569.namprd05.prod.outlook.com (25.161.217.147) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 2 Jun 2015 13:27:13 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) by BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) with mapi id 15.01.0172.012; Tue, 2 Jun 2015 13:27:13 +0000 From: Jens Schendel To: "lionel.morand@orange.com" , "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Thread-Topic: draft-ietf-dime-ovli-08 Thread-Index: AdCS/04/LnvBNll7TbWAQdOnvL3vRwEzamIAABAz8NAAAA9T4AFER6QAAAVwx1A= Date: Tue, 2 Jun 2015 13:27:13 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jens.schendel@redknee.com; x-originating-ip: [213.61.69.201] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1569; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1586; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN3PR0501MB1569; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1569; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(479174004)(24454002)(76104003)(55784002)(189002)(53754006)(51704005)(199003)(40100003)(62966003)(101416001)(5890100001)(2501003)(92566002)(122556002)(15975445007)(77156002)(68736005)(102836002)(2950100001)(2900100001)(66066001)(189998001)(230783001)(64706001)(76176999)(50986999)(54356999)(76576001)(107886002)(5001960100002)(106356001)(19580405001)(19580395003)(99286002)(5001770100001)(105586002)(5001830100001)(5001860100001)(4001540100001)(81156007)(97736004)(74316001)(87936001)(2656002)(5002640100001)(46102003)(33656002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1569; H:BN3PR0501MB1572.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: redknee.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2015 13:27:13.4653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c452882-d89d-4c15-bdff-49dbef6eddcf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1569 X-OriginatorOrg: redknee.com Archived-At: Subject: Re: [Dime] draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:27:23 -0000 Hi all, sorry for jumping in here. But I have been wondering why M-Bit usage is not= specified in that I-D. "... may be defined by the application." is not a s= afe statement: it either MUST be defined or it may be re-defined.=20 In general I would even think the default should be that M-Bit MUST NOT be = set in the table. As I understood that if the answering node did not imple= ment DOIC (maybe because of pending node upgrade or because the application= definition specified DOIC as optional feature), it should not be forced to= reject any request message with OC-Supported-features. Jens -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Dienstag, 2. Juni 2015 12:59 To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-ovli-08 Hi Ulrich, Steve, Ok in the principle. But we will have to work on the wording as there is no= thing about M-bit setting in this section and here we will have to make a s= tatement on the setting of the M-bit for OC related AVPs in the response wh= ereas there is nothing about the setting in the request and a general state= ment in sec. 7.8 saying: "As described in the Diameter base protocol [RFC6= 733], the M-bit usage for a given AVP in a given command may be defined by = the application." Regards, Lionel =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9=A0: mercredi 27 mai 2015 01:50 =C0=A0: dime@ietf.o= rg Objet=A0: [Dime] FW: draft-ietf-dime-ovli-08 Dear all, please see below. Is there any objection to allow reporting nodes (while in overload) to unco= nditionally include OC specific AVPs with M-bit cleared to answer messages = even when the corresponding request did not indicate support of DOIC? Best regards Ulrich -----Original Message----- From: Wiehe, Ulrich (Nokia - DE/Munich) Sent: Wednesday, May 27, 2015 1:45 AM To: 'ext Steve Donovan' Subject: RE: draft-ietf-dime-ovli-08 Thank you Steve, I shall forward the question to the DIME list to see whether there are obje= ctions. Regards Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, May 26, 2015 8:00 PM To: Wiehe, Ulrich (Nokia - DE/Munich) Subject: Re: draft-ietf-dime-ovli-08 Ulrich, If I remember correctly the MUST NOT was inserted based on your input. =20 I think it was related to constraining the number of OC-S-F AVPs received b= y reacting nodes. I don't have any objection to changing it if the rest of the DIME list agre= es. Steve On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: > Hi Steve, > > > draft-ietf-dime-ovli-08.txt says in clause 5.1.2: > > A reporting node MUST NOT include the OC-Supported-Features AVP, OC- > OLR AVP or any other overload control AVPs defined in extension > drafts in response messages for transactions where the request > message does not include the OC-Supported-Features AVP. > > This requirement seems to be too strict. > Would it not be enough to demand not including OC-specific AVPs with M-bi= t set and allow including OC-specific AVPs with M-bit cleared? > > The reporting node, when in overload, may want to check only application = ID and Command Code before deciding that a negative response is returned. I= n this case parsing the complete message to detect presence of the OC-Suppo= rted-Features AVP unnecessarily consumes resources and an unconditional inc= lusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be a= cceptable. > > What do you think? > > Regards > Ulrich > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te 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 From nobody Wed Jun 3 05:15:59 2015 Return-Path: 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 B298B1A7026 for ; Wed, 3 Jun 2015 05:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Uz68tZxnysOE for ; Wed, 3 Jun 2015 05:15:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12F41A7023 for ; Wed, 3 Jun 2015 05:15:55 -0700 (PDT) Received: from BN3PR0501MB1572.namprd05.prod.outlook.com (25.161.217.15) by BN3PR0501MB1571.namprd05.prod.outlook.com (25.161.217.149) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 12:15:53 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) by BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) with mapi id 15.01.0172.012; Wed, 3 Jun 2015 12:15:53 +0000 From: Jens Schendel To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-ovli-08 - minor comment Thread-Index: AdCd9wgKQ6gZQu2iQmecsxmPjwXDBg== Date: Wed, 3 Jun 2015 12:15:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jens.schendel@redknee.com; x-originating-ip: [213.61.69.201] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1571; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN3PR0501MB1571; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1571; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(53754006)(189002)(106356001)(64706001)(66066001)(74316001)(15975445007)(105586002)(2656002)(77156002)(62966003)(87936001)(2351001)(99286002)(16236675004)(46102003)(450100001)(92566002)(229853001)(40100003)(102836002)(122556002)(68736005)(50986999)(33656002)(19625215002)(97736004)(86362001)(101416001)(54356999)(5001860100001)(2501003)(5001830100001)(230783001)(19300405004)(107886002)(110136002)(5001920100001)(189998001)(5002640100001)(4001540100001)(2900100001)(19580395003)(5001960100002)(76576001)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1571; H:BN3PR0501MB1572.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: redknee.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB157279DC086B15526E5AF8A4E1B40BN3PR0501MB1572_" MIME-Version: 1.0 X-OriginatorOrg: redknee.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2015 12:15:53.3764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c452882-d89d-4c15-bdff-49dbef6eddcf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1571 Archived-At: Subject: [Dime] draft-ietf-dime-ovli-08 - minor comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 12:15:57 -0000 --_000_BN3PR0501MB157279DC086B15526E5AF8A4E1B40BN3PR0501MB1572_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, just a minor comment on the I-D: 7.7. OC-Reduction-Percentage AVP ... The value of 100 means that all traffic is to be throttled, i.e. the reporting node is under a severe load and ceases to process any new messages. I guess should read ... The value of 100 means that all traffic is to be throttled or diverted, i.e. the repo= rting node is under a severe load and ceases to process any new messages. As I understood that the abatement treatment is under responsibility of the= reacting node and 100% has no special meaning in that regard, right? Jens --_000_BN3PR0501MB157279DC086B15526E5AF8A4E1B40BN3PR0501MB1572_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

just a minor comment on the I-D:

 

7.7.  OC-Reduction-Percentage AVP

 

        ...  The value of=

=    100 means that all traffic is to be throttled, i.e. the report= ing

=    node is under a severe load and ceases to process any new mess= ages.

 

I guess should read

 

=    ...  The value of

=    100 means that all traffic is to be throttled or diverted, i.e= . the reporting

=    node is under a severe load and ceases to process any new mess= ages.

 

As I understood that the abatement treatment is unde= r responsibility of the reacting node and 100% has no special meaning in th= at regard, right?

 

Jens

--_000_BN3PR0501MB157279DC086B15526E5AF8A4E1B40BN3PR0501MB1572_-- From nobody Wed Jun 3 05:53:19 2015 Return-Path: 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 4FD091A87E8 for ; Wed, 3 Jun 2015 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 jsgAz1V3F4v2 for ; Wed, 3 Jun 2015 05:53:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD681A87EB for ; Wed, 3 Jun 2015 05:53:15 -0700 (PDT) Received: from BN3PR0501MB1572.namprd05.prod.outlook.com (25.161.217.15) by BN3PR0501MB1572.namprd05.prod.outlook.com (25.161.217.15) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 12:52:58 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) by BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) with mapi id 15.01.0172.012; Wed, 3 Jun 2015 12:52:58 +0000 From: Jens Schendel To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-ovli-08 - Result-Code Handling Thread-Index: AdCd9zYFQVgwNbWFQ4GG5+tEs8kGtg== Date: Wed, 3 Jun 2015 12:52:58 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jens.schendel@redknee.com; x-originating-ip: [213.61.69.201] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1572; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN3PR0501MB1572; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1572; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(53754006)(102836002)(99286002)(107886002)(68736005)(81156007)(62966003)(2351001)(229853001)(66066001)(5001860100001)(105586002)(5001960100002)(33656002)(92566002)(15975445007)(19300405004)(77156002)(16236675004)(5002640100001)(230783001)(74316001)(189998001)(97736004)(2501003)(2656002)(101416001)(87936001)(86362001)(19580395003)(106356001)(4001540100001)(450100001)(50986999)(5001830100001)(19625215002)(122556002)(54356999)(64706001)(46102003)(2900100001)(40100003)(110136002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1572; H:BN3PR0501MB1572.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: redknee.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB1572957318743C17138A5D5EE1B40BN3PR0501MB1572_" MIME-Version: 1.0 X-OriginatorOrg: redknee.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2015 12:52:58.1552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c452882-d89d-4c15-bdff-49dbef6eddcf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1572 Archived-At: Subject: [Dime] draft-ietf-dime-ovli-08 - Result-Code Handling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 12:53:18 -0000 --_000_BN3PR0501MB1572957318743C17138A5D5EE1B40BN3PR0501MB1572_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have some questions on section "8. Error Response Codes". As specified beforehand, reacting nodes are responsible for determining whi= ch treatment is appropriate for individual requests (diversion or throttli= ng). In the section the error handling for DIAMETER_TOO_BUSY and DIAMETER_UNABLE= _TO_COMPLY is described (basically according to Diameter Base) - rather fro= m reporting node point of view. So it may be that according to local policy= the reacting node treats to-be-abated messages with throttling per default= whereas it may happen that the reporting node in overload condition sets u= p error response code DIAMETER_TOO_BUSY for received requests which eventu= ally should lead to retry handling ("diversion"). This would result in inco= nsistent treatment for let's say "early" and "late" overload treated reques= ts. Is this acceptable? And another question: Is the mandatory reflection of OC-Supported-Features = by the reporting node still valid for (this) error scenarios? Or in other = words, is the reacting node also expected to handle OC-OLR in such error an= swers (I would doubt at least for 3xxx protocol errors because sender is no= t expected to conform standard answer message ABNF - but then there might b= e also inconsistent processing on reacting node side)? Jens --_000_BN3PR0501MB1572957318743C17138A5D5EE1B40BN3PR0501MB1572_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have some questions on section “8.  Err= or Response Codes”.

 

As specified beforehand, reacting nodes are responsi= ble for determining which  treatment is appropriate for individual req= uests (diversion or throttling).

In the section the error handling for DIAMETER_TOO_B= USY and DIAMETER_UNABLE_TO_COMPLY is described (basically according to Diam= eter Base) – rather from reporting node point of view. So it may be t= hat according to local policy the reacting node treats to-be-abated messages with throttling per default whereas it m= ay happen that the reporting node in overload condition sets up error respo= nse code  DIAMETER_TOO_BUSY for received requests which eventually sho= uld lead to retry handling (“diversion”). This would result in inconsistent treatment for let’s say “ear= ly” and “late” overload treated requests. Is this accepta= ble?

 

And another question: Is the mandatory reflection of= OC-Supported-Features by the reporting  node still valid for (this) e= rror scenarios? Or in other words, is the reacting node also expected to ha= ndle OC-OLR in such error answers (I would doubt at least for 3xxx protocol errors because sender is not expected to = conform standard answer message ABNF – but then there might be also i= nconsistent processing on reacting  node side)?

 

Jens

--_000_BN3PR0501MB1572957318743C17138A5D5EE1B40BN3PR0501MB1572_-- From nobody Mon Jun 8 05:38:59 2015 Return-Path: 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 1CD9E1A6F07; Mon, 8 Jun 2015 05:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 S4HkpQcCVL-B; Mon, 8 Jun 2015 05:38:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAD01A6F04; Mon, 8 Jun 2015 05:38:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608123856.12743.47035.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 05:38:56 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:38:58 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: This isn't clear enough that you're talking about using Diameter to help manage networks in which ECN may be used, as opposed to dealing with Diameter packets with the ECN bit set. While that may be obvious when one reads the text, some people will only see the abstract so I'd say maybe consider clarifying that here too. - intro: "the document" in 1st sentence is ambiguous - do you mean 3168 or this document? I assume s/the/this/ would be better. - intro: 2nd last para: what is an "ECN application"? Maybe you mean "networks deploying/using ECN" or something? - 3.3: is a 64-bit counter maybe too big for a number of flows? Would it be worth adding guidance to the effect that Diameter nodes ought have some max-believeable-flows setting just to avoid fat-finger or similar errors resulting in someone thinking there are 2^64-1 flows and trying to iterate over that number of things or allocate O(that) much memory? - 3.4: do you need to specify some kind of wrap-around rule for this? What value do I need to use if I've seen 2^64 packets? - 5.2: Please expand CCR on 1st use and provide a reference if one is needed. (Is it "Credit Control Request"?) - 5.2: 2nd last para, last sentence: Thanks! I think it's good that folks are including this consideration in ongoing work. - Section 6: 1st sentence is not needed and is usually a red flag statement (for me, but not only me:-) Actually, you could just lose the first para entirely. (Two more quite nitty things below, but I'll ask anyway:-) - section 6: does this define any new way in which a bad sending Diameter node could cause bad things to happen elsewhre in the network? (see comment above about section 3.3) - section 6: When I took a glance at the security considerations in 5777, it doesn't seem to consider that the "treatment" field could cause bad things to happen. Is that worth mentioning here (if real) even if it ought be more properly handled in some kind of update of 5777 sometime in the (probably far;-) future? From nobody Mon Jun 8 13:57:27 2015 Return-Path: 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 878B11A8A50 for ; Mon, 8 Jun 2015 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 jfoH1fh7_Uy6 for ; Mon, 8 Jun 2015 13:57:25 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034AE1A8A4F for ; Mon, 8 Jun 2015 13:57:24 -0700 (PDT) Received: by qkhq76 with SMTP id q76so84556236qkh.2 for ; Mon, 08 Jun 2015 13:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=d6r9lidSaiCAx/jdPOjsa5GqLzuodUGh7U1zzYom0DE=; b=e4EBYnQdSCjmJGD0LpsOBZezqFGhp4DuuhrG+U+utu7S1nQCsUPtl28EqXqwEzSPi7 Iem8fh3YThPx3FAe4TAcUZ5g+s44q5Q/cV17u7eLHym5NoRrlxtynBm8DWYImWX3/rCz So1HI+rpNYgGM00gUH0drOX+zqG8e31R+x88tG0mbBy4gomUTRRGVVUfn2Wpgku5fGqS eubR0EegTLq4xvPWSVt8EngW/E1YPrJRQKr+ecclgmQmUCtrIwc4ZD7FgQXApEtUb3xY 9qt0jFW/GynG3ThwN3DSLTmYcsRfzVE14AAIc2hshBL3KqNSO64G2phu7dVQH7HrXLnN NOgQ== X-Received: by 10.55.20.204 with SMTP id 73mr36013589qku.5.1433797044236; Mon, 08 Jun 2015 13:57:24 -0700 (PDT) Received: from [10.16.11.141] ([216.31.219.19]) by mx.google.com with ESMTPSA id z189sm1723141qhd.44.2015.06.08.13.57.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 13:57:23 -0700 (PDT) Message-ID: <557601B1.6060804@gmail.com> Date: Mon, 08 Jun 2015 13:57:21 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" , "Lionel.morand@orange.com" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] Agenda requests for IETF#93 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 20:57:26 -0000 Folks, Although Prague is about good beer and fascinating history, we are scheduled for a DIME meeting as well. We have requested for a 2h session. In addition to normal status update on WG I-Ds: draft-ietf-dime-4over6-provisioning draft-ietf-dime-agent-overload draft-ietf-dime-doic-rate-control draft-ietf-dime-e2e-sec-req draft-ietf-dime-group-signaling feel free to ask for agenda slot for your individual I-D. The normal practises apply: have an I-D, have some discussion on the list, indicate the needed time and why you think your I-D needs f2f time. - Jouni & Lionel From nobody Tue Jun 9 06:23:14 2015 Return-Path: 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 464671B2C27; Tue, 9 Jun 2015 06:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9cfK7uoW1TUc; Tue, 9 Jun 2015 06:23:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 210F71B2C24; Tue, 9 Jun 2015 06:23:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609132312.9266.23086.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 06:23:12 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Barry Leiba's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:23:13 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think IANA gets what they need to do, but the RFC Editor will have to replace four different "TBD" with four different values. It'd have been better to use "TBD1", "TBD2", "TBD3", and "TBD4", to make it less likely that something will go amiss. It's probably fine to just say that you need to check it closely during AUTH48, to make sure that the right values got into the right places. From nobody Tue Jun 9 11:55:58 2015 Return-Path: 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 63EE41B2E99; Tue, 9 Jun 2015 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 E1u6ufMhVQyt; Tue, 9 Jun 2015 11:55:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D84311B2E95; Tue, 9 Jun 2015 11:55:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609185554.12514.43910.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 11:55:54 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:55:56 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.) -- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment? "If Excess-Treatment or Congestion-Treatment has occurred..." Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”? --6, first sentence. I’d like to see a little more “show your work" here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs. (I'm probably the other person that Stephen mentioned consider such sentences as a red flag.) Editorial: -- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.) -- 3.2, first paragraph "In case..." I suggest either "If..." or "In the case that..." -- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..." From nobody Tue Jun 9 11:56:19 2015 Return-Path: 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 61E651B2E9E; Tue, 9 Jun 2015 11:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XjhunUfhg6yH; Tue, 9 Jun 2015 11:56:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F41ED1B2E99; Tue, 9 Jun 2015 11:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609185615.7145.32430.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 11:56:15 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:56:17 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This mostly looks good. I have a few comments that are not show stoppers: substantive: -- Abstract: I concur with Stephen that the abstract doesn't really address the heart of the matter. (It also seems longer than needed.) -- 5.2: I don’t see the Congestion-Treatment AVP actually used in the example. At least if it is, it’s not called out. I think it would be helpful to explicitly show it. Also, can you add a reference for Excess-Treatment? "If Excess-Treatment or Congestion-Treatment has occurred..." Does this mean “if the conditions associated with Excess-Treatment or Congestion-Treatment have occurred”, or “Excess-Treatment or Congestion-Treatment have been sent in a Diameter message”? --6, first sentence. I’d like to see a little more “show your work" here. These AVPs carry new kinds of content. That, in itself, might add new security considerations (e.g. is the content privacy-sensitive, especially damaging if tampered with, etc). Please consider adding a few sentences describing the new content, and why you believe that content does or does not have new security considerations. You kind of do that for ECN-IP-Codepoint and Congestion-Treatment, but I don't see anything for the other two new AVPs. (I'm probably the other person that Stephen mentioned consider such sentences as a red flag.) Editorial: -- Abstract: Please expand ECN and AVP on first mention (both in abstract and in body.) -- 3.2, first paragraph "In case..." I suggest either "If..." or "In the case that..." -- 5.1: There are several instances of "ECP-IP-Codepoint" that I assume should be "ECN..." From nobody Tue Jun 9 17:46:41 2015 Return-Path: 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 653E11B2F1C; Tue, 9 Jun 2015 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no 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 rp2tBopa0Id4; Tue, 9 Jun 2015 13:33:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC311B2F0B; Tue, 9 Jun 2015 13:33:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609203351.18194.56243.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 13:33:51 -0700 Archived-At: X-Mailman-Approved-At: Tue, 09 Jun 2015 17:46:40 -0700 Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 20:33:52 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If this means folks are using ECN more then I'm glad to hear it. :) In Section 5.1 there are three instances of "ECP-IP-Codepoint." I think these are meant to be "ECN-IP-Codepoint" right? In Section 6, I had the same thought as Ben. There could be some sensitivity about the fact that a particular user experienced congestion, and that's worth calling out. Comment for the WG: I note that RFC 6733 requires Diameter nodes to be able to negotiate TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA (among other cipher suites) for use with TLS and DTLS. Given the publication of RFC 7465, those requirements should be revisited. From nobody Wed Jun 10 08:34:55 2015 Return-Path: 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 EC26A1A87EF for ; Wed, 10 Jun 2015 08:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 bzlvjaQQP8eV for ; Wed, 10 Jun 2015 08:34:52 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897D01A8710 for ; Wed, 10 Jun 2015 08:34:52 -0700 (PDT) Received: by qkhg32 with SMTP id g32so27078245qkh.0 for ; Wed, 10 Jun 2015 08:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xaIcI+lKLwt5OzgtaFN1nGo17JfCGUJyYHJ/0km+Tk8=; b=HsvA9pm7METp+q2zqnnq0BcsKrIpAEvUIbXZbH1xFgfDMa3BfGQG6mv6c4KdIL6Nnm 7Rw9gIaHq5nUuxbY0ZaJ9Wq2+uMlfoja8ueOsRaxxay8j+Mqw6OckuzyPGjfTYpNFfzM 0dcKbPih3wUGxxBGHX0K/UYgYfKO5+EiiYQWyV1nLCLC/7FUUkK0NYZDahrXcJmjkwyy 03Rn0/6rv6JoYfIZ2fy4JbcbyrmhSF+xUJoCirYJgMOuh0yRfLDA8sjQygNkzykJNLLB uBKTgOEbKnIXNNwFo+5BiUPGQCAxbuUskpJA1yxJD1awO+Iy1R9NhuXDbBAieLpHOLaA 4dtQ== X-Received: by 10.55.33.209 with SMTP id f78mr7824451qki.38.1433950491853; Wed, 10 Jun 2015 08:34:51 -0700 (PDT) Received: from [10.16.10.44] ([216.31.219.19]) by mx.google.com with ESMTPSA id t91sm4276557qgd.45.2015.06.10.08.34.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 08:34:51 -0700 (PDT) Message-ID: <55785919.9050900@gmail.com> Date: Wed, 10 Jun 2015 08:34:49 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jens Schendel , "lionel.morand@orange.com" , "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" References: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 15:34:55 -0000 OK in pricinple what Ulrich is now reverting ;) Regarding M-bit setting, I think the current text is OK. For existing applications one does not have too much choices than clearing the M-bit. New applications can (and should) always define their M-bit settings for OC-* AVPs. - Jouni Sorry for jumping in late. If I recall correctly the discussion we had back then that 6/2/2015, 6:27 AM, Jens Schendel kirjoitti: > Hi all, > > sorry for jumping in here. But I have been wondering why M-Bit usage is not specified in that I-D. "... may be defined by the application." is not a safe statement: it either MUST be defined or it may be re-defined. > In general I would even think the default should be that M-Bit MUST NOT be set in the table. As I understood that if the answering node did not implement DOIC (maybe because of pending node upgrade or because the application definition specified DOIC as optional feature), it should not be forced to reject any request message with OC-Supported-features. > > Jens > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com > Sent: Dienstag, 2. Juni 2015 12:59 > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-ovli-08 > > Hi Ulrich, Steve, > > Ok in the principle. But we will have to work on the wording as there is nothing about M-bit setting in this section and here we will have to make a statement on the setting of the M-bit for OC related AVPs in the response whereas there is nothing about the setting in the request and a general statement in sec. 7.8 saying: "As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application." > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nokia - DE/Munich) Envoy : mercredi 27 mai 2015 01:50 : dime@ietf.org Objet : [Dime] FW: draft-ietf-dime-ovli-08 > > Dear all, > > please see below. > Is there any objection to allow reporting nodes (while in overload) to unconditionally include OC specific AVPs with M-bit cleared to answer messages even when the corresponding request did not indicate support of DOIC? > > Best regards > Ulrich > > -----Original Message----- > From: Wiehe, Ulrich (Nokia - DE/Munich) > Sent: Wednesday, May 27, 2015 1:45 AM > To: 'ext Steve Donovan' > Subject: RE: draft-ietf-dime-ovli-08 > > Thank you Steve, > > I shall forward the question to the DIME list to see whether there are objections. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, May 26, 2015 8:00 PM > To: Wiehe, Ulrich (Nokia - DE/Munich) > Subject: Re: draft-ietf-dime-ovli-08 > > Ulrich, > > If I remember correctly the MUST NOT was inserted based on your input. > I think it was related to constraining the number of OC-S-F AVPs received by reacting nodes. > > I don't have any objection to changing it if the rest of the DIME list agrees. > > Steve > > On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> >> >> draft-ietf-dime-ovli-08.txt says in clause 5.1.2: >> >> A reporting node MUST NOT include the OC-Supported-Features AVP, OC- >> OLR AVP or any other overload control AVPs defined in extension >> drafts in response messages for transactions where the request >> message does not include the OC-Supported-Features AVP. >> >> This requirement seems to be too strict. >> Would it not be enough to demand not including OC-specific AVPs with M-bit set and allow including OC-specific AVPs with M-bit cleared? >> >> The reporting node, when in overload, may want to check only application ID and Command Code before deciding that a negative response is returned. In this case parsing the complete message to detect presence of the OC-Supported-Features AVP unnecessarily consumes resources and an unconditional inclusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be acceptable. >> >> What do you think? >> >> Regards >> Ulrich >> > > _______________________________________________ > 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 mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jun 10 11:19:23 2015 Return-Path: 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 A32851B2D8E for ; Wed, 10 Jun 2015 11:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 wAAKxSpE_OuJ for ; Wed, 10 Jun 2015 11:19:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861791ABC10 for ; Wed, 10 Jun 2015 11:19:18 -0700 (PDT) Received: from BN3PR0501MB1571.namprd05.prod.outlook.com (25.161.217.149) by BN3PR0501MB1554.namprd05.prod.outlook.com (25.161.217.144) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 18:19:03 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com (25.161.217.15) by BN3PR0501MB1571.namprd05.prod.outlook.com (25.161.217.149) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 18:19:02 +0000 Received: from BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) by BN3PR0501MB1572.namprd05.prod.outlook.com ([25.161.217.15]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 18:19:02 +0000 From: Jens Schendel To: Jouni Korhonen , "lionel.morand@orange.com" , "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-ovli-08 Thread-Index: AdCS/04/LnvBNll7TbWAQdOnvL3vRwEzamIAABAz8NAAAA9T4AFER6QAAAVwx1ABl4V+gAAEZGzw Date: Wed, 10 Jun 2015 18:19:01 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55785919.9050900@gmail.com> In-Reply-To: <55785919.9050900@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jens.schendel@redknee.com; x-originating-ip: [77.6.251.233] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1571; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1554; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN3PR0501MB1571; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1571; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(76104003)(24454002)(55784002)(53754006)(51704005)(377454003)(13464003)(479174004)(68736005)(99286002)(102836002)(54356999)(87936001)(106356001)(93886004)(2656002)(77156002)(50986999)(76176999)(66066001)(76576001)(15975445007)(86362001)(5001960100002)(5001920100001)(5890100001)(189998001)(107886002)(19580405001)(74316001)(19580395003)(46102003)(92566002)(122556002)(97736004)(2950100001)(5002640100001)(2900100001)(230783001)(81156007)(33656002)(5001770100001)(2501003)(62966003)(40100003)(5003600100002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1571; H:BN3PR0501MB1572.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: redknee.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 18:19:01.5122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c452882-d89d-4c15-bdff-49dbef6eddcf X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1571 X-OriginatorOrg: redknee.com Archived-At: Subject: Re: [Dime] draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 18:19:21 -0000 Hi Jouni, yes, it is obvious that existing application should let M-Bit unset. I just= was thinking about a scenario where e.g. 3GPP specifies the DOIC for a par= ticular interface in a specific release (e.g. Release 13). The operator has= a lower interface release reference (e.g. 11) but wants to introduce DOIC.= If the DOIC specification already stated M-Bit as unset - fine. Otherwise = he should not forget to specify this (in particular when in R13 M-Bit would= be set - which I would not hope :-) So, of course you can say the implementer of the specification using DOIC i= s in charge of that. But my experience is that the "safer" a specification = is the better it will prevent issues. Jens -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Mittwoch, 10. Juni 2015 17:35 To: Jens Schendel; lionel.morand@orange.com; Wiehe, Ulrich (Nokia - DE/Muni= ch); dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-ovli-08 OK in pricinple what Ulrich is now reverting ;) Regarding M-bit setting, I think the current text is OK. For existing appli= cations one does not have too much choices than clearing the M-bit.=20 New applications can (and should) always define their M-bit settings for OC-* AVPs. - Jouni Sorry for jumping in late. If I recall correctly the discussion we had back= then that 6/2/2015, 6:27 AM, Jens Schendel kirjoitti: > Hi all, > > sorry for jumping in here. But I have been wondering why M-Bit usage is n= ot specified in that I-D. "... may be defined by the application." is not a= safe statement: it either MUST be defined or it may be re-defined. > In general I would even think the default should be that M-Bit MUST NOT b= e set in the table. As I understood that if the answering node did not imp= lement DOIC (maybe because of pending node upgrade or because the applicati= on definition specified DOIC as optional feature), it should not be forced = to reject any request message with OC-Supported-features. > > Jens > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran= ge.com > Sent: Dienstag, 2. Juni 2015 12:59 > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-ovli-08 > > Hi Ulrich, Steve, > > Ok in the principle. But we will have to work on the wording as there is = nothing about M-bit setting in this section and here we will have to make a= statement on the setting of the M-bit for OC related AVPs in the response = whereas there is nothing about the setting in the request and a general sta= tement in sec. 7.8 saying: "As described in the Diameter base protocol [RF= C6733], the M-bit usage for a given AVP in a given command may be defined b= y the application." > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9 : mercredi 27 mai 2015 01:50 =C0 : dime@ietf.org O= bjet : [Dime] FW: draft-ietf-dime-ovli-08 > > Dear all, > > please see below. > Is there any objection to allow reporting nodes (while in overload) to un= conditionally include OC specific AVPs with M-bit cleared to answer message= s even when the corresponding request did not indicate support of DOIC? > > Best regards > Ulrich > > -----Original Message----- > From: Wiehe, Ulrich (Nokia - DE/Munich) > Sent: Wednesday, May 27, 2015 1:45 AM > To: 'ext Steve Donovan' > Subject: RE: draft-ietf-dime-ovli-08 > > Thank you Steve, > > I shall forward the question to the DIME list to see whether there are ob= jections. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, May 26, 2015 8:00 PM > To: Wiehe, Ulrich (Nokia - DE/Munich) > Subject: Re: draft-ietf-dime-ovli-08 > > Ulrich, > > If I remember correctly the MUST NOT was inserted based on your input. > I think it was related to constraining the number of OC-S-F AVPs received= by reacting nodes. > > I don't have any objection to changing it if the rest of the DIME list ag= rees. > > Steve > > On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> >> >> draft-ietf-dime-ovli-08.txt says in clause 5.1.2: >> >> A reporting node MUST NOT include the OC-Supported-Features AVP, OC= - >> OLR AVP or any other overload control AVPs defined in extension >> drafts in response messages for transactions where the request >> message does not include the OC-Supported-Features AVP. >> >> This requirement seems to be too strict. >> Would it not be enough to demand not including OC-specific AVPs with M-b= it set and allow including OC-specific AVPs with M-bit cleared? >> >> The reporting node, when in overload, may want to check only application= ID and Command Code before deciding that a negative response is returned. = In this case parsing the complete message to detect presence of the OC-Supp= orted-Features AVP unnecessarily consumes resources and an unconditional in= clusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be = acceptable. >> >> What do you think? >> >> Regards >> Ulrich >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jun 10 13:35:41 2015 Return-Path: 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 1CDDD1AC529; Wed, 10 Jun 2015 13:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MANGLED_LIST=2.3] autolearn=no 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 Oeb8kXd0RRi4; Wed, 10 Jun 2015 13:35:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFA21AC42B; Wed, 10 Jun 2015 13:35:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610203536.14350.31271.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 13:35:36 -0700 Archived-At: Cc: david.black@emc.com, dime@ietf.org, dime-chairs@ietf.org Subject: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:35:38 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- No general objection to the publication of the document. However, I am relaying a question from David Black as a DISCUSS point. I assume that the draft is more than unclear in Section 3.2 about what traffic means. Is it a particular flow, a single packet, etc? "I found an ECN concern, and hence added the TSV ADs to the CC line. Section 3.2 says: The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and indicates how congested traffic, i.e., traffic that has Explicit Congestion Notification Congestion Experienced marking set or some other administratively defined criteria, is treated. That appears to say that the congestion treatment may be applied solely to packets that have the CE (Congestion Experienced) marking. That would be a problem, because the defined semantics of a CE marking is that it applies to the entire flow (e.g., causes TCP to react as if a packet has been dropped), hence the congestion treatment ought to apply to the entire flow. In other words, one wants to be able to use the ECN-IP-Codepoint AVP as part of the condition that determines whether the filter rule matches, but ignore that AVP (i.e., wildcard it) in determining what traffic the action applies to, so that the response to detecting a congested flow (i.e., packets with ECN field containing CE) applies to all packets in the flow, regardless of the value in the CE field. Otherwise, the result may be ineffective, as it won't encompass packets in the congested flow that aren't CE-marked. Am I reading the draft correctly?" ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1, 1st paragraph: It says "The first AVP provides direct support for ECN [RFC3168] in the IP header“. I am sure that your draft is ot providing any support for ECN in the IP header, as we have ECN in the IP header already, isn't it. I guess you mean something like this "The first AVP provides direct support for filtering ECN marked traffic[RFC3168]“ From nobody Wed Jun 10 15:24:16 2015 Return-Path: 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 72B1C1ACD17 for ; Wed, 10 Jun 2015 15:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nPuBFFza-Trv for ; Wed, 10 Jun 2015 15:24:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAE21A6EDC for ; Wed, 10 Jun 2015 15:24:10 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id B60461B8475; Thu, 11 Jun 2015 00:24:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 94B2838404A; Thu, 11 Jun 2015 00:24:08 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 00:24:08 +0200 From: To: Jens Schendel , Jouni Korhonen , "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Thread-Topic: Re : [Dime] draft-ietf-dime-ovli-08 Thread-Index: AQHQo8wpgq7WsV1rv06jbBUE2rDrug== Date: Wed, 10 Jun 2015 22:24:07 +0000 Message-ID: <29574_1433975048_5578B908_29574_17628_1_6B7134B31289DC4FAF731D844122B36E01C4C1F4@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <5BCBA1FC2B7F0B4C9D935572D90006682289733D@DEMUMBX014.nsn-intra.net> <13236_1433242756_556D8C84_13236_11570_1_6B7134B31289DC4FAF731D844122B36E01C3FB32@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55785919.9050900@gmail.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01C4C1F4OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.10.210316 Archived-At: Subject: Re: [Dime] draft-ietf-dime-ovli-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 22:24:15 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01C4C1F4OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, For an existing 3GPP Application, any new AVP will be added with M-bit not = set, whatever in which release the AVP is introduced. Otherwise it would be= needed to create a new application as per RFC 6733. Now, for a new defined application, it is up to the implementors to decide = whether they want to set M-bit for DOIC AVP.In some scenarios, it may be de= sired that non-supporting nodes reject commands that contain the DOIC AVPs = when not understood. So I think that the current statement in the draft is correct. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "Jens Schendel" Pour : "Jouni Korhonen" , "MORAND Lionel IMT/OLN" <= lionel.morand@orange.com>, "Wiehe, Ulrich (Nokia - DE/Munich)" , "dime@ietf.org" Objet : [Dime] draft-ietf-dime-ovli-08 Date : mer., juin 10, 2015 20:19 Hi Jouni, yes, it is obvious that existing application should let M-Bit unset. I just= was thinking about a scenario where e.g. 3GPP specifies the DOIC for a par= ticular interface in a specific release (e.g. Release 13). The operator has= a lower interface release reference (e.g. 11) but wants to introduce DOIC.= If the DOIC specification already stated M-Bit as unset - fine. Otherwise = he should not forget to specify this (in particular when in R13 M-Bit would= be set - which I would not hope :-) So, of course you can say the implementer of the specification using DOIC i= s in charge of that. But my experience is that the "safer" a specification = is the better it will prevent issues. Jens -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Mittwoch, 10. Juni 2015 17:35 To: Jens Schendel; lionel.morand@orange.com; Wiehe, Ulrich (Nokia - DE/Muni= ch); dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-ovli-08 OK in pricinple what Ulrich is now reverting ;) Regarding M-bit setting, I think the current text is OK. For existing appli= cations one does not have too much choices than clearing the M-bit. New applications can (and should) always define their M-bit settings for OC-* AVPs. - Jouni Sorry for jumping in late. If I recall correctly the discussion we had back= then that 6/2/2015, 6:27 AM, Jens Schendel kirjoitti: > Hi all, > > sorry for jumping in here. But I have been wondering why M-Bit usage is n= ot specified in that I-D. "... may be defined by the application." is not a= safe statement: it either MUST be defined or it may be re-defined. > In general I would even think the default should be that M-Bit MUST NOT b= e set in the table. As I understood that if the answering node did not imp= lement DOIC (maybe because of pending node upgrade or because the applicati= on definition specified DOIC as optional feature), it should not be forced = to reject any request message with OC-Supported-features. > > Jens > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@oran= ge.com > Sent: Dienstag, 2. Juni 2015 12:59 > To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org > Subject: Re: [Dime] draft-ietf-dime-ovli-08 > > Hi Ulrich, Steve, > > Ok in the principle. But we will have to work on the wording as there is = nothing about M-bit setting in this section and here we will have to make a= statement on the setting of the M-bit for OC related AVPs in the response = whereas there is nothing about the setting in the request and a general sta= tement in sec. 7.8 saying: "As described in the Diameter base protocol [RF= C6733], the M-bit usage for a given AVP in a given command may be defined b= y the application." > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (Nok= ia - DE/Munich) Envoy=E9 : mercredi 27 mai 2015 01:50 =C0 : dime@ietf.org O= bjet : [Dime] FW: draft-ietf-dime-ovli-08 > > Dear all, > > please see below. > Is there any objection to allow reporting nodes (while in overload) to un= conditionally include OC specific AVPs with M-bit cleared to answer message= s even when the corresponding request did not indicate support of DOIC? > > Best regards > Ulrich > > -----Original Message----- > From: Wiehe, Ulrich (Nokia - DE/Munich) > Sent: Wednesday, May 27, 2015 1:45 AM > To: 'ext Steve Donovan' > Subject: RE: draft-ietf-dime-ovli-08 > > Thank you Steve, > > I shall forward the question to the DIME list to see whether there are ob= jections. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, May 26, 2015 8:00 PM > To: Wiehe, Ulrich (Nokia - DE/Munich) > Subject: Re: draft-ietf-dime-ovli-08 > > Ulrich, > > If I remember correctly the MUST NOT was inserted based on your input. > I think it was related to constraining the number of OC-S-F AVPs received= by reacting nodes. > > I don't have any objection to changing it if the rest of the DIME list ag= rees. > > Steve > > On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote: >> Hi Steve, >> >> >> draft-ietf-dime-ovli-08.txt says in clause 5.1.2: >> >> A reporting node MUST NOT include the OC-Supported-Features AVP, OC- >> OLR AVP or any other overload control AVPs defined in extension >> drafts in response messages for transactions where the request >> message does not include the OC-Supported-Features AVP. >> >> This requirement seems to be too strict. >> Would it not be enough to demand not including OC-specific AVPs with M-b= it set and allow including OC-specific AVPs with M-bit cleared? >> >> The reporting node, when in overload, may want to check only application= ID and Command Code before deciding that a negative response is returned. = In this case parsing the complete message to detect presence of the OC-Supp= orted-Features AVP unnecessarily consumes resources and an unconditional in= clusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be = acceptable. >> >> What do you think? >> >> Regards >> Ulrich >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez 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 i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E01C4C1F4OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

For an existing 3GPP Application, any new AVP will be added with M-bit= not set, whatever in which release the AVP is introduced. Otherwise it wou= ld be needed to create a new application as per RFC 6733.

Now, for a new defined application, it is up to the implementors to de= cide whether they want to set M-bit for DOIC AVP.In some scenarios, it may = be desired that non-supporting nodes reject commands that contain the DOIC = AVPs when not understood.

So I think that the current statement in the draft is correct.

Regards,

Lionel

Envoy=E9 depuis mon mobile Orange

----- Reply message -----
De : "Jens Schendel" <jens.schendel@redknee.com>
Pour : "Jouni Korhonen" <jouni.nospam@gmail.com>, &quo= t;MORAND Lionel IMT/OLN" <lionel.morand@orange.com>, "Wiehe= , Ulrich (Nokia - DE/Munich)" <ulrich.wiehe@nokia.com>, "di= me@ietf.org" <dime@ietf.org>
Objet : [Dime] draft-ietf-dime-ovli-08
Date : mer., juin 10, 2015 20:19

Hi Jouni,

yes, it is obvious that existing application should let M-Bit unset. I just= was thinking about a scenario where e.g. 3GPP specifies the DOIC for a par= ticular interface in a specific release (e.g. Release 13). The operator has= a lower interface release reference (e.g. 11) but wants to introduce DOIC. If the DOIC specification already s= tated M-Bit as unset - fine. Otherwise he should not forget to specify this= (in particular when in R13 M-Bit would be set - which I would not hope :-)=
So, of course you can say the implementer of the specification using DOIC i= s in charge of that. But my experience is that the "safer" a spec= ification is the better it will prevent issues.

Jens

-----Original Message-----
From: Jouni Korhonen [mailto:joun= i.nospam@gmail.com]
Sent: Mittwoch, 10. Juni 2015 17:35
To: Jens Schendel; lionel.morand@orange.com; Wiehe, Ulrich (Nokia - DE/Muni= ch); dime@ietf.org
Subject: Re: [Dime] draft-ietf-dime-ovli-08

OK in pricinple what Ulrich is now reverting ;)

Regarding M-bit setting, I think the current text is OK. For existing appli= cations one does not have too much choices than clearing the M-bit.
New applications can (and should) always define their M-bit settings for
OC-* AVPs.

- Jouni


Sorry for jumping in late. If I recall correctly the discussion we had back= then that


6/2/2015, 6:27 AM, Jens Schendel kirjoitti:
> Hi all,
>
> sorry for jumping in here. But I have been wondering why M-Bit usage i= s not specified in that I-D. "... may be defined by the application.&q= uot; is not a safe statement: it either MUST be defined or it may be re-def= ined.
> In general I would even think the default should be that M-Bit MUST NO= T be set in the table. As I understood that  if the answering node did= not implement DOIC (maybe because of pending node upgrade or because the a= pplication definition specified DOIC as optional feature), it should not be forced to reject any request message w= ith OC-Supported-features.
>
> Jens
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounc= es@ietf.org] On Behalf Of lionel.morand@orange.com
> Sent: Dienstag, 2. Juni 2015 12:59
> To: Wiehe, Ulrich (Nokia - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] draft-ietf-dime-ovli-08
>
> Hi Ulrich, Steve,
>
> Ok in the principle. But we will have to work on the wording as there = is nothing about M-bit setting in this section and here we will have to mak= e a statement on the setting of the M-bit for OC related AVPs in the respon= se whereas there is nothing about the setting in the request and a general statement in sec. 7.8 saying:  &= quot;As described in the Diameter base protocol [RFC6733], the M-bit usage = for a given AVP in a given command may be defined by the application."=
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounce= s@ietf.org] De la part de Wiehe, Ulrich (Nokia - DE/Munich) Envoy=E9 : = mercredi 27 mai 2015 01:50 =C0 : dime@ietf.org Objet : [Dime] FW: draft-iet= f-dime-ovli-08
>
> Dear all,
>
> please see below.
> Is there any objection to allow reporting nodes (while in overload) to= unconditionally include OC specific AVPs with M-bit cleared to answer mess= ages even when the corresponding request did not indicate support of DOIC?<= br> >
> Best regards
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (Nokia - DE/Munich)
> Sent: Wednesday, May 27, 2015 1:45 AM
> To: 'ext Steve Donovan'
> Subject: RE: draft-ietf-dime-ovli-08
>
> Thank you Steve,
>
> I shall forward the question to the DIME list to see whether there are= objections.
>
> Regards
> Ulrich
>
> -----Original Message-----
> From: ext Steve Donovan [m= ailto:srdonovan@usdonovans.com]
> Sent: Tuesday, May 26, 2015 8:00 PM
> To: Wiehe, Ulrich (Nokia - DE/Munich)
> Subject: Re: draft-ietf-dime-ovli-08
>
> Ulrich,
>
> If I remember correctly the MUST NOT was inserted based on your input.=
> I think it was related to constraining the number of OC-S-F AVPs recei= ved by reacting nodes.
>
> I don't have any objection to changing it if the rest of the DIME list= agrees.
>
> Steve
>
> On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote:
>> Hi Steve,
>>
>>
>> draft-ietf-dime-ovli-08.txt says in clause 5.1.2:
>>
>>      A reporting node MUST NOT include th= e OC-Supported-Features AVP, OC-
>>      OLR AVP or any other overload contro= l AVPs defined in extension
>>      drafts in response messages for tran= sactions where the request
>>      message does not include the OC-Supp= orted-Features AVP.
>>
>> This requirement seems to be too strict.
>> Would it not be enough to demand not including OC-specific AVPs wi= th M-bit set and allow including OC-specific AVPs with M-bit cleared?
>>
>> The reporting node, when in overload, may want to check only appli= cation ID and Command Code before deciding that a negative response is retu= rned. In this case parsing the complete message to detect presence of the O= C-Supported-Features AVP unnecessarily consumes resources and an unconditional inclusion of OC-OLR and OC-Support= ed-Features AVPs with M-bit cleared may be acceptable.
>>
>> What do you think?
>>
>> Regards
>> Ulrich
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.iet= f.org/mailman/listinfo/dime
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite= s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez 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 messa= ge a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d 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.iet= f.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.iet= f.org/mailman/listinfo/dime
>
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E01C4C1F4OPEXCLILM43corp_-- From nobody Wed Jun 10 15:36:48 2015 Return-Path: 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 40B3F1B2CE5; Wed, 10 Jun 2015 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IEEfxyjO2ilU; Wed, 10 Jun 2015 15:36:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF451B2CAE; Wed, 10 Jun 2015 15:36:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610223645.2051.99673.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 15:36:45 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org, linda.dunbar@huawei.com Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 22:36:47 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- With some DIAMETER background, I can understand what the document specifies. However, I agree with Martin's COMMENT, and Stephen's abstract-related COMMENT. The document should be improved From nobody Wed Jun 10 21:27:04 2015 Return-Path: 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 B9E7A1A9051; Wed, 10 Jun 2015 21:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 Q46ciCIsU3W0; Wed, 10 Jun 2015 21:27:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D031A904E; Wed, 10 Jun 2015 21:27:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611042701.5448.30289.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 21:27:01 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org Subject: [Dime] Spencer Dawkins' No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 04:27:02 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Martin's Discuss, based on David's Gen-ART review. From nobody Thu Jun 11 15:02:07 2015 Return-Path: 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 E6EF71B31D5; Thu, 11 Jun 2015 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 iW-NU6NsMUXF; Thu, 11 Jun 2015 15:01:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4EA1B31CE; Thu, 11 Jun 2015 15:01:59 -0700 (PDT) Received: from BL2FFO11FD056.protection.gbl (10.173.160.34) by BL2FFO11HUB053.protection.gbl (10.173.161.153) with Microsoft SMTP Server (TLS) id 15.1.190.9; Thu, 11 Jun 2015 22:01:38 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BL2FFO11FD056.mail.protection.outlook.com (10.173.161.184) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Thu, 11 Jun 2015 22:01:38 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5BLfLeb026839; Thu, 11 Jun 2015 17:01:38 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm3.corp.sprint.com with ESMTP id 1uux455tf3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jun 2015 17:01:38 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 11 Jun 2015 17:01:37 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Thu, 11 Jun 2015 17:01:37 -0500 From: "Bertz, Lyle T [CTO]" To: Martin Stiemerling , The IESG Thread-Topic: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AQHQo70F4X8SI5Wk1EqRdOJjKpM6WJ2n1+ZQ Date: Thu, 11 Jun 2015 22:01:36 +0000 Message-ID: <59ce5385352047b9a02ad4db29d4add2@PLSWE13M07.ad.sprint.com> References: <20150610203536.14350.31271.idtracker@ietfa.amsl.com> In-Reply-To: <20150610203536.14350.31271.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD056; 1:IjRy5qAzkuzNewr6kHNc6I9YC8Fx86iH4HyBord8FFnLaxAFv1CEbdd6Fem70N6hGVCrDviKsFpO2CzrN4ViX0GU9fXEjHY0AaDGnuEZ4ZfLM9ADZe4sPVCkqNkYLPzGObdaECgrV0qzgiOA3NP9pzdFElQotTqq7c/Q9AJNYnpzCQxS3Slett1++z0siTON+yUmLKae1RFEZFUDUnWcAX+7RHqUIrQeACshfOkIJdGA8zkkDLrYI/zPoxi69+2lkfCgaYW0qgz0z4/sijoZv5vtPyXugaLS5dOeD8MwYGdP5Q/Lwd0q+uOJVQ1JrvG0HzAGp/ye3bwqpJdpfQGoJgWIGsBHJ6b2nfJLguVFPMk= X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(13464003)(199003)(52044002)(377454003)(189002)(230783001)(6806004)(33646002)(106466001)(106116001)(5250100002)(62966003)(77156002)(92566002)(5003600100002)(46102003)(5001960100002)(189998001)(85326001)(108616004)(5001920100001)(19580395003)(2900100001)(2950100001)(102836002)(15975445007)(86362001)(87936001)(47776003)(54356999)(2656002)(5001770100001)(23676002)(50986999)(76176999)(19580405001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB053; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB053; 2:+yF3b0mfNjCqeh+SQgTAALrf2vBgXbdCrMpEibdk2SxI1LekLN9rgc/CyFc1SiUC; 2:yTFsNJP8Ty+wU8sy1nMl0IulXA/sEAP/EzTxUnwb0ba6Pe+YGka/ebQS17/088Im6sf3MgySHlUPbiCmq7s6XuhW0KZcZ7veyqjZ4sfED3cpsgvDRgdeXS4+xX7GDb5JI0OgvOcDDIJ8cUJuTTCSEo3VyXw4QSpICNQYZOt9kqOCTjeKUJQlz8gSczI7dx9JPVpG5mx0xe7zFuHAqAkSyLwUVGg2B81KMAwOAVkBdJdfhwIUdj8o61oJvdiosAL3; 6:SDUVR9FxFHyqtyVYLoQVVhalWoIhaPCa6nO0HGv8teOx7zIGbpeOHZAxPY7THJPz7mjM9zx6ZOuN2AFEWQalf8ip8pT4wYE9bs9k4GFSVL3D+7LP8P4jq3IzKf0q8RHMgNgUpoNCcitBNWMPjfVf36SI3K2I9bh4iWKJHyDFAlSqwEg72nukazShXn90Y15Obh8rwubYHeppOX5dDr/Aq9GqqjCfxJsyZ8Bi2Fccmi8GN8rxU1+oBB/ncu9U5h3P; 3:pdU1fQ5bZyGA1jEoDHXMyjfUiqdO8JeGELw/WrWFXhlpTUqDMNYdY/iva3Hp2gJ7ZK8VBhr88DTdLlGqG3+3VG399Rj4BvFCtUPsr1/MOsqkG8u7NmG2CHwhWARaE68/BKUW19PgW3kwipdKf1qf+lQFC6hQx3K0VONZzk+xvh+rUfuRVMO1qqXWp/GPxfzkugDJoiiTGUSVQmQ5+eHiNBuJNU8+LZxGzCCWqRRDTJSZqXzCaers4zIjrOY8+P03RVyTyUzLcphUhbzISfhp6xGnf+p27oFLFSIe1KWfQX+Yd3X8ijm7hTVwI5a/c8Xc X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BL2FFO11HUB053; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB053; X-Forefront-PRVS: 0604AFA86B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJGRk8xMUhVQjA1Mzs5OnlxU0VhRGhMbmZiUzB3aXRzakc5Z2JLQWJ0?= =?utf-8?B?NUNEK1dTUW5JVGFSQXZSbE1KbDNFaC9pVHpic2J6MTZsV3M2NmhMUml2b0Qz?= =?utf-8?B?cWpIdnRFSGdlWW51YkJ5bmh4Q2xJa2ZsZnhzYmRPTFRIajhCZEZFSTUvVlRK?= =?utf-8?B?S3NKTjhWbVNMZEt1QTJ5MkxFL21lUEZxRWxtcEduUDl4T1NTZThzalJVNG53?= =?utf-8?B?dUJhUGJ1dWl3S09rWmgyd3Y0b2tPQ3VMb0NnNmZ5Z0I4djdqM3dGY2srVkY4?= =?utf-8?B?MStTVU5Yb25yeCtnN2V3Y3dLSUQzVFUzVkJsQ0wrSkdYci90ZC9QNlpZbmp6?= =?utf-8?B?UjF2Q1ROSXFtZm43Zk5VaDJXNWhGN1lISTJDWnNFOXhyZ0t4L2NZaytlR0Ju?= =?utf-8?B?RzRRSmQrNVNpd2tvN3loRCtnT3RPdjdHbnYyeUFTUm9JMGU4a0pUR0xkV1RE?= =?utf-8?B?Vmw3VmNOYkNUcm81VE45S3k1c3ZqSm5tdityWEM4WFNvQllPbmxlN0JCMFVL?= =?utf-8?B?NUlmZmF2TVJuUExoK3U5VXYrRFF6K2xCbnAvMXpncU1tVHVPc25VUEdjN0FK?= =?utf-8?B?akt1cDdmNEdTQWxaRmRFRWV5UlpBWmNEQUp4bVJWcWkwWlQ2YkJnWmJrQlF3?= =?utf-8?B?aXppSElQbUR0dHBvakEvMGVCVlNZTVpZUERXekoxNENwSXZlN3JGOG9nZHM5?= =?utf-8?B?WTUvODMvWnFoZ3hXSWxoQkZZZE1VTjZlNnd6Z2FBY2k5TmFHaStvSURsWStJ?= =?utf-8?B?a29TUGZOQW5idmVOcldjWmxEUHVaQ1RackZzK2xOcGdhc3JGZ240UzFxOEF4?= =?utf-8?B?cTJUajBUNDY5UGNBZWZpclRjTEI4T09SaCtIaXZtUUZ1RTBDSzNaNXB2K1NJ?= =?utf-8?B?dnZZNGYrM1RFdDVtdDI5cGxYd1pMVUlsZkhxVEtaRmljRGoxem5UaitxU3hT?= =?utf-8?B?U1Q3VmpMdVJCdm9neGVBYmVjMGk1U3hGNGhPNzIycUorNG9IakdvL1BIS1JB?= =?utf-8?B?MWtwUjh4VUVKRm1UUDlGTndYSEcwMmtpRktXdUZzTWhZL0ZpT1NpcmFnbjNn?= =?utf-8?B?Um9zSTNwSFBpd1RIZldrdkQ1ejlxcGVyN3V5KzVKZEtFQlhIY042NUpmNENC?= =?utf-8?B?cnpocWp3MVhsNkg2ZS8wT3g5aGxvUDVuQTZCL1drdkpnSnJ4VHA1MVd6UGlR?= =?utf-8?B?cHgvaXgxbmZ2VzZQcUpZOUo0eWRtM2MyM2xNczIyMXNXckU2QjNmL0luUnpT?= =?utf-8?B?M0JpTGlPZy9neFhvNzlyYjlNeFdFOSthbmFWNkhjVStWNzdJS1FvV2VLN082?= =?utf-8?B?MC9rcXVSbmlmeWMwTm9PL3ptNlNyVTRUQnNFaUpiMm9zNjQ0MjFBRTkzT1hl?= =?utf-8?B?OHVHemU4RjhidkJIWUl4MmVxRFVrc1kyWTVjaXpBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB053; 3:8WG1xznhOUTQV82Tx4npc7nFdVAvq1fKxQyEB9AvixNCHOloQpODUjEbjd2joTHcC5Gbk2Eb13YehcGnzVs8l4dBHiwmLWbO0brDg2ozuNowq7Mo3pMyHmTW8iMh5Gmcrow032dfDWktPgE16W725A==; 10:b21Fhg021naqTQrDY5Cdi2/+iVshKUEny96ecRb9j3JvQjeHX/OSAldMFqVvRn2HoHie0n6lzDqzCtWF13hdS27JiM0IQ7hcjckmT/+rL0g= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2015 22:01:38.9348 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB053 Archived-At: Cc: "david.black@emc.com" , "dime@ietf.org" , "dime-chairs@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 22:02:03 -0000 TWFydGluLA0KDQpSZWdhcmRpbmcgdGhlIERJU0NVU1MgcG9pbnQgdGhlIGxhbmd1YWdlIGluIDMu MiBpcyBwcm9ibGVtYXRpYywgd2Ugd2lsbCBjaGFuZ2UNCg0KICAgVGhlIENvbmdlc3Rpb24tVHJl YXRtZW50IEFWUCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQgYW5kDQogICBpbmRp Y2F0ZXMgaG93IGNvbmdlc3RlZCB0cmFmZmljLCBpLmUuLCB0cmFmZmljIHRoYXQgaGFzIEV4cGxp Y2l0DQogICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1h cmtpbmcgc2V0IG9yIHNvbWUNCiAgIG90aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0 ZXJpYSwgaXMgdHJlYXRlZC4NCg0KdG8NCg0KICAgVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFW UCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQuIEl0DQogICBpbmRpY2F0ZXMgaG93 IHRvIHRyZWF0IHRyYWZmaWMgZmxvdyhzKSB3aGVuIGNvbmdlc3Rpb24gaXMgZGV0ZWN0ZWQuDQog ICBUaGUgZGV0ZWN0aW9uIG9mIHRoZSBjb25nZXN0aW9uIGNhbiBiZSBiYXNlZCBvbiB0aGUgcmVj ZXB0aW9uIG9mIElQDQogICBwYWNrZXRzIHBhY2tldCAgd2l0aCAgdGhlIENFIChDb25nZXN0aW9u IEV4cGVyaWVuY2VkKSBjb2RlcG9pbnQgc2V0DQogIChzZWUgW1JGQyAzMTY4XSkgb3IgYnkgYW55 IG90aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0ZXJpYS4NCg0KVGhlIHJhdGlvbmFs ZSBmb3IgdGhlIHdvcmQgJ2Zsb3cocyknIGluIHRoZSBuZXcgbGFuZ3VhZ2UgaXMgdGhlIGxhc3Qg c2VudGVuY2Ugb2YgdGhlIHNlY3Rpb24gIDMuMiAtICAiVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50 IEFWUCBpcyBhbiBhY3Rpb24gYW5kIE1VU1QgYmUgIGFuIGF0dHJpYnV0ZSBvZiB0aGUgRmlsdGVy LVJ1bGUgR3JvdXBlZCBBVlAgYXMgZGVmaW5lZCBpbiBSRkM1Nzc3LiAiICBJdCBpcyBvdGhlciBB VlBzIGluIHRoZSBGaWx0ZXItUnVsZSwgZS5nLiBDbGFzc2lmaWVyLCB0aGF0IGRlc2NyaWJlcyB0 aGUgc2NvcGUgb2YgdHJhZmZpYyBpbXBhY3RlZC4gIFNheWluZyBzb21ldGhpbmcgaW4gU2VjdGlv biAzLjIgdGhhdCBkb2VzIG5vdCBhc3NvY2lhdGUgdGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFW UCB0byB0aGUgRmlsdGVyLVJ1bGUgaXQgaXMgYSBwYXJ0IG9mIG9ubHkgY3JlYXRlcyBjb25mdXNp b24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUGVyIHRoZSBDT01NRU5U LCB5b3UgYXJlIGNvcnJlY3QuICBXZSdsbCBjaGFuZ2UNCg0KIlRoZSBmaXJzdCBBVlAgcHJvdmlk ZXMgZGlyZWN0IHN1cHBvcnQgZm9yIEVDTiBbUkZDMzE2OF0gaW4gdGhlIElQDQogIGhlYWRlcuKA nA0KDQp0byB5b3VyIHN1Z2dlc3Rpb24NCg0KIlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0 IHN1cHBvcnQgZm9yIGZpbHRlcmluZyBFQ04NCiAgbWFya2VkIHRyYWZmaWNbUkZDMzE2OF3igJwN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gU3RpZW1lcmxpbmcNClNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAxMCwgMjAxNSAzOjM2IFBNDQpUbzogVGhlIElFU0cNCkNjOiBkYXZpZC5i bGFja0BlbWMuY29tOyBkaW1lQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVj dDogW0RpbWVdIE1hcnRpbiBTdGllbWVybGluZydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaW1l LWNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KDQpNYXJ0aW4gU3RpZW1lcmxpbmcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWRpbWUtY29uZ2VzdGlvbi1mbG93LWF0dHJpYnV0ZXMt MDE6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBw YXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1l LWNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VT UzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KTm8gZ2VuZXJhbCBvYmplY3Rpb24gdG8gdGhlIHB1YmxpY2F0 aW9uIG9mIHRoZSBkb2N1bWVudC4gSG93ZXZlciwgSSBhbSByZWxheWluZyBhIHF1ZXN0aW9uIGZy b20gRGF2aWQgQmxhY2sgYXMgYSBESVNDVVNTIHBvaW50Lg0KDQpJIGFzc3VtZSB0aGF0IHRoZSBk cmFmdCBpcyBtb3JlIHRoYW4gdW5jbGVhciBpbiBTZWN0aW9uIDMuMiAgYWJvdXQgd2hhdCB0cmFm ZmljIG1lYW5zLiBJcyBpdCBhIHBhcnRpY3VsYXIgZmxvdywgYSBzaW5nbGUgcGFja2V0LCBldGM/ DQoNCiJJIGZvdW5kIGFuIEVDTiBjb25jZXJuLCBhbmQgaGVuY2UgYWRkZWQgdGhlIFRTViBBRHMg dG8gdGhlIENDIGxpbmUuDQoNClNlY3Rpb24gMy4yIHNheXM6DQoNCiAgIFRoZSBDb25nZXN0aW9u LVRyZWF0bWVudCBBVlAgKEFWUCBDb2RlIFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkIGFuZA0KICAg aW5kaWNhdGVzIGhvdyBjb25nZXN0ZWQgdHJhZmZpYywgaS5lLiwgdHJhZmZpYyB0aGF0IGhhcyBF eHBsaWNpdA0KICAgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gQ29uZ2VzdGlvbiBFeHBlcmllbmNl ZCBtYXJraW5nIHNldCBvciBzb21lDQogICBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQg Y3JpdGVyaWEsIGlzIHRyZWF0ZWQuDQoNClRoYXQgYXBwZWFycyB0byBzYXkgdGhhdCB0aGUgY29u Z2VzdGlvbiB0cmVhdG1lbnQgbWF5IGJlIGFwcGxpZWQgc29sZWx5IHRvIHBhY2tldHMgdGhhdCBo YXZlIHRoZSBDRSAoQ29uZ2VzdGlvbiBFeHBlcmllbmNlZCkgbWFya2luZy4NClRoYXQgd291bGQg YmUgYSBwcm9ibGVtLCBiZWNhdXNlIHRoZSBkZWZpbmVkIHNlbWFudGljcyBvZiBhIENFIG1hcmtp bmcgaXMgdGhhdCBpdCBhcHBsaWVzIHRvIHRoZSBlbnRpcmUgZmxvdyAoZS5nLiwgY2F1c2VzIFRD UCB0byByZWFjdCBhcyBpZiBhIHBhY2tldCBoYXMgYmVlbiBkcm9wcGVkKSwgaGVuY2UgdGhlIGNv bmdlc3Rpb24gdHJlYXRtZW50IG91Z2h0IHRvIGFwcGx5IHRvIHRoZSBlbnRpcmUgZmxvdy4NCg0K SW4gb3RoZXIgd29yZHMsIG9uZSB3YW50cyB0byBiZSBhYmxlIHRvIHVzZSB0aGUgRUNOLUlQLUNv ZGVwb2ludCBBVlAgYXMgcGFydCBvZiB0aGUgY29uZGl0aW9uIHRoYXQgZGV0ZXJtaW5lcyB3aGV0 aGVyIHRoZSBmaWx0ZXIgcnVsZSBtYXRjaGVzLCBidXQgaWdub3JlIHRoYXQgQVZQIChpLmUuLCB3 aWxkY2FyZCBpdCkgaW4gZGV0ZXJtaW5pbmcgd2hhdCB0cmFmZmljIHRoZSBhY3Rpb24gYXBwbGll cyB0bywgc28gdGhhdCB0aGUgcmVzcG9uc2UgdG8gZGV0ZWN0aW5nIGEgY29uZ2VzdGVkIGZsb3cg KGkuZS4sIHBhY2tldHMgd2l0aCBFQ04gZmllbGQgY29udGFpbmluZyBDRSkgYXBwbGllcyB0byBh bGwgcGFja2V0cyBpbiB0aGUgZmxvdywgcmVnYXJkbGVzcyBvZiB0aGUgdmFsdWUgaW4gdGhlIENF IGZpZWxkLg0KDQpPdGhlcndpc2UsIHRoZSByZXN1bHQgbWF5IGJlIGluZWZmZWN0aXZlLCBhcyBp dCB3b24ndCBlbmNvbXBhc3MgcGFja2V0cyBpbiB0aGUgY29uZ2VzdGVkIGZsb3cgdGhhdCBhcmVu J3QgQ0UtbWFya2VkLg0KDQpBbSBJIHJlYWRpbmcgdGhlIGRyYWZ0IGNvcnJlY3RseT8iDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiAxLCAxc3Qg cGFyYWdyYXBoOg0KSXQgc2F5cyAiVGhlIGZpcnN0IEFWUCBwcm92aWRlcyBkaXJlY3Qgc3VwcG9y dCBmb3IgRUNOIFtSRkMzMTY4XSBpbiB0aGUgSVAgaGVhZGVy4oCcLiBJIGFtICBzdXJlIHRoYXQg eW91ciBkcmFmdCBpcyAgb3QgcHJvdmlkaW5nIGFueSBzdXBwb3J0IGZvciBFQ04gaW4gdGhlIElQ IGhlYWRlciwgYXMgd2UgaGF2ZSBFQ04gaW4gdGhlIElQIGhlYWRlciBhbHJlYWR5LCBpc24ndCBp dC4NCkkgZ3Vlc3MgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgdGhpcyAiVGhlIGZpcnN0IEFWUCBw cm92aWRlcyBkaXJlY3Qgc3VwcG9ydCBmb3IgZmlsdGVyaW5nIEVDTiBtYXJrZWQgdHJhZmZpY1tS RkMzMTY4XeKAnA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFu eSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29w aWVzIG9mIHRoZSBtZXNzYWdlLg0K From nobody Thu Jun 11 17:59:39 2015 Return-Path: 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 B65A11A8A86; Thu, 11 Jun 2015 17:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 FmN8le6691og; Thu, 11 Jun 2015 17:59:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEA71A8A85; Thu, 11 Jun 2015 17:59:33 -0700 (PDT) Received: from BN1AFFO11FD013.protection.gbl (10.58.52.33) by BN1AFFO11HUB017.protection.gbl (10.58.52.127) with Microsoft SMTP Server (TLS) id 15.1.190.9; Fri, 12 Jun 2015 00:59:32 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1AFFO11FD013.mail.protection.outlook.com (10.58.52.73) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Fri, 12 Jun 2015 00:59:32 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5C0wliv027373; Thu, 11 Jun 2015 19:59:31 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm3.corp.sprint.com with ESMTP id 1uux456nkt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jun 2015 19:59:31 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 11 Jun 2015 20:59:30 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Thu, 11 Jun 2015 19:59:30 -0500 From: "Bertz, Lyle T [CTO]" To: "Black, David" , Martin Stiemerling , The IESG Thread-Topic: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AQHQo70F4X8SI5Wk1EqRdOJjKpM6WJ2n1+ZQgABclID//9efUA== Date: Fri, 12 Jun 2015 00:59:29 +0000 Message-ID: <004850850630479cb8dc5206728f454f@PLSWE13M07.ad.sprint.com> References: <20150610203536.14350.31271.idtracker@ietfa.amsl.com> <59ce5385352047b9a02ad4db29d4add2@PLSWE13M07.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.94] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD013; 1:I1pfJS0I8Sx7OL77h/ATJzB01HS5GuZ31tocW5A6tzdR1pSKGkZ242p28278HKqGT7asnufCDZ1Kkt/cK+PzTmhuGQQK/VSOaOx3hzXOJiFE87lwky2nO8xSRaaYriJr0/5nzRt0nyo7gD+cvmbjQDWlM8addIAJaqIklyYon+FYkiSkBjbYkZjeBo+46n6j/C50Xaz5TIUCwdSy/Goy6tvGdD1+NvsaC6HY/txlAfJfuwQrkMUhnPIce0Od4Sncnh8zGNFD5m12fnIz06W5C2eFnd3LIDUVPIl7bBHXMsvPUr34Ht9PaJTYF/v/913I7cuMbEvW3zfBvuQJhNOFZnH0wH78tFTl6m3yTIgebro= X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(52044002)(164054003)(51704005)(377454003)(189002)(199003)(13464003)(230783001)(102836002)(6806004)(19580395003)(19580405001)(5003600100002)(2950100001)(47776003)(92566002)(24736003)(86362001)(2900100001)(2656002)(23676002)(5001770100001)(5250100002)(15975445007)(50466002)(46102003)(189998001)(5001960100002)(106116001)(108616004)(77156002)(62966003)(33646002)(87936001)(50986999)(106466001)(54356999)(76176999)(85326001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB017; H:plsapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB017; 2:taOK7W21MzjEp3TGB91lFOt/KggdZoFKcfHU+NqqP0PUndusxjqJGUJiWFYct23m; 2:KzAB05LGWVdyXsjD90Rk0MNGlYMp9GuuP9wVts7nefva6GOWE8HK4J2tGGh/tFvXTvly4FH4uWsjCFs19ONjpc8xLUOreeONWmgrpETv/17m1ItrBbtC9X0F49tjQ4QfRcKyc6IAOTYwOuKZjST6rECdn/1/NK6Ayx8D6OzAVTAYLUfFCNiw3hBwvRTsRkefcj1puA55YsIEWq07JYQ190kAuKjeddXkd+rbFeVR/mvviRbIyXloGhaHBZmHbn9D; 6:PdN/hzpLElt0cSJNu58duq4znRzAfM24HsziPrUw9SbM0knF+gLZxHEyZuUsgMi/uXGqA31PJgAY111UHhXrQsICZVvhwzfZHr2XFlpItzMw0fFIDNlckMQNAT9S2qI0RJIuKu7T/G4FYMehDDscLAfuMVEjbqbngf3nMnhUDKwwjWNXB/t8HbAbjOnKos09CvD6KVKGn21qvLXy2rdP3NC9Rzz21yFA6XmZ4yJqdchtssGhaA45oaOhhbeW/XvF; 3:C5OQF/db1n+GcAiIr7mdDnmhx3te5QTEkcMsfiQ6MScvHCi241FFTnLWNnbNWkqwKabGQL+04npoUIscXooDPokzvtb3uZhbM6ZStrupaqsG5iGIfQ16TrvOzucml9pjqEvgRGRjvSJyLhf0/yzHsfUOVhIeLvn6LKVodFXsEH61XtR3XE0UtXIhL66JRMnTuWTjMpbOLiY3xqZ2bhlhpIGrMoDj/l3z6RmsxaOZNwmgSQBlwqhKDZNjX+kV4n8soLtH1PqvYAGc0PJljDtbwMxR8pHAuDxfF5kj/PkTNE0f7UPwn+ZE/3m3rSdFg5HV X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB017; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB017; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB017; X-Forefront-PRVS: 060503E79B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMTc7OTp1bU5pcHBaWlU3WGMyR1BXZGF4cituRkdT?= =?utf-8?B?eGFiK01JWjBvdktwbFZtR0ZhT3UyWkRrZ2liRWQ0YXdpYldqVXdRUmppQU5B?= =?utf-8?B?VGpDSlNaV05TMEU3NE9qeWFFREVCTVllT0ZzL3dGUWFKaEFmbTZmZnNmb3BD?= =?utf-8?B?QytjWHVqMnJBaGdYS1VuY09zWWh1UHZLT0l1K2dGd205VzBnMVRIbEVpOHow?= =?utf-8?B?UEJOUHlrMzFFRHEvYWlsTng1QzY3c3ZzejFBeEROZXlvdWRIci9pbW0vMUYw?= =?utf-8?B?L1ZBL1J2TDIwMWxtS09sL0RCMHV6SVRZcDcrM0lxNk5UMnkwNUVOZlVZczVr?= =?utf-8?B?Z2ZVa3ZDN3ZlcmYxSzA4SjREUkcvMTJZa1FCbFFFS0FZRFRkOGt0VFNwd0Vp?= =?utf-8?B?bWxkZHlnbGkwSVJTaUFwT2F0Z0xtUVcwaDlndzNTTGpFVmtqdkx6MHBtTi9u?= =?utf-8?B?bGpjTXorWlI1cExDVWRKNXN2Y1V3SFgzeTg0c2FjN3R6VFpnbnNjN0s2emph?= =?utf-8?B?VjNvRnRoamgrc3VEQXIvQ1cxY0dkM0kxYXNEYzdULzhPRmsvd0k2RWFvdytk?= =?utf-8?B?bkpmV3hVRTZvTTlqTURuV2ozN3orZGlzUXk2NmcxOGt6YWo2bWoyWFBtYVBv?= =?utf-8?B?VHVUTE5TWTlDbUc5VDc3TkdsNU5PTVNsT2IxVDUzWFRRc2xjckNCZ2l4Nm1Z?= =?utf-8?B?VUZuVTNZdXczaDJBSDMyaVdyNFF5WDlLM09RcGRoRHRkZE14d1JUWVpxcTVI?= =?utf-8?B?aGJ0ZWVlWGZIZlVkVHpVVUJkM1JLOE9reXQrazZXSUIyZEJLbGR1cWxnUnhn?= =?utf-8?B?Z2tveXhLc2YwVEZ1MTZlbzd5SjZSQ2dXeDBTNGszemVLLzZaTlBFL2R1SC9B?= =?utf-8?B?SDRVei9EVjE3U3B1ak9wYkpPMTErdVRKM0c0NkpQcktrSzFZai9DS1I0eGZa?= =?utf-8?B?bm5LOVVyMEtOSDB3L2Z1KzkwdzBnb1FEV1RJZW1XdjV1enhjUHRhQ2wrLzZT?= =?utf-8?B?YmlEN1dubHNrZWpQZ1lvL2xXSzNzWnA4MjVlVHpVOWNZenZZU3BFbXNXdzJQ?= =?utf-8?B?WGFoOGg2Wko2Q1MxRTI1Y1hDaFhQQzAzUzl6YjdjaWtvSjMwNTVzSFhqcmts?= =?utf-8?B?L2ZzdmxlZmNpTmVsOFgxb1gxSUpnSDROWE45bjNFclR1ZWlkaUZjV0NncjZ6?= =?utf-8?B?Z2F5WHZ6Vit6M2xGL2VVRTdLd3crV2MyQi9ibUxqaUlaWEZucE1scGh4bU16?= =?utf-8?B?ajJzWVByRkZoOXlxVTc0UmVUU1hibDE0bFZFcFkvZ2wrUVVBMnI0bE9RUkxN?= =?utf-8?B?cmZGK1dGL040K2ZCQk9PckJCNzhpUURIeE03enpGbFEwOUFXWjhYNFd6dld2?= =?utf-8?B?OWNIbWpzbmxsQjBFNENVV2JSMVlodjBNbGI4MDF3TnEwNlVpZ0MvaUJtOFk3?= =?utf-8?B?bnkzZVMxWFdZS2I1VUZ2Yk9Bb3NUcXMvN0RKZEZ0b3dhaWlkVHFyd3R5TXZP?= =?utf-8?B?b0tkMHc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB017; 3:Y1Xw3yqCBlMp9VuJgU8LbwFIbYohbNysquAzmeH2lKdZ/oeyiraAe/JwafpJSOoVxQbdL/u2Xxyj9a4JeInCQDJZn3Ow9dzj+DcuvfMmOMunEVxT7z4xSeFLBxI8FCDFcX6fdjs3vJ0ca48ioou1cw==; 10:gF0vp48Z12Ukry1gijz0wjLTJsbWXSAcz9bdokSzugbnnUedlR6k8bHdohszoF0MIhW/ZY6CULHLZ1f01bOlJ2wX+GGlz7sRXXY5SV5rGCE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2015 00:59:32.3408 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB017 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 00:59:36 -0000 RGF2aWQsDQoNClRyYWZmaWMgZmxvdyhzKSBhcmUgSVAgKDUtdHVwbGUpIGZsb3cocykuDQoNCk15 IHF1ZXN0aW9uIHRvIHlvdSBpcyB3b3VsZCBpdCBiZSBiZXN0IHRvIHNheSAiSVAgZmxvd3MiIG9y ICJJUCAoNS10dXBsZSkgZmxvd3MiIG9yICI1LXR1cGxlIGZsb3dzIj8gICBJIGFtIHVuc3VyZSBv ZiB0aGUgYmVzdCB3b3JkaW5nIGhlcmUuICBUaGlzIHRyZWF0bWVudCBhcHBsaWVzIHRvIGFsbCBw YWNrZXRzIGFzc29jaWF0ZWQgdG8gYWxsIDUtdHVwbGVzIChmbG93cykgY2FwdHVyZWQgYnkgdGhl IEZpbHRlci1SdWxlLg0KDQpBIEZpbHRlci1SdWxlIG1heSBjb250YWluIGEgQ2xhc3NpZmllciB0 aGF0IGRlc2NyaWJlcyBvbmUgb3IgbWFueSA1LXR1cGxlcyBwZXIgUkZDIDU3NzcuDQoNClRoYW5r cy4NCkx5bGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJsYWNrLCBEYXZp ZCBbbWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwg MjAxNSA1OjE1IFBNDQpUbzogQmVydHosIEx5bGUgVCBbQ1RPXTsgTWFydGluIFN0aWVtZXJsaW5n OyBUaGUgSUVTRw0KQ2M6IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3JnOyBCbGFj aywgRGF2aWQNClN1YmplY3Q6IFJFOiBbRGltZV0gTWFydGluIFN0aWVtZXJsaW5nJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLWRpbWUtY29uZ2VzdGlvbi1mbG93LWF0dHJpYnV0ZXMtMDE6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkx5bGUsDQoNCj4gICAgVGhlIENvbmdlc3Rpb24tVHJl YXRtZW50IEFWUCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQuIEl0DQo+ICAgIGlu ZGljYXRlcyBob3cgdG8gdHJlYXQgdHJhZmZpYyBmbG93KHMpIHdoZW4gY29uZ2VzdGlvbiBpcyBk ZXRlY3RlZC4NCj4gICAgVGhlIGRldGVjdGlvbiBvZiB0aGUgY29uZ2VzdGlvbiBjYW4gYmUgYmFz ZWQgb24gdGhlIHJlY2VwdGlvbiBvZiBJUA0KPiAgICBwYWNrZXRzIHBhY2tldCAgd2l0aCAgdGhl IENFIChDb25nZXN0aW9uIEV4cGVyaWVuY2VkKSBjb2RlcG9pbnQgc2V0DQo+ICAgKHNlZSBbUkZD IDMxNjhdKSBvciBieSBhbnkgb3RoZXIgYWRtaW5pc3RyYXRpdmVseSBkZWZpbmVkIGNyaXRlcmlh Lg0KDQpXaGF0IGRvZXMgInRyYWZmaWMgZmxvdyhzKSIgbWVhbiBpbiB0aGlzIHRleHQ/DQoNCkEg Y2xlYXIgZXhwbGFuYXRpb24gb2YgdGhhdCBzaG91bGQgcmVtb3ZlIHRoZSBjb25jZXJuIHRoYXQg dGhpcyBkcmFmdCBtaWdodCBiZSBhcHBseWluZyBjb25nZXN0aW9uIHRyZWF0bWVudCB0byBqdXN0 IHRoZSBDRS1tYXJrZWQgcGFja2V0cyBhbmQgbm90IHRoZSBlbnRpcmUgNS10dXBsZSAob3IgbW9y ZSkuDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBCZXJ0eiwgTHlsZSBUIFtDVE9dIFttYWlsdG86THlsZS5ULkJlcnR6QHNwcmludC5j b21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1IDY6MDIgUE0NCj4gVG86IE1hcnRp biBTdGllbWVybGluZzsgVGhlIElFU0cNCj4gQ2M6IEJsYWNrLCBEYXZpZDsgZGltZUBpZXRmLm9y ZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtEaW1lXSBNYXJ0aW4gU3Rp ZW1lcmxpbmcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZGltZS0NCj4gY29uZ2VzdGlvbi1mbG93 LWF0dHJpYnV0ZXMtMDE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+DQo+IE1hcnRpbiwN Cj4NCj4gUmVnYXJkaW5nIHRoZSBESVNDVVNTIHBvaW50IHRoZSBsYW5ndWFnZSBpbiAzLjIgaXMg cHJvYmxlbWF0aWMsIHdlDQo+IHdpbGwgY2hhbmdlDQo+DQo+ICAgIFRoZSBDb25nZXN0aW9uLVRy ZWF0bWVudCBBVlAgKEFWUCBDb2RlIFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkIGFuZA0KPiAgICBp bmRpY2F0ZXMgaG93IGNvbmdlc3RlZCB0cmFmZmljLCBpLmUuLCB0cmFmZmljIHRoYXQgaGFzIEV4 cGxpY2l0DQo+ICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIENvbmdlc3Rpb24gRXhwZXJpZW5j ZWQgbWFya2luZyBzZXQgb3Igc29tZQ0KPiAgICBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmlu ZWQgY3JpdGVyaWEsIGlzIHRyZWF0ZWQuDQo+DQo+IHRvDQo+DQo+ICAgIFRoZSBDb25nZXN0aW9u LVRyZWF0bWVudCBBVlAgKEFWUCBDb2RlIFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkLiBJdA0KPiAg ICBpbmRpY2F0ZXMgaG93IHRvIHRyZWF0IHRyYWZmaWMgZmxvdyhzKSB3aGVuIGNvbmdlc3Rpb24g aXMgZGV0ZWN0ZWQuDQo+ICAgIFRoZSBkZXRlY3Rpb24gb2YgdGhlIGNvbmdlc3Rpb24gY2FuIGJl IGJhc2VkIG9uIHRoZSByZWNlcHRpb24gb2YgSVANCj4gICAgcGFja2V0cyBwYWNrZXQgIHdpdGgg IHRoZSBDRSAoQ29uZ2VzdGlvbiBFeHBlcmllbmNlZCkgY29kZXBvaW50IHNldA0KPiAgIChzZWUg W1JGQyAzMTY4XSkgb3IgYnkgYW55IG90aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0 ZXJpYS4NCj4NCj4gVGhlIHJhdGlvbmFsZSBmb3IgdGhlIHdvcmQgJ2Zsb3cocyknIGluIHRoZSBu ZXcgbGFuZ3VhZ2UgaXMgdGhlIGxhc3QNCj4gc2VudGVuY2Ugb2YgdGhlIHNlY3Rpb24gIDMuMiAt ICAiVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFWUCBpcyBhbg0KPiBhY3Rpb24gYW5kIE1VU1Qg YmUgYW4gYXR0cmlidXRlIG9mIHRoZSBGaWx0ZXItUnVsZSBHcm91cGVkIEFWUCBhcw0KPiBkZWZp bmVkIGluIFJGQzU3NzcuICIgIEl0IGlzIG90aGVyIEFWUHMgaW4gdGhlIEZpbHRlci1SdWxlLCBl LmcuDQo+IENsYXNzaWZpZXIsIHRoYXQgZGVzY3JpYmVzIHRoZSBzY29wZSBvZiB0cmFmZmljIGlt cGFjdGVkLiAgU2F5aW5nDQo+IHNvbWV0aGluZyBpbiBTZWN0aW9uIDMuMiB0aGF0IGRvZXMgbm90 IGFzc29jaWF0ZSB0aGUNCj4gQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQIHRvIHRoZSBGaWx0ZXIt UnVsZSBpdCBpcyBhIHBhcnQgb2Ygb25seSBjcmVhdGVzIGNvbmZ1c2lvbi4NCj4NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFBlciB0aGUgQ09NTUVOVCwgeW91IGFyZSBj b3JyZWN0LiAgV2UnbGwgY2hhbmdlDQo+DQo+ICJUaGUgZmlyc3QgQVZQIHByb3ZpZGVzIGRpcmVj dCBzdXBwb3J0IGZvciBFQ04gW1JGQzMxNjhdIGluIHRoZSBJUA0KPiAgIGhlYWRlcuKAnA0KPg0K PiB0byB5b3VyIHN1Z2dlc3Rpb24NCj4NCj4gIlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0 IHN1cHBvcnQgZm9yIGZpbHRlcmluZyBFQ04NCj4gICBtYXJrZWQgdHJhZmZpY1tSRkMzMTY4XeKA nA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEaU1FIFttYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluDQo+IFN0aWVtZXJsaW5n DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMCwgMjAxNSAzOjM2IFBNDQo+IFRvOiBUaGUgSUVT Rw0KPiBDYzogZGF2aWQuYmxhY2tAZW1jLmNvbTsgZGltZUBpZXRmLm9yZzsgZGltZS1jaGFpcnNA aWV0Zi5vcmcNCj4gU3ViamVjdDogW0RpbWVdIE1hcnRpbiBTdGllbWVybGluZydzIERpc2N1c3Mg b24NCj4gZHJhZnQtaWV0Zi1kaW1lLWNvbmdlc3Rpb24tDQo+IGZsb3ctYXR0cmlidXRlcy0wMTog KHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4NCj4gTWFydGluIFN0aWVtZXJsaW5nIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWRp bWUtY29uZ2VzdGlvbi1mbG93LWF0dHJpYnV0ZXMtMDE6IERpc2N1c3MNCj4NCj4gV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dA0KPiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KQ0KPg0KPg0KPiBQbGVhc2UgcmVmZXIgdG8NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWNv bmdlc3Rpb24tZmxvdy1hdHRyaQ0KPiBidXRlcy8NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IE5vIGdlbmVyYWwgb2JqZWN0aW9uIHRv IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgZG9jdW1lbnQuIEhvd2V2ZXIsIEkgYW0NCj4gcmVsYXlp bmcgYSBxdWVzdGlvbiBmcm9tIERhdmlkIEJsYWNrIGFzIGEgRElTQ1VTUyBwb2ludC4NCj4NCj4g SSBhc3N1bWUgdGhhdCB0aGUgZHJhZnQgaXMgbW9yZSB0aGFuIHVuY2xlYXIgaW4gU2VjdGlvbiAz LjIgIGFib3V0DQo+IHdoYXQgdHJhZmZpYyBtZWFucy4gSXMgaXQgYSBwYXJ0aWN1bGFyIGZsb3cs IGEgc2luZ2xlIHBhY2tldCwgZXRjPw0KPg0KPiAiSSBmb3VuZCBhbiBFQ04gY29uY2VybiwgYW5k IGhlbmNlIGFkZGVkIHRoZSBUU1YgQURzIHRvIHRoZSBDQyBsaW5lLg0KPg0KPiBTZWN0aW9uIDMu MiBzYXlzOg0KPg0KPiAgICBUaGUgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQIChBVlAgQ29kZSBU QkQpIGlzIG9mIHR5cGUgR3JvdXBlZCBhbmQNCj4gICAgaW5kaWNhdGVzIGhvdyBjb25nZXN0ZWQg dHJhZmZpYywgaS5lLiwgdHJhZmZpYyB0aGF0IGhhcyBFeHBsaWNpdA0KPiAgICBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1hcmtpbmcgc2V0IG9yIHNvbWUN Cj4gICAgb3RoZXIgYWRtaW5pc3RyYXRpdmVseSBkZWZpbmVkIGNyaXRlcmlhLCBpcyB0cmVhdGVk Lg0KPg0KPiBUaGF0IGFwcGVhcnMgdG8gc2F5IHRoYXQgdGhlIGNvbmdlc3Rpb24gdHJlYXRtZW50 IG1heSBiZSBhcHBsaWVkDQo+IHNvbGVseSB0byBwYWNrZXRzIHRoYXQgaGF2ZSB0aGUgQ0UgKENv bmdlc3Rpb24gRXhwZXJpZW5jZWQpIG1hcmtpbmcuDQo+IFRoYXQgd291bGQgYmUgYSBwcm9ibGVt LCBiZWNhdXNlIHRoZSBkZWZpbmVkIHNlbWFudGljcyBvZiBhIENFIG1hcmtpbmcNCj4gaXMgdGhh dCBpdCBhcHBsaWVzIHRvIHRoZSBlbnRpcmUgZmxvdyAoZS5nLiwgY2F1c2VzIFRDUCB0byByZWFj dCBhcyBpZg0KPiBhIHBhY2tldCBoYXMgYmVlbiBkcm9wcGVkKSwgaGVuY2UgdGhlIGNvbmdlc3Rp b24gdHJlYXRtZW50IG91Z2h0IHRvDQo+IGFwcGx5IHRvIHRoZSBlbnRpcmUgZmxvdy4NCj4NCj4g SW4gb3RoZXIgd29yZHMsIG9uZSB3YW50cyB0byBiZSBhYmxlIHRvIHVzZSB0aGUgRUNOLUlQLUNv ZGVwb2ludCBBVlANCj4gYXMgcGFydCBvZiB0aGUgY29uZGl0aW9uIHRoYXQgZGV0ZXJtaW5lcyB3 aGV0aGVyIHRoZSBmaWx0ZXIgcnVsZQ0KPiBtYXRjaGVzLCBidXQgaWdub3JlIHRoYXQgQVZQIChp LmUuLCB3aWxkY2FyZCBpdCkgaW4gZGV0ZXJtaW5pbmcgd2hhdA0KPiB0cmFmZmljIHRoZSBhY3Rp b24gYXBwbGllcyB0bywgc28gdGhhdCB0aGUgcmVzcG9uc2UgdG8gZGV0ZWN0aW5nIGENCj4gY29u Z2VzdGVkIGZsb3cgKGkuZS4sIHBhY2tldHMgd2l0aCBFQ04gZmllbGQgY29udGFpbmluZyBDRSkg YXBwbGllcyB0bw0KPiBhbGwgcGFja2V0cyBpbiB0aGUgZmxvdywgcmVnYXJkbGVzcyBvZiB0aGUg dmFsdWUgaW4gdGhlIENFIGZpZWxkLg0KPg0KPiBPdGhlcndpc2UsIHRoZSByZXN1bHQgbWF5IGJl IGluZWZmZWN0aXZlLCBhcyBpdCB3b24ndCBlbmNvbXBhc3MNCj4gcGFja2V0cyBpbiB0aGUgY29u Z2VzdGVkIGZsb3cgdGhhdCBhcmVuJ3QgQ0UtbWFya2VkLg0KPg0KPiBBbSBJIHJlYWRpbmcgdGhl IGRyYWZ0IGNvcnJlY3RseT8iDQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPg0KPiBTZWN0aW9uIDEsIDFzdCBwYXJhZ3JhcGg6DQo+IEl0IHNheXMg IlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0IHN1cHBvcnQgZm9yIEVDTiBbUkZDMzE2OF0g aW4NCj4gdGhlIElQIGhlYWRlcuKAnC4gSSBhbSAgc3VyZSB0aGF0IHlvdXIgZHJhZnQgaXMgIG90 IHByb3ZpZGluZyBhbnkNCj4gc3VwcG9ydCBmb3IgRUNOIGluIHRoZSBJUCBoZWFkZXIsIGFzIHdl IGhhdmUgRUNOIGluIHRoZSBJUCBoZWFkZXIgYWxyZWFkeSwgaXNuJ3QgaXQuDQo+IEkgZ3Vlc3Mg eW91IG1lYW4gc29tZXRoaW5nIGxpa2UgdGhpcyAiVGhlIGZpcnN0IEFWUCBwcm92aWRlcyBkaXJl Y3QNCj4gc3VwcG9ydCBmb3IgZmlsdGVyaW5nIEVDTiBtYXJrZWQgdHJhZmZpY1tSRkMzMTY4XeKA nA0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPg0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRh cnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yDQo+IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBp ZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZg0KPiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZA0K PiBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVu dChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Thu Jun 11 21:29:01 2015 Return-Path: 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 8AE631B2C4E; Thu, 11 Jun 2015 15:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 etdaP58AQF0q; Thu, 11 Jun 2015 15:15:22 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2035B1B2C4D; Thu, 11 Jun 2015 15:15:21 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5BMFJnu019226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jun 2015 18:15:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t5BMFJnu019226 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1434060920; bh=t0iQPYdd+FrKYahUsH3qR5ifHo4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qa1hBTVA8lo2hRlw+RuBlz3K8f5qqoZWF43QNtTdZJl8aOK49cTfPYycjPnoNHItu 8KJEsiAmNNOmIdfRcOO3GaEDBIxD3qz/Wq+mA77qHR7wTw7ui+PyySTG9Qts7g3Bxm EoRbL0Av03q1/1wp1IwXmrGuLVXyrCGX+Xjar+EM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t5BMFJnu019226 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Thu, 11 Jun 2015 18:15:06 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5BMF7Yh007678 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jun 2015 18:15:08 -0400 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 11 Jun 2015 18:15:07 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 18:15:06 -0400 From: "Black, David" To: "Bertz, Lyle T [CTO]" , Martin Stiemerling , The IESG Thread-Topic: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AQHQo70E/5Ortlxiskuf5jKsamXFsp2oH/IA//+/fBA= Date: Thu, 11 Jun 2015 22:15:05 +0000 Message-ID: References: <20150610203536.14350.31271.idtracker@ietfa.amsl.com> <59ce5385352047b9a02ad4db29d4add2@PLSWE13M07.ad.sprint.com> In-Reply-To: <59ce5385352047b9a02ad4db29d4add2@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: X-Mailman-Approved-At: Thu, 11 Jun 2015 21:28:59 -0700 Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , "Black, David" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 22:15:24 -0000 THlsZSwNCg0KPiAgICBUaGUgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQIChBVlAgQ29kZSBUQkQp IGlzIG9mIHR5cGUgR3JvdXBlZC4gSXQNCj4gICAgaW5kaWNhdGVzIGhvdyB0byB0cmVhdCB0cmFm ZmljIGZsb3cocykgd2hlbiBjb25nZXN0aW9uIGlzIGRldGVjdGVkLg0KPiAgICBUaGUgZGV0ZWN0 aW9uIG9mIHRoZSBjb25nZXN0aW9uIGNhbiBiZSBiYXNlZCBvbiB0aGUgcmVjZXB0aW9uIG9mIElQ DQo+ICAgIHBhY2tldHMgcGFja2V0ICB3aXRoICB0aGUgQ0UgKENvbmdlc3Rpb24gRXhwZXJpZW5j ZWQpIGNvZGVwb2ludCBzZXQNCj4gICAoc2VlIFtSRkMgMzE2OF0pIG9yIGJ5IGFueSBvdGhlciBh ZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQgY3JpdGVyaWEuDQoNCldoYXQgZG9lcyAidHJhZmZpYyBm bG93KHMpIiBtZWFuIGluIHRoaXMgdGV4dD8NCg0KQSBjbGVhciBleHBsYW5hdGlvbiBvZiB0aGF0 IHNob3VsZCByZW1vdmUgdGhlIGNvbmNlcm4gdGhhdCB0aGlzIGRyYWZ0IG1pZ2h0IGJlDQphcHBs eWluZyBjb25nZXN0aW9uIHRyZWF0bWVudCB0byBqdXN0IHRoZSBDRS1tYXJrZWQgcGFja2V0cyBh bmQgbm90IHRoZSBlbnRpcmUNCjUtdHVwbGUgKG9yIG1vcmUpLg0KDQpUaGFua3MsDQotLURhdmlk DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVydHosIEx5bGUgVCBb Q1RPXSBbbWFpbHRvOkx5bGUuVC5CZXJ0ekBzcHJpbnQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwg SnVuZSAxMSwgMjAxNSA2OjAyIFBNDQo+IFRvOiBNYXJ0aW4gU3RpZW1lcmxpbmc7IFRoZSBJRVNH DQo+IENjOiBCbGFjaywgRGF2aWQ7IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJFOiBbRGltZV0gTWFydGluIFN0aWVtZXJsaW5nJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLWRpbWUtDQo+IGNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gTWFydGluLA0KPiANCj4gUmVnYXJkaW5nIHRoZSBE SVNDVVNTIHBvaW50IHRoZSBsYW5ndWFnZSBpbiAzLjIgaXMgcHJvYmxlbWF0aWMsIHdlIHdpbGwg Y2hhbmdlDQo+IA0KPiAgICBUaGUgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQIChBVlAgQ29kZSBU QkQpIGlzIG9mIHR5cGUgR3JvdXBlZCBhbmQNCj4gICAgaW5kaWNhdGVzIGhvdyBjb25nZXN0ZWQg dHJhZmZpYywgaS5lLiwgdHJhZmZpYyB0aGF0IGhhcyBFeHBsaWNpdA0KPiAgICBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1hcmtpbmcgc2V0IG9yIHNvbWUN Cj4gICAgb3RoZXIgYWRtaW5pc3RyYXRpdmVseSBkZWZpbmVkIGNyaXRlcmlhLCBpcyB0cmVhdGVk Lg0KPiANCj4gdG8NCj4gDQo+ICAgIFRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgKEFWUCBD b2RlIFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkLiBJdA0KPiAgICBpbmRpY2F0ZXMgaG93IHRvIHRy ZWF0IHRyYWZmaWMgZmxvdyhzKSB3aGVuIGNvbmdlc3Rpb24gaXMgZGV0ZWN0ZWQuDQo+ICAgIFRo ZSBkZXRlY3Rpb24gb2YgdGhlIGNvbmdlc3Rpb24gY2FuIGJlIGJhc2VkIG9uIHRoZSByZWNlcHRp b24gb2YgSVANCj4gICAgcGFja2V0cyBwYWNrZXQgIHdpdGggIHRoZSBDRSAoQ29uZ2VzdGlvbiBF eHBlcmllbmNlZCkgY29kZXBvaW50IHNldA0KPiAgIChzZWUgW1JGQyAzMTY4XSkgb3IgYnkgYW55 IG90aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0ZXJpYS4NCj4gDQo+IFRoZSByYXRp b25hbGUgZm9yIHRoZSB3b3JkICdmbG93KHMpJyBpbiB0aGUgbmV3IGxhbmd1YWdlIGlzIHRoZSBs YXN0IHNlbnRlbmNlDQo+IG9mIHRoZSBzZWN0aW9uICAzLjIgLSAgIlRoZSBDb25nZXN0aW9uLVRy ZWF0bWVudCBBVlAgaXMgYW4gYWN0aW9uIGFuZCBNVVNUIGJlDQo+IGFuIGF0dHJpYnV0ZSBvZiB0 aGUgRmlsdGVyLVJ1bGUgR3JvdXBlZCBBVlAgYXMgZGVmaW5lZCBpbiBSRkM1Nzc3LiAiICBJdCBp cw0KPiBvdGhlciBBVlBzIGluIHRoZSBGaWx0ZXItUnVsZSwgZS5nLiBDbGFzc2lmaWVyLCB0aGF0 IGRlc2NyaWJlcyB0aGUgc2NvcGUgb2YNCj4gdHJhZmZpYyBpbXBhY3RlZC4gIFNheWluZyBzb21l dGhpbmcgaW4gU2VjdGlvbiAzLjIgdGhhdCBkb2VzIG5vdCBhc3NvY2lhdGUgdGhlDQo+IENvbmdl c3Rpb24tVHJlYXRtZW50IEFWUCB0byB0aGUgRmlsdGVyLVJ1bGUgaXQgaXMgYSBwYXJ0IG9mIG9u bHkgY3JlYXRlcw0KPiBjb25mdXNpb24uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gUGVyIHRoZSBDT01NRU5ULCB5b3UgYXJlIGNvcnJlY3QuICBXZSdsbCBjaGFu Z2UNCj4gDQo+ICJUaGUgZmlyc3QgQVZQIHByb3ZpZGVzIGRpcmVjdCBzdXBwb3J0IGZvciBFQ04g W1JGQzMxNjhdIGluIHRoZSBJUA0KPiAgIGhlYWRlcuKAnA0KPiANCj4gdG8geW91ciBzdWdnZXN0 aW9uDQo+IA0KPiAiVGhlIGZpcnN0IEFWUCBwcm92aWRlcyBkaXJlY3Qgc3VwcG9ydCBmb3IgZmls dGVyaW5nIEVDTg0KPiAgIG1hcmtlZCB0cmFmZmljW1JGQzMxNjhd4oCcDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFN0aWVtZXJsaW5nDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgSnVuZSAxMCwgMjAxNSAzOjM2IFBNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogZGF2aWQuYmxh Y2tAZW1jLmNvbTsgZGltZUBpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVj dDogW0RpbWVdIE1hcnRpbiBTdGllbWVybGluZydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaW1l LWNvbmdlc3Rpb24tDQo+IGZsb3ctYXR0cmlidXRlcy0wMTogKHdpdGggRElTQ1VTUyBhbmQgQ09N TUVOVCkNCj4gDQo+IE1hcnRpbiBTdGllbWVybGluZyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1kaW1lLWNvbmdlc3Rpb24tZmxvdy1h dHRyaWJ1dGVzLTAxOiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVz c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRo aXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWNvbmdlc3Rpb24tZmxvdy1hdHRy aWJ1dGVzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IE5vIGdlbmVyYWwgb2JqZWN0aW9uIHRvIHRoZSBwdWJsaWNhdGlvbiBv ZiB0aGUgZG9jdW1lbnQuIEhvd2V2ZXIsIEkgYW0NCj4gcmVsYXlpbmcgYSBxdWVzdGlvbiBmcm9t IERhdmlkIEJsYWNrIGFzIGEgRElTQ1VTUyBwb2ludC4NCj4gDQo+IEkgYXNzdW1lIHRoYXQgdGhl IGRyYWZ0IGlzIG1vcmUgdGhhbiB1bmNsZWFyIGluIFNlY3Rpb24gMy4yICBhYm91dCB3aGF0DQo+ IHRyYWZmaWMgbWVhbnMuIElzIGl0IGEgcGFydGljdWxhciBmbG93LCBhIHNpbmdsZSBwYWNrZXQs IGV0Yz8NCj4gDQo+ICJJIGZvdW5kIGFuIEVDTiBjb25jZXJuLCBhbmQgaGVuY2UgYWRkZWQgdGhl IFRTViBBRHMgdG8gdGhlIENDIGxpbmUuDQo+IA0KPiBTZWN0aW9uIDMuMiBzYXlzOg0KPiANCj4g ICAgVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFWUCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBl IEdyb3VwZWQgYW5kDQo+ICAgIGluZGljYXRlcyBob3cgY29uZ2VzdGVkIHRyYWZmaWMsIGkuZS4s IHRyYWZmaWMgdGhhdCBoYXMgRXhwbGljaXQNCj4gICAgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24g Q29uZ2VzdGlvbiBFeHBlcmllbmNlZCBtYXJraW5nIHNldCBvciBzb21lDQo+ICAgIG90aGVyIGFk bWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0ZXJpYSwgaXMgdHJlYXRlZC4NCj4gDQo+IFRoYXQg YXBwZWFycyB0byBzYXkgdGhhdCB0aGUgY29uZ2VzdGlvbiB0cmVhdG1lbnQgbWF5IGJlIGFwcGxp ZWQgc29sZWx5IHRvDQo+IHBhY2tldHMgdGhhdCBoYXZlIHRoZSBDRSAoQ29uZ2VzdGlvbiBFeHBl cmllbmNlZCkgbWFya2luZy4NCj4gVGhhdCB3b3VsZCBiZSBhIHByb2JsZW0sIGJlY2F1c2UgdGhl IGRlZmluZWQgc2VtYW50aWNzIG9mIGEgQ0UgbWFya2luZyBpcyB0aGF0DQo+IGl0IGFwcGxpZXMg dG8gdGhlIGVudGlyZSBmbG93IChlLmcuLCBjYXVzZXMgVENQIHRvIHJlYWN0IGFzIGlmIGEgcGFj a2V0IGhhcw0KPiBiZWVuIGRyb3BwZWQpLCBoZW5jZSB0aGUgY29uZ2VzdGlvbiB0cmVhdG1lbnQg b3VnaHQgdG8gYXBwbHkgdG8gdGhlIGVudGlyZQ0KPiBmbG93Lg0KPiANCj4gSW4gb3RoZXIgd29y ZHMsIG9uZSB3YW50cyB0byBiZSBhYmxlIHRvIHVzZSB0aGUgRUNOLUlQLUNvZGVwb2ludCBBVlAg YXMgcGFydA0KPiBvZiB0aGUgY29uZGl0aW9uIHRoYXQgZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBm aWx0ZXIgcnVsZSBtYXRjaGVzLCBidXQgaWdub3JlDQo+IHRoYXQgQVZQIChpLmUuLCB3aWxkY2Fy ZCBpdCkgaW4gZGV0ZXJtaW5pbmcgd2hhdCB0cmFmZmljIHRoZSBhY3Rpb24gYXBwbGllcw0KPiB0 bywgc28gdGhhdCB0aGUgcmVzcG9uc2UgdG8gZGV0ZWN0aW5nIGEgY29uZ2VzdGVkIGZsb3cgKGku ZS4sIHBhY2tldHMgd2l0aCBFQ04NCj4gZmllbGQgY29udGFpbmluZyBDRSkgYXBwbGllcyB0byBh bGwgcGFja2V0cyBpbiB0aGUgZmxvdywgcmVnYXJkbGVzcyBvZiB0aGUNCj4gdmFsdWUgaW4gdGhl IENFIGZpZWxkLg0KPiANCj4gT3RoZXJ3aXNlLCB0aGUgcmVzdWx0IG1heSBiZSBpbmVmZmVjdGl2 ZSwgYXMgaXQgd29uJ3QgZW5jb21wYXNzIHBhY2tldHMgaW4gdGhlDQo+IGNvbmdlc3RlZCBmbG93 IHRoYXQgYXJlbid0IENFLW1hcmtlZC4NCj4gDQo+IEFtIEkgcmVhZGluZyB0aGUgZHJhZnQgY29y cmVjdGx5PyINCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IFNlY3Rpb24gMSwgMXN0IHBhcmFncmFwaDoNCj4gSXQgc2F5cyAiVGhlIGZp cnN0IEFWUCBwcm92aWRlcyBkaXJlY3Qgc3VwcG9ydCBmb3IgRUNOIFtSRkMzMTY4XSBpbiB0aGUg SVANCj4gaGVhZGVy4oCcLiBJIGFtICBzdXJlIHRoYXQgeW91ciBkcmFmdCBpcyAgb3QgcHJvdmlk aW5nIGFueSBzdXBwb3J0IGZvciBFQ04gaW4NCj4gdGhlIElQIGhlYWRlciwgYXMgd2UgaGF2ZSBF Q04gaW4gdGhlIElQIGhlYWRlciBhbHJlYWR5LCBpc24ndCBpdC4NCj4gSSBndWVzcyB5b3UgbWVh biBzb21ldGhpbmcgbGlrZSB0aGlzICJUaGUgZmlyc3QgQVZQIHByb3ZpZGVzIGRpcmVjdCBzdXBw b3J0DQo+IGZvciBmaWx0ZXJpbmcgRUNOIG1hcmtlZCB0cmFmZmljW1JGQzMxNjhd4oCcDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g RGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IA0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlDQo+IHVzZSBvZiB0aGUgcmVjaXBpZW50 KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUN Cj4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgYWxsIGNvcGllcyBvZiB0aGUNCj4gbWVzc2FnZS4NCg== From nobody Fri Jun 12 10:32:39 2015 Return-Path: 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 8034D1ACDD3; Fri, 12 Jun 2015 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 rCAswLBYE-nY; Fri, 12 Jun 2015 10:32:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226F51ACDCA; Fri, 12 Jun 2015 10:32:26 -0700 (PDT) Received: from BY2FFO11FD026.protection.gbl (10.1.14.31) by BY2FFO11HUB014.protection.gbl (10.1.14.80) with Microsoft SMTP Server (TLS) id 15.1.190.9; Fri, 12 Jun 2015 17:32:24 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Fri, 12 Jun 2015 17:32:24 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5CHTxiq017881; Fri, 12 Jun 2015 12:32:23 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 1uuxn1bmng-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Jun 2015 12:32:23 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 12 Jun 2015 12:32:23 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Fri, 12 Jun 2015 12:32:23 -0500 From: "Bertz, Lyle T [CTO]" To: "Black, David" , Martin Stiemerling , The IESG Thread-Topic: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AdClJQY74X8SI5Wk1EqRdOJjKpM6WAAAdEjg Date: Fri, 12 Jun 2015 17:32:22 +0000 Message-ID: <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD026; 1:zbd1B7ocJElNqshqJjrl9qmPibVjnMr0pdgMRr8c3kbqymf7TbD6tAXCqyVLOwdv3JVEsmbYMk/hKJXn45PgEhKN57F4LJvIaI1XfdiGvtBmiNpbKA23pOBsZ4EDmehk2GuGaCrsSxpjSYCVvFbdfrOMqMm8fHzeXeaFw/yXPj8qwWs68BmrpGvA2FCtItrbCR9JyvIdZmEPvc0yhgD6S+6IMn5v8qscPnMZqs9hSZ/IIM53bDgwF5E/21932tHEo3LPVq5UMWX6s3p/IclIbrpDMZY1x0o91jzBfQf2j26l/BiPZNS3xlPpI7fyoI3BUq3owGwefZrNAa4YFEN7JAhVhLDobEj4mtdOOIcAMJI= X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(51704005)(51914003)(199003)(13464003)(189002)(377454003)(52044002)(164054003)(50466002)(5001770100001)(15975445007)(54356999)(76176999)(19580405001)(19580395003)(86362001)(6806004)(5003600100002)(102836002)(2656002)(47776003)(24736003)(92566002)(106466001)(87936001)(23676002)(2950100001)(50986999)(2900100001)(33646002)(77156002)(46102003)(62966003)(85326001)(230783001)(189998001)(108616004)(5001960100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB014; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB014; 2:i3SHGWK3EYXDPC1nqC/AItGtHxItOmGMho2/ztyjsoCXMcJUUwEJpHaXluGfROkF; 2:2vStgUbps8wRzTwgAdBJjKVJS7Q3+xX66e1nLKUVMhzE2fw3KYJ47iZFpQb8Aurl3Zq1/1ejUpzaV2sW6RBpzvAur355J8vPUvnuWbLMc0CkQIJXsZ1Hc3FPA61HRHfuf1ujGS1K4C7T3/cA+Yc/lkimkao3JaVFFi3/0hX5+ihSbbwfkjsAO7Ce4f/WrhxOg0rUwTybnJuOvEqTVboHnZJVLeNKI625lzQDZKHFPu4hfH2It9TNiv5naix54ddd; 6:9NTXY/ys9uEOqbBmr3tumvedmd6tt+71tjnecwpzO536eLtnzhaHDUn2E5e63f5EZ1r837Cf6lgYvCxBMcYHNC8wN0GswYYRHM2AtltXuOP25vpQwh78bO0T8JCq6o2zmYuqbbLnYr3BrLDDCVd/zMHuvXAnU/aD8LqtMH9nFrFNTo5dtSOfWIAeyxwWJyXYW7lH9r/A8naGuAUpyVvmDYYx6H7s2MI0+YBtECqlTxkHWcSQ1nRjU6e5va2rpYtq; 3:T+M3ako30zsWntmp9SxRFy0BuGpavQath27uzOkvJjTUrTdk1ssCX2nd6C/NolAoD191apiujJKdOIK0eiRznChz5kxa7/aNggnE7pH46UigjA3lHOKSV5grLGms5qOdo9jJ4dpVhYpt+fuATzkG0Oeo4p/PnwvkhOjvztQVUGVhObNPIB/yKYhoS1cVa05lf2hfLxRqKCJYZHBsn5pnd5H9iVbCzm+vRWqNe4pRdz37jJ1frHr8wOyllT2UaVbGID7Psr184S2KKHAyXDvN8bpv0BFIgikymcLDF0OmZlgUdvLz/CVbgPKMowAWVq4c X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB014; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY2FFO11HUB014; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB014; X-Forefront-PRVS: 060503E79B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJGRk8xMUhVQjAxNDs5OkJnc3F1OFVHUEFvV1FBZXhZeDJ5aENEMjR2?= =?utf-8?B?TTIraGdOYXV5SzFhaGRkYnNaSGU2VnkvODFRdDVXWlovUVhwSVhCb1ZoRS9w?= =?utf-8?B?M1JVdjNQSTRxWFFJcmthRjIwNmVCdzlpeVlPMUJHSk5tWmxDMEZXOUwvR0dj?= =?utf-8?B?UElFV1VkM0k0MEFJT09rOWlaQjh5U2Uzc1ZWOGpyWDFQNTB3S0d6Z2F1dXIv?= =?utf-8?B?dlduNlBCdkdqRXZlSkozSXU1OXlHOWFETDhVdHJZRm9RUlp4VlhoMi9ZQ2I1?= =?utf-8?B?cUlKRTVycEpzYlkvSGxxNzB2L2tBNDJBbUh6RzRBNUZXeEdLcEtBVWRxU0tK?= =?utf-8?B?bVg3TFh0VWU2bG05aTk1UDNxMHpON0pwa3FNZGdnNkhhOHl2K3cxYWVTdXg4?= =?utf-8?B?Zjk0NXdqb25hZUd4ZWZoZjh4Q1dQTTluSXRHNXlIajhia3N2cFpVQTZrMVhw?= =?utf-8?B?SUtmQmRTRlI5SlA2RU1YNTRwYXVVU2NGU2x0OVdsN3g1WWVHM0JYMlFwQUgz?= =?utf-8?B?bUxGNDdQUzBQMkp2QkRWV1ppb1lpQXFtTVhtNDB0Y0pFRjZGdy9DWmcxVkk5?= =?utf-8?B?M1Buek1XaWlTUE1ZV0kvcG0wLy83MWIvbG9Lek83bkNQcDNDTDNZZVNBcFFS?= =?utf-8?B?eitRMGwvbkdDR0pvbnFMdGcvcHRUTEw3OFZIVWduRzV2NG5CMkIzeXRBMEJU?= =?utf-8?B?akpYZWt6c2FhU0YzN29DSlZKRXZhbGoya2liNm9WNlQyZ3JQTEFNUjBvYWJF?= =?utf-8?B?TWdKUlV6Y2RlZnlLUnJxZXFVNU9NTEczeTVmR2I0b3crQWxkTUNBck9OZk1X?= =?utf-8?B?ZjhkTXRmS3NVRFdnRmxNMWxvOVpMYjBqOUY1YzZpTlJ6cEVheENmZDVyeU1P?= =?utf-8?B?K1QvRXE5SERPU2laL2JKUHBhcmc2cFU4d3Z5TEpwU1dqaTJpNnAzT0N1N3pv?= =?utf-8?B?K0MxTXNOMGoxd0kvVDU1ZWJiVEIzbFlOTGFVWGJtdE1USXdpZkpuazFkYWR3?= =?utf-8?B?c25tUTNuQ2xpc0FLZis2UWtyOXByMEhxaFpsRG5TT2VlQjJhNUlxaVR3OGZZ?= =?utf-8?B?YTBKZjRZc3o2YU8vSjRGc1FWZU5FdnJldnlVNjB2QXcxdnRIcDhzdTVXem9i?= =?utf-8?B?YW00MGNxeDBZc0w4K1d3OVdLZXhwMUVFM1N0RE9pQWM1ZEY0ZmlISFNZYkFy?= =?utf-8?B?UnE5eS8vUTRLTmNQNFBaZFl6SFAwSXJ4MmoxTU9xTVd6YzFaTHRaWmtXMC90?= =?utf-8?B?QmQ0NStsN29PS2NwRC9pQmRJWENFcDNlcER3ZTF0MkQ1Y3gxZTFmWTIrU3J4?= =?utf-8?B?Q3JZSENrdEpEVjN5K1FPQ1JHa3JTemdtT0hxRkdpME9MNTlLSGRKWWhrYTlI?= =?utf-8?B?N1o3eS9hU1VleDNsS0g3YmFOT3JTR2hzTENyUmUva1hmZ0t1NEo1ZGxHczNl?= =?utf-8?Q?swGnXE=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB014; 3:Y/DefVnQjCfipWFm0N2SLrUcKURVOTz6ef+MLrY8gj2t9xHQ16yixsDB39jC7RJ1b85D/QuTnozTK53EqRhpEUlxsmMs91C6gMpAiU1WT0ePuL0nrFrcYgBSq93IywFFtgJRCJSvg9oMbOH4boJ4jg==; 10:DkP76OcFQTB5iB6Z5MLdGNTNlktolXtCP7dvcdBrXDGbAocSkl6kW3jEcaaWZrC8RZ/OWU6xPoOAdMe+X23Aoclt1hRyS0LdZXADWKkjwfE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2015 17:32:24.7970 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB014 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:32:30 -0000 RGF2aWQsDQoNClRoYW5rcyBmb3IgdGhlIGd1aWRhbmNlIGhlcmUuICBXZSBkZWZpbml0ZWx5IHdh bnQgdG8gbWVldCB0aGUgZ29hbHMgeW91IG5vdGUgYmVsb3cuDQoNCkkgd2lsbCBhc3N1bWUgTWFy dGluIGhhcyBubyBvYmplY3Rpb24gdG8gIklQICg1LXR1cGxlKSBmbG93cyIuICBJZiBzbywgd2Ug Y2FuIGFkanVzdCB0aGUgbGFuZ3VhZ2UuDQoNCk5ldyBsYW5ndWFnZSAoSSBhbHNvIGNoYW5nZWQg J0luIGNhc2UgdGhlIiB0byAiSWYgdGhlIiBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBuZXh0IHBh cmFncmFwaC4NCg0KPiA+ICAgIFRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgKEFWUCBDb2Rl IFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkLiBJdA0KPiA+ICAgIGluZGljYXRlcyBob3cgdG8gdHJl YXQgdHJhZmZpYyBJUCAoNS10dXBsZSkgZmxvdyhzKSB3aGVuIGNvbmdlc3Rpb24gaXMgZGV0ZWN0 ZWQuDQo+ID4gICAgVGhlIGRldGVjdGlvbiBvZiB0aGUgY29uZ2VzdGlvbiBjYW4gYmUgYmFzZWQg b24gdGhlIHJlY2VwdGlvbiBvZiBJUA0KPiA+ICAgIHBhY2tldHMgcGFja2V0ICB3aXRoICB0aGUg Q0UgKENvbmdlc3Rpb24gRXhwZXJpZW5jZWQpIGNvZGVwb2ludCBzZXQNCj4gPiAgIChzZWUgW1JG QyAzMTY4XSkgb3IgYnkgYW55IG90aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0ZXJp YS4NCj4gPg0KPiA+ICAgQSBGaWx0ZXItUnVsZSBtYXkgY29udGFpbiBhIENsYXNzaWZpZXIgdGhh dCBkZXNjcmliZXMgb25lIG9yIG1hbnkgNS10dXBsZXMgcGVyDQo+ID4gICBSRkMgNTc3Ny4gIFRo aXMgdHJlYXRtZW50IGFwcGxpZXMgdG8gYWxsIHBhY2tldHMgYXNzb2NpYXRlZCB0byBhbGwgNS10 dXBsZXMgKGZsb3dzKSA+ID4gICBjYXB0dXJlZCBieSB0aGUgRmlsdGVyLVJ1bGUuDQo+ID4NCj4g PiAgIElmIHRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgaXMgYWJzZW50Li4uDQoNCkkgYmVs aWV2ZSB0aGlzIGxhbmd1YWdlIG1lZXRzIHRoZSBvYmplY3RpdmVzIG91dGxpbmVkIGJlbG93Lg0K DQpUaGFuayB5b3UuDQpMeWxlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBC bGFjaywgRGF2aWQgW21haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tXQ0KU2VudDogRnJpZGF5LCBK dW5lIDEyLCAyMDE1IDEwOjMzIEFNDQpUbzogQmVydHosIEx5bGUgVCBbQ1RPXTsgTWFydGluIFN0 aWVtZXJsaW5nOyBUaGUgSUVTRw0KQ2M6IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYu b3JnOyBCbGFjaywgRGF2aWQNClN1YmplY3Q6IFJFOiBbRGltZV0gTWFydGluIFN0aWVtZXJsaW5n J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtY29uZ2VzdGlvbi1mbG93LWF0dHJpYnV0ZXMt MDE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkx5bGUsDQoNClRoYW5rcyBmb3IgdGhl IGV4cGxhbmF0aW9uIC0gZm9yIG15IGNvbmNlcm4sIEkgdGhpbmsgd2UncmUgY2xvc2UgdG8gZG9u ZS4uLg0KDQo+IFRyYWZmaWMgZmxvdyhzKSBhcmUgSVAgKDUtdHVwbGUpIGZsb3cocykuDQoNClRo YXQncyBhIHJlbGllZiAtIEknbSBnbGFkIHRoYXQgd2UncmUgb25seSBkZWFsaW5nIHdpdGggZWRp dG9yaWFsIGNvbmNlcm5zIGluIHRoZSBkcmFmdCwgYW5kIG5vdCBhbiBhY3R1YWwgZGVzaWduIHBy b2JsZW0uDQoNCj4gTXkgcXVlc3Rpb24gdG8geW91IGlzIHdvdWxkIGl0IGJlIGJlc3QgdG8gc2F5 ICJJUCBmbG93cyIgb3IgIklQDQo+ICg1LXR1cGxlKSBmbG93cyIgb3IgIjUtdHVwbGUgZmxvd3Mi Pw0KDQpJIGxpa2UgIklQICg1LXR1cGxlKSBmbG93cyIgLSBNYXJ0aW4/DQoNCj4gSSBhbSB1bnN1 cmUgb2YgdGhlIGJlc3Qgd29yZGluZyBoZXJlLiAgVGhpcyB0cmVhdG1lbnQgYXBwbGllcyB0byBh bGwNCj4gcGFja2V0cyBhc3NvY2lhdGVkIHRvIGFsbCA1LXR1cGxlcyAoZmxvd3MpIGNhcHR1cmVk IGJ5IHRoZQ0KPiBGaWx0ZXItUnVsZS4NCg0KUGxlYXNlIGFkZCB0aGF0IGxhdHRlciBzZW50ZW5j ZSAoIlRoaXMgdHJlYXRtZW50IGFwcGxpZXMgLi4uIikgdG8gdGhlIGRyYWZ0IC4uLg0KDQo+IEEg RmlsdGVyLVJ1bGUgbWF5IGNvbnRhaW4gYSBDbGFzc2lmaWVyIHRoYXQgZGVzY3JpYmVzIG9uZSBv ciBtYW55DQo+IDUtdHVwbGVzIHBlciBSRkMgNTc3Ny4NCg0KLi4uIGFuZCBwbGVhc2UgYWRkIHRo YXQgc2VudGVuY2UgYWxzbyA7LSkuDQoNClRoZSBnb2FsIGlzIHRvIGJlIGNsZWFyIHRoYXQ6DQot IGFkZGluZyBhbiBFQ04tSVAtQ29kZXBvaW50IEFWUCB0byBhIENsYXNzaWZpZXIgc3RpbGwgcmVz dWx0cyBpbiB0aGUNCkNsYXNzaWZpZXIgZGVzY3JpYmluZyA1LXR1cGxlIGZsb3dzIChhcyBvcHBv c2VkIHRvIHN1YnNldHMgb2YgNS10dXBsZQ0KZmxvd3MgdGhhdCBjb250YWluIGEgc3BlY2lmaWMg dmFsdWUgb3IgdmFsdWVzIGluIHRoZSBFQ04gZmllbGQpOyBhbmQNCi0gaGVuY2UsIHRoZSBDb25n ZXN0aW9uLVRyZWF0bWVudCBBVlAgYXBwbGllcyB0byA1LXR1cGxlcyBhbmQgbm90IHRvDQphbnl0 aGluZyBzbWFsbGVyLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQmVydHosIEx5bGUgVCBbQ1RPXSBbbWFpbHRvOkx5bGUuVC5CZXJ0 ekBzcHJpbnQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwgMjAxNSA4OjU5IFBNDQo+ IFRvOiBCbGFjaywgRGF2aWQ7IE1hcnRpbiBTdGllbWVybGluZzsgVGhlIElFU0cNCj4gQ2M6IGRp bWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbRGltZV0g TWFydGluIFN0aWVtZXJsaW5nJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRpbWUtDQo+IGNvbmdl c3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPg0K PiBEYXZpZCwNCj4NCj4gVHJhZmZpYyBmbG93KHMpIGFyZSBJUCAoNS10dXBsZSkgZmxvdyhzKS4N Cj4NCj4gTXkgcXVlc3Rpb24gdG8geW91IGlzIHdvdWxkIGl0IGJlIGJlc3QgdG8gc2F5ICJJUCBm bG93cyIgb3IgIklQICg1LXR1cGxlKQ0KPiBmbG93cyIgb3IgIjUtdHVwbGUgZmxvd3MiPyAgIEkg YW0gdW5zdXJlIG9mIHRoZSBiZXN0IHdvcmRpbmcgaGVyZS4gIFRoaXMNCj4gdHJlYXRtZW50IGFw cGxpZXMgdG8gYWxsIHBhY2tldHMgYXNzb2NpYXRlZCB0byBhbGwgNS10dXBsZXMgKGZsb3dzKQ0K PiBjYXB0dXJlZCBieSB0aGUgRmlsdGVyLVJ1bGUuDQo+DQo+IEEgRmlsdGVyLVJ1bGUgbWF5IGNv bnRhaW4gYSBDbGFzc2lmaWVyIHRoYXQgZGVzY3JpYmVzIG9uZSBvciBtYW55DQo+IDUtdHVwbGVz IHBlciBSRkMgNTc3Ny4NCj4NCj4gVGhhbmtzLg0KPiBMeWxlDQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEJsYWNrLCBEYXZpZCBbbWFpbHRvOmRhdmlkLmJsYWNrQGVt Yy5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1IDU6MTUgUE0NCj4gVG86IEJl cnR6LCBMeWxlIFQgW0NUT107IE1hcnRpbiBTdGllbWVybGluZzsgVGhlIElFU0cNCj4gQ2M6IGRp bWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYub3JnOyBCbGFjaywgRGF2aWQNCj4gU3ViamVj dDogUkU6IFtEaW1lXSBNYXJ0aW4gU3RpZW1lcmxpbmcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt ZGltZS0NCj4gY29uZ2VzdGlvbi1mbG93LWF0dHJpYnV0ZXMtMDE6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQo+DQo+IEx5bGUsDQo+DQo+ID4gICAgVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50 IEFWUCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQuIEl0DQo+ID4gICAgaW5kaWNh dGVzIGhvdyB0byB0cmVhdCB0cmFmZmljIGZsb3cocykgd2hlbiBjb25nZXN0aW9uIGlzIGRldGVj dGVkLg0KPiA+ICAgIFRoZSBkZXRlY3Rpb24gb2YgdGhlIGNvbmdlc3Rpb24gY2FuIGJlIGJhc2Vk IG9uIHRoZSByZWNlcHRpb24gb2YgSVANCj4gPiAgICBwYWNrZXRzIHBhY2tldCAgd2l0aCAgdGhl IENFIChDb25nZXN0aW9uIEV4cGVyaWVuY2VkKSBjb2RlcG9pbnQgc2V0DQo+ID4gICAoc2VlIFtS RkMgMzE2OF0pIG9yIGJ5IGFueSBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQgY3JpdGVy aWEuDQo+DQo+IFdoYXQgZG9lcyAidHJhZmZpYyBmbG93KHMpIiBtZWFuIGluIHRoaXMgdGV4dD8N Cj4NCj4gQSBjbGVhciBleHBsYW5hdGlvbiBvZiB0aGF0IHNob3VsZCByZW1vdmUgdGhlIGNvbmNl cm4gdGhhdCB0aGlzIGRyYWZ0DQo+IG1pZ2h0IGJlIGFwcGx5aW5nIGNvbmdlc3Rpb24gdHJlYXRt ZW50IHRvIGp1c3QgdGhlIENFLW1hcmtlZCBwYWNrZXRzDQo+IGFuZCBub3QgdGhlIGVudGlyZSA1 LXR1cGxlIChvciBtb3JlKS4NCj4NCj4gVGhhbmtzLA0KPiAtLURhdmlkDQo+DQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBCZXJ0eiwgTHlsZSBUIFtDVE9dIFttYWls dG86THlsZS5ULkJlcnR6QHNwcmludC5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMTEs IDIwMTUgNjowMiBQTQ0KPiA+IFRvOiBNYXJ0aW4gU3RpZW1lcmxpbmc7IFRoZSBJRVNHDQo+ID4g Q2M6IEJsYWNrLCBEYXZpZDsgZGltZUBpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmcNCj4g PiBTdWJqZWN0OiBSRTogW0RpbWVdIE1hcnRpbiBTdGllbWVybGluZydzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1kaW1lLQ0KPiA+IGNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gTWFydGluLA0KPiA+DQo+ID4gUmVnYXJkaW5n IHRoZSBESVNDVVNTIHBvaW50IHRoZSBsYW5ndWFnZSBpbiAzLjIgaXMgcHJvYmxlbWF0aWMsIHdl DQo+ID4gd2lsbCBjaGFuZ2UNCj4gPg0KPiA+ICAgIFRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBB VlAgKEFWUCBDb2RlIFRCRCkgaXMgb2YgdHlwZSBHcm91cGVkIGFuZA0KPiA+ICAgIGluZGljYXRl cyBob3cgY29uZ2VzdGVkIHRyYWZmaWMsIGkuZS4sIHRyYWZmaWMgdGhhdCBoYXMgRXhwbGljaXQN Cj4gPiAgICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1h cmtpbmcgc2V0IG9yIHNvbWUNCj4gPiAgICBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQg Y3JpdGVyaWEsIGlzIHRyZWF0ZWQuDQo+ID4NCj4gPiB0bw0KPiA+DQo+ID4gICAgVGhlIENvbmdl c3Rpb24tVHJlYXRtZW50IEFWUCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQuIEl0 DQo+ID4gICAgaW5kaWNhdGVzIGhvdyB0byB0cmVhdCB0cmFmZmljIGZsb3cocykgd2hlbiBjb25n ZXN0aW9uIGlzIGRldGVjdGVkLg0KPiA+ICAgIFRoZSBkZXRlY3Rpb24gb2YgdGhlIGNvbmdlc3Rp b24gY2FuIGJlIGJhc2VkIG9uIHRoZSByZWNlcHRpb24gb2YgSVANCj4gPiAgICBwYWNrZXRzIHBh Y2tldCAgd2l0aCAgdGhlIENFIChDb25nZXN0aW9uIEV4cGVyaWVuY2VkKSBjb2RlcG9pbnQgc2V0 DQo+ID4gICAoc2VlIFtSRkMgMzE2OF0pIG9yIGJ5IGFueSBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5 IGRlZmluZWQgY3JpdGVyaWEuDQo+ID4NCj4gPiBUaGUgcmF0aW9uYWxlIGZvciB0aGUgd29yZCAn ZmxvdyhzKScgaW4gdGhlIG5ldyBsYW5ndWFnZSBpcyB0aGUgbGFzdA0KPiA+IHNlbnRlbmNlIG9m IHRoZSBzZWN0aW9uICAzLjIgLSAgIlRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgaXMgYW4N Cj4gPiBhY3Rpb24gYW5kIE1VU1QgYmUgYW4gYXR0cmlidXRlIG9mIHRoZSBGaWx0ZXItUnVsZSBH cm91cGVkIEFWUCBhcw0KPiA+IGRlZmluZWQgaW4gUkZDNTc3Ny4gIiAgSXQgaXMgb3RoZXIgQVZQ cyBpbiB0aGUgRmlsdGVyLVJ1bGUsIGUuZy4NCj4gPiBDbGFzc2lmaWVyLCB0aGF0IGRlc2NyaWJl cyB0aGUgc2NvcGUgb2YgdHJhZmZpYyBpbXBhY3RlZC4gIFNheWluZw0KPiA+IHNvbWV0aGluZyBp biBTZWN0aW9uIDMuMiB0aGF0IGRvZXMgbm90IGFzc29jaWF0ZSB0aGUNCj4gPiBDb25nZXN0aW9u LVRyZWF0bWVudCBBVlAgdG8gdGhlIEZpbHRlci1SdWxlIGl0IGlzIGEgcGFydCBvZiBvbmx5DQo+ ID4gY3JlYXRlcw0KPiBjb25mdXNpb24uDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiBQZXIgdGhlIENPTU1FTlQsIHlvdSBhcmUgY29ycmVjdC4gIFdlJ2xs IGNoYW5nZQ0KPiA+DQo+ID4gIlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0IHN1cHBvcnQg Zm9yIEVDTiBbUkZDMzE2OF0gaW4gdGhlIElQDQo+ID4gICBoZWFkZXLigJwNCj4gPg0KPiA+IHRv IHlvdXIgc3VnZ2VzdGlvbg0KPiA+DQo+ID4gIlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0 IHN1cHBvcnQgZm9yIGZpbHRlcmluZyBFQ04NCj4gPiAgIG1hcmtlZCB0cmFmZmljW1JGQzMxNjhd 4oCcDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERpTUUg W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4NCj4gPiBT dGllbWVybGluZw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMCwgMjAxNSAzOjM2IFBNDQo+ ID4gVG86IFRoZSBJRVNHDQo+ID4gQ2M6IGRhdmlkLmJsYWNrQGVtYy5jb207IGRpbWVAaWV0Zi5v cmc7IGRpbWUtY2hhaXJzQGlldGYub3JnDQo+ID4gU3ViamVjdDogW0RpbWVdIE1hcnRpbiBTdGll bWVybGluZydzIERpc2N1c3Mgb24NCj4gPiBkcmFmdC1pZXRmLWRpbWUtY29uZ2VzdGlvbi0NCj4g PiBmbG93LWF0dHJpYnV0ZXMtMDE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4g PiBNYXJ0aW4gU3RpZW1lcmxpbmcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQo+ID4gZHJhZnQtaWV0Zi1kaW1lLWNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVz LTAxOiBEaXNjdXNzDQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiA+IGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiA+IGN1dCB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVh c2UgcmVmZXIgdG8NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+DQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWNvbmdl c3Rpb24tZmxvdy1hdHQNCj4gPiByaQ0KPiA+IGJ1dGVzLw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gLS0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0N Cj4gPg0KPiA+IE5vIGdlbmVyYWwgb2JqZWN0aW9uIHRvIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUg ZG9jdW1lbnQuIEhvd2V2ZXIsIEkNCj4gPiBhbSByZWxheWluZyBhIHF1ZXN0aW9uIGZyb20gRGF2 aWQgQmxhY2sgYXMgYSBESVNDVVNTIHBvaW50Lg0KPiA+DQo+ID4gSSBhc3N1bWUgdGhhdCB0aGUg ZHJhZnQgaXMgbW9yZSB0aGFuIHVuY2xlYXIgaW4gU2VjdGlvbiAzLjIgIGFib3V0DQo+ID4gd2hh dCB0cmFmZmljIG1lYW5zLiBJcyBpdCBhIHBhcnRpY3VsYXIgZmxvdywgYSBzaW5nbGUgcGFja2V0 LCBldGM/DQo+ID4NCj4gPiAiSSBmb3VuZCBhbiBFQ04gY29uY2VybiwgYW5kIGhlbmNlIGFkZGVk IHRoZSBUU1YgQURzIHRvIHRoZSBDQyBsaW5lLg0KPiA+DQo+ID4gU2VjdGlvbiAzLjIgc2F5czoN Cj4gPg0KPiA+ICAgIFRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgKEFWUCBDb2RlIFRCRCkg aXMgb2YgdHlwZSBHcm91cGVkIGFuZA0KPiA+ICAgIGluZGljYXRlcyBob3cgY29uZ2VzdGVkIHRy YWZmaWMsIGkuZS4sIHRyYWZmaWMgdGhhdCBoYXMgRXhwbGljaXQNCj4gPiAgICBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1hcmtpbmcgc2V0IG9yIHNvbWUN Cj4gPiAgICBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQgY3JpdGVyaWEsIGlzIHRyZWF0 ZWQuDQo+ID4NCj4gPiBUaGF0IGFwcGVhcnMgdG8gc2F5IHRoYXQgdGhlIGNvbmdlc3Rpb24gdHJl YXRtZW50IG1heSBiZSBhcHBsaWVkDQo+ID4gc29sZWx5IHRvIHBhY2tldHMgdGhhdCBoYXZlIHRo ZSBDRSAoQ29uZ2VzdGlvbiBFeHBlcmllbmNlZCkgbWFya2luZy4NCj4gPiBUaGF0IHdvdWxkIGJl IGEgcHJvYmxlbSwgYmVjYXVzZSB0aGUgZGVmaW5lZCBzZW1hbnRpY3Mgb2YgYSBDRQ0KPiA+IG1h cmtpbmcgaXMgdGhhdCBpdCBhcHBsaWVzIHRvIHRoZSBlbnRpcmUgZmxvdyAoZS5nLiwgY2F1c2Vz IFRDUCB0bw0KPiA+IHJlYWN0IGFzIGlmIGEgcGFja2V0IGhhcyBiZWVuIGRyb3BwZWQpLCBoZW5j ZSB0aGUgY29uZ2VzdGlvbg0KPiA+IHRyZWF0bWVudCBvdWdodCB0byBhcHBseSB0byB0aGUgZW50 aXJlIGZsb3cuDQo+ID4NCj4gPiBJbiBvdGhlciB3b3Jkcywgb25lIHdhbnRzIHRvIGJlIGFibGUg dG8gdXNlIHRoZSBFQ04tSVAtQ29kZXBvaW50IEFWUA0KPiA+IGFzIHBhcnQgb2YgdGhlIGNvbmRp dGlvbiB0aGF0IGRldGVybWluZXMgd2hldGhlciB0aGUgZmlsdGVyIHJ1bGUNCj4gPiBtYXRjaGVz LCBidXQgaWdub3JlIHRoYXQgQVZQIChpLmUuLCB3aWxkY2FyZCBpdCkgaW4gZGV0ZXJtaW5pbmcg d2hhdA0KPiA+IHRyYWZmaWMgdGhlIGFjdGlvbiBhcHBsaWVzIHRvLCBzbyB0aGF0IHRoZSByZXNw b25zZSB0byBkZXRlY3RpbmcgYQ0KPiA+IGNvbmdlc3RlZCBmbG93IChpLmUuLCBwYWNrZXRzIHdp dGggRUNOIGZpZWxkIGNvbnRhaW5pbmcgQ0UpIGFwcGxpZXMNCj4gPiB0byBhbGwgcGFja2V0cyBp biB0aGUgZmxvdywgcmVnYXJkbGVzcyBvZiB0aGUgdmFsdWUgaW4gdGhlIENFIGZpZWxkLg0KPiA+ DQo+ID4gT3RoZXJ3aXNlLCB0aGUgcmVzdWx0IG1heSBiZSBpbmVmZmVjdGl2ZSwgYXMgaXQgd29u J3QgZW5jb21wYXNzDQo+ID4gcGFja2V0cyBpbiB0aGUgY29uZ2VzdGVkIGZsb3cgdGhhdCBhcmVu J3QgQ0UtbWFya2VkLg0KPiA+DQo+ID4gQW0gSSByZWFkaW5nIHRoZSBkcmFmdCBjb3JyZWN0bHk/ Ig0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gQ09NTUVOVDoNCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4NCj4gPiBTZWN0aW9uIDEsIDFzdCBwYXJhZ3JhcGg6DQo+ ID4gSXQgc2F5cyAiVGhlIGZpcnN0IEFWUCBwcm92aWRlcyBkaXJlY3Qgc3VwcG9ydCBmb3IgRUNO IFtSRkMzMTY4XSBpbg0KPiA+IHRoZSBJUCBoZWFkZXLigJwuIEkgYW0gIHN1cmUgdGhhdCB5b3Vy IGRyYWZ0IGlzICBvdCBwcm92aWRpbmcgYW55DQo+ID4gc3VwcG9ydCBmb3IgRUNOIGluIHRoZSBJ UCBoZWFkZXIsIGFzIHdlIGhhdmUgRUNOIGluIHRoZSBJUCBoZWFkZXINCj4gPiBhbHJlYWR5LA0K PiBpc24ndCBpdC4NCj4gPiBJIGd1ZXNzIHlvdSBtZWFuIHNvbWV0aGluZyBsaWtlIHRoaXMgIlRo ZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0DQo+ID4gc3VwcG9ydCBmb3IgZmlsdGVyaW5nIEVD TiBtYXJrZWQgdHJhZmZpY1tSRkMzMTY4XeKAnA0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERpTUUgbWFpbGluZyBsaXN0 DQo+ID4gRGlNRUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pg0KPiA+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiBpbnRlbmRlZCBmb3INCj4gPiB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4g QW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4NCj4gPiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZA0KPiA+IGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPg0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yDQo+IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVj aXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZg0KPiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFu ZA0KPiBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3By aWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lw aWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Fri Jun 12 11:12:32 2015 Return-Path: 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 325BE1ACE93; Fri, 12 Jun 2015 11:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 R39UAjBGjE2s; Fri, 12 Jun 2015 11:12:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2471ACE8B; Fri, 12 Jun 2015 11:12:25 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3E9203744C1; Fri, 12 Jun 2015 20:12:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.33]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0E8AE15804E; Fri, 12 Jun 2015 20:12:23 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0235.001; Fri, 12 Jun 2015 20:12:22 +0200 From: To: "Bertz, Lyle T [CTO]" , "Black, David" , Martin Stiemerling , The IESG Thread-Topic: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AQHQpTtUURWvKT/B9E+eEEoG25E/6w== Date: Fri, 12 Jun 2015 18:12:22 +0000 Message-ID: <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: , <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> In-Reply-To: <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01C4EABFOPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.12.174515 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:12:31 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01C4EABFOPEXCLILM43corp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Except that a "packets packet" is maybe too explicit! :) (Second sentence) Please wait for a formal go-ahead from the AD or myself before submitting a= new version. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "Bertz, Lyle T [CTO]" Pour : "Black, David" , "Martin Stiemerling" , "The IESG" Cc : "dime@ietf.org" , "dime-chairs@ietf.org" Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT) Date : ven., juin 12, 2015 19:32 David, Thanks for the guidance here. We definitely want to meet the goals you not= e below. I will assume Martin has no objection to "IP (5-tuple) flows". If so, we c= an adjust the language. New language (I also changed 'In case the" to "If the" at the beginning of = the next paragraph. > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic IP (5-tuple) flow(s) when congestion = is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > A Filter-Rule may contain a Classifier that describes one or many 5-t= uples per > > RFC 5777. This treatment applies to all packets associated to all 5-= tuples (flows) > > captured by the Filter-Rule. > > > > If the Congestion-Treatment AVP is absent... I believe this language meets the objectives outlined below. Thank you. Lyle -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Friday, June 12, 2015 10:33 AM To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT) Lyle, Thanks for the explanation - for my concern, I think we're close to done... > Traffic flow(s) are IP (5-tuple) flow(s). That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem. > My question to you is would it be best to say "IP flows" or "IP > (5-tuple) flows" or "5-tuple flows"? I like "IP (5-tuple) flows" - Martin? > I am unsure of the best wording here. This treatment applies to all > packets associated to all 5-tuples (flows) captured by the > Filter-Rule. Please add that latter sentence ("This treatment applies ...") to the draft= ... > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. ... and please add that sentence also ;-). The goal is to be clear that: - adding an ECN-IP-Codepoint AVP to a Classifier still results in the Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple flows that contain a specific value or values in the ECN field); and - hence, the Congestion-Treatment AVP applies to 5-tuples and not to anything smaller. Thanks, --David > -----Original Message----- > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > Sent: Thursday, June 11, 2015 8:59 PM > To: Black, David; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > David, > > Traffic flow(s) are IP (5-tuple) flow(s). > > My question to you is would it be best to say "IP flows" or "IP (5-tuple) > flows" or "5-tuple flows"? I am unsure of the best wording here. This > treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule. > > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. > > Thanks. > Lyle > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, June 11, 2015 5:15 PM > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > Lyle, > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > What does "traffic flow(s)" mean in this text? > > A clear explanation of that should remove the concern that this draft > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more). > > Thanks, > --David > > > -----Original Message----- > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > > Sent: Thursday, June 11, 2015 6:02 PM > > To: Martin Stiemerling; The IESG > > Cc: Black, David; dime@ietf.org; dime-chairs@ietf.org > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin, > > > > Regarding the DISCUSS point the language in 3.2 is problematic, we > > will change > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > to > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > The rationale for the word 'flow(s)' in the new language is the last > > sentence of the section 3.2 - "The Congestion-Treatment AVP is an > > action and MUST be an attribute of the Filter-Rule Grouped AVP as > > defined in RFC5777. " It is other AVPs in the Filter-Rule, e.g. > > Classifier, that describes the scope of traffic impacted. Saying > > something in Section 3.2 that does not associate the > > Congestion-Treatment AVP to the Filter-Rule it is a part of only > > creates > confusion. > > > > --------------------------------- > > Per the COMMENT, you are correct. We'll change > > > > "The first AVP provides direct support for ECN [RFC3168] in the IP > > header=93 > > > > to your suggestion > > > > "The first AVP provides direct support for filtering ECN > > marked traffic[RFC3168]=93 > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Martin > > Stiemerling > > Sent: Wednesday, June 10, 2015 3:36 PM > > To: The IESG > > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org > > Subject: [Dime] Martin Stiemerling's Discuss on > > draft-ietf-dime-congestion- > > flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin Stiemerling has entered the following ballot position for > > draft-ietf-dime-congestion-flow-attributes-01: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri > > butes/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > No general objection to the publication of the document. However, I > > am relaying a question from David Black as a DISCUSS point. > > > > I assume that the draft is more than unclear in Section 3.2 about > > what traffic means. Is it a particular flow, a single packet, etc? > > > > "I found an ECN concern, and hence added the TSV ADs to the CC line. > > > > Section 3.2 says: > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > That appears to say that the congestion treatment may be applied > > solely to packets that have the CE (Congestion Experienced) marking. > > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP to > > react as if a packet has been dropped), hence the congestion > > treatment ought to apply to the entire flow. > > > > In other words, one wants to be able to use the ECN-IP-Codepoint AVP > > as part of the condition that determines whether the filter rule > > matches, but ignore that AVP (i.e., wildcard it) in determining what > > traffic the action applies to, so that the response to detecting a > > congested flow (i.e., packets with ECN field containing CE) applies > > to all packets in the flow, regardless of the value in the CE field. > > > > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked. > > > > Am I reading the draft correctly?" > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Section 1, 1st paragraph: > > It says "The first AVP provides direct support for ECN [RFC3168] in > > the IP header=93. I am sure that your draft is ot providing any > > support for ECN in the IP header, as we have ECN in the IP header > > already, > isn't it. > > I guess you mean something like this "The first AVP provides direct > > support for filtering ECN marked traffic[RFC3168]=93 > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information intended for > > the sole use of the recipient(s). Any use by others is prohibited. > > If you are not the intended recipient, please contact the sender and > > delete all copies of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E01C4EABFOPEXCLILM43corp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Except that a "packets packet" is maybe too explicit! :)

(Second sentence)
Please wait for a formal go-ahead from the AD or myself before submitt= ing a new version.

Regards,

Lionel 

Envoy=E9 depuis mon mobile Orange

----- Reply message -----
De : "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Pour : "Black, David" <david.black@emc.com>, "Mar= tin Stiemerling" <mls.ietf@gmail.com>, "The IESG" <= iesg@ietf.org>
Cc : "dime@ietf.org" <dime@ietf.org>, "dime-chairs@iet= f.org" <dime-chairs@ietf.org>
Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT)
Date : ven., juin 12, 2015 19:32

David,

Thanks for the guidance here.  We definitely want to meet the goals yo= u note below.

I will assume Martin has no objection to "IP (5-tuple) flows".&nb= sp; If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" at th= e beginning of the next paragraph.

> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic IP (5-tuple) flo= w(s) when congestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> >   A Filter-Rule may contain a Classifier that describes= one or many 5-tuples per
> >   RFC 5777.  This treatment applies to all packets= associated to all 5-tuples (flows) > >   captured by the F= ilter-Rule.
> >
> >   If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.bla= ck@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to done...=

> Traffic flow(s) are IP (5-tuple) flow(s).

That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or = "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

> I am unsure of the best wording here.  This treatment applies to = all
> packets associated to all 5-tuples (flows) captured by the
> Filter-Rule.

Please add that latter sentence ("This treatment applies ...") to= the draft ...

> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [= mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> David,
>
> Traffic flow(s) are IP (5-tuple) flow(s).
>
> My question to you is would it be best to say "IP flows" or = "IP (5-tuple)
> flows" or "5-tuple flows"?   I am unsure of t= he best wording here.  This
> treatment applies to all packets associated to all 5-tuples (flows)
> captured by the Filter-Rule.
>
> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.
>
> Thanks.
> Lyle
>
> -----Original Message-----
> From: Black, David [mailto:davi= d.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
>
> What does "traffic flow(s)" mean in this text?
>
> A clear explanation of that should remove the concern that this draft<= br> > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more).
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-di= me-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, w= e
> > will change
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > to
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> > The rationale for the word 'flow(s)' in the new language is the l= ast
> > sentence of the section  3.2 -  "The Congestion-Tr= eatment AVP is an
> > action and MUST be an attribute of the Filter-Rule Grouped AVP as=
> > defined in RFC5777. "  It is other AVPs in the Filter-R= ule, e.g.
> > Classifier, that describes the scope of traffic impacted.  S= aying
> > something in Section 3.2 that does not associate the
> > Congestion-Treatment AVP to the Filter-Rule it is a part of only<= br> > > creates
> confusion.
> >
> > ---------------------------------
> > Per the COMMENT, you are correct.  We'll change
> >
> > "The first AVP provides direct support for ECN [RFC3168] in = the IP
> >   header=93
> >
> > to your suggestion
> >
> > "The first AVP provides direct support for filtering ECN
> >   marked traffic[RFC3168]=93
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-= bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin Stiemerling has entered the following ballot position for<= br> > > draft-ietf-dime-congestion-flow-attributes-01: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att
> > ri
> > butes/
> >
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > No general objection to the publication of the document. However,= I
> > am relaying a question from David Black as a DISCUSS point.
> >
> > I assume that the draft is more than unclear in Section 3.2 = about
> > what traffic means. Is it a particular flow, a single packet, etc= ?
> >
> > "I found an ECN concern, and hence added the TSV ADs to the = CC line.
> >
> > Section 3.2 says:
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > That appears to say that the congestion treatment may be applied<= br> > > solely to packets that have the CE (Congestion Experienced) marki= ng.
> > That would be a problem, because the defined semantics of a CE
> > marking is that it applies to the entire flow (e.g., causes TCP t= o
> > react as if a packet has been dropped), hence the congestion
> > treatment ought to apply to the entire flow.
> >
> > In other words, one wants to be able to use the ECN-IP-Codepoint = AVP
> > as part of the condition that determines whether the filter rule<= br> > > matches, but ignore that AVP (i.e., wildcard it) in determining w= hat
> > traffic the action applies to, so that the response to detecting = a
> > congested flow (i.e., packets with ECN field containing CE) appli= es
> > to all packets in the flow, regardless of the value in the CE fie= ld.
> >
> > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked.
> >
> > Am I reading the draft correctly?"
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 1, 1st paragraph:
> > It says "The first AVP provides direct support for ECN [RFC3= 168] in
> > the IP header=93. I am  sure that your draft is  ot pro= viding any
> > support for ECN in the IP header, as we have ECN in the IP header=
> > already,
> isn't it.
> > I guess you mean something like this "The first AVP provides= direct
> > support for filtering ECN marked traffic[RFC3168]=93
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww= w.ietf.org/mailman/listinfo/dime
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended f= or
> > the sole use of the recipient(s). Any use by others is prohibited= .
> > If you are not the intended recipient, please contact the sender = and
> > delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for
> the sole use of the recipient(s). Any use by others is prohibited. If<= br> > you are not the intended recipient, please contact the sender and
> delete all copies of the message.

________________________________

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E01C4EABFOPEXCLILM43corp_-- From nobody Fri Jun 12 11:22:00 2015 Return-Path: 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 1D9161AC7E8; Fri, 12 Jun 2015 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 P3uhfLo9Alvd; Fri, 12 Jun 2015 11:21:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFB11A8A7B; Fri, 12 Jun 2015 11:21:48 -0700 (PDT) Received: from BY2FFO11FD034.protection.gbl (10.1.14.34) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.1.190.9; Fri, 12 Jun 2015 18:21:46 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Fri, 12 Jun 2015 18:21:46 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5CI1XQi023786; Fri, 12 Jun 2015 13:21:45 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm1.corp.sprint.com with ESMTP id 1uuxgbbxrx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Jun 2015 13:21:45 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 12 Jun 2015 13:21:44 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Fri, 12 Jun 2015 13:21:44 -0500 From: "Bertz, Lyle T [CTO]" To: "lionel.morand@orange.com" , "Black, David" , Martin Stiemerling , The IESG Thread-Topic: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AdClJQY74X8SI5Wk1EqRdOJjKpM6WAAAdEjgAA+ZTAAACk8TsA== Date: Fri, 12 Jun 2015 18:21:44 +0000 Message-ID: <565c7289e23441ff93f3fd8328bb1107@PLSWE13M07.ad.sprint.com> References: , <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: multipart/alternative; boundary="_000_565c7289e23441ff93f3fd8328bb1107PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD034; 1:gTNDMyYQI8g0JnUG4tlx8mGGqRJlWjTRqvqmnogwM4rfeipncYU62r+8vobicgU28O+k4LJFCXEEo08vjrVh4LmTofclRgSYRQSEUjD8f6QO8SW7j4wm7ppP8B/Rx7pzpZGAy3Ypgaxi+78l7Ha6N2KCOd6Lyzse/UN6OyL9VhRt7BiJd2Sic+kzl5Squ2XAkj6NlBw2EBT+yHZzeGYc6E7bkIyFoY4m4qV8X6jxwC+PI+0G9hk2ak0u4uM5VDLffLFVPzYQHSCHRI+mPfqli5mPUycvuayZ1et/BVX/n5BbWzsOGjN2e78dpA99gt7sd31b4WXtC3SdUbj/tKklUOFQ0fOK2xCwGknGK0wIc0fW11qLYOHJUbxnE1rNzP4n X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(448002)(164054003)(52044002)(199003)(13464003)(51704005)(189002)(51914003)(377454003)(19617315012)(33646002)(230783001)(106466001)(46102003)(189998001)(6806004)(5001770100001)(62966003)(77156002)(24736003)(5001960100002)(512934002)(2501003)(19300405004)(5003600100002)(19580395003)(92566002)(16236675004)(19580405001)(50986999)(76176999)(54356999)(5890100001)(87936001)(4546004)(30436002)(86362001)(19625215002)(2950100001)(2900100001)(108616004)(2656002)(85326001)(84326002)(102836002)(15975445007)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB031; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB031; 2:IrieQPvOqXbiaqQO2J4fkoDjkOW+VL/ogAFPrtC3pJD6VnF+bjFQZJNNl2YFJo9I; 2:a52Hj7fZOb4O/wf3cRuYn1LdBcbdUzBFopgcTQy4rJA+9HwgaN2CpYmFMhj8u0Le82PjzDLl3weG1NxECV6ati6n81EvfJdoHRvEr/Kq6+f9pUkDtWd23qCAGOAA8pkpL5Zm3bdyajgWazaTrfwN4rm0dDTfqq6W9RuQ1E7vQjVpsyV52nP2uQeuFmiWjIXk3P05FdUSF4o4Dpc50Y0ClgpqscJuHqpAcvdLCFmpo6qdg119fuTHa3lyaXe92CrB; 6:5QxIpnNWpybDvQ2u9F6SQE4cXGw+i5N25P6NFLnzR0D1ykQg2pPS5Ea9h/75YQ/SudxrBNaTuBNgHcD4/c7aOEhq/xMPL9PwDYeUo2LHaLNPeB66R3nLHqY3VLIR9/mVdDNfLpYxcnTrdQtTcGxxHXwPns9+OGXI44Il0F5iMLMzImxORakaXF4dw1k8dJxMea42rJd+ZWElVZKCLwSm4lXyw2HDoIDUDIYGSsBPWDCE/48fa5WX6BiGWwZw6XhQ; 3:UBlpgSCFJ0HxiyAKbSNiZFIFs9YO4zTB7znVKWsOGYW0UqJnj7MlKDhkZOKug73QH6tNRbIQp5tFOCEjXVNp+Qy3vrHsVKca9LcjQYDphheiZwX5QeWbZ6Th3IrkUYVuOjzYgtv3KA+QF0pq/3O3LHK8KJ9XxEx7fgCfeXEmBml872rdoPe1PCdl22CLVTT2WeYENRP/MQlr3E23W/H769AIYZtF6dprnnn1m5YBM9lgPo+TGBGlDxvnmXCZFd+WbIAdGj8C46po44cvFY2wb4aWPVQjsDDfmc5p5HN38n2P84yywXT3o6qyQkYNJvqo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB031; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BY2FFO11HUB031; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB031; X-Forefront-PRVS: 060503E79B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB031; 9:VGRC+BRQF4zli4ZjZFA4RN8Q54RV/TP/WEjss84wS?= =?us-ascii?Q?SBdBb9Qz371LUKOVthaam/mc9R0da2BCxwhgYxaKOscj87j0y5bLrILAUsva?= =?us-ascii?Q?zRBs5iM6CxQt46rxW4xGhcBoI8bYBZ8M8gX1hyuyMzA6lbYYhysSbZKgcA1t?= =?us-ascii?Q?wNFGYjdBJvStW5nGIXEyysR3XUrEviCWGbKW53qA4S3d0S9foDiTs3uvu8Ik?= =?us-ascii?Q?X6SViC5XVLMinhVt49x0RrEfvVzPUEnxppvl70lVwDfvcvOZOpw0jP4hSk0n?= =?us-ascii?Q?UeGPDAs15Aq3EaPlBvvUpFu/m3dpzRbSMh5viMX2i+nkWcIN4lCChMbUtk//?= =?us-ascii?Q?RXsXVJf7qen9vXjfjJTXdlxNiOhb9dCgHI4TBgxQbontYP0xA6OgC9s+TWdx?= =?us-ascii?Q?9kfuvdlxhMO6uBpBMzO7ztkXQqCshM6EDcc0VeKzTjwBNVsInsWsKwa+9Yz5?= =?us-ascii?Q?im6vcFkQhw26jNMUWUpXyxFcD9h2EOTN7RDGCRBXb5CsOQwhLaWiyQYtcu9g?= =?us-ascii?Q?kQC9VkgZ0IbqWP10FRWvLXWx+mLy4MoyFAbv/fRzQiJXj1g9FvcxvrZZXEU/?= =?us-ascii?Q?YsaYsfn+7LhUqE1BLv9IdggwHt4h/Z18X6FY/064gScx+jV47Z2wwLVGgGV3?= =?us-ascii?Q?2YPF7g4iec5tuoo2MyqctY7P4F140rOJPxrP2/Fv1RZKv8QK3uIO2PkgFlnR?= =?us-ascii?Q?tRMkgnvMGATGsHid7UusOv+F4KhC4malMMYSHmjGMz18UWzx8nctbEf4QRgS?= =?us-ascii?Q?lJft7z/bluUv3RCRkpRB1l2bsufpoP8o2NuVhhBuSZDM1jCPkPbQBvE62TU8?= =?us-ascii?Q?LxVY8MVS0J1va5KjCKJJU5UdKiNsY9TzJQX4bD3YGYWs6BpflFZqjGzBgIjd?= =?us-ascii?Q?MUdIjIj4LRewBr/zgeD/DDO3R+1MrFqRGRcQmbfxlNjxK5mm26kl2Qdfv+nc?= =?us-ascii?Q?j1XaAcvE4mWobRTCYuaoo98egChVPvv3uanCcDSnuAy+YfSR0vKO+oLsjCCZ?= =?us-ascii?Q?TOAf4bkZeBQyj430FYIOzn7zv730YMnIrZAoEiZKvAPtHWWPd3Qb56vYNG/o?= =?us-ascii?Q?7shDiD+8jsNVRoM+9hRq35l3lovw0x6atwjR7AmAfDW/gcyttwbjUTtg3e+R?= =?us-ascii?Q?JTLtFjte8WSQiaux4FdeywX0tAUAGZTjy4ocY4hIhrR0QAXb9fIcx9evAp7b?= =?us-ascii?Q?222wA/GTqe7ojlHjNAIARkVXzJZIyBdwU4PQdx+VDKILUbltyoPPvdvJA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB031; 3:TZqB+xMQtcN7KO9oaceb+GivitsS2cI0uNCNhQAUKOw3Kq2kdWVYUktQPq1hkzVSXECIlszFHY5rkBZAX4ezy9WevaDQIVUovH4b6mgcKcc0tRF7EgANzPYVymS9VIEgdjTZFdAX4rdvaQdUf//HxQ==; 10:lNFWaUFEQymYrvRTHX40ggJgpOzlcc5Y3nKhVJaIjb/eodJvRQIdqcTOE+KJx2OhY4zDe4m7jFBR+RLiRx4TFBLdo+uauY3F2v9/a1OlNuk= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2015 18:21:46.2295 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB031 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:21:57 -0000 --_000_565c7289e23441ff93f3fd8328bb1107PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... Even my corrections have errors this week. From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Friday, June 12, 2015 1:12 PM To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-conges= tion-flow-attributes-01: (with DISCUSS and COMMENT) Except that a "packets packet" is maybe too explicit! :) (Second sentence) Please wait for a formal go-ahead from the AD or myself before submitting a= new version. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "Bertz, Lyle T [CTO]" > Pour : "Black, David" >, "M= artin Stiemerling" >, "The IE= SG" > Cc : "dime@ietf.org" >, "dime-chairs@ietf.org" > Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT) Date : ven., juin 12, 2015 19:32 David, Thanks for the guidance here. We definitely want to meet the goals you not= e below. I will assume Martin has no objection to "IP (5-tuple) flows". If so, we c= an adjust the language. New language (I also changed 'In case the" to "If the" at the beginning of = the next paragraph. > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic IP (5-tuple) flow(s) when congestion = is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > A Filter-Rule may contain a Classifier that describes one or many 5-t= uples per > > RFC 5777. This treatment applies to all packets associated to all 5-= tuples (flows) > > captured by the Filter-Rule. > > > > If the Congestion-Treatment AVP is absent... I believe this language meets the objectives outlined below. Thank you. Lyle -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Friday, June 12, 2015 10:33 AM To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT) Lyle, Thanks for the explanation - for my concern, I think we're close to done... > Traffic flow(s) are IP (5-tuple) flow(s). That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem. > My question to you is would it be best to say "IP flows" or "IP > (5-tuple) flows" or "5-tuple flows"? I like "IP (5-tuple) flows" - Martin? > I am unsure of the best wording here. This treatment applies to all > packets associated to all 5-tuples (flows) captured by the > Filter-Rule. Please add that latter sentence ("This treatment applies ...") to the draft= ... > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. ... and please add that sentence also ;-). The goal is to be clear that: - adding an ECN-IP-Codepoint AVP to a Classifier still results in the Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple flows that contain a specific value or values in the ECN field); and - hence, the Congestion-Treatment AVP applies to 5-tuples and not to anything smaller. Thanks, --David > -----Original Message----- > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > Sent: Thursday, June 11, 2015 8:59 PM > To: Black, David; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > David, > > Traffic flow(s) are IP (5-tuple) flow(s). > > My question to you is would it be best to say "IP flows" or "IP (5-tuple) > flows" or "5-tuple flows"? I am unsure of the best wording here. This > treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule. > > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. > > Thanks. > Lyle > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, June 11, 2015 5:15 PM > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > Lyle, > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > What does "traffic flow(s)" mean in this text? > > A clear explanation of that should remove the concern that this draft > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more). > > Thanks, > --David > > > -----Original Message----- > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > > Sent: Thursday, June 11, 2015 6:02 PM > > To: Martin Stiemerling; The IESG > > Cc: Black, David; dime@ietf.org; dime-chairs@ietf= .org > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin, > > > > Regarding the DISCUSS point the language in 3.2 is problematic, we > > will change > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > to > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > The rationale for the word 'flow(s)' in the new language is the last > > sentence of the section 3.2 - "The Congestion-Treatment AVP is an > > action and MUST be an attribute of the Filter-Rule Grouped AVP as > > defined in RFC5777. " It is other AVPs in the Filter-Rule, e.g. > > Classifier, that describes the scope of traffic impacted. Saying > > something in Section 3.2 that does not associate the > > Congestion-Treatment AVP to the Filter-Rule it is a part of only > > creates > confusion. > > > > --------------------------------- > > Per the COMMENT, you are correct. We'll change > > > > "The first AVP provides direct support for ECN [RFC3168] in the IP > > header" > > > > to your suggestion > > > > "The first AVP provides direct support for filtering ECN > > marked traffic[RFC3168]" > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Martin > > Stiemerling > > Sent: Wednesday, June 10, 2015 3:36 PM > > To: The IESG > > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org > > Subject: [Dime] Martin Stiemerling's Discuss on > > draft-ietf-dime-congestion- > > flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin Stiemerling has entered the following ballot position for > > draft-ietf-dime-congestion-flow-attributes-01: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri > > butes/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > No general objection to the publication of the document. However, I > > am relaying a question from David Black as a DISCUSS point. > > > > I assume that the draft is more than unclear in Section 3.2 about > > what traffic means. Is it a particular flow, a single packet, etc? > > > > "I found an ECN concern, and hence added the TSV ADs to the CC line. > > > > Section 3.2 says: > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > That appears to say that the congestion treatment may be applied > > solely to packets that have the CE (Congestion Experienced) marking. > > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP to > > react as if a packet has been dropped), hence the congestion > > treatment ought to apply to the entire flow. > > > > In other words, one wants to be able to use the ECN-IP-Codepoint AVP > > as part of the condition that determines whether the filter rule > > matches, but ignore that AVP (i.e., wildcard it) in determining what > > traffic the action applies to, so that the response to detecting a > > congested flow (i.e., packets with ECN field containing CE) applies > > to all packets in the flow, regardless of the value in the CE field. > > > > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked. > > > > Am I reading the draft correctly?" > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Section 1, 1st paragraph: > > It says "The first AVP provides direct support for ECN [RFC3168] in > > the IP header". I am sure that your draft is ot providing any > > support for ECN in the IP header, as we have ECN in the IP header > > already, > isn't it. > > I guess you mean something like this "The first AVP provides direct > > support for filtering ECN marked traffic[RFC3168]" > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information intended for > > the sole use of the recipient(s). Any use by others is prohibited. > > If you are not the intended recipient, please contact the sender and > > delete all copies of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_565c7289e23441ff93f3fd8328bb1107PLSWE13M07adsprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<sigh>… Even my correctio= ns have errors this week. 

From: lionel.morand@orange.com [mail= to:lionel.morand@orange.com]
Sent: Friday, June 12, 2015 1:12 PM
To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG<= br> Cc: dime@ietf.org; dime-chairs@ietf.org
Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime= -congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

Except that a "packets packet" is maybe too explicit! :)

 

(Second sentence)

Please wait for a formal go-ahead from the AD or myself before submi= tting a new version.

 

Regards,

 

Lionel 

 

Envoy=E9 depuis mon mobile Orange

 

----- Reply message -----
De : "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Pour : "Black, David" <david.black@emc.com>, "Martin Stiemerling" <mls.ietf@gmail.com>, "The IESG&= quot; <iesg@ietf.org>
Cc : "dime@ietf.org" <dime@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>
Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT)
Date : ven., juin 12, 2015 19:32

 

David,

Thanks for the guidance here.  We definitely want to meet the goals yo= u note below.

I will assume Martin has no objection to "IP (5-tuple) flows".&nb= sp; If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" at th= e beginning of the next paragraph.

> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic IP (5-tuple) flo= w(s) when congestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> >   A Filter-Rule may contain a Classifier that describes= one or many 5-tuples per
> >   RFC 5777.  This treatment applies to all packets= associated to all 5-tuples (flows) > >   captured by the F= ilter-Rule.
> >
> >   If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.bla= ck@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to done...=

> Traffic flow(s) are IP (5-tuple) flow(s).

That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or = "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

> I am unsure of the best wording here.  This treatment applies to = all
> packets associated to all 5-tuples (flows) captured by the
> Filter-Rule.

Please add that latter sentence ("This treatment applies ...") to= the draft ...

> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [= mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> David,
>
> Traffic flow(s) are IP (5-tuple) flow(s).
>
> My question to you is would it be best to say "IP flows" or = "IP (5-tuple)
> flows" or "5-tuple flows"?   I am unsure of t= he best wording here.  This
> treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule.
>
> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.
>
> Thanks.
> Lyle
>
> -----Original Message-----
> From: Black, David [mailto:davi= d.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
>
> What does "traffic flow(s)" mean in this text?
>
> A clear explanation of that should remove the concern that this draft<= br> > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more).
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org<= /a>; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-di= me-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, w= e
> > will change
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > to
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> > The rationale for the word 'flow(s)' in the new language is the l= ast
> > sentence of the section  3.2 -  "The Congestion-Tr= eatment AVP is an
> > action and MUST be an attribute of the Filter-Rule Grouped AVP as=
> > defined in RFC5777. "  It is other AVPs in the Filter-R= ule, e.g.
> > Classifier, that describes the scope of traffic impacted.  S= aying
> > something in Section 3.2 that does not associate the
> > Congestion-Treatment AVP to the Filter-Rule it is a part of only<= br> > > creates
> confusion.
> >
> > ---------------------------------
> > Per the COMMENT, you are correct.  We'll change
> >
> > "The first AVP provides direct support for ECN [RFC3168] in = the IP
> >   header“
> >
> > to your suggestion
> >
> > "The first AVP provides direct support for filtering ECN
> >   marked traffic[RFC3168]“
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-= bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf= .org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin Stiemerling has entered the following ballot position for<= br> > > draft-ietf-dime-congestion-flow-attributes-01: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri
> > butes/
> >
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > No general objection to the publication of the document. However,= I
> > am relaying a question from David Black as a DISCUSS point.
> >
> > I assume that the draft is more than unclear in Section 3.2 = about
> > what traffic means. Is it a particular flow, a single packet, etc= ?
> >
> > "I found an ECN concern, and hence added the TSV ADs to the = CC line.
> >
> > Section 3.2 says:
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > That appears to say that the congestion treatment may be applied<= br> > > solely to packets that have the CE (Congestion Experienced) marki= ng.
> > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP t= o
> > react as if a packet has been dropped), hence the congestion
> > treatment ought to apply to the entire flow.
> >
> > In other words, one wants to be able to use the ECN-IP-Codepoint = AVP
> > as part of the condition that determines whether the filter rule<= br> > > matches, but ignore that AVP (i.e., wildcard it) in determining w= hat
> > traffic the action applies to, so that the response to detecting = a
> > congested flow (i.e., packets with ECN field containing CE) appli= es
> > to all packets in the flow, regardless of the value in the CE fie= ld.
> >
> > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked.
> >
> > Am I reading the draft correctly?"
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 1, 1st paragraph:
> > It says "The first AVP provides direct support for ECN [RFC3= 168] in
> > the IP header“. I am  sure that your draft is  ot= providing any
> > support for ECN in the IP header, as we have ECN in the IP header=
> > already,
> isn't it.
> > I guess you mean something like this "The first AVP provides= direct
> > support for filtering ECN marked traffic[RFC3168]“
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww= w.ietf.org/mailman/listinfo/dime
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended f= or
> > the sole use of the recipient(s). Any use by others is prohibited= .
> > If you are not the intended recipient, please contact the sender = and
> > delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If<= br> > you are not the intended recipient, please contact the sender and
> delete all copies of the message.

________________________________

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_565c7289e23441ff93f3fd8328bb1107PLSWE13M07adsprintcom_-- From nobody Sat Jun 13 09:55:15 2015 Return-Path: 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 DEE961A0406; Fri, 12 Jun 2015 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ezkms_L_5heK; Fri, 12 Jun 2015 08:33:12 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA861A039A; Fri, 12 Jun 2015 08:33:11 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CFX9xx004058 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jun 2015 11:33:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t5CFX9xx004058 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1434123190; bh=ssQF2xl/Fp8EOzVLimZJZqunCbc=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=q6YazQpIcLwMMID+m8ZJaTV4oEdJCiBaaNRZ4LmKlryxiwxDOwR3l363vC7DXUFyE EJ3xyNnLgo/V8Zp4ZrxdaSA7yRRw0uFEnTZoydb3B4CV5BHkdI6cTHamyC92VSOnJI 73OThW4sciFoYyrWlbDFXaWzZ364Frvlf2JEo19U= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t5CFX9xx004058 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 12 Jun 2015 11:32:48 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CFWnmZ013402 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 11:32:50 -0400 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub14.corp.emc.com (128.222.70.235) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 12 Jun 2015 11:32:25 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Fri, 12 Jun 2015 11:32:48 -0400 From: "Black, David" To: "Bertz, Lyle T [CTO]" , Martin Stiemerling , The IESG Thread-Topic: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AdClJQY7bDX02JNSQVyRtfBFUqyd5w== Date: Fri, 12 Jun 2015 15:32:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: X-Mailman-Approved-At: Sat, 13 Jun 2015 09:55:13 -0700 Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , "Black, David" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:33:16 -0000 THlsZSwNCg0KVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24gLSBmb3IgbXkgY29uY2VybiwgSSB0 aGluayB3ZSdyZSBjbG9zZSB0byBkb25lLi4uDQoNCj4gVHJhZmZpYyBmbG93KHMpIGFyZSBJUCAo NS10dXBsZSkgZmxvdyhzKS4NCg0KVGhhdCdzIGEgcmVsaWVmIC0gSSdtIGdsYWQgdGhhdCB3ZSdy ZSBvbmx5IGRlYWxpbmcgd2l0aCBlZGl0b3JpYWwgY29uY2VybnMNCmluIHRoZSBkcmFmdCwgYW5k IG5vdCBhbiBhY3R1YWwgZGVzaWduIHByb2JsZW0uDQoNCj4gTXkgcXVlc3Rpb24gdG8geW91IGlz IHdvdWxkIGl0IGJlIGJlc3QgdG8gc2F5ICJJUCBmbG93cyIgb3IgIklQICg1LXR1cGxlKQ0KPiBm bG93cyIgb3IgIjUtdHVwbGUgZmxvd3MiPw0KDQpJIGxpa2UgIklQICg1LXR1cGxlKSBmbG93cyIg LSBNYXJ0aW4/DQoNCj4gSSBhbSB1bnN1cmUgb2YgdGhlIGJlc3Qgd29yZGluZyBoZXJlLiAgVGhp cw0KPiB0cmVhdG1lbnQgYXBwbGllcyB0byBhbGwgcGFja2V0cyBhc3NvY2lhdGVkIHRvIGFsbCA1 LXR1cGxlcyAoZmxvd3MpIGNhcHR1cmVkDQo+IGJ5IHRoZSBGaWx0ZXItUnVsZS4NCg0KUGxlYXNl IGFkZCB0aGF0IGxhdHRlciBzZW50ZW5jZSAoIlRoaXMgdHJlYXRtZW50IGFwcGxpZXMgLi4uIikg dG8gdGhlIGRyYWZ0IC4uLg0KDQo+IEEgRmlsdGVyLVJ1bGUgbWF5IGNvbnRhaW4gYSBDbGFzc2lm aWVyIHRoYXQgZGVzY3JpYmVzIG9uZSBvciBtYW55IDUtdHVwbGVzIHBlcg0KPiBSRkMgNTc3Ny4N Cg0KLi4uIGFuZCBwbGVhc2UgYWRkIHRoYXQgc2VudGVuY2UgYWxzbyA7LSkuDQoNClRoZSBnb2Fs IGlzIHRvIGJlIGNsZWFyIHRoYXQ6DQotIGFkZGluZyBhbiBFQ04tSVAtQ29kZXBvaW50IEFWUCB0 byBhIENsYXNzaWZpZXIgc3RpbGwgcmVzdWx0cyBpbiB0aGUNCglDbGFzc2lmaWVyIGRlc2NyaWJp bmcgNS10dXBsZSBmbG93cyAoYXMgb3Bwb3NlZCB0byBzdWJzZXRzIG9mIDUtdHVwbGUNCglmbG93 cyB0aGF0IGNvbnRhaW4gYSBzcGVjaWZpYyB2YWx1ZSBvciB2YWx1ZXMgaW4gdGhlIEVDTiBmaWVs ZCk7IGFuZA0KLSBoZW5jZSwgdGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFWUCBhcHBsaWVzIHRv IDUtdHVwbGVzIGFuZCBub3QgdG8NCglhbnl0aGluZyBzbWFsbGVyLg0KDQpUaGFua3MsDQotLURh dmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVydHosIEx5bGUg VCBbQ1RPXSBbbWFpbHRvOkx5bGUuVC5CZXJ0ekBzcHJpbnQuY29tXQ0KPiBTZW50OiBUaHVyc2Rh eSwgSnVuZSAxMSwgMjAxNSA4OjU5IFBNDQo+IFRvOiBCbGFjaywgRGF2aWQ7IE1hcnRpbiBTdGll bWVybGluZzsgVGhlIElFU0cNCj4gQ2M6IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJFOiBbRGltZV0gTWFydGluIFN0aWVtZXJsaW5nJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLWRpbWUtDQo+IGNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0 aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gRGF2aWQsDQo+IA0KPiBUcmFmZmljIGZsb3co cykgYXJlIElQICg1LXR1cGxlKSBmbG93KHMpLg0KPiANCj4gTXkgcXVlc3Rpb24gdG8geW91IGlz IHdvdWxkIGl0IGJlIGJlc3QgdG8gc2F5ICJJUCBmbG93cyIgb3IgIklQICg1LXR1cGxlKQ0KPiBm bG93cyIgb3IgIjUtdHVwbGUgZmxvd3MiPyAgIEkgYW0gdW5zdXJlIG9mIHRoZSBiZXN0IHdvcmRp bmcgaGVyZS4gIFRoaXMNCj4gdHJlYXRtZW50IGFwcGxpZXMgdG8gYWxsIHBhY2tldHMgYXNzb2Np YXRlZCB0byBhbGwgNS10dXBsZXMgKGZsb3dzKSBjYXB0dXJlZA0KPiBieSB0aGUgRmlsdGVyLVJ1 bGUuDQo+IA0KPiBBIEZpbHRlci1SdWxlIG1heSBjb250YWluIGEgQ2xhc3NpZmllciB0aGF0IGRl c2NyaWJlcyBvbmUgb3IgbWFueSA1LXR1cGxlcyBwZXINCj4gUkZDIDU3NzcuDQo+IA0KPiBUaGFu a3MuDQo+IEx5bGUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJs YWNrLCBEYXZpZCBbbWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb21dDQo+IFNlbnQ6IFRodXJzZGF5 LCBKdW5lIDExLCAyMDE1IDU6MTUgUE0NCj4gVG86IEJlcnR6LCBMeWxlIFQgW0NUT107IE1hcnRp biBTdGllbWVybGluZzsgVGhlIElFU0cNCj4gQ2M6IGRpbWVAaWV0Zi5vcmc7IGRpbWUtY2hhaXJz QGlldGYub3JnOyBCbGFjaywgRGF2aWQNCj4gU3ViamVjdDogUkU6IFtEaW1lXSBNYXJ0aW4gU3Rp ZW1lcmxpbmcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtZGltZS0NCj4gY29uZ2VzdGlvbi1mbG93 LWF0dHJpYnV0ZXMtMDE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBMeWxlLA0K PiANCj4gPiAgICBUaGUgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQIChBVlAgQ29kZSBUQkQpIGlz IG9mIHR5cGUgR3JvdXBlZC4gSXQNCj4gPiAgICBpbmRpY2F0ZXMgaG93IHRvIHRyZWF0IHRyYWZm aWMgZmxvdyhzKSB3aGVuIGNvbmdlc3Rpb24gaXMgZGV0ZWN0ZWQuDQo+ID4gICAgVGhlIGRldGVj dGlvbiBvZiB0aGUgY29uZ2VzdGlvbiBjYW4gYmUgYmFzZWQgb24gdGhlIHJlY2VwdGlvbiBvZiBJ UA0KPiA+ICAgIHBhY2tldHMgcGFja2V0ICB3aXRoICB0aGUgQ0UgKENvbmdlc3Rpb24gRXhwZXJp ZW5jZWQpIGNvZGVwb2ludCBzZXQNCj4gPiAgIChzZWUgW1JGQyAzMTY4XSkgb3IgYnkgYW55IG90 aGVyIGFkbWluaXN0cmF0aXZlbHkgZGVmaW5lZCBjcml0ZXJpYS4NCj4gDQo+IFdoYXQgZG9lcyAi dHJhZmZpYyBmbG93KHMpIiBtZWFuIGluIHRoaXMgdGV4dD8NCj4gDQo+IEEgY2xlYXIgZXhwbGFu YXRpb24gb2YgdGhhdCBzaG91bGQgcmVtb3ZlIHRoZSBjb25jZXJuIHRoYXQgdGhpcyBkcmFmdCBt aWdodCBiZQ0KPiBhcHBseWluZyBjb25nZXN0aW9uIHRyZWF0bWVudCB0byBqdXN0IHRoZSBDRS1t YXJrZWQgcGFja2V0cyBhbmQgbm90IHRoZSBlbnRpcmUNCj4gNS10dXBsZSAob3IgbW9yZSkuDQo+ IA0KPiBUaGFua3MsDQo+IC0tRGF2aWQNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiBGcm9tOiBCZXJ0eiwgTHlsZSBUIFtDVE9dIFttYWlsdG86THlsZS5ULkJlcnR6QHNw cmludC5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMTEsIDIwMTUgNjowMiBQTQ0KPiA+ IFRvOiBNYXJ0aW4gU3RpZW1lcmxpbmc7IFRoZSBJRVNHDQo+ID4gQ2M6IEJsYWNrLCBEYXZpZDsg ZGltZUBpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW0Rp bWVdIE1hcnRpbiBTdGllbWVybGluZydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaW1lLQ0KPiA+ IGNvbmdlc3Rpb24tZmxvdy1hdHRyaWJ1dGVzLTAxOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KPiA+DQo+ID4gTWFydGluLA0KPiA+DQo+ID4gUmVnYXJkaW5nIHRoZSBESVNDVVNTIHBvaW50 IHRoZSBsYW5ndWFnZSBpbiAzLjIgaXMgcHJvYmxlbWF0aWMsIHdlDQo+ID4gd2lsbCBjaGFuZ2UN Cj4gPg0KPiA+ICAgIFRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgKEFWUCBDb2RlIFRCRCkg aXMgb2YgdHlwZSBHcm91cGVkIGFuZA0KPiA+ICAgIGluZGljYXRlcyBob3cgY29uZ2VzdGVkIHRy YWZmaWMsIGkuZS4sIHRyYWZmaWMgdGhhdCBoYXMgRXhwbGljaXQNCj4gPiAgICBDb25nZXN0aW9u IE5vdGlmaWNhdGlvbiBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIG1hcmtpbmcgc2V0IG9yIHNvbWUN Cj4gPiAgICBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQgY3JpdGVyaWEsIGlzIHRyZWF0 ZWQuDQo+ID4NCj4gPiB0bw0KPiA+DQo+ID4gICAgVGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFW UCAoQVZQIENvZGUgVEJEKSBpcyBvZiB0eXBlIEdyb3VwZWQuIEl0DQo+ID4gICAgaW5kaWNhdGVz IGhvdyB0byB0cmVhdCB0cmFmZmljIGZsb3cocykgd2hlbiBjb25nZXN0aW9uIGlzIGRldGVjdGVk Lg0KPiA+ICAgIFRoZSBkZXRlY3Rpb24gb2YgdGhlIGNvbmdlc3Rpb24gY2FuIGJlIGJhc2VkIG9u IHRoZSByZWNlcHRpb24gb2YgSVANCj4gPiAgICBwYWNrZXRzIHBhY2tldCAgd2l0aCAgdGhlIENF IChDb25nZXN0aW9uIEV4cGVyaWVuY2VkKSBjb2RlcG9pbnQgc2V0DQo+ID4gICAoc2VlIFtSRkMg MzE2OF0pIG9yIGJ5IGFueSBvdGhlciBhZG1pbmlzdHJhdGl2ZWx5IGRlZmluZWQgY3JpdGVyaWEu DQo+ID4NCj4gPiBUaGUgcmF0aW9uYWxlIGZvciB0aGUgd29yZCAnZmxvdyhzKScgaW4gdGhlIG5l dyBsYW5ndWFnZSBpcyB0aGUgbGFzdA0KPiA+IHNlbnRlbmNlIG9mIHRoZSBzZWN0aW9uICAzLjIg LSAgIlRoZSBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgaXMgYW4NCj4gPiBhY3Rpb24gYW5kIE1V U1QgYmUgYW4gYXR0cmlidXRlIG9mIHRoZSBGaWx0ZXItUnVsZSBHcm91cGVkIEFWUCBhcw0KPiA+ IGRlZmluZWQgaW4gUkZDNTc3Ny4gIiAgSXQgaXMgb3RoZXIgQVZQcyBpbiB0aGUgRmlsdGVyLVJ1 bGUsIGUuZy4NCj4gPiBDbGFzc2lmaWVyLCB0aGF0IGRlc2NyaWJlcyB0aGUgc2NvcGUgb2YgdHJh ZmZpYyBpbXBhY3RlZC4gIFNheWluZw0KPiA+IHNvbWV0aGluZyBpbiBTZWN0aW9uIDMuMiB0aGF0 IGRvZXMgbm90IGFzc29jaWF0ZSB0aGUNCj4gPiBDb25nZXN0aW9uLVRyZWF0bWVudCBBVlAgdG8g dGhlIEZpbHRlci1SdWxlIGl0IGlzIGEgcGFydCBvZiBvbmx5IGNyZWF0ZXMNCj4gY29uZnVzaW9u Lg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gUGVyIHRo ZSBDT01NRU5ULCB5b3UgYXJlIGNvcnJlY3QuICBXZSdsbCBjaGFuZ2UNCj4gPg0KPiA+ICJUaGUg Zmlyc3QgQVZQIHByb3ZpZGVzIGRpcmVjdCBzdXBwb3J0IGZvciBFQ04gW1JGQzMxNjhdIGluIHRo ZSBJUA0KPiA+ICAgaGVhZGVy4oCcDQo+ID4NCj4gPiB0byB5b3VyIHN1Z2dlc3Rpb24NCj4gPg0K PiA+ICJUaGUgZmlyc3QgQVZQIHByb3ZpZGVzIGRpcmVjdCBzdXBwb3J0IGZvciBmaWx0ZXJpbmcg RUNODQo+ID4gICBtYXJrZWQgdHJhZmZpY1tSRkMzMTY4XeKAnA0KPiA+DQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluDQo+ID4gU3RpZW1lcmxpbmcNCj4gPiBTZW50OiBX ZWRuZXNkYXksIEp1bmUgMTAsIDIwMTUgMzozNiBQTQ0KPiA+IFRvOiBUaGUgSUVTRw0KPiA+IENj OiBkYXZpZC5ibGFja0BlbWMuY29tOyBkaW1lQGlldGYub3JnOyBkaW1lLWNoYWlyc0BpZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFtEaW1lXSBNYXJ0aW4gU3RpZW1lcmxpbmcncyBEaXNjdXNzIG9uDQo+ ID4gZHJhZnQtaWV0Zi1kaW1lLWNvbmdlc3Rpb24tDQo+ID4gZmxvdy1hdHRyaWJ1dGVzLTAxOiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gTWFydGluIFN0aWVtZXJsaW5nIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWll dGYtZGltZS1jb25nZXN0aW9uLWZsb3ctYXR0cmlidXRlcy0wMTogRGlzY3Vzcw0KPiA+DQo+ID4g V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg cmVwbHkgdG8gYWxsDQo+ID4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ID4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdy YXBoLCBob3dldmVyLikNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIHJlZmVyIHRvDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGltZS1jb25nZXN0aW9uLWZsb3ctYXR0cmkNCj4gPiBi dXRlcy8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoNCj4g PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBObyBnZW5lcmFsIG9iamVjdGlvbiB0byB0aGUgcHVi bGljYXRpb24gb2YgdGhlIGRvY3VtZW50LiBIb3dldmVyLCBJIGFtDQo+ID4gcmVsYXlpbmcgYSBx dWVzdGlvbiBmcm9tIERhdmlkIEJsYWNrIGFzIGEgRElTQ1VTUyBwb2ludC4NCj4gPg0KPiA+IEkg YXNzdW1lIHRoYXQgdGhlIGRyYWZ0IGlzIG1vcmUgdGhhbiB1bmNsZWFyIGluIFNlY3Rpb24gMy4y ICBhYm91dA0KPiA+IHdoYXQgdHJhZmZpYyBtZWFucy4gSXMgaXQgYSBwYXJ0aWN1bGFyIGZsb3cs IGEgc2luZ2xlIHBhY2tldCwgZXRjPw0KPiA+DQo+ID4gIkkgZm91bmQgYW4gRUNOIGNvbmNlcm4s IGFuZCBoZW5jZSBhZGRlZCB0aGUgVFNWIEFEcyB0byB0aGUgQ0MgbGluZS4NCj4gPg0KPiA+IFNl Y3Rpb24gMy4yIHNheXM6DQo+ID4NCj4gPiAgICBUaGUgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgQVZQ IChBVlAgQ29kZSBUQkQpIGlzIG9mIHR5cGUgR3JvdXBlZCBhbmQNCj4gPiAgICBpbmRpY2F0ZXMg aG93IGNvbmdlc3RlZCB0cmFmZmljLCBpLmUuLCB0cmFmZmljIHRoYXQgaGFzIEV4cGxpY2l0DQo+ ID4gICAgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gQ29uZ2VzdGlvbiBFeHBlcmllbmNlZCBtYXJr aW5nIHNldCBvciBzb21lDQo+ID4gICAgb3RoZXIgYWRtaW5pc3RyYXRpdmVseSBkZWZpbmVkIGNy aXRlcmlhLCBpcyB0cmVhdGVkLg0KPiA+DQo+ID4gVGhhdCBhcHBlYXJzIHRvIHNheSB0aGF0IHRo ZSBjb25nZXN0aW9uIHRyZWF0bWVudCBtYXkgYmUgYXBwbGllZA0KPiA+IHNvbGVseSB0byBwYWNr ZXRzIHRoYXQgaGF2ZSB0aGUgQ0UgKENvbmdlc3Rpb24gRXhwZXJpZW5jZWQpIG1hcmtpbmcuDQo+ ID4gVGhhdCB3b3VsZCBiZSBhIHByb2JsZW0sIGJlY2F1c2UgdGhlIGRlZmluZWQgc2VtYW50aWNz IG9mIGEgQ0UgbWFya2luZw0KPiA+IGlzIHRoYXQgaXQgYXBwbGllcyB0byB0aGUgZW50aXJlIGZs b3cgKGUuZy4sIGNhdXNlcyBUQ1AgdG8gcmVhY3QgYXMgaWYNCj4gPiBhIHBhY2tldCBoYXMgYmVl biBkcm9wcGVkKSwgaGVuY2UgdGhlIGNvbmdlc3Rpb24gdHJlYXRtZW50IG91Z2h0IHRvDQo+ID4g YXBwbHkgdG8gdGhlIGVudGlyZSBmbG93Lg0KPiA+DQo+ID4gSW4gb3RoZXIgd29yZHMsIG9uZSB3 YW50cyB0byBiZSBhYmxlIHRvIHVzZSB0aGUgRUNOLUlQLUNvZGVwb2ludCBBVlANCj4gPiBhcyBw YXJ0IG9mIHRoZSBjb25kaXRpb24gdGhhdCBkZXRlcm1pbmVzIHdoZXRoZXIgdGhlIGZpbHRlciBy dWxlDQo+ID4gbWF0Y2hlcywgYnV0IGlnbm9yZSB0aGF0IEFWUCAoaS5lLiwgd2lsZGNhcmQgaXQp IGluIGRldGVybWluaW5nIHdoYXQNCj4gPiB0cmFmZmljIHRoZSBhY3Rpb24gYXBwbGllcyB0bywg c28gdGhhdCB0aGUgcmVzcG9uc2UgdG8gZGV0ZWN0aW5nIGENCj4gPiBjb25nZXN0ZWQgZmxvdyAo aS5lLiwgcGFja2V0cyB3aXRoIEVDTiBmaWVsZCBjb250YWluaW5nIENFKSBhcHBsaWVzIHRvDQo+ ID4gYWxsIHBhY2tldHMgaW4gdGhlIGZsb3csIHJlZ2FyZGxlc3Mgb2YgdGhlIHZhbHVlIGluIHRo ZSBDRSBmaWVsZC4NCj4gPg0KPiA+IE90aGVyd2lzZSwgdGhlIHJlc3VsdCBtYXkgYmUgaW5lZmZl Y3RpdmUsIGFzIGl0IHdvbid0IGVuY29tcGFzcw0KPiA+IHBhY2tldHMgaW4gdGhlIGNvbmdlc3Rl ZCBmbG93IHRoYXQgYXJlbid0IENFLW1hcmtlZC4NCj4gPg0KPiA+IEFtIEkgcmVhZGluZyB0aGUg ZHJhZnQgY29ycmVjdGx5PyINCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1F TlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gU2VjdGlvbiAxLCAxc3QgcGFyYWdyYXBo Og0KPiA+IEl0IHNheXMgIlRoZSBmaXJzdCBBVlAgcHJvdmlkZXMgZGlyZWN0IHN1cHBvcnQgZm9y IEVDTiBbUkZDMzE2OF0gaW4NCj4gPiB0aGUgSVAgaGVhZGVy4oCcLiBJIGFtICBzdXJlIHRoYXQg eW91ciBkcmFmdCBpcyAgb3QgcHJvdmlkaW5nIGFueQ0KPiA+IHN1cHBvcnQgZm9yIEVDTiBpbiB0 aGUgSVAgaGVhZGVyLCBhcyB3ZSBoYXZlIEVDTiBpbiB0aGUgSVAgaGVhZGVyIGFscmVhZHksDQo+ IGlzbid0IGl0Lg0KPiA+IEkgZ3Vlc3MgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgdGhpcyAiVGhl IGZpcnN0IEFWUCBwcm92aWRlcyBkaXJlY3QNCj4gPiBzdXBwb3J0IGZvciBmaWx0ZXJpbmcgRUNO IG1hcmtlZCB0cmFmZmljW1JGQzMxNjhd4oCcDQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QN Cj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaW1lDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ DQo+ID4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uIGludGVuZGVkIGZvcg0KPiA+IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBB bnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZg0KPiA+IHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kDQo+ID4gZGVs ZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiANCj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3By aWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZQ0KPiB1c2Ugb2YgdGhlIHJl Y2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlDQo+IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBh bmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlDQo+IG1lc3NhZ2UuDQo= From nobody Sat Jun 13 09:55:16 2015 Return-Path: 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 BF0141ACEE8; Fri, 12 Jun 2015 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 89bPqlhr33EM; Fri, 12 Jun 2015 11:55:38 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE9A1ACEE7; Fri, 12 Jun 2015 11:55:38 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CItZPq004774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jun 2015 14:55:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t5CItZPq004774 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1434135336; bh=0LsL+OnJvfID4z72jHx+VD5nOYc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Mx1gk1S0fIgBEKM8QUKUBeVgvkgg0TyGV6YMLamHlF+YjCKNO4k3RzKKaRW5Pdj7q eH9D5r5WGhVVSxSgy2HjKl0+FWfoflUa0g6tT1r5gJgwiPsCZ+lGK4Nezkz3UZhyMQ I6lP/++YHe6a67PK04uayTkX160YahP2Plh5VWhk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t5CItZPq004774 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 12 Jun 2015 14:55:20 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t5CItM40027621 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jun 2015 14:55:22 -0400 Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub29.corp.emc.com (128.222.70.169) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 12 Jun 2015 14:55:21 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0224.002; Fri, 12 Jun 2015 14:55:21 -0400 From: "Black, David" To: "Bertz, Lyle T [CTO]" , "lionel.morand@orange.com" , Martin Stiemerling , The IESG Thread-Topic: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AdClJQY7bDX02JNSQVyRtfBFUqyd5wAMj4MAAAFloAAAAFO/AAAHeR1A Date: Fri, 12 Jun 2015 18:55:20 +0000 Message-ID: References: , <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> <565c7289e23441ff93f3fd8328bb1107@PLSWE13M07.ad.sprint.com> In-Reply-To: <565c7289e23441ff93f3fd8328bb1107@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949360B373B09MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: X-Mailman-Approved-At: Sat, 13 Jun 2015 09:55:13 -0700 Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , "Black, David" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:55:48 -0000 --_000_CE03DB3D7B45C245BCA0D243277949360B373B09MX104CL02corpem_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With that extra "packet" dropped ;-), the proposed text looks good enough for my concern. I'll leave any further adjustment to Martin, as he's holdi= ng the Discuss. Many thanks for the prompt attention to this, and (as noted earlier), I'm pleased that this was not an actual design problem. Thanks, --David From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Friday, June 12, 2015 2:22 PM To: lionel.morand@orange.com; Black, David; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org Subject: RE: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-co= ngestion-flow-attributes-01: (with DISCUSS and COMMENT) ... Even my corrections have errors this week. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, June 12, 2015 1:12 PM To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-conges= tion-flow-attributes-01: (with DISCUSS and COMMENT) Except that a "packets packet" is maybe too explicit! :) (Second sentence) Please wait for a formal go-ahead from the AD or myself before submitting a= new version. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "Bertz, Lyle T [CTO]" > Pour : "Black, David" >, "M= artin Stiemerling" >, "The IE= SG" > Cc : "dime@ietf.org" >, "dime-chairs@ietf.org" > Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT) Date : ven., juin 12, 2015 19:32 David, Thanks for the guidance here. We definitely want to meet the goals you not= e below. I will assume Martin has no objection to "IP (5-tuple) flows". If so, we c= an adjust the language. New language (I also changed 'In case the" to "If the" at the beginning of = the next paragraph. > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic IP (5-tuple) flow(s) when congestion = is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > A Filter-Rule may contain a Classifier that describes one or many 5-t= uples per > > RFC 5777. This treatment applies to all packets associated to all 5-= tuples (flows) > > captured by the Filter-Rule. > > > > If the Congestion-Treatment AVP is absent... I believe this language meets the objectives outlined below. Thank you. Lyle -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Friday, June 12, 2015 10:33 AM To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT) Lyle, Thanks for the explanation - for my concern, I think we're close to done... > Traffic flow(s) are IP (5-tuple) flow(s). That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem. > My question to you is would it be best to say "IP flows" or "IP > (5-tuple) flows" or "5-tuple flows"? I like "IP (5-tuple) flows" - Martin? > I am unsure of the best wording here. This treatment applies to all > packets associated to all 5-tuples (flows) captured by the > Filter-Rule. Please add that latter sentence ("This treatment applies ...") to the draft= ... > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. ... and please add that sentence also ;-). The goal is to be clear that: - adding an ECN-IP-Codepoint AVP to a Classifier still results in the Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple flows that contain a specific value or values in the ECN field); and - hence, the Congestion-Treatment AVP applies to 5-tuples and not to anything smaller. Thanks, --David > -----Original Message----- > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > Sent: Thursday, June 11, 2015 8:59 PM > To: Black, David; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > David, > > Traffic flow(s) are IP (5-tuple) flow(s). > > My question to you is would it be best to say "IP flows" or "IP (5-tuple) > flows" or "5-tuple flows"? I am unsure of the best wording here. This > treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule. > > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. > > Thanks. > Lyle > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, June 11, 2015 5:15 PM > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > Lyle, > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > What does "traffic flow(s)" mean in this text? > > A clear explanation of that should remove the concern that this draft > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more). > > Thanks, > --David > > > -----Original Message----- > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > > Sent: Thursday, June 11, 2015 6:02 PM > > To: Martin Stiemerling; The IESG > > Cc: Black, David; dime@ietf.org; dime-chairs@ietf= .org > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin, > > > > Regarding the DISCUSS point the language in 3.2 is problematic, we > > will change > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > to > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > The rationale for the word 'flow(s)' in the new language is the last > > sentence of the section 3.2 - "The Congestion-Treatment AVP is an > > action and MUST be an attribute of the Filter-Rule Grouped AVP as > > defined in RFC5777. " It is other AVPs in the Filter-Rule, e.g. > > Classifier, that describes the scope of traffic impacted. Saying > > something in Section 3.2 that does not associate the > > Congestion-Treatment AVP to the Filter-Rule it is a part of only > > creates > confusion. > > > > --------------------------------- > > Per the COMMENT, you are correct. We'll change > > > > "The first AVP provides direct support for ECN [RFC3168] in the IP > > header" > > > > to your suggestion > > > > "The first AVP provides direct support for filtering ECN > > marked traffic[RFC3168]" > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Martin > > Stiemerling > > Sent: Wednesday, June 10, 2015 3:36 PM > > To: The IESG > > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org > > Subject: [Dime] Martin Stiemerling's Discuss on > > draft-ietf-dime-congestion- > > flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin Stiemerling has entered the following ballot position for > > draft-ietf-dime-congestion-flow-attributes-01: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri > > butes/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > No general objection to the publication of the document. However, I > > am relaying a question from David Black as a DISCUSS point. > > > > I assume that the draft is more than unclear in Section 3.2 about > > what traffic means. Is it a particular flow, a single packet, etc? > > > > "I found an ECN concern, and hence added the TSV ADs to the CC line. > > > > Section 3.2 says: > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > That appears to say that the congestion treatment may be applied > > solely to packets that have the CE (Congestion Experienced) marking. > > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP to > > react as if a packet has been dropped), hence the congestion > > treatment ought to apply to the entire flow. > > > > In other words, one wants to be able to use the ECN-IP-Codepoint AVP > > as part of the condition that determines whether the filter rule > > matches, but ignore that AVP (i.e., wildcard it) in determining what > > traffic the action applies to, so that the response to detecting a > > congested flow (i.e., packets with ECN field containing CE) applies > > to all packets in the flow, regardless of the value in the CE field. > > > > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked. > > > > Am I reading the draft correctly?" > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Section 1, 1st paragraph: > > It says "The first AVP provides direct support for ECN [RFC3168] in > > the IP header". I am sure that your draft is ot providing any > > support for ECN in the IP header, as we have ECN in the IP header > > already, > isn't it. > > I guess you mean something like this "The first AVP provides direct > > support for filtering ECN marked traffic[RFC3168]" > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information intended for > > the sole use of the recipient(s). Any use by others is prohibited. > > If you are not the intended recipient, please contact the sender and > > delete all copies of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_CE03DB3D7B45C245BCA0D243277949360B373B09MX104CL02corpem_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

With that extra “packet” dropped ;= -), the proposed text looks good enough

for my concern.  I’ll leave any fur= ther adjustment to Martin, as he’s holding

the Discuss.

 

Many thanks for the prompt attention to this, = and (as noted earlier), I’m

pleased that this was not an actual design pro= blem.

 

Thanks,
--David

 

From: Bertz, L= yle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Friday, June 12, 2015 2:22 PM
To: lionel.morand@orange.com; Black, David; Martin Stiemerling; The = IESG
Cc: dime@ietf.org; dime-chairs@ietf.org
Subject: RE: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-= dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

<sigh>… Even = my corrections have errors this week. 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, June 12, 2015 1:12 PM
To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG<= br> Cc: dime@ietf.org; dime-chairs@ietf.org
Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime= -congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

Except that a "packets packet" is maybe too ex= plicit! :)

 

(Second sentence)

Please wait for a formal go-ahead from the AD or myself = before submitting a new version.

 

Regards,

 

Lionel 

 

Envoy=E9 depuis mon mobile Orange

 

----- Reply message -----
De : "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Pour : "Black, David" <david.black@emc.com>, "Martin Stiemerling" <mls.ietf@gmail.com>, "The IESG&= quot; <iesg@ietf.org>
Cc : "dime@ietf.org" <dime@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>
Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT)
Date : ven., juin 12, 2015 19:32

 

David,

Thanks for the guidance here.  We definitely want to meet the goals yo= u note below.

I will assume Martin has no objection to "IP (5-tuple) flows".&nb= sp; If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" at th= e beginning of the next paragraph.

> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic IP (5-tuple) flo= w(s) when congestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> >   A Filter-Rule may contain a Classifier that describes= one or many 5-tuples per
> >   RFC 5777.  This treatment applies to all packets= associated to all 5-tuples (flows) > >   captured by the F= ilter-Rule.
> >
> >   If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.bla= ck@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to done...=

> Traffic flow(s) are IP (5-tuple) flow(s).

That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or = "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

> I am unsure of the best wording here.  This treatment applies to = all
> packets associated to all 5-tuples (flows) captured by the
> Filter-Rule.

Please add that latter sentence ("This treatment applies ...") to= the draft ...

> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [= mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> David,
>
> Traffic flow(s) are IP (5-tuple) flow(s).
>
> My question to you is would it be best to say "IP flows" or = "IP (5-tuple)
> flows" or "5-tuple flows"?   I am unsure of t= he best wording here.  This
> treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule.
>
> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.
>
> Thanks.
> Lyle
>
> -----Original Message-----
> From: Black, David [mailto:davi= d.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
>
> What does "traffic flow(s)" mean in this text?
>
> A clear explanation of that should remove the concern that this draft<= br> > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more).
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org<= /a>; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-di= me-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, w= e
> > will change
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > to
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> > The rationale for the word 'flow(s)' in the new language is the l= ast
> > sentence of the section  3.2 -  "The Congestion-Tr= eatment AVP is an
> > action and MUST be an attribute of the Filter-Rule Grouped AVP as=
> > defined in RFC5777. "  It is other AVPs in the Filter-R= ule, e.g.
> > Classifier, that describes the scope of traffic impacted.  S= aying
> > something in Section 3.2 that does not associate the
> > Congestion-Treatment AVP to the Filter-Rule it is a part of only<= br> > > creates
> confusion.
> >
> > ---------------------------------
> > Per the COMMENT, you are correct.  We'll change
> >
> > "The first AVP provides direct support for ECN [RFC3168] in = the IP
> >   header“
> >
> > to your suggestion
> >
> > "The first AVP provides direct support for filtering ECN
> >   marked traffic[RFC3168]“
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-= bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf= .org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin Stiemerling has entered the following ballot position for<= br> > > draft-ietf-dime-congestion-flow-attributes-01: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri
> > butes/
> >
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > No general objection to the publication of the document. However,= I
> > am relaying a question from David Black as a DISCUSS point.
> >
> > I assume that the draft is more than unclear in Section 3.2 = about
> > what traffic means. Is it a particular flow, a single packet, etc= ?
> >
> > "I found an ECN concern, and hence added the TSV ADs to the = CC line.
> >
> > Section 3.2 says:
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > That appears to say that the congestion treatment may be applied<= br> > > solely to packets that have the CE (Congestion Experienced) marki= ng.
> > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP t= o
> > react as if a packet has been dropped), hence the congestion
> > treatment ought to apply to the entire flow.
> >
> > In other words, one wants to be able to use the ECN-IP-Codepoint = AVP
> > as part of the condition that determines whether the filter rule<= br> > > matches, but ignore that AVP (i.e., wildcard it) in determining w= hat
> > traffic the action applies to, so that the response to detecting = a
> > congested flow (i.e., packets with ECN field containing CE) appli= es
> > to all packets in the flow, regardless of the value in the CE fie= ld.
> >
> > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked.
> >
> > Am I reading the draft correctly?"
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 1, 1st paragraph:
> > It says "The first AVP provides direct support for ECN [RFC3= 168] in
> > the IP header“. I am  sure that your draft is  ot= providing any
> > support for ECN in the IP header, as we have ECN in the IP header=
> > already,
> isn't it.
> > I guess you mean something like this "The first AVP provides= direct
> > support for filtering ECN marked traffic[RFC3168]“
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww= w.ietf.org/mailman/listinfo/dime
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended f= or
> > the sole use of the recipient(s). Any use by others is prohibited= .
> > If you are not the intended recipient, please contact the sender = and
> > delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If<= br> > you are not the intended recipient, please contact the sender and
> delete all copies of the message.

________________________________

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_CE03DB3D7B45C245BCA0D243277949360B373B09MX104CL02corpem_-- From nobody Mon Jun 15 09:34:28 2015 Return-Path: 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 5A96A1A8F36; Mon, 15 Jun 2015 09:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 dXuo72C8Chyr; Mon, 15 Jun 2015 09:34:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298481A8BB7; Mon, 15 Jun 2015 09:34:11 -0700 (PDT) Received: from BL2FFO11OLC001.protection.gbl (10.173.160.33) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:34:10 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BL2FFO11OLC001.mail.protection.outlook.com (10.173.161.185) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 15 Jun 2015 16:34:10 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5FGBCCm008532; Mon, 15 Jun 2015 11:21:13 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm2.corp.sprint.com with ESMTP id 1v0ja146hd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 11:21:13 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jun 2015 12:21:12 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Mon, 15 Jun 2015 11:21:12 -0500 From: "Bertz, Lyle T [CTO]" To: Stephen Farrell , The IESG Thread-Topic: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) Thread-Index: AQHQoegaH4e2TeOE+k+EzrS0GsjEV52txLsg Date: Mon, 15 Jun 2015 16:21:11 +0000 Message-ID: <24d8500889194ef9bce335a76dad537a@PLSWE13M07.ad.sprint.com> References: <20150608123856.12743.47035.idtracker@ietfa.amsl.com> In-Reply-To: <20150608123856.12743.47035.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC001; 1:mgKJonvS1qF6KQvDMhOMuw/139p6DHS5bFx3dgHFde6mqPcihBNy2jZJmgb4yLyjdgVLCNGz2Yx+m2yrCB4FiLtbaMqLM7oEant0PSMwkPcpwbvltLAWCAuZ1qyV2CM+F1QdQgVEuGQi5ebg2hUzt9UIT/jy9bks1eogg859goVPcuYeODxf3J2KFeOfBgsCaQlkEVKZz55NiHjjwFaQBaOTOWgZUF1vgF5xsa8ogSvO6T6uG1BoVd5BJRf7T8ka5LarHKWGkGMxPJzP5froYbTJGAYej7Xg0mZZqNTIvwlF2KSNBqYfYnaDXSSDuoqzgenPGgMqkomKrkDcsxmDJGjxP6gFvgoJG/6P83T2T2g= X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(199003)(52044002)(13464003)(377454003)(189002)(33646002)(2900100001)(561944003)(5250100002)(5001960100002)(54356999)(5001770100001)(230783001)(108616004)(76176999)(189998001)(5003600100002)(86362001)(19580405001)(19580395003)(15975445007)(87936001)(2950100001)(92566002)(6806004)(97756001)(85326001)(46406003)(102836002)(106116001)(50986999)(23726002)(46102003)(24736003)(106466001)(77156002)(50466002)(2656002)(47776003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB038; H:plsapdm2.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 2:h7JM778pidyH9f9C67711MYF+8P8xbuX6GEcBf794T7alBsigKsr+SBY145WoWDU; 2:9jfHmuJd50GOKBA3QTxOW7VhK+R+z3PO045UCpVf2XmNonIagzVFigkILGQ7gDWeeF0easZgiSXv4Vz1cLOoJVtWmvgJEkGsoi1LITm5WALvJvanFuj/bePQfWr9EUOx8XOnTpm9U38aRXenMlzSz8j8weCwJ7+bLoz1XgxeBX8kbej4egNuAL/UmYtFhGkb1tvLn/GNPK4hC9vFAqvaRdGSmPP5y/cRBT8r7I6IpBO9Z8gR1QtwIlj/jUBj0Uc2; 6:SUdpqoEyeOzYiOH9xNkJygL9IvrIQebEz6Vh66LZCk6E2OxpS8+MlLjCmzSIFk8nygh67GRfsF8iBdL1ocungBw7TurkAhjAQgtvX25+vi948vGzyKZKYuIlLc1dXsKbBhft306nrurc5/K1pRbh8cQLWbSvcI9Z0FqzV8aAExrZSJQ0XDXz7c8MOtUAepQo9shPddb+POuVt6xZUxsjrJZv56YawrmtEvXI2dWxvH8AVInzFhu/oIEm0eyL3VHU; 3:Pl3AC6NF3sgRnStGw6IEqOCIKjSWAdK+oBa3Q0Ul27PQgEScReBaYfAJk1bqx+8p3VxyKq+YR/s5/mBxtVkg9o7hzQLfgBPKDXDjXi1xF7GpRwaleappD4T45Myve3GEv/42cbYSpSLdE9m1yqFoayMFxSWXCIwOO+D1hWq5OyS1eiSW+yEQp4+TQC/xupAX7oSZHmuzFWexg1Gc72qUib6EJ4O8z9LN1Lvc5kiTzzobGUFh76HcdA87vDT4gHHW/uOsN1vj48CfSfM9HUAJ/7IvuJ23aEQmfKCPvS27/aZzyYqZX0Z8V1kjugaFNyPD X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB038; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BL2FFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB038; X-Forefront-PRVS: 0608DEDB67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB038; 9:AQHHoQSfRjXXhMgMMP+OZcIrVuUVh9xhyWowrKXDZ?= =?us-ascii?Q?yLRD9yhFjBDwcxdZNim2Np9+CMT4NI8BA7NHzKMAzroswU/0i+Lqu1/8qN5l?= =?us-ascii?Q?aGHgL6GKG7NHc7DD73rHIdR2Fv8qsI7kNTX/CrIbIsBdKQYMdILKesJG1FsJ?= =?us-ascii?Q?+39RveWU+9liR7da+ehWyPLntbVupTZwstCMduU7WN4VjUgyg+3EGY+TQe0G?= =?us-ascii?Q?ADx7DLMZa8tnS2zfGvTPJQcLE9sh4v2LUok+lM60gNkqqmfhBHs+GBatHC4g?= =?us-ascii?Q?fcTl2NjB/Z+qhZwOO1hqgQeXQxkFD0Afbj/8NaF4bnft5ulKG8Cbu2N7WIDu?= =?us-ascii?Q?Y41dNuVk6wxS7zcplBJN+vdDDP2qsmVxHuDjGlNAd4Jc2rxrRT5pG1PtqvsV?= =?us-ascii?Q?T8DHSbKGhiIzpkf9TtJrbw1sqitzdDMg/O7f1yDTavVamiGuX1eKPQUJ7nSC?= =?us-ascii?Q?MNwUQP5UEwniDA8JnM2OGQAuMKYyR/BBdVKWoAKx9wVmcO0oI0g72icN0P6+?= =?us-ascii?Q?AgGSJ55c6QawFBf4pvSVBTWz0kMCeZdOSl3FQXenB2XQrTFDKZ9DFJthdBfk?= =?us-ascii?Q?rJj32Z0sEN19jH0JXx1S4vXNIEH6jIG9Vfutx1rxET7h+2iCeEIesH9s3c1E?= =?us-ascii?Q?3Mkx4ToFXRqJHJ0jrTQysuVVW42TCo0DpET9GrKeVF9L5g/U6pmSsIc2Yz45?= =?us-ascii?Q?1/CjksiEr2Cw/hOUNfbGq2kc8KX4HY+Q+JgTm8wHiCwBrqS/FWFMX4w7MOQb?= =?us-ascii?Q?yGdB7dA4A+dpqbV+IVOnv8wlmIyM1s5fDI7s/BnB+DG6E/K646RId1oSikDf?= =?us-ascii?Q?s9L/SXs6ElH7WHs/EDG6C7knuztqSsO80gE0++HOhbGFIFYtFj1XHVS7LFdu?= =?us-ascii?Q?Oy0yIEBu8VEW6V3pu+/7UQEboEQMKwVOUEuHFWQMsqYlYckiyUujUt3CbTZ1?= =?us-ascii?Q?gSVspG4ROOwPE7887i33YTcb628kqbmie5JzUsQYQs4ROr9GfMwuDNo4Dleg?= =?us-ascii?Q?ESz5STt0CDHK2OxovnWCNvDBNkYq34EZH9gpJfsy98fxeF0X5DJzXjjPaNbf?= =?us-ascii?Q?riRY2M5TFlGUnb8lgqMe7Q+MF4Kfbio6BCiq1MmrYgbBIpFOg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 3:Rb6lSkZ7xeqQl1+J0y97eI/6BiMeolqMkFCJzrcqGGJ4dRc8iDBS5P9r8DvYNZK6aSOnT4VUPk9KPpXe//g59amywzae88o+OlRv0yduNq8Gb9RkJkWrh8SLuqUGDST9LGsHvRWkRvZ0EAb6UEq+Dw==; 10:2WemLyGQQxwPgyLRsFo1zQ9sdwvrzSKjYyZD2t8zL7+aqofu4ReRBXoNr7eUtDylHRi7wOFAQj7FtC2F1oLegEzPX7yz4J0wQu1/Bu943Oc= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2015 16:34:10.2799 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB038 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:34:17 -0000 Stephen, Thank you for the review. Our comments and suggested changes are below. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, June 08, 2015 7:39 AM To: The IESG Cc: dime-chairs@ietf.org; dime@ietf.org Subject: [Dime] Stephen Farrell's No Objection on draft-ietf-dime-congestio= n-flow-attributes-01: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes= / ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: This isn't clear enough that you're talking about using Diamete= r to help manage networks in which ECN may be used, as opposed to dealing w= ith Diameter packets with the ECN bit set. While that may be obvious when o= ne reads the text, some people will only see the abstract so I'd say maybe = consider clarifying that here too. >>>> Originally a title was suggested that included ECN. An internal revie= wer noted that at any one moment an administrator may not have ECN based Fi= lter-Rules in place but could still use the Flow-Count and Packet-Count. We= then realized that ECN was not mandatory and therefore was a bit soft in t= he abstract. In fact that is why we say ' ECN or Diameter traffic', otherw= ise we would merely state 'ECN related' >>> Another pass has been taken at the Intro, we included a couple of updat= es from other commenters and I will note that in their responses as well. -------------- New Intro ---------------- This document defines optional Diameter attributes that can be used to help= manage networks that use Explicit Congestion Notification (ECN) or Diamete= r traffic filters. These new attributes allow for improved data traffic ide= ntification, support of ECN and minimize Diameter filter administration. RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates= extensions for classification, conditions and actions. It however, does no= t support traffic identification for packets using Explicit Congestion Not= ification as defined in RFC 3168 and does not provide specific actions when= the flow(s) described by the Filter-Rule are congested. Further, a Filter-Rule can describe multiple flows but not the exact number= of flows. Flow count and other associated data (e.g. packets) are not capt= ured in Accounting applications, leaving administrators without useful info= rmation regarding the effectiveness or appropriateness of the filter defini= tion. The optional attributes defined in this document are forward and backwards = compatible with RFC 5777. --------------------------------------------- - intro: "the document" in 1st sentence is ambiguous - do you mean 3168 or = this document? I assume s/the/this/ would be better. >>>> We will change to "the document" to "this document". - intro: 2nd last para: what is an "ECN application"? Maybe you mean "netwo= rks deploying/using ECN" or something? >>>> We propose changing "ECN application" to "congestion management functi= ons". - 3.3: is a 64-bit counter maybe too big for a number of flows? Would it be worth adding guidance to the effect that Diameter nodes ought h= ave some max-believeable-flows setting just to avoid fat-finger or similar = errors resulting in someone thinking there are 2^64-1 flows and trying to i= terate over that number of things or allocate O(that) much memory? >>>> This depends entirely on the scope of the filter (Classifier) put in t= he Filter-Rule. There are some Diameter applications that group results a= nd we did not want to force them into a situation where they needed a 64 bi= t version of a 32 bit AVP. - 3.4: do you need to specify some kind of wrap-around rule for this? What = value do I need to use if I've seen 2^64 packets? >>>> There are numerous rules in the IETF and other standards bodies for wr= ap around in Diameter accounting and we felt that further specification is = unnecessary. (In fact, if we could reduce the amount and get to some consi= stency that would be fantastic but is out of the scope of this discussion.) - 5.2: Please expand CCR on 1st use and provide a reference if one is neede= d. (Is it "Credit Control Request"?) >>>> Yes it is Credit Control Request. We will expand out the acronym for= CCR at its first appearance (first paragraph in the section). - 5.2: 2nd last para, last sentence: Thanks! I think it's good that folks a= re including this consideration in ongoing work. >>>> You're welcome. This is important to the authors and provides a compr= omise between what is necessary for congestion management and what is too m= uch. - Section 6: 1st sentence is not needed and is usually a red flag statement= (for me, but not only me:-) Actually, you could just lose the first para e= ntirely. >>>> We are going to scratch the first sentence and add a bit more per Ben = Campbell 's review. (Two more quite nitty things below, but I'll ask anyway:-) - section 6: does this define any new way in which a bad sending Diameter n= ode could cause bad things to happen elsewhre in the network? (see comment = above about section 3.3) >>>> No. Sending more bad information to a Diameter application does not ma= ke the situation worse. If the node was poor (and not just a bad actor) th= en sending more information that conflicts would be easier to detect. Howe= ver, I would not give credit to this proposal for making the detection of b= ad Diameter nodes easier. I would presume if someone took the time to crea= te a bad acting node they would have skills or clumsiness (depending upon i= ntent) to report information in such a way that the Diameter application co= uld not detect it regardless of the amount of information it sent. - section 6: When I took a glance at the security considerations in 5777, i= t doesn't seem to consider that the "treatment" field could cause bad thing= s to happen. Is that worth mentioning here (if real) even if it ought be m= ore properly handled in some kind of update of 5777 sometime in the (probab= ly far;-) future? >>>> Recommendations currently for the document is that it is not an update= to 5777 so my concern would be that even if a discussion occurs here it wo= uld be missed by the casual reader of 5777. As treatment action occurs bas= ed upon the larger Filter-Rule structure so I am reluctant to blame the ham= mer for hitting my finger but will probably do it anyway :D. A general dis= cussion of classifiers and actions would be good but it is far broader than= this proposal (and many more pages imo but I am prone to long responses as= well). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jun 15 09:43:54 2015 Return-Path: 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 735F21A908C; Mon, 15 Jun 2015 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 mPESqvWatYZe; Mon, 15 Jun 2015 09:43:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5A41A908A; Mon, 15 Jun 2015 09:43:49 -0700 (PDT) Received: from BN1AFFO11FD032.protection.gbl (10.58.52.33) by BN1AFFO11HUB010.protection.gbl (10.58.52.120) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:43:31 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 15 Jun 2015 16:43:30 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5FGZDC9004787; Mon, 15 Jun 2015 12:43:30 -0400 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by preapdm1.corp.sprint.com with ESMTP id 1v0h0a4mn7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 12:43:30 -0400 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jun 2015 12:43:29 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Mon, 15 Jun 2015 11:43:29 -0500 From: "Bertz, Lyle T [CTO]" To: Ben Campbell , The IESG Thread-Topic: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) Thread-Index: AQHQouX71p1RMb+akkKP57wDqWfHap2tyQQQ Date: Mon, 15 Jun 2015 16:43:28 +0000 Message-ID: <7c2281e81c8c4f7592d8fcd8478211bd@PLSWE13M07.ad.sprint.com> References: <20150609185615.7145.32430.idtracker@ietfa.amsl.com> In-Reply-To: <20150609185615.7145.32430.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD032; 1:SMHlw1v59eog3iCzRUh3jsxJEZXUzYvqbJsv6TU81vtTIfLAhOvMrrgTa9dkp/4oc6ADiE1tgEAnFqGhO6uMZ6mBLDViyxdPBgvJeLwJmJJsnmxpzJstaGfcdGqJ4Dk9CdZ7GYjIOTkDrzBTeQrfDTP5bNs0uqn144bSl9O/ttm8HPhYvZopwdwIAZ6GM8zwO2VHS35kYlFZISJKSGyXcwm1ZYbrOws/L75v777RsT6PURAUGgwdQLd5mC29rwoAsRPexWh3DMgFWM/Z31eBkTZ1T89ZGgFssrCNFXRTW7er9sRpK9s/K1pZHGNuFJEKCrLqALxdhXwQn4p9Oe/wYQ== X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(13464003)(377454003)(52044002)(189002)(199003)(62966003)(23676002)(77156002)(86362001)(106116001)(5250100002)(54356999)(76176999)(85326001)(50986999)(19580405001)(6806004)(5001960100002)(108616004)(189998001)(33646002)(46102003)(24736003)(2950100001)(2900100001)(5003600100002)(19580395003)(230783001)(87936001)(50466002)(2656002)(5001770100001)(92566002)(102836002)(106466001)(15975445007)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB010; H:preapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB010; 2:gxKIpp2lnQArn4/ftiq64muhKPClfKEyiDFL+h08ylLZ77ebp+DnHrqjg0dyNs3C; 2:8Sdc3KyoyryyZ1ahzp2Gcyw+mgprCFeGEKje9d9rJiZ3joKturzKkhCiv54HsdSCwATApqz4Uz104aMX2cvgSQaZsuQ+kwzj51uhKGZx1ccyeIdMCM3xjYRhQuhiZliiIxcFl2XQ+U5eZxdPJMqYkIOPN0AiBBvlz3PkJdhmU0AngFTuUatBl7CHQFz7uWHNhiRNCK93oLZMukiumld3xYOcl2APLYOQwZvh2bIH2B4=; 6:RCyPOP7N5UYhK6FyY8yqkTp2VOE4Z0mpIVmKx3HPuGXbZzAh8q4pXYQrq4SvOzq5IFePa7yq2o8XfxkxytRB2Jhb/iapevjHf2N+UDBGWMYQkTfB3HtizmhR7E5i7WX1xctQcsxNUFdrevwXL03jutasHCIKtWTAY1N1NFF0+grzQx/FC1pBOj0uHRZtIQ2VhQ6MLEA3JcR/2ocJZMtXy+izXFmrk8uVZxqMymH7KVfIDMublGUZVQlYC4iXqok6; 3:BvP181wSHwuxHMQNjotI4JH6H8V8gLINFQqA7qE32w6j3dfEz5PDNWzDzlCIrdg4NI6JHzEJPQRRJWp7jt4DiwSTgF/q5OJNU2IrAjUKp2v7ItPMGQx8xLYVc1xa78q0MliMEbGe1UQKUevaNgV/FThvTlNqwWc6soosy6BpTEivHN1HWlUucIhlczaP0Fr1HwIW0T3cJnOMiMokNk3HGRqw5WXqCFiN8+/Gnm1UfD6lVz9jWUSE+u4WlGGs3E3F2/lP7JOjKJWCJU/qUDdpv0Js+AdRsKbrAEa5PIJFDe82w20ZvhwJyv36gFTW2Esz X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB010; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN1AFFO11HUB010; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB010; X-Forefront-PRVS: 0608DEDB67 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMTA7OTo3SE80MGhUbHZveUxtdWxvYlpNem92TFBY?= =?utf-8?B?bTIrVVlnRFpsNWxQMmlYMGIvUGVxd0VSNmtzaGx3VVJ2ZXhPWDJrZml2dnE1?= =?utf-8?B?UmhPS3B0K0lTZ1FndkNHYjdWd291d25McERvNlN1M25SV1FNZi9EcDFOV0t5?= =?utf-8?B?OUtFQjl6a251V1ZBQVFRVlNxeU96OTBwRS9WL1BEOENmbEZNdWF5N0trQzhT?= =?utf-8?B?RjJDT240ckg1OFRrTmJzRGwydDdwZk1zbkd2a1pCZktLcHNmc1ZFdGRzZVoz?= =?utf-8?B?bFZvVHZsSU9adVA2NzlwS282MzVFVWtEekNCNUdPK09ET1I5N0JEU2trOXlw?= =?utf-8?B?bHdweTU4cVBZOFIrWHd0K2pSUW9TL085M2lkb2xmNlZZMlFzYVA1d05WbVdq?= =?utf-8?B?cHd5RXNUcHYrM3cwWGlINGlSdkdEY3J4Q2tsR25WOUNHWEhudUhPZDF5TnZV?= =?utf-8?B?NFNwdC9RS0lEWlZQVzROU2p4Y0lTNlFjQm04cmVyaFV0Um9pcUlPZmdFSytK?= =?utf-8?B?KzVVRTYyQXdBbVZIcjNPYVF6QzlxNjFObmFCcEg1Sm0rU2V0OWp0SUxZNXAy?= =?utf-8?B?SzNuSWJYSUxZbHp6REswS0JlaS94U05KM1JWQVRiSTR6ZEQvSVovQkVHV0pY?= =?utf-8?B?VVdHeVhGYU1jT2xoTEFWcm5RS0lrVVpaeDBXWTAwS1NuN01JSXdrTytGdFlr?= =?utf-8?B?K2VNK0pFejl6UFhqOEl4QlBqSjNtQmJmaHNqckhKVFNCWHRYTkRXU0h0bEFh?= =?utf-8?B?NlgxeW1PWk95OU9wRUJCendLVENQQzJ1Qm5tSG1TMHpTQk90Ykk2OTRoaXNV?= =?utf-8?B?VCtlcldqTXRaSWRRVTV3aWFLS04rT2NDMWtDUVZyMEJEK2xSYmNyVVZhUUNF?= =?utf-8?B?U1l5QmJBWG9NQkwzS3RhWXhFK0tiVjJ3eVhhdFM2T2hyNlptSklHc1VJMnNZ?= =?utf-8?B?R3k3TXZYUUc0Q0M3QWZLOEt6elp1UjJtSXBUanFzaCtaWXhQRDBCeHA4Y29N?= =?utf-8?B?R3IwWFQ2SFVOd1NiQWdZNVZhT2VSeFcyS2ZTODdhR2svd3dRYnhZd25MbW8w?= =?utf-8?B?YmtvcU1YeEk4RTk5RUlZL3hvQzgwdGxCdkxDTiswdGRZMFVOd21sZnBlYXJy?= =?utf-8?B?R1lYdzZVbnZ0UHd6UFFKSEk4Wkloa1RtbmhrQytMZWllZ2Y2OEUrMk40S29m?= =?utf-8?B?NFpTdUFBclphRXVFMWhndDZXUlNHYTUyeCtFUWNSVjZyc09kRzFBYzVkWkpx?= =?utf-8?B?NFdheENXeDZYREZkWk9wVE5la2RZRHByYytHNSs0NDlpZDFCTjd6VGVPTnR2?= =?utf-8?B?ejFwUEJUTW1yRy9jWW5KL0c5cnNKbDhnWmRsK1VRUjVqU0ppWjNLU04zQmds?= =?utf-8?B?Qmdwc0ZkeWQ0RjBoNnlVKzJieGNtdjlMYjBYNWkzZz09?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB010; 3:6YuSWUHnObn8/qluMWTyo3BrfBsM952m9t2R4ypBf2UHxgbE02gh4t9l/159R+lR97QwM0MNRdj7wS3x7nTnB2f4Of8C5FtMMvE9JHz3MUgrRdO2mcV+9SA4odUIL2Z25NxuMF5lXPMNCXizWrN3LA==; 10:2xYsBsgfswfYDms506OKyXzJhLokzXCoO/UmqXMvsW4IJcLJOZSUatnBUivyN/bsmEzxlprNa7LpesN5l/f9Mv3eVZbwrtDIgbBRRJxG/kU= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2015 16:43:30.9702 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB010 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:43:52 -0000 QmVuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuICBPdXIgY2hhbmdlcyBhbmQgcmVzcG9u c2VzIGFyZSBiZWxvdy4NCg0KTHlsZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBD YW1wYmVsbA0KU2VudDogVHVlc2RheSwgSnVuZSAwOSwgMjAxNSAxOjU2IFBNDQpUbzogVGhlIElF U0cNCkNjOiBkaW1lLWNoYWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogW0Rp bWVdIEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWRpbWUtY29uZ2Vz dGlvbi1mbG93LWF0dHJpYnV0ZXMtMDE6ICh3aXRoIENPTU1FTlQpDQoNCkJlbiBDYW1wYmVsbCBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYt ZGltZS1jb25nZXN0aW9uLWZsb3ctYXR0cmlidXRlcy0wMTogTm8gT2JqZWN0aW9uDQoNCldoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikN Cg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGltZS1jb25nZXN0aW9uLWZsb3ctYXR0 cmlidXRlcy8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN ClRoaXMgbW9zdGx5IGxvb2tzIGdvb2QuIEkgaGF2ZSBhIGZldyBjb21tZW50cyB0aGF0IGFyZSBu b3Qgc2hvdw0Kc3RvcHBlcnM6DQoNCnN1YnN0YW50aXZlOg0KDQotLSBBYnN0cmFjdDogSSBjb25j dXIgd2l0aCBTdGVwaGVuIHRoYXQgdGhlIGFic3RyYWN0IGRvZXNuJ3QgcmVhbGx5IGFkZHJlc3Mg dGhlIGhlYXJ0IG9mIHRoZSBtYXR0ZXIuIChJdCBhbHNvIHNlZW1zIGxvbmdlciB0aGFuIG5lZWRl ZC4pDQoNCj4+Pj4gV2UgcmVzcG9uZGVkIHRvIFN0ZXBoZW4ncyBjb21tZW50cyByZWdhcmRpbmcg dGhlIGludHJvLiAgSWYgeW91IGNvdWxkIGdpdmUgeW91ciBmZWVkYmFjayBvbiB0aGF0IHRocmVh ZCBpdCB3b3VsZCBiZSBtdWNoIGFwcHJlY2lhdGVkLg0KDQotLSA1LjI6IEkgZG9u4oCZdCBzZWUg dGhlIENvbmdlc3Rpb24tVHJlYXRtZW50IEFWUCBhY3R1YWxseSB1c2VkIGluIHRoZSBleGFtcGxl LiBBdCBsZWFzdCBpZiBpdCBpcywgaXTigJlzIG5vdCBjYWxsZWQgb3V0LiBJIHRoaW5rIGl0IHdv dWxkIGJlIGhlbHBmdWwgdG8gZXhwbGljaXRseSBzaG93IGl0LiBBbHNvLCBjYW4geW91IGFkZCBh IHJlZmVyZW5jZSBmb3IgRXhjZXNzLVRyZWF0bWVudD8NCg0KPj4+PiBXZSBoYXZlIG5vdCBhZGRl ZCBvbmUgZm9yIENvbmdlc3Rpb24tVHJlYXRtZW50IGR1ZSB0byB0aGUgc2ltaWxhcml0eSB0byBF eGNlc3MgVHJlYXRtZW50LiBUaGUgZXhhbXBsZSB3ZSBkcmFmdGVkIHdlcmUgc2ltcGxpc3RpYyBh dCBiZXN0LCAiQ0UgbWFyayBzZXQgdGhlIERpYW1ldGVyIG5vZGUgZGVjbGFyZXMgY29uZ2VzdGlv biBhbmQgYWN0cyBhY2NvcmRpbmcgdG8gdGhlIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoZSBD b25nZXN0aW9uLVRyZWF0bWVudCBBVlAiLiAgQmVjYXVzZSB0aGUgQVZQIGxldHMgdGhlIG5vZGUg dGFrZSBpbW1lZGlhdGUgYWN0aW9uIHRoZSBleGFtcGxlIHdhcyBzbWFsbCBhbmQgdGhlbiBpdCBi ZWNhbWUgYSBxdWVzdGlvbiBvZiB3aGV0aGVyIGl0IHNob3VsZCBiZSBpdHMgb3duIHN1YmhlYWRp bmcgaW4gdGhlIGV4YW1wbGVzLiAgSW4gdGhhdCBjYXNlIHlvdSBoYXZlIGEgbmV3IHN1YmhlYWRp bmcgZm9yIHJvdWdobHkgYSBvbmUgbGluZSBzZW50ZW5jZS4NCg0KIklmIEV4Y2Vzcy1UcmVhdG1l bnQgb3IgQ29uZ2VzdGlvbi1UcmVhdG1lbnQgaGFzIG9jY3VycmVkLi4uIg0KDQpEb2VzIHRoaXMg bWVhbiDigJxpZiB0aGUgY29uZGl0aW9ucyBhc3NvY2lhdGVkIHdpdGggRXhjZXNzLVRyZWF0bWVu dCBvciBDb25nZXN0aW9uLVRyZWF0bWVudCBoYXZlIG9jY3VycmVk4oCdLCBvciDigJxFeGNlc3Mt VHJlYXRtZW50IG9yIENvbmdlc3Rpb24tVHJlYXRtZW50IGhhdmUgYmVlbg0KIHNlbnQgaW4gYSBE aWFtZXRlciBtZXNzYWdl4oCdPw0KDQo+Pj4+IEl0IGlzIGNvbmRpdGlvbnMgYXNzb2NpYXRlZCB3 aXRoIC4uLiAgIFRoZSBwb2ludCBvZiA1Nzc3IGlzIHRvIGdpdmUgdGhlIG5vZGUgcmVjZWl2aW5n IHRoZSBGaWx0ZXItUnVsZSBhIHBsYW4gb2Ygd2hhdCB0byBkbyB3aGVuIHRoZSBjb25kaXRpb25z IG9jY3VyIGFzIG9wcG9zZWQgdG8gdGhlIG5vZGUgcXVlcnlpbmcgYSBkZWNpc2lvbiBwb2ludCBm b3IgbW9yZSBkaXJlY3Rpb24uICBXZSB3aWxsIGNoYW5nZSB0aGUgdGV4dCB0byAiSWYgY29uZGl0 aW9ucyBhc3NvY2lhdGVkIHdpdGggRXhjZXNzLVRyZWF0bWVudCBbUkZDNTc3N10gLi4uICINCg0K LS02LCBmaXJzdCBzZW50ZW5jZS4NCg0KSeKAmWQgbGlrZSB0byBzZWUgYSBsaXR0bGUgbW9yZSDi gJxzaG93IHlvdXIgd29yayIgaGVyZS4gVGhlc2UgQVZQcyBjYXJyeSBuZXcga2luZHMgb2YgY29u dGVudC4gVGhhdCwgaW4gaXRzZWxmLCBtaWdodCBhZGQgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIChlLmcuIGlzIHRoZSBjb250ZW50IHByaXZhY3ktc2Vuc2l0aXZlLCBlc3BlY2lhbGx5IGRh bWFnaW5nIGlmIHRhbXBlcmVkIHdpdGgsIGV0YykuIFBsZWFzZSBjb25zaWRlciBhZGRpbmcgYSBm ZXcgc2VudGVuY2VzIGRlc2NyaWJpbmcgdGhlIG5ldyBjb250ZW50LCBhbmQgd2h5IHlvdSBiZWxp ZXZlIHRoYXQgY29udGVudCBkb2VzIG9yIGRvZXMgbm90IGhhdmUgbmV3IHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLiBZb3Uga2luZCBvZiBkbyB0aGF0IGZvciBFQ04tSVAtQ29kZXBvaW50IGFuZCBD b25nZXN0aW9uLVRyZWF0bWVudCwgYnV0IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGZvciB0aGUgb3Ro ZXIgdHdvIG5ldyBBVlBzLg0KDQooSSdtIHByb2JhYmx5IHRoZSBvdGhlciBwZXJzb24gdGhhdCBT dGVwaGVuIG1lbnRpb25lZCBjb25zaWRlciBzdWNoIHNlbnRlbmNlcyBhcyBhIHJlZCBmbGFnLikN Cg0KPj4+PiBPay4gIEJpZ2dlciB1cGRhdGUgaGVyZS4gIFdlIGFyZSBkcm9wcGluZyB0aGUgZmly c3Qgc2VudGVuY2UgYW5kIGV4cGFuZGluZyB1cG9uIHRoZSBub3RlIHdlIG1hZGUgaW4gNS4yIGFi b3V0IGxlc3MgcmVsaWFuY2Ugb24gRFBJIGZvciBhdCBsZWFzdCBjb25nZXN0aW9uIG1hbmFnZW1l bnQuDQo+Pj4+IFRoaXMgaXMgdGhlIG5ldyBTZWN0aW9uIDYuICBUaGUgbGFzdCBwYXJhZ3JhcGgg aXMgdW5jaGFuZ2VkLg0KDQotLS0tLS0tLSBOZXcgU2VjdGlvbiA2IC0tLS0tLS0tDQpUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gb2YgUkZDNTc3NyB0aGF0IGludHJvZHVjZXMg YSBuZXcgZmlsdGVyIHBhcmFtZXRlciBhcHBsaWVkIHRvIEVDTiBhcyBkZWZpbmVkIGJ5IFtSRkMz MTY4XS4gIEl0IGFsc28gZGVmaW5lcyBhIG5ldyBHcm91cGVkIEFWUCB0aGF0IGV4cHJlc3NlcyB3 aGF0IGFjdGlvbiB0byB0YWtlIHNob3VsZCBjb25nZXN0aW9uIGJlIGRldGVjdGVkLiAgVGhlIEdy b3VwZWQgQVZQIHJldXNlcyBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gUkZDNTc3Ny4gQXMgdGhlc2Ug YXJlIGV4dGVuc2lvbnMgdG8gUkZDIDU3NzcsIHRoZXkgZG8gbm90IHJhaXNlIG5ldyBzZWN1cml0 eSBjb25jZXJucy4NCg0KVGhlIEZsb3ctQ291bnQgYW5kIFBhY2tldC1Db3VudCBBVlBzIGNhbiBi ZSBwcm92aWRlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGN1c3RvbWFyeSBBVlBzLCBlLmcuIEJ5dGVz LCBUaW1lLCBTZXJ2aWNlIFVuaXRzLCBkdXJpbmcgQWNjb3VudGluZyBhY3Rpdml0aWVzIGFzIGRl c2NyaWJlZCBpbiB0aGUgYmFzZSBwcm90b2NvbCBbUkZDNjczM10gb3Igb3RoZXIgRGlhbWV0ZXIg YXBwbGljYXRpb25zLiBUaGVzZSBBVlBzIHByb3ZpZGUgaW5mb3JtYXRpb24gdGhhdCBjYW4gYmUg cHJpdmFjeSBzZW5zaXRpdmUuICBUaGUgcHJpdmFjeSBzZW5zaXRpdml0eSBpcyBkaXJlY3RseSBy ZWxhdGVkIHRvIHRyYWZmaWMgY2FwdHVyZWQgYnkgRmlsdGVycyBhbmQgYXNzb2NpYXRlZCByZXBv cnRzLiAgTmFycm93IGZpbHRlcmluZywgd2hpY2ggY3JlYXRlcyB0aGUgaGlnaGVzdCBsZXZlbCBv ZiBwcml2YWN5IHNlbnNpdGl2aXR5LCBpcyB0b28gcmVzb3VyY2UgaW50ZW5zaXZlIHRvIGJlIHBy YWN0aWNhbCBvbiBsYXJnZSBuZXR3b3Jrcy4gIFBhcmFkb3hpY2FsbHksIGltcHJvdmluZyByZXBv cnRpbmcgaW5mb3JtYXRpb24gbGVzc2VucyB0aGUgZGVwdGggb2YgaW5zcGVjdGlvbiByZXF1aXJl ZCB0byBjaGFyYWN0ZXJpemUgdHJhZmZpYyBmb3IgbWFueSBjb25nZXN0aW9uIG1hbmFnZW1lbnQg YWN0aXZpdGllcyBhcyBub3RlZCBpbiBTZWN0aW9uIDUuMi4NCg0KSWYgYW4gYWRtaW5pc3RyYXRv ciBjYW4gcHJvdmlkZSBjb25nZXN0aW9uIGFjdGlvbnMgd2l0aG91dCB0aGUgbmVlZCB0byByZXBv cnQgdGhlbSB0byBhIERpYW1ldGVyIGFwcGxpY2F0aW9uIHRoZXkgc2hvdWxkIHVzZSB0aGUgQ29u Z2VzdGlvbi1UcmVhdG1lbnQgQVZQIHdoaWNoIGFsc28gcmVkdWNlcyBEaWFtZXRlciB0cmFmZmlj IGR1cmluZyBjb25nZXN0aW9uIGV2ZW50cy4NCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IG9mIHRoZSBEaWFtZXRlciBwcm90b2NvbCBpdHNlbGYgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiBS RkMgNjczMyBbUkZDNjczM10uICBVc2Ugb2YgdGhlIEFWUHMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50IE1VU1QgdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIHNlY3VyaXR5IGlzc3VlcyBhbmQg cmVxdWlyZW1lbnRzIG9mIHRoZSBEaWFtZXRlciBiYXNlIHByb3RvY29sLg0KX19fLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCj4+Pk90aGVyIHBvaW50cyAoanVzdCBwaWxpbmcgb24gaGVyZSBh dCB0aGlzIHBvaW50KToNCj4+PjEuICBTb21lIE1JQnMgaGF2ZSB0aGlzIGRhdGEgYnV0IHBvbGlj eSBkZWNpc2lvbiBwb2ludHMgaGF2ZSBleGlzdGluZyBEaWFtZXRlciBiYXNlZCBzZXNzaW9ucy4N Cj4+PjIuICBUaGlzIHNvbHV0aW9uIHdvcmtzIGlmIHRoZSB0cmFmZmljIGlzIGVuY3J5cHRlZCAg b3Igbm90IC0gcHJvdmlkaW5nIGEgbmVjZXNzYXJ5IGFuZCBzdWZmaWNpZW50IGJhc2VsaW5lIGZv ciBjb25nZXN0aW9uIG1hbmFnZW1lbnQuDQoNCj4+PiBXZSB0aG91Z2h0IHRoYXQgU2VjdGlvbiA1 LjIsIDJuZCBsYXN0IHBhcmEsIGxhc3Qgc2VudGVuY2UgZXhwcmVzc2VkIG91ciBpbnRlbnQgYnV0 IGhpZ2hsaWdodGluZyBpdCBhZ2FpbiBpbiBTZWN0aW9uIDYgaXMgbm90IGFuIGlzc3VlLiAgSW4g c3VtbWFyeSwgdGhlIGFkZGl0aW9uIG9mIHRoZSBBVlBzIGxlc3NlbnMgRFBJIHJlcXVpcmVtZW50 cyBmb3IgY29uZ2VzdGlvbiBtYW5hZ2VtZW50IGFuZCBhIG5lZWQgZm9yIHRoZSB0cmFmZmljIHRv IGJlIHVuZW5jcnlwdGVkIGluIG9yZGVyIHRvIHRha2UgY29uZ2VzdGlvbiBtYW5hZ2VtZW50IGFj dGlvbi4gIEFyZ3VhYmx5IHRoZXJlIG1heSBiZSBiZXR0ZXIgbWFuYWdlbWVudCBtZXRob2RzIHRo YXQgcmVxdWlyZSBjbGVhciBvciBvdGhlciBkcml2ZXJzIGZvciBEUEkgYnV0IGlmIG9uZSBiYXNl cyBhY3Rpb24gb24gRUNOLCBmbG93LCBwYWNrZXQgYW5kIGJ5dGUgY291bnQgdGhlbiBEUEkgYXJl IGNsZWFyIHRyYWZmaWMgaXMgbm90IHJlcXVpcmVkLg0KRWRpdG9yaWFsOg0KDQotLSBBYnN0cmFj dDogUGxlYXNlIGV4cGFuZCBFQ04gYW5kIEFWUCBvbiBmaXJzdCBtZW50aW9uIChib3RoIGluIGFi c3RyYWN0IGFuZCBpbiBib2R5LikNCg0KLS0gMy4yLCBmaXJzdCBwYXJhZ3JhcGggIkluIGNhc2Uu Li4iDQoNCkkgc3VnZ2VzdCBlaXRoZXIgIklmLi4uIiBvciAiSW4gdGhlIGNhc2UgdGhhdC4uLiIN Cg0KPj4+PiBXZSB3aWxsIGNoYW5nZSB0byAiSW4gdGhlIGNhc2UgdGhhdC4uLiINCg0KLS0gNS4x OiBUaGVyZSBhcmUgc2V2ZXJhbCBpbnN0YW5jZXMgb2YgIkVDUC1JUC1Db2RlcG9pbnQiIHRoYXQg SSBhc3N1bWUgc2hvdWxkIGJlICJFQ04uLi4iDQoNCj4+Pj4gWWVzLiBXZSB3aWxsIGNvcnJlY3Qu DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBt YWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlz IGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVy cyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVz c2FnZS4NCg== From nobody Mon Jun 15 09:47:23 2015 Return-Path: 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 23E241A909F; Mon, 15 Jun 2015 09:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 raH9MjPMC9lS; Mon, 15 Jun 2015 09:47:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046C81A8FD6; Mon, 15 Jun 2015 09:47:11 -0700 (PDT) Received: from BN1BFFO11FD017.protection.gbl (10.58.144.34) by BN1BFFO11HUB039.protection.gbl (10.58.144.186) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:47:07 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1BFFO11FD017.mail.protection.outlook.com (10.58.144.80) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 15 Jun 2015 16:47:08 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5FG1gfr021892; Mon, 15 Jun 2015 12:47:07 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm3.corp.sprint.com with ESMTP id 1v0es25c0k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 12:47:07 -0400 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jun 2015 12:47:06 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Mon, 15 Jun 2015 11:47:06 -0500 From: "Bertz, Lyle T [CTO]" To: Barry Leiba , The IESG Thread-Topic: [Dime] Barry Leiba's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) Thread-Index: AQHQord1bbNtd1w7Ek+EDUGTMW53752tz+nw Date: Mon, 15 Jun 2015 16:47:05 +0000 Message-ID: References: <20150609132312.9266.23086.idtracker@ietfa.amsl.com> In-Reply-To: <20150609132312.9266.23086.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD017; 1:+l04/nhvLeGkLhfA/EU2UB/5t2VMLPg0QbQrYSa/rVSoCfeOZd2gm+x3UYdZRU0UsowOe17AOyE5q+H6lfFkxnUaa1H0ddj0hlszMz0BvYvqAaUkpx9jV2J9Go/JzDnHrAO/vuk3b1W6zQXPtz55Cs9KwCkOMxQhwWHk3Y4jpsTPqCCfRAGTEdc8MJ9m8/EqdiE4RWyxynatPRvo5cCGj1K/jEY/X3ETnV2JmIshPsDxpG4Nyn2qaA6FvU2iM8SuvWQ75cANAAegUCkgfOX4ksN627rkxPFbITcHP7hwfu1tKQlTi9cdfN/9afWS9cUSZKI5pvnocytKPy+jCsKSJA== X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(13464003)(189002)(377454003)(199003)(52044002)(106116001)(85326001)(230783001)(108616004)(97756001)(33646002)(46406003)(5001960100002)(2950100001)(15975445007)(46102003)(102836002)(2900100001)(92566002)(50466002)(24736003)(5001770100001)(5003600100002)(47776003)(86362001)(62966003)(77156002)(2656002)(87936001)(6806004)(189998001)(23726002)(54356999)(106466001)(50986999)(5250100002)(19580405001)(19580395003)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB039; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB039; 2:c64cb5EkN53+/OKjw/2B71rD5gvaY9JTNknuhmc5GJR4xy0erWBFDU1TwAt+L2lW; 2:9Relywh/novGeiNv5Pa5K1auqc4sg53O1i+jnEkbAaKAoXNhCGcAIxdIy1JbxhPPzwg2CfncPKmHemAK9y3KDGy7j7dGN2sqHszQ6mLZRl31dwzwgo7PoZss6yL1OcQ5JrnQdnilsm0Grtf5mPItlpAs79/D4EQm+V6vBAo/sKuUUF9bxxShSRH1PxauKyZzu7wTEjMkh8SUojXQtKKMLjz++aM5hF6sKqtcUbzmq0c=; 6:4Q73/Avx0x8BRITIMnyQr2arNtLdSkkiFO0V0j56X9dqeU0yam8KhV9N8qzTGsqYFcrCFd47IGncQURWF9ZJNCiUoqRhCFl8PEjY861+uooLKyIRFidNyBiwtWsUHlHZH6RrYKtflFCotPjc8TTL1BPTrrwnDyTCij233gNtOhvUITzljTzHy6fgN3jljjmZy4XL3G8+33j1ja5G9EC3d2hFamFDZ2wpFpAaxogF7wf2GB+njlmK+gJb3A8LWYIl; 3:II1SJwEVZ9Jho5C7/XyNO9V4D/hRhlf6uCAQm2EYu5vjfgozYk3UCL/FmZKbeI3Resi2vYfq3mWTHX77W6ukfgRtMqY+L2WH50lhNwzvTpPvMcuTV5PaBdDwnPDu/17ESW9FV0X+9ULxwWoPW6/qCXEXhc7ZZytDch6d0dHxFWLTmjdbGB109vl5wMSfaByVwHmZoIvrAeCf4ZyVlaVvWS9OYo3H81EBQPb+qLkxZUjDGGWBcMjYD2fTJDlIsKB1kgpAPVbcUUHcEitg78JlswNgmTpvAlNT+cbIjDTOAw1bFJbw4lONpPqnXhsSsZWk X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB039; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1BFFO11HUB039; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB039; X-Forefront-PRVS: 0608DEDB67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB039; 9:V91T5P+EATlowsaejGLmWTSw9TTkhM8QV8P5mY9E?= =?us-ascii?Q?Bz9NSQZuQcd+Id9vplPBoQ/vGnAPz8/B8ObiBnNP7u0IghXebE24qduTDLgp?= =?us-ascii?Q?JzenKwP1b2tUGTupPQauiSv8HNWfqu3U/LXF0jTRo/mWPNASu66rrGKmtlbr?= =?us-ascii?Q?HuLDl0QG7/DwZIJOdcAQAslVgFaGd1GrIzUotk91M6U37qu6LceiaZTpS2wv?= =?us-ascii?Q?0Hchc/dA5Ep2xkCGz4Mv+kfzb1vfhQNIFR3+x+0EDXVONVRXZV2/qtxe0Ddd?= =?us-ascii?Q?9IzNQ7rSrM+fPovwzhb9G8ASQNMzWJovPsEEyav/TA5Xxc/TKFmdUKcq2++A?= =?us-ascii?Q?3EIsmGUXvGVXfE4swRJ1pJ4hU15xKJxpXrUi1OeUM2P3IZh58sJODW3gOgUl?= =?us-ascii?Q?GBA55SrTjPY/Bd1+vzWDHs7OZl0Lb+99bI0+JxqOoyRtntetipD3PwjBSYQk?= =?us-ascii?Q?uWx2yayljk30QcEMDv2Mixi6bNFrufo4SDkW84OfmUigp8MHP83vfpXETNXu?= =?us-ascii?Q?hmY2r6UH4psPCBxJPfsZ7baY0cF2/dtvNzvSR9EeIk61z4vGNlJ2T1oGxdP7?= =?us-ascii?Q?gvNtfmPQvLCJwO9zcpxzhf/FqcqwpCQ+qOdS5CqB6SMz9AXrcWQweUsJ7vyB?= =?us-ascii?Q?JAqdgbvIjj7CmchQuW9cffYMs/ggSHWGUyILzEO8sExU3dw2qBBcyWLa1fJu?= =?us-ascii?Q?AlxDYC9ZHPZL5bEptd78DYFh07Y8FpFiU92Jvr6JkJM7wG673B0fflDJt6ag?= =?us-ascii?Q?hf/Cu+WIpUZhGqB6XQyISCibkzyQBn4WrqpVGCTFnqnghT9FfuTST5Egfo2k?= =?us-ascii?Q?XT/I0ZpBRN0/o9+4a9J1UXa+IWUL/bLNFCq0P0zi9WH5tLPbuE3rakQd42KQ?= =?us-ascii?Q?KdJaBFs3pi0Jtqnx4LxGm5TVeof5Y3yOzC66QwpTyLyXPTERXRQbEacobnKa?= =?us-ascii?Q?IVCF2qxTdA6bCg9ss5LrlfmyRGXiabfaimY5f9tX71ji4VNw7WsmfDtsGwwB?= =?us-ascii?Q?oP5IzHLlHSRJNVdAGFa1mufzRBVt3tEQku54fNHfMjHruEf+gDgrNH3zTizm?= =?us-ascii?Q?robtGbD0I9hCC6Z6fq8zYJb+e5Ux?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB039; 3:F+rQ5TR7Qavay1UPXyT0tR8PN+iSo9QCl3uvq3kOl0NVAtLFixxZlapMv6zLwbhM1lJZo79nvUS53hJQxqjkVXMjhbVcdCMFXl/LCkK4EJCeNeziYiQnNJuDi6WoqAZO6XsvETVfCT5QEFO/AT7/Sg==; 10:Tf3/DV6N7FSh0HQUCcERQJmhfKwloqAXKxMzCE/Kokh3k1BPXWlZ7ykaqV7Di5vFjM7SntUpGes6Oql/k9NMYpKy52adcjgMcoU+9/TB+qQ= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2015 16:47:08.0076 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB039 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Barry Leiba's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:47:19 -0000 Barry, Thank you for the review. This is a great suggestion. We are making edit= orial updates as you can see and we will make the changes as you suggest. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, June 09, 2015 8:23 AM To: The IESG Cc: dime-chairs@ietf.org; dime@ietf.org Subject: [Dime] Barry Leiba's No Objection on draft-ietf-dime-congestion-fl= ow-attributes-01: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes= / ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think IANA gets what they need to do, but the RFC Editor will have to rep= lace four different "TBD" with four different values. It'd have been bette= r to use "TBD1", "TBD2", "TBD3", and "TBD4", to make it less likely that so= mething will go amiss. It's probably fine to just say that you need to che= ck it closely during AUTH48, to make sure that the right values got into th= e right places. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jun 15 09:51:39 2015 Return-Path: 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 2C5C21A90B8; Mon, 15 Jun 2015 09:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 8Cex4mX0TKCT; Mon, 15 Jun 2015 09:51:37 -0700 (PDT) Received: from na01-BY2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2199B1A90B6; Mon, 15 Jun 2015 09:50:56 -0700 (PDT) Received: from BN1BFFO11HUB057.protection.gbl (10.58.144.204) by BN1BFFO11SHT003.protection.gbl (10.58.144.214) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:50:47 +0000 Received: from BN1BFFO11FD055.protection.gbl (10.58.144.34) by BN1BFFO11HUB057.protection.gbl (10.58.144.204) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:50:31 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1BFFO11FD055.mail.protection.outlook.com (10.58.145.10) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 15 Jun 2015 16:50:31 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5FGn8jc034083; Mon, 15 Jun 2015 11:50:30 -0500 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsapdm1.corp.sprint.com with ESMTP id 1v0j5b4f38-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 11:50:30 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jun 2015 12:50:29 -0400 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Mon, 15 Jun 2015 11:50:29 -0500 From: "Bertz, Lyle T [CTO]" To: Alissa Cooper , The IESG Thread-Topic: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) Thread-Index: AQHQoxbu24rgZ2BJF0+ML1r3FXaM5Z2tz/QA Date: Mon, 15 Jun 2015 16:50:28 +0000 Message-ID: References: <20150609203351.18194.56243.idtracker@ietfa.amsl.com> In-Reply-To: <20150609203351.18194.56243.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD055; 1:l6PzhZ1rbCXQ3N3fJsEFGqRlAumDj9AqjK/umJB3K8bZQXGyJ8atIIPAkBr1n3LmSIpLZwJxUEkm79R2XwAKCWYU43Sb12TDNDXKaF2Ba7h+5BYq7YlNyD/Te3z9XfThJ0Z1fN06tb7Lm4PB+3Zzim8Ea7OFAO6GqOGpeRmtDUmSGoJMW7tZSOTkW/5quB0Znd2DJzw1qo6BSCfbMtt/pk1UTDqUdDDQ6m2sPK2TmiIwkwCDaB0Z6KyZQwzqOOacJ9Yj9uphZX9qYb2Pauc0mKt/N+x5O8cUN78hTPfJNLAeSa7M+Va1BblJ9JJuYcBTsoeedCi5UcI2+iDzoth//g== X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(199003)(377454003)(189002)(13464003)(52044002)(19580395003)(19580405001)(106116001)(2656002)(2900100001)(24736003)(46102003)(85326001)(6806004)(5001960100002)(33646002)(97756001)(92566002)(5001770100001)(5250100002)(230783001)(23726002)(62966003)(77156002)(47776003)(50466002)(87936001)(2950100001)(76176999)(108616004)(106466001)(46406003)(189998001)(50986999)(86362001)(54356999)(102836002)(5003600100002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB057; H:plsapdm1.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB057; 2:cjjIr37RkFu9ZHGHzOGti4eCJBuf/4yjYdeRq3piSVCXn6+6a1yqyfYNdVHAyRld; 2:BYRiUcVVf4D+c0sjkACyVCkpsaCH3L3NNPHd53ZevXnN7y/qqwZwrtrs4e0YPDXY2lhg4/ESb8iAHlDPr+IDhjC3jVarvkiXDY8gul8k0/vWIm3oAcOHqCRykmcyhGIVhLc+cPZSvgWtCvLmIuDssRUNoXOiieUp9j3GERjwRgK3L0EvtZRGWf3GGoNLSQgekzj7TpQnF+8FbBu5ykT5wDMWZt3xdvKkrjB1PNge7pujjlEfres2E6RCiGmsIKYN; 6:5ChOxbWR3CSuFl8dhMukK1+54iFUpiGyp5JXt96Jr+fzKPaU0LN+JBQS9zefziOuIrTOeXs6jVGBu96NZFRuShqF+fsm0uMOTSvj5ZQFbiij5HPnP/AOGx+oM1VxD1EUKCMT8JAnzItuFLX6vOO4qp/sBVa2E5FrkRktwt9N5J9oobpvz09pf95yRodHZgy6g6NIlyd8DpASTmngzTAVc2f7/UqabGo+RfFC+LWCKBCKR3WvnDwETaCUK9/E96FN; 3:DpgBUdnDiRMUruSc/4NGvij6pxVvmfNdxkAN8hAntRocoQqIrwbGOFg3JXtd0bjyRhd5bYzZfks21nl7wQ0k+3xZ7qkixLsoxK1pxX+psrpBmATVzLRn5Gg2bTYJWIk+dAV6lNlqwlomSDRWTW3Q/d7JyCc0x2AMOItRSKbGXOsM2iqYL4JXBJh99gARHalzkY9sV0u+uCRC/DOk2jcQP2IRiWpYBeFJKksi7k9eOZyfEct8+q0tSeacR+uzJOIaXb4+q/N+quP4164dLHBmzuNDcdMgydnkbhkht1RDHP4WCBVdLz47hCR3xCyn1BVE X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB057; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN1BFFO11HUB057; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB057; X-Forefront-PRVS: 0608DEDB67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB057; 9:+NFpfseOJ0vFSn8SUQhbkqvMw1pUF/S9vQldKSYK?= =?us-ascii?Q?/jH7th7Nz5E8lFTyzeThiS5aYr6i/4E7x7yv9HyhXNR2pBWWy8RxwqyQk1sG?= =?us-ascii?Q?Y9x+nX47GcEMdwD1qwYtaK8TgCVjEAufIBiBzLtfS6YWgjK0S6II1LFNLlFN?= =?us-ascii?Q?B9tKs5fK9OTcu6uozkQzYMoLVuCAti+39kNkuqkyTwsTefL3+s8Bdj0NPjv8?= =?us-ascii?Q?edd09IrydY0toP5TtvbzIKZdF1Y+CiPkahROaQDTOJKLzOBAgo+bM7+wrP37?= =?us-ascii?Q?tNmKK+dU4XYRRh/RWPkLnyhp3xddFfJRRnI3PeB1eDj9WMD/9GYklG6e9TEp?= =?us-ascii?Q?R77aYc5A+wfqjFFnz87tObz5UdOaDVsFDzHfz0X2Tu1zmyqsVu0P7NaQd0gF?= =?us-ascii?Q?nDYiYA/SEqOYcOZNpJmUtJtF/2Yv5ufrI4CaSSXTbTCbLBNUZ8k3CdiTtsYU?= =?us-ascii?Q?C8QETrJXGxR8H0YSKh0nwtqnO5wG9PqbBBup/n6i+6n73aPQDKwBHMhQ7/D/?= =?us-ascii?Q?fp3FBGIzf/Myh7W0c6NMPQ2e//iGkv6opwdDTCvzpaPuesOHyxviisPR34kj?= =?us-ascii?Q?ue4ENQKtFHLqaWiLut+JDW5EUBFKP2HYyY8Ogn/ME3+Zk2pkF6Kz8Ec/gw0X?= =?us-ascii?Q?qriC6SWRGMtT3+3iB861UlsCP+MgHcFyjk7BKIj02YGEQRKIeondPlNNyxDU?= =?us-ascii?Q?wE02s+KKvJ1ga/jyiTRe00Oa2iiwKLxGZRPAAyyoyWpvb4Gy/pljVI12mS6l?= =?us-ascii?Q?D60X5qIu5HBLlRQNy3xuxosClWDH9iGALxqp/T+YRGOg9ZmR3c8CBn8mx+Yp?= =?us-ascii?Q?z6iiwGhMXzhGBE9gM13osOGO+5hkY1MzpW41buod1/EcbfimBxWDugve8Xtg?= =?us-ascii?Q?rbkSdYcmKiGW1gpon3m9PiWKzcBEYn6lH1KRneAticPtcMsBjMBtvkz9p1mv?= =?us-ascii?Q?bfCSfYCCTWsOKbmgxePq/V7GKKBslO7S0zdC8F057ENXIVFySy53EtIC99A5?= =?us-ascii?Q?880I595UPOvpc9rcrbAiKqv5yGtxmqM9RUrm6wHcUBqFbXNYGcpKbRj63GKT?= =?us-ascii?Q?ZqZeaBJB0kY9uZjElTPZQr6xYOrQ?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB057; 3:RSouTCilozg0l+fnlkINGvIcPQl9Fpu10VRnRMQOa+rS/60HRWMzPKJSnXWufmMhBkKKTGa9gnQhs7z80aTCKs6dwYCT/nldiuAONJ7o9ClduH9G6m2q3jpyD0XrpGOrP17XRmA5rQm4wGxhEYqjQg==; 10:lp+cAMwHj3lKViXI+xFR40mOnQ2eqlOZu6vOM+/BPRUNhnqqNc2IxK3EJlXd/K+pP/ElNVMuj9mR7/UeFnXvKWAubAOYm4Q3LT4TmRLde+k= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2015 16:50:31.6750 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB057 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11SHT003; 9:Ou+X/XiBm1ohSDhqW0iIVCuLc/46Gy0y4jsRwe3l8F5vBdzB/FHZ7+K6Q3CdD1OPU1sBLECv966xdEhB0JMTmQqmKpbI0HjAHBOo3genlCAEWFdo0HQBh7DV2PnnuWAUmG8tX3cDBjqFbbXZYOnp0g== X-OriginatorOrg: sprint.com Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:51:39 -0000 Alissa, Thanks for your review. Our responses are below. Lyle -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Tuesday, June 09, 2015 3:34 PM To: The IESG Cc: dime-chairs@ietf.org; dime@ietf.org Subject: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-congestion-= flow-attributes-01: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes= / ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If this means folks are using ECN more then I'm glad to hear it. :) In Section 5.1 there are three instances of "ECP-IP-Codepoint." I think the= se are meant to be "ECN-IP-Codepoint" right? >>> You are correct. We will make those corrections. In Section 6, I had the same thought as Ben. There could be some sensitivit= y about the fact that a particular user experienced congestion, and that's = worth calling out. >>> Please see our response back to Ben as it includes the update Section 6= . We would definitely appreciate your comments. Comment for the WG: I note that RFC 6733 requires Diameter nodes to be able= to negotiate TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA (among = other cipher suites) for use with TLS and DTLS. Given the publication of RF= C 7465, those requirements should be revisited. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Jun 15 09:53:33 2015 Return-Path: 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 AB2AA1A90C5; Mon, 15 Jun 2015 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 vFmGTIshU8i4; Mon, 15 Jun 2015 09:53:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182431A90B6; Mon, 15 Jun 2015 09:53:26 -0700 (PDT) Received: from BN1AFFO11FD044.protection.gbl (10.58.52.31) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.1.190.9; Mon, 15 Jun 2015 16:53:01 +0000 Authentication-Results: spf=permerror (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; huawei.com; dkim=none (message not signed) header.d=none; Received-SPF: PermError (protection.outlook.com: domain of sprint.com used an invalid SPF mechanism) Received: from preapdm3.corp.sprint.com (144.230.32.82) by BN1AFFO11FD044.mail.protection.outlook.com (10.58.52.191) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Mon, 15 Jun 2015 16:53:01 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t5FG1gi8021892; Mon, 15 Jun 2015 12:53:01 -0400 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by preapdm3.corp.sprint.com with ESMTP id 1v0es25dk9-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jun 2015 12:53:01 -0400 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jun 2015 11:52:59 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c]) by PLSWE13M07.ad.sprint.com ([fe80::b8a7:9769:a6fe:384c%15]) with mapi id 15.00.1044.021; Mon, 15 Jun 2015 11:52:59 -0500 From: "Bertz, Lyle T [CTO]" To: Benoit Claise , The IESG Thread-Topic: [Dime] Benoit Claise's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) Thread-Index: AQHQo83zC+MZUtTiDkK7oH1fpnWAW52tz3eg Date: Mon, 15 Jun 2015 16:52:59 +0000 Message-ID: References: <20150610223645.2051.99673.idtracker@ietfa.amsl.com> In-Reply-To: <20150610223645.2051.99673.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD044; 1:jetZSMCosX0dCllbm5lpZFjykFjhusaLtL6EUn0ywRX3su+cILnHWZulLs/Bdr866+SpVBGNPzNzzmmyhFzlpUEqZFoMPjE/mlHzIRgOBpiH74aD4q3rcAMhk0a0BIvXPgZUwOjFqual1EU/fkA5OCNZh1I5b8DdncDuDfIEXpa2iI7E+lstpe4R3FHKzeGfR7MgQwKjwzErLe2Gn050EEHa9n3F4wwKFuMiMcLq3wzD0BZ7qtm/ryoFLrhaCFzUdGkTIOigy3XZwOMGD3QkTNHwmmbKlRizkiELDBiehRKzdcSWb6s7VFgpfch2TdxGNlc0EqqZMjZvdB5V3dAQ25sP+mHzG3lPuVlIb0bxgWA= X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(448002)(52044002)(199003)(13464003)(189002)(377454003)(106466001)(19580405001)(106116001)(62966003)(46102003)(33646002)(230783001)(50466002)(5001770100001)(5001960100002)(24736003)(189998001)(77156002)(6806004)(5003600100002)(76176999)(50986999)(5250100002)(54356999)(47776003)(46406003)(87936001)(86362001)(2950100001)(92566002)(19580395003)(108616004)(97756001)(2900100001)(2656002)(102836002)(85326001)(15975445007)(23726002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB028; H:preapdm3.corp.sprint.com; FPR:; SPF:PermError; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB028; 2:iRuaXn/AXmOVXY3LYt7o9glg9Wzv7TZCOX64Io6srgQSnsC8FStQ7djNcxPcxsMy; 2:pYu1bWsjNcF1DHdhTluga/4urT9HKc44NEBmECA4uwqa88KxFq8gO7BXbxMflani//aIG08nLoAUaSfq+qwy4F99N+Jni7AM1RKLnD/VMK3jfz/3Ly4Hq8VTRWr+o5VLRuJvNvjykcytIZ+avCCPorFEN/FclkftMOWKsE+CJnAHvF5CE8fTS+8hQ/sr3XijaZQr/2eIJKAnzzJeYRX66ElBRKPPy9B4KukNWwRRnT0=; 6:1dXUjuusOdGhuH5+hghqEejnf9RHRGafdqeAF3qhPCB9HCr6e5kGeS3403bi5tzCvxs4/zZY9PhDPRESjWqoLjWh269Obc9H4/UhfqyR2AC4uMVW8IzkxScJbj/EjPbt6XZ2ttM2FPnUldLbVTz7FXmhVqLOcP1VzvtPSq1VXNrwEyrOaOh5QstFtnM7OQflRNvkJM1VZRoggVaePLRN0tOWJNwuXNE9b0OJ/KBVEQVeo8DLIpKuBWplIDruJBpd; 3:vmL78mRQjbnL5Y5mD/dTXRCUCidLG3Lh110b07xLZTicEJAUCkC1tlyvmAjMBMu6+UMTZPCJGiaH2KjYRta0R1QArVWTRjfZoMel+RWpGrSfbuXDjBfl0D+SngJkkodkxVvA7eG9203xhgp5NwScEK/uc7zPw0lBvtbPai/4zsgAsEpc9jy7MoaVs1d6Svctb9vSXKkcqnXYumzJRMdaRT6kQqGNWPUQG9pi+BbbE6AHyUpXo3fkanOI5yc4Yc3bApNay+QGjwcnAhcQdjkzN1VSh+5RwPwwMbbv0evvg5CtAVmpi6DZ1IaD+V3BvI6K X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB028; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1AFFO11HUB028; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB028; X-Forefront-PRVS: 0608DEDB67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB028; 9:Ek1gmueGtvIdc8kWvRYx3v6HAVlfu0231Pl5NzBD?= =?us-ascii?Q?4We6q1GYOAmTKaukJvvF5B0HdRUrLWpagpEyKnPNS+bjRpo/YxEB8YDtbxfR?= =?us-ascii?Q?nLUUHuQGHEEzddn9o1ig0BLoUfu9qbtmzKVZjDNPW9vfdornsGkUcAfUy5CT?= =?us-ascii?Q?06rRMsG7q5LShShqMR21u78ZZWp6p7jpJEnoLzeauRxhXiZWay85rKyUr/Lg?= =?us-ascii?Q?bwX5ItnGjJ53JWl2Rxi96UkRszey/+TguAAGkdmYDeTjqWBkmMdUh0ACg/nc?= =?us-ascii?Q?oggva3HEwpIMkee4dLeHi98/tWHuSF6oxXgz09LnZxujd9xAqO/E7Tr0i47s?= =?us-ascii?Q?nHuLkCWqVABJ9M69Kn+nAUAkAI/iHYKCJLGosgILY2ZMrtsa6eEhgWCXZf+y?= =?us-ascii?Q?nsD1QI4i2OjB968PUNOt+DlcbiLoDNCkJJ6oORw5ylxkTmPSrqxmAOPBLyaX?= =?us-ascii?Q?jBvl9vrxH6yVG1G7I0SHLCXMzhrd016l+8uGjN+JjunNn7JvuEs4PdcO86iA?= =?us-ascii?Q?gDfv4jzjevaZv5YTS6V3DTb6hbbKFOUS4ywx+P+S6dMCId11PEYTNnFQHOw/?= =?us-ascii?Q?FKr30UvUvHreETW+vAL/HSfyeEUi42l4c3G57qlJiodm21lQK9LaAxnDt6tU?= =?us-ascii?Q?pKIp1nDNN6EfzjDUviWzDJ9PISV/UwgJSrRVLuW1sqap6pA6Rd1Wzm6hNHhv?= =?us-ascii?Q?/zI/h4qD4M+TdiXrrfl2hhS2uO33tCMiz5+k09Hk/H6oO+krJ4dND9xFuvQy?= =?us-ascii?Q?LSZ2lnbAuVYOR3twDBj1EulRw66j0VDu04bK980SX9fAtbqn3OD+kKqCn2Oc?= =?us-ascii?Q?ua/MIz4oKdb2eUbAOpislUwB5DEjCUnmW0CUp+WUiYbEnbK/gB+KOguatvmC?= =?us-ascii?Q?SHtZNmsMutZTQRIpmpcpO8rIP3u356H8+oBd26QGbD3e8hJUTXuCu226MXEn?= =?us-ascii?Q?44c47nV1qBXgRWxmMglOdTmP8db1SDX1fxOw0C2919Xzpjj14WkB0s9uPCSH?= =?us-ascii?Q?2QA0motttbbscF7v1AzjesGQuuLUFwxcnkiz3IsSqCDMNNukg/3R77fwm8E9?= =?us-ascii?Q?ofrgrGiayzrlxwrlAqD1f5RTxGD2?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB028; 3:ZZ2h4vGcXa+vu8LlhO6AMW7ckoVRIdqiDpeXbMfdul7C0XZJRbOYzlve+NYLtbNXzBf6xmyheNXO1xczxJdBVvJgLIvxui9jbgOnK3/0mspy5GvRQioDNDAfgESAyTr04Sz/xpUXLPEA6Oi4k6U/gg==; 10:63amXIBQBRM2EMLUlNJba0IsvrOBSOh1EUS42hk4FlU4j8ce2tTP815GyNTV1yQ7UXOda36AxyK6Hf2duNB77+S/X7At96W3IOK3gJe7Sgo= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2015 16:53:01.5343 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB028 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , "linda.dunbar@huawei.com" Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-congestion-flow-attributes-01: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 16:53:31 -0000 Benoit, Thank you for the review. Please see our comments back to Stephen and Mar= tin - hopefully they improve the document. Lyle -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, June 10, 2015 5:37 PM To: The IESG Cc: dime-chairs@ietf.org; dime@ietf.org; linda.dunbar@huawei.com Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-congestion-= flow-attributes-01: (with COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-dime-congestion-flow-attributes-01: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-attributes= / ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- With some DIAMETER background, I can understand what the document specifies= . However, I agree with Martin's COMMENT, and Stephen's abstract-related COMM= ENT. The document should be improved _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jun 17 18:50:42 2015 Return-Path: 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 E4D191A92B5; Wed, 17 Jun 2015 18:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Oy3c39Tf2oZz; Wed, 17 Jun 2015 18:50:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D888A1A92B3; Wed, 17 Jun 2015 18:50:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150618015034.9019.19117.idtracker@ietfa.amsl.com> Date: Wed, 17 Jun 2015 18:50:34 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 01:50:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter AVP Level Security End-to-End Security: Scenarios and Requirements Authors : Hannes Tschofenig Jouni Korhonen Glen Zorn Kervin Pillay Filename : draft-ietf-dime-e2e-sec-req-03.txt Pages : 9 Date : 2015-06-17 Abstract: This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-e2e-sec-req-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 17 18:52:01 2015 Return-Path: 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 83C6E1A92B5 for ; Wed, 17 Jun 2015 18:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 nSUyQjANPA1K for ; Wed, 17 Jun 2015 18:51:59 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84D61A9145 for ; Wed, 17 Jun 2015 18:51:58 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so3241163pab.1 for ; Wed, 17 Jun 2015 18:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ws30NE9POpzw60lHBPUQB1FMD/VSt2m23j7ysFoDNlE=; b=wsVksiIUXsk+we1orzWwx42J+bxtL3F8JDyW+lMlQcixHjMqSV3uJLYI92g276sWID 4z6CEG3WlkncObLLXLc9J6LO2tbd1tlTJBBzSqrmvDJDUfSCBK+7ImKHS/irtbZqGFxy wYVtK0gs1/b6smwPZx9wFn3oxuBWLFY1qHFr/HXHip7E+k+WSKh+KjcW/dIaJc+MH3t6 HX9Pr54m6fmg4VytJh+Al7cqR+iNymt93hQorGVkm5S1YGdZL/OypbMdRhKXawTfpk20 T1L3nCB0oduAfLRbRm+sSMqsgzeIbjc6lQ+oNZVOCn+1TiI9ZLn3QpoMV30yz/PT31Ht df9Q== X-Received: by 10.70.102.226 with SMTP id fr2mr16717640pdb.26.1434592318499; Wed, 17 Jun 2015 18:51:58 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:60f8:4917:294b:b8e1? ([2601:647:4204:228b:60f8:4917:294b:b8e1]) by mx.google.com with ESMTPSA id fk5sm1366743pab.40.2015.06.17.18.51.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 18:51:57 -0700 (PDT) Message-ID: <5582243D.7050602@gmail.com> Date: Wed, 17 Jun 2015 18:51:57 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20150618015035.9019.47192.idtracker@ietfa.amsl.com> In-Reply-To: <20150618015035.9019.47192.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150618015035.9019.47192.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] Fwd: New Version Notification for draft-ietf-dime-e2e-sec-req-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 01:52:00 -0000 FYI This should address comments from Steve and Tom. - Jouni -------- Välitetty viesti / Fwd.Msg -------- Aihe: New Version Notification for draft-ietf-dime-e2e-sec-req-03.txt Päiväys: Wed, 17 Jun 2015 18:50:35 -0700 Lähettäjä: internet-drafts@ietf.org Vastaanottaja: Jouni Korhonen , Kervin Pillay , Jouni Korhonen , Hannes Tschofenig , Kervin Pillay , Glen Zorn , Hannes Tschofenig , Glen Zorn A new version of I-D, draft-ietf-dime-e2e-sec-req-03.txt has been successfully submitted by Jouni Korhonen and posted to the IETF repository. Name: draft-ietf-dime-e2e-sec-req Revision: 03 Title: Diameter AVP Level Security End-to-End Security: Scenarios and Requirements Document date: 2015-06-17 Group: dime Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-dime-e2e-sec-req-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ Htmlized: https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-e2e-sec-req-03 Abstract: This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Jun 20 09:52:15 2015 Return-Path: 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 6184B1A8939 for ; Sat, 20 Jun 2015 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 6N6wexIS2zEz for ; Sat, 20 Jun 2015 09:52:11 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7121A8938 for ; Sat, 20 Jun 2015 09:52:10 -0700 (PDT) Received: by pdjn11 with SMTP id n11so110773761pdj.0 for ; Sat, 20 Jun 2015 09:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=LeQ7yqZQsOkubsT+qFiSDsn5OOxcTwA7ku28HMUGqVc=; b=V61kKD6k6WBIKZ8TZo06nyjqroVvV/XecWUHxOBvaB8F/hnDWy5J7VWCiwq4Lr85wE o5fX/8cG/Y3EKlv0IZh4iSLpTQ20NmyKTMbEOyk40PHOaFvnMHHT9BG41XiQPhxsIetS bTsNSlq2nfgaAyWKkk8XHnvsIg5yaS5Dsw6OjmTKk71lWGl5zDnWfQbFmnwGHEP14OhQ T5tbRXvkOYE30IhdFG9GeYFbfwZMNcj9trsJYKpzqc9SM7dZVAPaHdktCOxf2tERiBP6 vaL++Pd/f5YVYOaLpQvaCcmQVwHORlL4tJv0Ta+M6vHCpzDASXthZK0CnX4qaU25YYe6 htCA== X-Received: by 10.68.69.37 with SMTP id b5mr43424886pbu.35.1434819130370; Sat, 20 Jun 2015 09:52:10 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:b9df:d575:3551:c562? ([2601:647:4204:228b:b9df:d575:3551:c562]) by mx.google.com with ESMTPSA id ks7sm14702881pbc.34.2015.06.20.09.52.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 09:52:09 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6061EDCC-F998-435B-9C22-A55751E5CAE5@gmail.com> Date: Sat, 20 Jun 2015 09:52:07 -0700 To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Dime] Draft agenda has been posted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 16:52:12 -0000 Folks, The draft agenda is out, see: http://tools.ietf.org/agenda/93/ Dime is scheduled at Wednesday afternoon session 1 and we got full 2.5h = time to spend. - Jouni & Lionel From nobody Mon Jun 22 02:09:05 2015 Return-Path: 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 7C31F1B2E7B; Mon, 22 Jun 2015 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 APUG_ihMOtOz; Mon, 22 Jun 2015 02:08:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1531B2E76; Mon, 22 Jun 2015 02:08:51 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5E376190A6E; Mon, 22 Jun 2015 11:08:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.10]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 33CCF18004F; Mon, 22 Jun 2015 11:08:49 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0235.001; Mon, 22 Jun 2015 11:08:49 +0200 From: To: "Black, David" , Martin Stiemerling , The IESG Thread-Topic: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) Thread-Index: AdClJQY74X8SI5Wk1EqRdOJjKpM6WAAAdEjgAADuNQAAAFO+AAABLGkAAeZwsQA= Date: Mon, 22 Jun 2015 09:08:48 +0000 Message-ID: <3784_1434964129_5587D0A1_3784_11741_1_6B7134B31289DC4FAF731D844122B36E01C59A80@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: , <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> <565c7289e23441ff93f3fd8328bb1107@PLSWE13M07.ad.sprint.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01C59A80OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.22.83617 Archived-At: Cc: "dime-chairs@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 09:09:01 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01C59A80OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Martin, do you please confirm that the proposed correction answers your con= cerns identified in the DISCUSS? I'm waiting for a go-ahead before authoriz= ing authors to submit a new version of the draft. Regards, Lionel De : Black, David [mailto:david.black@emc.com] Envoy=E9 : vendredi 12 juin 2015 20:55 =C0 : Bertz, Lyle T [CTO]; MORAND Lionel IMT/OLN; Martin Stiemerling; The I= ESG Cc : dime@ietf.org; dime-chairs@ietf.org; Black, David Objet : RE: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-con= gestion-flow-attributes-01: (with DISCUSS and COMMENT) With that extra "packet" dropped ;-), the proposed text looks good enough for my concern. I'll leave any further adjustment to Martin, as he's holdi= ng the Discuss. Many thanks for the prompt attention to this, and (as noted earlier), I'm pleased that this was not an actual design problem. Thanks, --David From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Friday, June 12, 2015 2:22 PM To: lionel.morand@orange.com; Black, David= ; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org Subject: RE: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-co= ngestion-flow-attributes-01: (with DISCUSS and COMMENT) ... Even my corrections have errors this week. From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, June 12, 2015 1:12 PM To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-conges= tion-flow-attributes-01: (with DISCUSS and COMMENT) Except that a "packets packet" is maybe too explicit! :) (Second sentence) Please wait for a formal go-ahead from the AD or myself before submitting a= new version. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "Bertz, Lyle T [CTO]" > Pour : "Black, David" >, "M= artin Stiemerling" >, "The IE= SG" > Cc : "dime@ietf.org" >, "dime-chairs@ietf.org" > Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT) Date : ven., juin 12, 2015 19:32 David, Thanks for the guidance here. We definitely want to meet the goals you not= e below. I will assume Martin has no objection to "IP (5-tuple) flows". If so, we c= an adjust the language. New language (I also changed 'In case the" to "If the" at the beginning of = the next paragraph. > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic IP (5-tuple) flow(s) when congestion = is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > A Filter-Rule may contain a Classifier that describes one or many 5-t= uples per > > RFC 5777. This treatment applies to all packets associated to all 5-= tuples (flows) > > captured by the Filter-Rule. > > > > If the Congestion-Treatment AVP is absent... I believe this language meets the objectives outlined below. Thank you. Lyle -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Friday, June 12, 2015 10:33 AM To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT) Lyle, Thanks for the explanation - for my concern, I think we're close to done... > Traffic flow(s) are IP (5-tuple) flow(s). That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem. > My question to you is would it be best to say "IP flows" or "IP > (5-tuple) flows" or "5-tuple flows"? I like "IP (5-tuple) flows" - Martin? > I am unsure of the best wording here. This treatment applies to all > packets associated to all 5-tuples (flows) captured by the > Filter-Rule. Please add that latter sentence ("This treatment applies ...") to the draft= ... > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. ... and please add that sentence also ;-). The goal is to be clear that: - adding an ECN-IP-Codepoint AVP to a Classifier still results in the Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple flows that contain a specific value or values in the ECN field); and - hence, the Congestion-Treatment AVP applies to 5-tuples and not to anything smaller. Thanks, --David > -----Original Message----- > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > Sent: Thursday, June 11, 2015 8:59 PM > To: Black, David; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > David, > > Traffic flow(s) are IP (5-tuple) flow(s). > > My question to you is would it be best to say "IP flows" or "IP (5-tuple) > flows" or "5-tuple flows"? I am unsure of the best wording here. This > treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule. > > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per RFC 5777. > > Thanks. > Lyle > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, June 11, 2015 5:15 PM > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > Lyle, > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > What does "traffic flow(s)" mean in this text? > > A clear explanation of that should remove the concern that this draft > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more). > > Thanks, > --David > > > -----Original Message----- > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > > Sent: Thursday, June 11, 2015 6:02 PM > > To: Martin Stiemerling; The IESG > > Cc: Black, David; dime@ietf.org; dime-chairs@ietf= .org > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin, > > > > Regarding the DISCUSS point the language in 3.2 is problematic, we > > will change > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > to > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > indicates how to treat traffic flow(s) when congestion is detected. > > The detection of the congestion can be based on the reception of IP > > packets packet with the CE (Congestion Experienced) codepoint set > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > The rationale for the word 'flow(s)' in the new language is the last > > sentence of the section 3.2 - "The Congestion-Treatment AVP is an > > action and MUST be an attribute of the Filter-Rule Grouped AVP as > > defined in RFC5777. " It is other AVPs in the Filter-Rule, e.g. > > Classifier, that describes the scope of traffic impacted. Saying > > something in Section 3.2 that does not associate the > > Congestion-Treatment AVP to the Filter-Rule it is a part of only > > creates > confusion. > > > > --------------------------------- > > Per the COMMENT, you are correct. We'll change > > > > "The first AVP provides direct support for ECN [RFC3168] in the IP > > header" > > > > to your suggestion > > > > "The first AVP provides direct support for filtering ECN > > marked traffic[RFC3168]" > > > > -----Original Message----- > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Martin > > Stiemerling > > Sent: Wednesday, June 10, 2015 3:36 PM > > To: The IESG > > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org > > Subject: [Dime] Martin Stiemerling's Discuss on > > draft-ietf-dime-congestion- > > flow-attributes-01: (with DISCUSS and COMMENT) > > > > Martin Stiemerling has entered the following ballot position for > > draft-ietf-dime-congestion-flow-attributes-01: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri > > butes/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > No general objection to the publication of the document. However, I > > am relaying a question from David Black as a DISCUSS point. > > > > I assume that the draft is more than unclear in Section 3.2 about > > what traffic means. Is it a particular flow, a single packet, etc? > > > > "I found an ECN concern, and hence added the TSV ADs to the CC line. > > > > Section 3.2 says: > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > indicates how congested traffic, i.e., traffic that has Explicit > > Congestion Notification Congestion Experienced marking set or some > > other administratively defined criteria, is treated. > > > > That appears to say that the congestion treatment may be applied > > solely to packets that have the CE (Congestion Experienced) marking. > > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP to > > react as if a packet has been dropped), hence the congestion > > treatment ought to apply to the entire flow. > > > > In other words, one wants to be able to use the ECN-IP-Codepoint AVP > > as part of the condition that determines whether the filter rule > > matches, but ignore that AVP (i.e., wildcard it) in determining what > > traffic the action applies to, so that the response to detecting a > > congested flow (i.e., packets with ECN field containing CE) applies > > to all packets in the flow, regardless of the value in the CE field. > > > > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked. > > > > Am I reading the draft correctly?" > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Section 1, 1st paragraph: > > It says "The first AVP provides direct support for ECN [RFC3168] in > > the IP header". I am sure that your draft is ot providing any > > support for ECN in the IP header, as we have ECN in the IP header > > already, > isn't it. > > I guess you mean something like this "The first AVP provides direct > > support for filtering ECN marked traffic[RFC3168]" > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information intended for > > the sole use of the recipient(s). Any use by others is prohibited. > > If you are not the intended recipient, please contact the sender and > > delete all copies of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If > you are not the intended recipient, please contact the sender and > delete all copies of the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E01C59A80OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Martin, do= you please confirm that the proposed correction answers your concerns iden= tified in the DISCUSS? I'm waiting for a go-ahead before authorizing authors to submit a new version of the draft.

 = ;

Regards,

 = ;

Lionel

 = ;

De : Blac= k, David [mailto:david.black@emc.com]
Envoy=E9 : vendredi 12 juin 2015 20:55
=C0 : Bertz, Lyle T [CTO]; MORAND Lionel IMT/OLN; Martin Stieme= rling; The IESG
Cc : dime@ietf.org; dime-chairs@ietf.org; Black, David
Objet : RE: Re : [Dime] Martin Stiemerling's Discuss on draft-i= etf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

With that extra “packet&#= 8221; dropped ;-), the proposed text looks good enough

for my concern.  I’l= l leave any further adjustment to Martin, as he’s holding<= /span>

the Discuss.<= /p>

 

Many thanks for the prompt atte= ntion to this, and (as noted earlier), I’m

pleased that this was not an ac= tual design problem.

 

Thanks,
--David

 

From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Friday, June 12, 2015 2:22 PM
To: lionel.morand@orange= .com; Black, David; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org
Subject: RE: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-= dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

<sigh&g= t;… Even my corrections have errors this week. 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, June 12, 2015 1:12 PM
To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG<= br> Cc: dime@ietf.org; dime-chairs@ietf.org
Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime= -congestion-flow-attributes-01: (with DISCUSS and COMMENT)

 

Except that a "packets packet" = is maybe too explicit! :)

 

(Second sentence)

Please wait for a formal go-ahead from th= e AD or myself before submitting a new version.

 

Regards,

 

Lionel 

 

Envoy=E9 depuis mon mobile Orange

 

----- Reply message -----
De : "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Pour : "Black, David" <david.black@emc.com>, "Martin Stiemerling" <mls.ietf@gmail.com>, "The IESG&= quot; <iesg@ietf.org>
Cc : "dime@ietf.org" <dime@ietf.org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>
Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-f= low-attributes-01: (with DISCUSS and COMMENT)
Date : ven., juin 12, 2015 19:32

 

Davi= d,

Thanks for the guidance here.  We definitely want to meet the goals yo= u note below.

I will assume Martin has no objection to "IP (5-tuple) flows".&nb= sp; If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" at th= e beginning of the next paragraph.

> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic IP (5-tuple) flo= w(s) when congestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> >   A Filter-Rule may contain a Classifier that describes= one or many 5-tuples per
> >   RFC 5777.  This treatment applies to all packets= associated to all 5-tuples (flows) > >   captured by the F= ilter-Rule.
> >
> >   If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.bla= ck@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congest= ion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to done...=

> Traffic flow(s) are IP (5-tuple) flow(s).

That's a relief - I'm glad that we're only dealing with editorial concerns = in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or = "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

> I am unsure of the best wording here.  This treatment applies to = all
> packets associated to all 5-tuples (flows) captured by the
> Filter-Rule.

Please add that latter sentence ("This treatment applies ...") to= the draft ...

> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [= mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> David,
>
> Traffic flow(s) are IP (5-tuple) flow(s).
>
> My question to you is would it be best to say "IP flows" or = "IP (5-tuple)
> flows" or "5-tuple flows"?   I am unsure of t= he best wording here.  This
> treatment applies to all packets associated to all 5-tuples (flows)
> captured by the Filter-Rule.
>
> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.
>
> Thanks.
> Lyle
>
> -----Original Message-----
> From: Black, David [mailto:davi= d.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
>
> What does "traffic flow(s)" mean in this text?
>
> A clear explanation of that should remove the concern that this draft<= br> > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more).
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org<= /a>; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-di= me-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, w= e
> > will change
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > to
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >    indicates how to treat traffic flow(s) when con= gestion is detected.
> >    The detection of the congestion can be based on= the reception of IP
> >    packets packet  with  the CE (Congest= ion Experienced) codepoint set
> >   (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> > The rationale for the word 'flow(s)' in the new language is the l= ast
> > sentence of the section  3.2 -  "The Congestion-Tr= eatment AVP is an
> > action and MUST be an attribute of the Filter-Rule Grouped AVP as=
> > defined in RFC5777. "  It is other AVPs in the Filter-R= ule, e.g.
> > Classifier, that describes the scope of traffic impacted.  S= aying
> > something in Section 3.2 that does not associate the
> > Congestion-Treatment AVP to the Filter-Rule it is a part of only<= br> > > creates
> confusion.
> >
> > ---------------------------------
> > Per the COMMENT, you are correct.  We'll change
> >
> > "The first AVP provides direct support for ECN [RFC3168] in = the IP
> >   header“
> >
> > to your suggestion
> >
> > "The first AVP provides direct support for filtering ECN
> >   marked traffic[RFC3168]“
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-= bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf= .org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin Stiemerling has entered the following ballot position for<= br> > > draft-ietf-dime-congestion-flow-attributes-01: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att
> > ri
> > butes/
> >
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > No general objection to the publication of the document. However,= I
> > am relaying a question from David Black as a DISCUSS point.
> >
> > I assume that the draft is more than unclear in Section 3.2 = about
> > what traffic means. Is it a particular flow, a single packet, etc= ?
> >
> > "I found an ECN concern, and hence added the TSV ADs to the = CC line.
> >
> > Section 3.2 says:
> >
> >    The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >    indicates how congested traffic, i.e., traffic = that has Explicit
> >    Congestion Notification Congestion Experienced = marking set or some
> >    other administratively defined criteria, is tre= ated.
> >
> > That appears to say that the congestion treatment may be applied<= br> > > solely to packets that have the CE (Congestion Experienced) marki= ng.
> > That would be a problem, because the defined semantics of a CE
> > marking is that it applies to the entire flow (e.g., causes TCP t= o
> > react as if a packet has been dropped), hence the congestion
> > treatment ought to apply to the entire flow.
> >
> > In other words, one wants to be able to use the ECN-IP-Codepoint = AVP
> > as part of the condition that determines whether the filter rule<= br> > > matches, but ignore that AVP (i.e., wildcard it) in determining w= hat
> > traffic the action applies to, so that the response to detecting = a
> > congested flow (i.e., packets with ECN field containing CE) appli= es
> > to all packets in the flow, regardless of the value in the CE fie= ld.
> >
> > Otherwise, the result may be ineffective, as it won't encompass > > packets in the congested flow that aren't CE-marked.
> >
> > Am I reading the draft correctly?"
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 1, 1st paragraph:
> > It says "The first AVP provides direct support for ECN [RFC3= 168] in
> > the IP header“. I am  sure that your draft is  ot= providing any
> > support for ECN in the IP header, as we have ECN in the IP header=
> > already,
> isn't it.
> > I guess you mean something like this "The first AVP provides= direct
> > support for filtering ECN marked traffic[RFC3168]“
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://ww= w.ietf.org/mailman/listinfo/dime
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended f= or
> > the sole use of the recipient(s). Any use by others is prohibited= .
> > If you are not the intended recipient, please contact the sender = and
> > delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for
> the sole use of the recipient(s). Any use by others is prohibited. If<= br> > you are not the intended recipient, please contact the sender and
> delete all copies of the message.

________________________________

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=

Thank you.

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E01C59A80OPEXCLILM43corp_-- From nobody Wed Jun 24 00:00:16 2015 Return-Path: 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 77C3C1B2C51; Wed, 24 Jun 2015 00:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kLXKMkQz5M-R; Wed, 24 Jun 2015 00:00:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 374EC1B2B59; Wed, 24 Jun 2015 00:00:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150624070011.28898.29580.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 00:00:11 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 07:00:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Authors : Cathy Zhou Tom Taylor Qiong Sun Mohamed Boucadair Filename : draft-ietf-dime-4over6-provisioning-03.txt Pages : 21 Date : 2015-06-23 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-4over6-provisioning-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 24 02:23:31 2015 Return-Path: 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 286231B32A7 for ; Wed, 24 Jun 2015 02:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QpZJmy5Eq3XB for ; Wed, 24 Jun 2015 02:23:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A981B29A6 for ; Wed, 24 Jun 2015 02:23:27 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 229BF37489D for ; Wed, 24 Jun 2015 11:23:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0763138404A for ; Wed, 24 Jun 2015 11:23:26 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0235.001; Wed, 24 Jun 2015 11:23:26 +0200 From: To: "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-03.txt Thread-Index: AQHQrkuBJJ8Tel5IgEWRegWRc5LHbJ27YN8A Date: Wed, 24 Jun 2015 09:23:24 +0000 Message-ID: <21636_1435137806_558A770E_21636_7946_1_6B7134B31289DC4FAF731D844122B36E01C5C645@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150624070011.28898.29580.idtracker@ietfa.amsl.com> In-Reply-To: <20150624070011.28898.29580.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.24.84517 Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 09:23:30 -0000 This new version of the draft captures minor corrections and clarifications= resulting from the comments received by the authors during the final revie= w done by the doc shepherd for the proto-writeup. No substantial changes and therefore no need for a new WGLC on this documen= t. please check: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-4over6-pr= ovisioning-03 Next step: proto-writeup and IESG submission. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9=A0: mercredi 24 juin 2015 09:00 =C0=A0: i-d-announce@ietf.org Cc=A0: dime@ietf.org Objet=A0: [Dime] I-D Action: draft-ietf-dime-4over6-provisioning-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Attribute-Value Pairs For Provisioning Customer E= quipment Supporting IPv4-Over-IPv6 Transitional Solutions Authors : Cathy Zhou Tom Taylor Qiong Sun Mohamed Boucadair Filename : draft-ietf-dime-4over6-provisioning-03.txt Pages : 21 Date : 2015-06-23 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) attribute-value pairs to be used for that purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-4over6-provisioning/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-4over6-provisioning-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-4over6-provisioning-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. From nobody Tue Jun 30 08:05:41 2015 Return-Path: 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 4118C1A92FC; Tue, 30 Jun 2015 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no 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 Eq09LXBiIzkk; Tue, 30 Jun 2015 08:05:30 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E04C1AC3D5; Tue, 30 Jun 2015 08:05:30 -0700 (PDT) Received: by wgjx7 with SMTP id x7so12350645wgj.2; Tue, 30 Jun 2015 08:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=neefbZzn9/yXjU3Aad7tTMbNDHf+exy42n0d8bCT2hE=; b=wBELSpFLmgfxkHpyj3BD6vHykE1FH2X/gNaGWutDq4LZ/aPi8kffh81BB9Afeu3MSY n8L54HtAeRF5czoM8eM6WJh1MYf5LJfL6N/SMZq6Dr9/JwSXbB+7lLURrFfgnfUeoE/t Cd2ghuqKlIBvAxLVqdQAUAl4MJ4yhxBeFHjmz3VnGEkkIMXTPR2wQQ4LrfLb2XX9MbhF WTdoJ+LlKZNS2Q9dw6ysBNCbz1u+yZdeiOrt9LxhLoXPalbOx9BGl2iyHD2F2+CyFU6P r+GYBYaoQEm34rUOIleFAkCj4Lfz/0lzO/ZVylVRvEPZjW0SV1NNb+IeSgy4ii9GG9Qs RZUA== MIME-Version: 1.0 X-Received: by 10.194.75.132 with SMTP id c4mr37521847wjw.80.1435676728757; Tue, 30 Jun 2015 08:05:28 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Tue, 30 Jun 2015 08:05:28 -0700 (PDT) In-Reply-To: <3784_1434964129_5587D0A1_3784_11741_1_6B7134B31289DC4FAF731D844122B36E01C59A80@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <0601083147b8451ab4c131e6ec105ae1@PLSWE13M07.ad.sprint.com> <15232_1434132743_557B2107_15232_4160_1_6B7134B31289DC4FAF731D844122B36E01C4EABF@OPEXCLILM43.corporate.adroot.infra.ftgroup> <565c7289e23441ff93f3fd8328bb1107@PLSWE13M07.ad.sprint.com> <3784_1434964129_5587D0A1_3784_11741_1_6B7134B31289DC4FAF731D844122B36E01C59A80@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 30 Jun 2015 11:05:28 -0400 Message-ID: From: Kathleen Moriarty To: "" Content-Type: multipart/alternative; boundary=047d7bb04b7c6e115d0519bd8945 Archived-At: Cc: "Black, David" , Martin Stiemerling , "dime-chairs@ietf.org" , "dime@ietf.org" , The IESG Subject: Re: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 15:05:36 -0000 --047d7bb04b7c6e115d0519bd8945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, Could you please verify that your concerns have been addressed? I believe they have been. Thank you! Kathleen On Mon, Jun 22, 2015 at 5:08 AM, wrote: > Hi, > > > > Martin, do you please confirm that the proposed correction answers your > concerns identified in the DISCUSS? I'm waiting for a go-ahead before > authorizing authors to submit a new version of the draft. > > > > Regards, > > > > Lionel > > > > *De :* Black, David [mailto:david.black@emc.com] > *Envoy=C3=A9 :* vendredi 12 juin 2015 20:55 > *=C3=80 :* Bertz, Lyle T [CTO]; MORAND Lionel IMT/OLN; Martin Stiemerling= ; The > IESG > *Cc :* dime@ietf.org; dime-chairs@ietf.org; Black, David > *Objet :* RE: Re : [Dime] Martin Stiemerling's Discuss on > draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > With that extra =E2=80=9Cpacket=E2=80=9D dropped ;-), the proposed text l= ooks good enough > > for my concern. I=E2=80=99ll leave any further adjustment to Martin, as = he=E2=80=99s > holding > > the Discuss. > > > > Many thanks for the prompt attention to this, and (as noted earlier), I= =E2=80=99m > > pleased that this was not an actual design problem. > > > > Thanks, > --David > > > > *From:* Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com > ] > *Sent:* Friday, June 12, 2015 2:22 PM > *To:* lionel.morand@orange.com; Black, David; Martin Stiemerling; The IES= G > *Cc:* dime@ietf.org; dime-chairs@ietf.org > *Subject:* RE: Re : [Dime] Martin Stiemerling's Discuss on > draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > =E2=80=A6 Even my corrections have errors this week. > > *From:* lionel.morand@orange.com [mailto:lionel.morand@orange.com > ] > *Sent:* Friday, June 12, 2015 1:12 PM > *To:* Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG > *Cc:* dime@ietf.org; dime-chairs@ietf.org > *Subject:* Re : [Dime] Martin Stiemerling's Discuss on > draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Except that a "packets packet" is maybe too explicit! :) > > > > (Second sentence) > > Please wait for a formal go-ahead from the AD or myself before submitting > a new version. > > > > Regards, > > > > Lionel > > > > Envoy=C3=A9 depuis mon mobile Orange > > > > ----- Reply message ----- > De : "Bertz, Lyle T [CTO]" > Pour : "Black, David" , "Martin Stiemerling" < > mls.ietf@gmail.com>, "The IESG" > Cc : "dime@ietf.org" , "dime-chairs@ietf.org" < > dime-chairs@ietf.org> > Objet : [Dime] Martin Stiemerling's Discuss on > draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) > Date : ven., juin 12, 2015 19:32 > > > > David, > > Thanks for the guidance here. We definitely want to meet the goals you > note below. > > I will assume Martin has no objection to "IP (5-tuple) flows". If so, we > can adjust the language. > > New language (I also changed 'In case the" to "If the" at the beginning o= f > the next paragraph. > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > > indicates how to treat traffic IP (5-tuple) flow(s) when congestio= n > is detected. > > > The detection of the congestion can be based on the reception of I= P > > > packets packet with the CE (Congestion Experienced) codepoint se= t > > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > > > A Filter-Rule may contain a Classifier that describes one or many > 5-tuples per > > > RFC 5777. This treatment applies to all packets associated to all > 5-tuples (flows) > > captured by the Filter-Rule. > > > > > > If the Congestion-Treatment AVP is absent... > > I believe this language meets the objectives outlined below. > > Thank you. > Lyle > > -----Original Message----- > From: Black, David [mailto:david.black@emc.com ] > Sent: Friday, June 12, 2015 10:33 AM > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > Subject: RE: [Dime] Martin Stiemerling's Discuss on > draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > Lyle, > > Thanks for the explanation - for my concern, I think we're close to done.= .. > > > Traffic flow(s) are IP (5-tuple) flow(s). > > That's a relief - I'm glad that we're only dealing with editorial concern= s > in the draft, and not an actual design problem. > > > My question to you is would it be best to say "IP flows" or "IP > > (5-tuple) flows" or "5-tuple flows"? > > I like "IP (5-tuple) flows" - Martin? > > > I am unsure of the best wording here. This treatment applies to all > > packets associated to all 5-tuples (flows) captured by the > > Filter-Rule. > > Please add that latter sentence ("This treatment applies ...") to the > draft ... > > > A Filter-Rule may contain a Classifier that describes one or many > > 5-tuples per RFC 5777. > > ... and please add that sentence also ;-). > > The goal is to be clear that: > - adding an ECN-IP-Codepoint AVP to a Classifier still results in the > Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple > flows that contain a specific value or values in the ECN field); and > - hence, the Congestion-Treatment AVP applies to 5-tuples and not to > anything smaller. > > Thanks, > --David > > > -----Original Message----- > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com > ] > > Sent: Thursday, June 11, 2015 8:59 PM > > To: Black, David; Martin Stiemerling; The IESG > > Cc: dime@ietf.org; dime-chairs@ietf.org > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > David, > > > > Traffic flow(s) are IP (5-tuple) flow(s). > > > > My question to you is would it be best to say "IP flows" or "IP (5-tupl= e) > > flows" or "5-tuple flows"? I am unsure of the best wording here. Thi= s > > treatment applies to all packets associated to all 5-tuples (flows) > > captured by the Filter-Rule. > > > > A Filter-Rule may contain a Classifier that describes one or many > > 5-tuples per RFC 5777. > > > > Thanks. > > Lyle > > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com ] > > Sent: Thursday, June 11, 2015 5:15 PM > > To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG > > Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > Lyle, > > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > > indicates how to treat traffic flow(s) when congestion is detected= . > > > The detection of the congestion can be based on the reception of I= P > > > packets packet with the CE (Congestion Experienced) codepoint se= t > > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > What does "traffic flow(s)" mean in this text? > > > > A clear explanation of that should remove the concern that this draft > > might be applying congestion treatment to just the CE-marked packets > > and not the entire 5-tuple (or more). > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com > ] > > > Sent: Thursday, June 11, 2015 6:02 PM > > > To: Martin Stiemerling; The IESG > > > Cc: Black, David; dime@ietf.org; dime-chairs@ietf.org > > > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime- > > > congestion-flow-attributes-01: (with DISCUSS and COMMENT) > > > > > > Martin, > > > > > > Regarding the DISCUSS point the language in 3.2 is problematic, we > > > will change > > > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > > indicates how congested traffic, i.e., traffic that has Explicit > > > Congestion Notification Congestion Experienced marking set or some > > > other administratively defined criteria, is treated. > > > > > > to > > > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped. It > > > indicates how to treat traffic flow(s) when congestion is detected= . > > > The detection of the congestion can be based on the reception of I= P > > > packets packet with the CE (Congestion Experienced) codepoint se= t > > > (see [RFC 3168]) or by any other administratively defined criteria. > > > > > > The rationale for the word 'flow(s)' in the new language is the last > > > sentence of the section 3.2 - "The Congestion-Treatment AVP is an > > > action and MUST be an attribute of the Filter-Rule Grouped AVP as > > > defined in RFC5777. " It is other AVPs in the Filter-Rule, e.g. > > > Classifier, that describes the scope of traffic impacted. Saying > > > something in Section 3.2 that does not associate the > > > Congestion-Treatment AVP to the Filter-Rule it is a part of only > > > creates > > confusion. > > > > > > --------------------------------- > > > Per the COMMENT, you are correct. We'll change > > > > > > "The first AVP provides direct support for ECN [RFC3168] in the IP > > > header=E2=80=9C > > > > > > to your suggestion > > > > > > "The first AVP provides direct support for filtering ECN > > > marked traffic[RFC3168]=E2=80=9C > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org ] On > Behalf Of Martin > > > Stiemerling > > > Sent: Wednesday, June 10, 2015 3:36 PM > > > To: The IESG > > > Cc: david.black@emc.com; dime@ietf.org; dime-chairs@ietf.org > > > Subject: [Dime] Martin Stiemerling's Discuss on > > > draft-ietf-dime-congestion- > > > flow-attributes-01: (with DISCUSS and COMMENT) > > > > > > Martin Stiemerling has entered the following ballot position for > > > draft-ietf-dime-congestion-flow-attributes-01: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > > ri > > > butes/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > No general objection to the publication of the document. However, I > > > am relaying a question from David Black as a DISCUSS point. > > > > > > I assume that the draft is more than unclear in Section 3.2 about > > > what traffic means. Is it a particular flow, a single packet, etc? > > > > > > "I found an ECN concern, and hence added the TSV ADs to the CC line. > > > > > > Section 3.2 says: > > > > > > The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and > > > indicates how congested traffic, i.e., traffic that has Explicit > > > Congestion Notification Congestion Experienced marking set or some > > > other administratively defined criteria, is treated. > > > > > > That appears to say that the congestion treatment may be applied > > > solely to packets that have the CE (Congestion Experienced) marking. > > > That would be a problem, because the defined semantics of a CE > > > marking is that it applies to the entire flow (e.g., causes TCP to > > > react as if a packet has been dropped), hence the congestion > > > treatment ought to apply to the entire flow. > > > > > > In other words, one wants to be able to use the ECN-IP-Codepoint AVP > > > as part of the condition that determines whether the filter rule > > > matches, but ignore that AVP (i.e., wildcard it) in determining what > > > traffic the action applies to, so that the response to detecting a > > > congested flow (i.e., packets with ECN field containing CE) applies > > > to all packets in the flow, regardless of the value in the CE field. > > > > > > Otherwise, the result may be ineffective, as it won't encompass > > > packets in the congested flow that aren't CE-marked. > > > > > > Am I reading the draft correctly?" > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Section 1, 1st paragraph: > > > It says "The first AVP provides direct support for ECN [RFC3168] in > > > the IP header=E2=80=9C. I am sure that your draft is ot providing a= ny > > > support for ECN in the IP header, as we have ECN in the IP header > > > already, > > isn't it. > > > I guess you mean something like this "The first AVP provides direct > > > support for filtering ECN marked traffic[RFC3168]=E2=80=9C > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > ________________________________ > > > > > > This e-mail may contain Sprint proprietary information intended for > > > the sole use of the recipient(s). Any use by others is prohibited. > > > If you are not the intended recipient, please contact the sender and > > > delete all copies of the message. > > > > ________________________________ > > > > This e-mail may contain Sprint proprietary information intended for > > the sole use of the recipient(s). Any use by others is prohibited. If > > you are not the intended recipient, please contact the sender and > > delete all copies of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copi= es > of the message. > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > ------------------------------ > > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copi= es > of the message. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Best regards, Kathleen --047d7bb04b7c6e115d0519bd8945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

Could you please verify that yo= ur concerns have been addressed?=C2=A0 I believe they have been.
=
Thank you!
Kathleen

On Mon, Jun 22, 2015 at 5:08 AM, <lionel.morand@orange.com> wrote:

Hi,<= /p>

=C2=A0

Martin, do= you please confirm that the proposed correction answers your concerns iden= tified in the DISCUSS? I'm waiting for a go-ahead before authorizing authors to submit a new version of the draft.

=C2= =A0

Regards,

=C2= =A0

Lionel<= /u>

=C2= =A0

De=C2=A0: Blac= k, David [mailto:d= avid.black@emc.com]
Envoy=C3=A9=C2=A0: vendredi 12 juin 2015 20:55
=C3=80=C2=A0: Bertz, Lyle T [CTO]; MORAND Lionel IMT/OLN; Martin Sti= emerling; The IESG
Cc=C2=A0: dime@ie= tf.org; dime-= chairs@ietf.org; Black, David
Objet=C2=A0: RE: Re : [Dime] Martin Stiemerling's Discuss= on draft-ietf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMEN= T)

=C2=A0

With that extra =E2=80=9Cpacket= =E2=80=9D dropped ;-), the proposed text looks good enough

for my concern.=C2=A0 I=E2=80= =99ll leave any further adjustment to Martin, as he=E2=80=99s holding

the Discuss.

=C2=A0

Many thanks for the prompt atte= ntion to this, and (as noted earlier), I=E2=80=99m

pleased that this was not an ac= tual design problem.

=C2=A0

Thanks,
--David

=C2=A0

From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Friday, June 12, 2015 2:22 PM
To: li= onel.morand@orange.com; Black, David; Martin Stiemerling; The IESG
Cc: dime@ietf.org= ; dime-chairs@ietf.org
Subject: RE: Re : [Dime] Martin Stiemerling's Discuss on draft-i= etf-dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

=C2=A0

<sigh&g= t;=E2=80=A6 Even my corrections have errors this week.=C2=A0

From: lionel.morand= @orange.com [mailto:lionel.morand@orange.com]
Sent: Friday, June 12, 2015 1:12 PM
To: Bertz, Lyle T [CTO]; Black, David; Martin Stiemerling; The IESG<= br> Cc: dime@ietf.org= ; dime-chairs@ietf.org
Subject: Re : [Dime] Martin Stiemerling's Discuss on draft-ietf-= dime-congestion-flow-attributes-01: (with DISCUSS and COMMENT)

=C2=A0

Except that a "packets packet" = is maybe too explicit! :)

=C2=A0

(Second sentence)

Please wait for a formal go-ahead from th= e AD or myself before submitting a new version.

=C2=A0

Regards,

=C2=A0

Lionel=C2=A0

=C2=A0

Envoy=C3=A9 depuis mon mobile Orange

=C2=A0

----- Reply message -----
De : "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Pour=C2=A0: "Black, David" <david.black@emc.com>, "Martin Stiemerlin= g" <mls.iet= f@gmail.com>, "The IESG" <iesg@ietf.org>
Cc : "dime@ietf.org= " <dime@ietf= .org>, "dime-chairs@ietf.org" <dime-chairs@ietf.org>
Objet : [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-congesti= on-flow-attributes-01: (with DISCUSS and COMMENT)
Date : ven., juin 12, 2015 19:32

=C2=A0

Davi= d,

Thanks for the guidance here.=C2=A0 We definitely want to meet the goals yo= u note below.

I will assume Martin has no objection to "IP (5-tuple) flows".=C2= =A0 If so, we can adjust the language.

New language (I also changed 'In case the" to "If the" a= t the beginning of the next paragraph.

> >=C2=A0=C2=A0=C2=A0 The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >=C2=A0=C2=A0=C2=A0 indicates how to treat traffic IP (5-tuple) flo= w(s) when congestion is detected.
> >=C2=A0=C2=A0=C2=A0 The detection of the congestion can be based on= the reception of IP
> >=C2=A0=C2=A0=C2=A0 packets packet=C2=A0 with=C2=A0 the CE (Congest= ion Experienced) codepoint set
> >=C2=A0=C2=A0 (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> >=C2=A0=C2=A0 A Filter-Rule may contain a Classifier that describes= one or many 5-tuples per
> >=C2=A0=C2=A0 RFC 5777.=C2=A0 This treatment applies to all packets= associated to all 5-tuples (flows) > >=C2=A0=C2=A0 captured by the F= ilter-Rule.
> >
> >=C2=A0=C2=A0 If the Congestion-Treatment AVP is absent...

I believe this language meets the objectives outlined below.

Thank you.
Lyle

-----Original Message-----
From: Black, David [mailto:david.black@emc.com]
Sent: Friday, June 12, 2015 10:33 AM
To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
Cc: dime@ietf.org; <= a href=3D"mailto:dime-chairs@ietf.org" target=3D"_blank"> dime-chairs@ietf.org; Black, David
Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dime-con= gestion-flow-attributes-01: (with DISCUSS and COMMENT)

Lyle,

Thanks for the explanation - for my concern, I think we're close to don= e...

> Traffic flow(s) are IP (5-tuple) flow(s).

That's a relief - I'm glad that we're only dealing with editori= al concerns in the draft, and not an actual design problem.

> My question to you is would it be best to say "IP flows" or = "IP
> (5-tuple) flows" or "5-tuple flows"?

I like "IP (5-tuple) flows" - Martin?

> I am unsure of the best wording here.=C2=A0 This treatment applies to = all
> packets associated to all 5-tuples (flows) captured by the
> Filter-Rule.

Please add that latter sentence ("This treatment applies ...") to= the draft ...

> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.

... and please add that sentence also ;-).

The goal is to be clear that:
- adding an ECN-IP-Codepoint AVP to a Classifier still results in the
Classifier describing 5-tuple flows (as opposed to subsets of 5-tuple
flows that contain a specific value or values in the ECN field); and
- hence, the Congestion-Treatment AVP applies to 5-tuples and not to
anything smaller.

Thanks,
--David

> -----Original Message-----
> From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> Sent: Thursday, June 11, 2015 8:59 PM
> To: Black, David; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dim= e-
> congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> David,
>
> Traffic flow(s) are IP (5-tuple) flow(s).
>
> My question to you is would it be best to say "IP flows" or = "IP (5-tuple)
> flows" or "5-tuple flows"?=C2=A0=C2=A0 I am unsure of t= he best wording here.=C2=A0 This
> treatment applies to all packets associated to all 5-tuples (flows) > captured by the Filter-Rule.
>
> A Filter-Rule may contain a Classifier that describes one or many
> 5-tuples per RFC 5777.
>
> Thanks.
> Lyle
>
> -----Original Message-----
> From: Black, David [mailto:david.black@emc.com]
> Sent: Thursday, June 11, 2015 5:15 PM
> To: Bertz, Lyle T [CTO]; Martin Stiemerling; The IESG
> Cc: dime@ietf.org; dime-chairs@ietf.org; Black, David
> Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-ietf-dim= e-
> congestion-flow-attributes-01: (with DISCUSS and COMMENT)
>
> Lyle,
>
> >=C2=A0=C2=A0=C2=A0 The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >=C2=A0=C2=A0=C2=A0 indicates how to treat traffic flow(s) when con= gestion is detected.
> >=C2=A0=C2=A0=C2=A0 The detection of the congestion can be based on= the reception of IP
> >=C2=A0=C2=A0=C2=A0 packets packet=C2=A0 with=C2=A0 the CE (Congest= ion Experienced) codepoint set
> >=C2=A0=C2=A0 (see [RFC 3168]) or by any other administratively def= ined criteria.
>
> What does "traffic flow(s)" mean in this text?
>
> A clear explanation of that should remove the concern that this draft<= br> > might be applying congestion treatment to just the CE-marked packets > and not the entire 5-tuple (or more).
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
> > Sent: Thursday, June 11, 2015 6:02 PM
> > To: Martin Stiemerling; The IESG
> > Cc: Black, David; dime@ietf.org; dime-chairs@ietf.org
> > Subject: RE: [Dime] Martin Stiemerling's Discuss on draft-iet= f-dime-
> > congestion-flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin,
> >
> > Regarding the DISCUSS point the language in 3.2 is problematic, w= e
> > will change
> >
> >=C2=A0=C2=A0=C2=A0 The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >=C2=A0=C2=A0=C2=A0 indicates how congested traffic, i.e., traffic = that has Explicit
> >=C2=A0=C2=A0=C2=A0 Congestion Notification Congestion Experienced = marking set or some
> >=C2=A0=C2=A0=C2=A0 other administratively defined criteria, is tre= ated.
> >
> > to
> >
> >=C2=A0=C2=A0=C2=A0 The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped. It
> >=C2=A0=C2=A0=C2=A0 indicates how to treat traffic flow(s) when con= gestion is detected.
> >=C2=A0=C2=A0=C2=A0 The detection of the congestion can be based on= the reception of IP
> >=C2=A0=C2=A0=C2=A0 packets packet=C2=A0 with=C2=A0 the CE (Congest= ion Experienced) codepoint set
> >=C2=A0=C2=A0 (see [RFC 3168]) or by any other administratively def= ined criteria.
> >
> > The rationale for the word 'flow(s)' in the new language = is the last
> > sentence of the section=C2=A0 3.2 -=C2=A0 "The Congestion-Tr= eatment AVP is an
> > action and MUST be an attribute of the Filter-Rule Grouped AVP as=
> > defined in RFC5777. "=C2=A0 It is other AVPs in the Filter-R= ule, e.g.
> > Classifier, that describes the scope of traffic impacted.=C2=A0 S= aying
> > something in Section 3.2 that does not associate the
> > Congestion-Treatment AVP to the Filter-Rule it is a part of only<= br> > > creates
> confusion.
> >
> > ---------------------------------
> > Per the COMMENT, you are correct.=C2=A0 We'll change
> >
> > "The first AVP provides direct support for ECN [RFC3168] in = the IP
> >=C2=A0=C2=A0 header=E2=80=9C
> >
> > to your suggestion
> >
> > "The first AVP provides direct support for filtering ECN
> >=C2=A0=C2=A0 marked traffic[RFC3168]=E2=80=9C
> >
> > -----Original Message-----
> > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Martin
> > Stiemerling
> > Sent: Wednesday, June 10, 2015 3:36 PM
> > To: The IESG
> > Cc: davi= d.black@emc.com; dime@ietf.org; dime-chairs@ietf.org
> > Subject: [Dime] Martin Stiemerling's Discuss on
> > draft-ietf-dime-congestion-
> > flow-attributes-01: (with DISCUSS and COMMENT)
> >
> > Martin Stiemerling has entered the following ballot position for<= br> > > draft-ietf-dime-congestion-flow-attributes-01: Discuss
> >
> > When responding, please keep the subject line intact and reply to=
> > all email addresses included in the To and CC lines. (Feel free t= o
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria= .html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/doc/draft-ietf-dime-congestion-flow-att > > ri
> > butes/
> >
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > DISCUSS:
> > -----------------------------------------------------------------= ---
> > --
> >
> > No general objection to the publication of the document. However,= I
> > am relaying a question from David Black as a DISCUSS point.
> >
> > I assume that the draft is more than unclear in Section 3.2=C2=A0= about
> > what traffic means. Is it a particular flow, a single packet, etc= ?
> >
> > "I found an ECN concern, and hence added the TSV ADs to the = CC line.
> >
> > Section 3.2 says:
> >
> >=C2=A0=C2=A0=C2=A0 The Congestion-Treatment AVP (AVP Code TBD) is = of type Grouped and
> >=C2=A0=C2=A0=C2=A0 indicates how congested traffic, i.e., traffic = that has Explicit
> >=C2=A0=C2=A0=C2=A0 Congestion Notification Congestion Experienced = marking set or some
> >=C2=A0=C2=A0=C2=A0 other administratively defined criteria, is tre= ated.
> >
> > That appears to say that the congestion treatment may be applied<= br> > > solely to packets that have the CE (Congestion Experienced) marki= ng.
> > That would be a problem, because the defined semantics of a CE > > marking is that it applies to the entire flow (e.g., causes TCP t= o
> > react as if a packet has been dropped), hence the congestion
> > treatment ought to apply to the entire flow.
> >
> > In other words, one wants to be able to use the ECN-IP-Codepoint = AVP
> > as part of the condition that determines whether the filter rule<= br> > > matches, but ignore that AVP (i.e., wildcard it) in determining w= hat
> > traffic the action applies to, so that the response to detecting = a
> > congested flow (i.e., packets with ECN field containing CE) appli= es
> > to all packets in the flow, regardless of the value in the CE fie= ld.
> >
> > Otherwise, the result may be ineffective, as it won't encompa= ss
> > packets in the congested flow that aren't CE-marked.
> >
> > Am I reading the draft correctly?"
> >
> >
> > -----------------------------------------------------------------= ---
> > --
> > COMMENT:
> > -----------------------------------------------------------------= ---
> > --
> >
> > Section 1, 1st paragraph:
> > It says "The first AVP provides direct support for ECN [RFC3= 168] in
> > the IP header=E2=80=9C. I am=C2=A0 sure that your draft is=C2=A0 = ot providing any
> > support for ECN in the IP header, as we have ECN in the IP header=
> > already,
> isn't it.
> > I guess you mean something like this "The first AVP provides= direct
> > support for filtering ECN marked traffic[RFC3168]=E2=80=9C
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/dime
> >
> > ________________________________
> >
> > This e-mail may contain Sprint proprietary information intended f= or
> > the sole use of the recipient(s). Any use by others is prohibited= .
> > If you are not the intended recipient, please contact the sender = and
> > delete all copies of the message.
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for > the sole use of the recipient(s). Any use by others is prohibited. If<= br> > you are not the intended recipient, please contact the sender and
> delete all copies of the message.

________________________________

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

_________________________________________________=
________________________________________________________________________=

=C2=A0
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;<=
/u>
they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.
Thank you.

=C2=A0


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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.



--

Best regards,
Kath= leen
--047d7bb04b7c6e115d0519bd8945--