From nobody Mon Jun 2 00:26:53 2014 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 098111A02AE for ; Mon, 2 Jun 2014 00:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.253 X-Spam-Level: X-Spam-Status: No, score=-8.253 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl_1Fwl1j_FJ for ; Mon, 2 Jun 2014 00:26:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A2D1A02A7 for ; Mon, 2 Jun 2014 00:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7323; q=dns/txt; s=iport; t=1401694003; x=1402903603; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j+fsSS7TJE7tZs1fNiXUznp8Er6/lv+Tvr+b4P7RoAo=; b=TdiH0tTdRbYGF9NfqR1LyQv83vOjc6P1hw7aaFy+OeGsBxR2k6lKt9tC +USYpCsWLjEs9MCmhgM143xjZ2jWZQEboluV8EtgTzTRlBNqyV/SjFBTM Cz1HkQwhsSrMKNUaiLfZU4EChl/qSNqqfVgt5ww6NilMVB4w45e3CBoO2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAGAmjFOtJssW/2dsb2JhbABZg1m7coc5AYEldIImAQEEAQEBLwEFNgoBEAshFggHCQMCAQIBDwYfEQYBDAEFAgEBEIgaAxENzX0NhgQTBIw8gSkLEQFLBQeEQAEDmAiBeIZthk2Fc4M6Oy+BCg X-IronPort-AV: E=Sophos;i="4.98,955,1392163200"; d="scan'208";a="71723766" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Jun 2014 07:26:41 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s527QfRI009194; Mon, 2 Jun 2014 07:26:41 GMT Message-ID: <538C2730.3040309@cisco.com> Date: Mon, 02 Jun 2014 09:26:40 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Jouni Korhonen , "draft-ietf-dime-app-design-guide.all@tools.ietf.org" References: <52D9030B.3010402@cisco.com> <533BD276.7000401@cisco.com> <22885_1396976646_53442C06_22885_3037_1_6B7134B31289DC4FAF731D844122B36E54D5C4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53514D73.3090006@cisco.com> <53714817.8020100@cisco.com> <7656_1399962480_5371BB70_7656_3268_1_6B7134B31289DC4FAF731D844122B36E59FE4D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53722C6C.4000405@gmail.com> <21032_1400081845_53738DB5_21032_16360_1_6B7134B31289DC4FAF731D844122B36E5A4181@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <21032_1400081845_53738DB5_21032_16360_1_6B7134B31289DC4FAF731D844122B36E5A4181@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9Q2lRR7mKNJt-sWkciZqM8RG1eI Cc: dime mailing list Subject: Re: [Dime] AD review draft-ietf-dime-app-design-guide X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 07:26:51 -0000 Hi Lionel, No more feedback from the mailing list, please post a new version with the text below. Regards, Benoit > Hi Benoit, > > Would you be happy with the following rewording? > > OLD: > > 4.4.1. Setting of the AVP Flags > > When reusing AVPs in a new application, the M-bit flag setting MUST > be re-evaluated for a new Diameter application and, if necessary, > even for every command within the application. In general, for AVPs > defined outside of the Diameter base protocol, the characteristics of > an AVP are tied to its role within a given application and the > commands used in this application. > > All other AVP flags (V-bit, P-bit, reserved bits) MUST remain > unchanged. > > NEW: > > 4.4.1. Setting of the AVP Flags > > When reusing existing AVPs in a new application, application designers > MUST specify the setting of the M-bit flag for a new Diameter application > and, if necessary, even for every command within the application. > In general, for AVPs defined outside of the Diameter base protocol, the > characteristics of an AVP are tied to its role within a given application > and the commands used in this application. > > All other AVP flags (V-bit, P-bit, reserved bits) MUST remain > unchanged. > > -----Message d'origine----- > De : Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Envoyé : mardi 13 mai 2014 16:30 > À : MORAND Lionel IMT/OLN; Benoit Claise; draft-ietf-dime-app-design-guide.all@tools.ietf.org > Cc : dime mailing list > Objet : Re: [Dime] AD review draft-ietf-dime-app-design-guide > > > I think the change Lionel made is a good one. Diameter allows us, even > if not too much recommended, to change M-bits for existing AVP per > application. Emphasizing the "sanity check" is a good practise imho. > > - Jouni > > 5/13/2014 9:27 AM, lionel.morand@orange.com kirjoitti: >> Hi Benoit, >> >> The "MUST" is maybe not required. >> >> But this will cause interoperability issues if you just say "re-use AVP >> 1" without saying exactly how to set the M-bit. Some may decide to set >> the M-bit as initially defined, others may decide to change it. >> >> So the idea was to provide an absolute recommendation for designers and >> then a MUST/REQUIRED/SHALL for all the AVP flags: >> >> - The M-bit flag MUST be re-evaluated >> >> - Other AVP flags MUST remain unchanged. >> >> If not valid, no problem to revert the change. >> >> Regards, >> >> Lionel >> >> *De :*Benoit Claise [mailto:bclaise@cisco.com] >> *Envoyé :* mardi 13 mai 2014 00:16 >> *À :* MORAND Lionel IMT/OLN; >> draft-ietf-dime-app-design-guide.all@tools.ietf.org >> *Cc :* dime mailing list >> *Objet :* Re: [Dime] AD review draft-ietf-dime-app-design-guide >> >> Hi Lionel, >> >> Thanks for the new version 23. >> >> One question regarding the attached picture. >> >> >> What does it mean "MUST be re-evaluated" with a RFC 2119 keyword. >> RFC 2119 keywords are useful for interoperability, and I don't see why >> it's used here. >> >> Regards, Benoit. >> >> Hi Lionel, >> >> Thanks for the new version. >> See in line >> >> >> >> - When I read the document, it looked to me as a BCP. >> >> BCP definition from RFC 2026: >> >> 5. BEST CURRENT PRACTICE (BCP) RFCs >> >> >> >> The BCP subseries of the RFC series is designed to be a way to >> >> standardize practices and the results of community deliberations. >> >> Interestingly, the charter mentions: >> >> May 2012, Submit 'Diameter Application Design Guidelines' to the >> IESG for consideration as a BCP document >> >> */[LM] discussed in another email thread./* >> >> >> If you go to BCP, don't forget to update the abstract, and the >> writeup. >> >> Abstract: >> >> It is meant as a guidelines document and >> >> therefore as informative in nature. >> >> >> >> I would remove this sentence. Informative and BCP don't go along very well. >> >> >> >> Jouni, don't forget to update the writeup. >> >> >> - Editorial in section 5.7 >> OLD: >> >> Destination- Realm >> >> >> >> NEW: >> >> Destination-Realm >> >> */ /* >> >> Still there. >> >> >> >> >> >> - Section 5.9 >> >> Applications that do not understand these AVPs can discard >> >> them upon receipt. >> >> Generic comment: Each time there is a sentence like this one above, >> we should mention RFC 6733 as the reference. >> This document is not an extension/deviation to RFC 6733. >> >> */[LM] ok/* >> >> Still there. >> >> >> Regards, Benoit >> >> >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dime >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Wed Jun 4 01:51:06 2014 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 C3EBE1A011F; Wed, 4 Jun 2014 01:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 L_uRy4jHxaY7; Wed, 4 Jun 2014 01:51:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 52D291A0159; Wed, 4 Jun 2014 01:50:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5E6C180016; Wed, 4 Jun 2014 01:49:55 -0700 (PDT) To: jouni.nospam@gmail.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140604084955.A5E6C180016@rfc-editor.org> Date: Wed, 4 Jun 2014 01:49:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QHn3J5_5YoiQbfmxjDROQK423rw Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (3997) 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, 04 Jun 2014 08:51:01 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3997 -------------------------------------- Status: Verified Type: Technical Reported by: Jouni Korhonen Date Reported: 2014-05-24 Verified by: Benoit Claise (IESG) Section: GLOBAL Original Text ------------- Section 2.1. The base Diameter protocol is run on port 3868 for both TCP [RFC0793] and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5658. It is assumed that TLS is run on top of TCP when it is used, and DTLS is run on top of SCTP when it is used. If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (i.e., the peer complies only with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the purpose of backward compatibility and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent unprotected (see Section 5.6). Diameter clients MUST support either TCP or SCTP; agents and servers SHOULD support both. A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records take precedence over the default ports (3868 and 5658). Section 4.3.1. port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, the default Diameter port ; (3868) is assumed if no transport ; security is used and port 5658 when ; transport security (TLS/TCP and DTLS/SCTP) ; is used. Corrected Text -------------- Section 2.1. The base Diameter protocol is run on port 3868 for both TCP [RFC0793] and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5868. It is assumed that TLS is run on top of TCP when it is used, and DTLS is run on top of SCTP when it is used. If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5868 (i.e., the peer complies only with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the purpose of backward compatibility and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent unprotected (see Section 5.6). Diameter clients MUST support either TCP or SCTP; agents and servers SHOULD support both. A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5868 for TLS/TCP and DTLS/SCTP connections. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records take precedence over the default ports (3868 and 5868). Section 4.3.1. port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, the default Diameter port ; (3868) is assumed if no transport ; security is used and port 5868 when ; transport security (TLS/TCP and DTLS/SCTP) ; is used. Notes ----- RFC 6733 defined the Diameter port number for secure transport in IANA considerations Section 11.4. to be 5868. This is also in IANA port numbers registry "Service Name and Transport Protocol Port Number Registry". However, the RFC 6733 body text uses different port number in Sections 2.1. and 4.3.1. for secure transports. Since the IANA registry already contains the port number 5868 instead of the body text used value 5658, the values in Sections 2.1. and 4.3.1. should be 5868 instead of 5658. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From Ilya.Peregudov@cbossgroup.com Wed Jun 4 03:39:06 2014 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 87A681A02D1 for ; Wed, 4 Jun 2014 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.467 X-Spam-Level: * X-Spam-Status: No, score=1.467 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, 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 7KJQReiMN9xH for ; Wed, 4 Jun 2014 03:39:04 -0700 (PDT) Received: from mx1.cboss.ru (mx1.cboss.ru [195.245.232.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0FE1A02BD for ; Wed, 4 Jun 2014 03:39:03 -0700 (PDT) Received: from z102737.int.cboss.ru (z102737.int.cboss.ru [10.1.200.15]) by mx1.cboss.ru (8.13.8/8.13.8) with ESMTP id s54ActCu007868 for ; Wed, 4 Jun 2014 14:38:55 +0400 Received: from MAILSRV3.int.cboss.ru (unverified) by z102737.int.cboss.ru (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Wed, 4 Jun 2014 10:38:54 +0000 Received: from [127.0.0.1] ([10.3.35.4]) by MAILSRV3.int.cboss.ru with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jun 2014 14:38:51 +0400 Message-ID: <538EF73F.3070309@cboss.ru> Date: Wed, 04 Jun 2014 14:38:55 +0400 From: Iliya Peregoudov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2014 10:38:51.0865 (UTC) FILETIME=[2D22AC90:01CF7FE1] X-Antivirus: Dr.Web (R) for Mail Servers on mx1.cboss.ru host X-Antivirus-Code: 100000 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZRi57e7P7f8cLby5A1TyhIkTvMc Subject: [Dime] Diameter request routing clarification needed 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, 04 Jun 2014 10:44:13 -0000 Hello all, I need clarification about Diameter request routing. Consider the use-case: host: pcef, realm: example.com | A |CCR |RAR V | host: relay, realm: example.com | A |CCR |RAR V | host: ocs, realm: example.com RFC6733 says that request routing should be controlled by routing table. Host `ocs' has to consume CCR requests to realm example.com of application 4, so it should have route (example.com, 4) -> (LOCAL) Host `ocs' also has to send locally generated RAR requests to realm example.com of application 4, so it should have route (example.com, 4) -> (RELAY, relay) How `ocs' host should operate to select correct route? Does it mean that Diameter host should maintain two routing tables, one for handling of incoming requests, and one another for handling locally generated requests? Thank you in advance. Iliya Peregoudov Software engineer, CBOSS Group From nobody Wed Jun 4 07:28:56 2014 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 AC5A81A0301; Wed, 4 Jun 2014 07:28:53 -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 Oc84StPIpw3t; Wed, 4 Jun 2014 07:28:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D15B1A01F6; Wed, 4 Jun 2014 07:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604142852.3868.54087.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 07:28:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FhKbjhuiLtETS0UoV9UK279icVY Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-24.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, 04 Jun 2014 14:28:54 -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 Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-24.txt Pages : 26 Date : 2014-06-04 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Futhermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-24 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-24 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 4 13:16:40 2014 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 05E791A02B0 for ; Wed, 4 Jun 2014 13:16:38 -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 So7b6wp_8YWj for ; Wed, 4 Jun 2014 13:16:36 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366761A0085 for ; Wed, 4 Jun 2014 13:16:36 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr17so8223lab.17 for ; Wed, 04 Jun 2014 13:16:28 -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=r2VEbbVISZrAk7bPa5YXrkPoc1KQIjP7SjN1kOkhmNM=; b=DDfVUn89HaZmGqMxhZDsXKQb3x5VU6cAv5smUMiQMrJxExDhY+XtqJSeggHW0hcLBv 2ZPLNUG6WD44y78fcXfQF4SokHWAUPiXjnqwsFs9wZtRMPjcIVnlXQI2+thZpNMo7eIo JztDaX755uhlsnvmF4i+ZO/yol2DbSNiyOiUveFeMVqWxHUSHrYzBgYl02XGQJcJkjYu Ut18mVCNEF+h3Mjuhnw4bL2beS9UJ4FlSTODs24SuzCVQb11M+BBgJbrvxFF8PiwrVR7 tti70upmHpAI7yOxBsCsFINDC7BUuOoYGchb+xiR8FgCUgArEYe/puCqPuzMq2TVyaPz H6mQ== X-Received: by 10.112.54.135 with SMTP id j7mr4227566lbp.94.1401912988708; Wed, 04 Jun 2014 13:16:28 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id xa9sm3430356lbb.36.2014.06.04.13.16.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 13:16:28 -0700 (PDT) Message-ID: <538F7E9C.5030504@gmail.com> Date: Wed, 04 Jun 2014 23:16:28 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KoXdrxnvBAKnYEdiXhQRiZ9eKX4 Subject: [Dime] IETF #90 and call for agenda items 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, 04 Jun 2014 20:16:38 -0000 Folks, IETF #90 is getting near and the time to start gathering the agenda. We got the following WG items automatically on the agenda: draft-ietf-dime-congestion-flow-attributes draft-ietf-dime-group-signaling draft-ietf-dime-ovli draft-ietf-dime-e2e-sec-req and we'll get the update on those. If you want to pursue new/existing work outside of these, just let the chairs know (with a small justification of why). Majority of the f2f time will be spent to progress existing WG items, specifically the overload I-D. - Jouni & Lionel From nobody Thu Jun 5 07:17:23 2014 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 E8CFB1A01B1 for ; Thu, 5 Jun 2014 07:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ls3gC2JiWl0l for ; Thu, 5 Jun 2014 07:17:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64DB1A01C3 for ; Thu, 5 Jun 2014 07:17:15 -0700 (PDT) Received: from mail120-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Jun 2014 14:17:08 +0000 Received: from mail120-ch1 (localhost [127.0.0.1]) by mail120-ch1-R.bigfish.com (Postfix) with ESMTP id 8D7B83403D0 for ; Thu, 5 Jun 2014 14:17:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.57; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(z579ehz9371I9f17Rc85fhd838h4015Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL1df219h17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h27e2h9a9j) Received-SPF: pass (mail120-ch1: domain of sprint.com designates 144.229.32.57 as permitted sender) client-ip=144.229.32.57; envelope-from=Brent.Hirschman@sprint.com; helo=pdaasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail120-ch1 (localhost.localdomain [127.0.0.1]) by mail120-ch1 (MessageSwitch) id 1401977826911008_15770; Thu, 5 Jun 2014 14:17:06 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail120-ch1.bigfish.com (Postfix) with ESMTP id D112220007D for ; Thu, 5 Jun 2014 14:17:06 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Jun 2014 14:17:02 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s55EH0cv002557 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2014 09:17:00 -0500 Received: from plswe13m02.ad.sprint.com (plswe13m02.corp.sprint.com [144.229.214.21]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s55EH0j5014047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Jun 2014 09:17:00 -0500 Received: from PREWE13M19.ad.sprint.com (2002:90e2:8026::90e2:8026) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Jun 2014 09:16:59 -0500 Received: from PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a]) by PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a%15]) with mapi id 15.00.0847.030; Thu, 5 Jun 2014 10:16:58 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: Ac9juE1vbr3p/ZQ9STaza+gT8Lz6aAPug+xAA1WEkbA= Date: Thu, 5 Jun 2014 14:16:57 +0000 Message-ID: <123bcb87dd964139b5ad73b7454fe55f@PREWE13M19.ad.sprint.com> References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.20] Content-Type: multipart/alternative; boundary="_000_123bcb87dd964139b5ad73b7454fe55fPREWE13M19adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Xl68JK86SfDVYcoYWDlpVRjJiPI Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases 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, 05 Jun 2014 14:17:22 -0000 --_000_123bcb87dd964139b5ad73b7454fe55fPREWE13M19adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am sure everyone is starting to prepare for Toronto. I would please requ= est any comments on our draft soon so that I can prepare any special covera= ge of these topics in our discussion at the Toronto meeting. Thanks, Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: Hirschman, Brent B [CTO] Sent: Monday, May 19, 2014 9:56 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: RE: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-0= 0 - Use Cases Our request for comments on this draft issue has not had any responses yet.= Please take a look at this straightforward, 6 page draft and provide comm= ents. I know the overload work is of high importance to the working group. We fe= el this draft is complete and need everyone's quick review to capture any a= reas that need refinement. Your assistance is appreciated. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Tuesday, April 29, 2014 9:36 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - = Use Cases At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 2: Second, we were requested to investigate providing example use cases of ECN= . RFC5777 already provides a set of use cases for reporting and ECN is jus= t one of many such reporting parameters such as byte count. Adding a parag= raph of text such as the following may add some information but the authors= feel little incremental information is needed because of the work already = in RFC 5777. "Diameter nodes along the bearer path can implement filters to collect acco= unting and policy control information based on these congestion parameters = similar to byte count information. These filters on flows and overall node = congestion for these AVPs can report a measure of quality of byte counts to= collection points in the network where decisions can be made to mitigate o= r mediate any congestion conditions for accounting or real time policy cont= rol. These AVPs provide supplemental information as described in the use c= ases discussed in RFC5777." Thus, the authors are proposing no modification to the working group draft = at this time. Comments are welcome. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ 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. ________________________________ 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_123bcb87dd964139b5ad73b7454fe55fPREWE13M19adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am sure everyone is = starting to prepare for Toronto.  I would please request any comments = on our draft soon so that I can prepare any special coverage of these topic= s in our discussion at the Toronto meeting.

 

Thanks,

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: Hirschma= n, Brent B [CTO]
Sent: Monday, May 19, 2014 9:56 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: RE: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attri= butes-00 - Use Cases

 

Our request for commen= ts on this draft issue has not had any responses yet.  Please take a l= ook at this straightforward, 6 page draft and provide comments.

I know the overload wo= rk is of high importance to the working group.  We feel this draft is = complete and need everyone’s quick review to capture any areas that n= eed refinement.  Your assistance is appreciated.

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Tuesday, April 29, 2014 9:36 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attribute= s-00 - Use Cases

 

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 2:

 

Second, we were requested to investigate providing e= xample use cases of ECN.  RFC5777 already provides a set of use cases = for reporting and ECN is just one of many such reporting parameters such as= byte count.  Adding a paragraph of text such as the following may add some information but the authors feel little= incremental information is needed because of the work already in RFC 5777.=

“D= iameter nodes along the bearer path can implement filters to collect accoun= ting and policy control information based on these congestion parameters si= milar to byte count information. These filters on flows and overall node congestion for these AVPs can report a measure o= f quality of byte counts to collection points in the network where decision= s can be made to mitigate or mediate any congestion conditions for accounti= ng or real time policy control.  These AVPs provide supplemental information as described in the use cases = discussed in RFC5777.”

 

Thus, the authors are proposing no modification to t= he working group draft at this time.  Comments are welcome.=

 

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

 


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.



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_123bcb87dd964139b5ad73b7454fe55fPREWE13M19adsprintcom_-- From nobody Thu Jun 5 07:17:52 2014 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 EA85C1A01B1 for ; Thu, 5 Jun 2014 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Vv9X72L6v7Q6 for ; Thu, 5 Jun 2014 07:17:41 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DF91A01CA for ; Thu, 5 Jun 2014 07:17:40 -0700 (PDT) Received: from mail158-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Jun 2014 14:17:34 +0000 Received: from mail158-co9 (localhost [127.0.0.1]) by mail158-co9-R.bigfish.com (Postfix) with ESMTP id ECE9734023A for ; Thu, 5 Jun 2014 14:17:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(z579ehz9371I9f17Rc85fhd838h4015Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL1df219h17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h27e2h9a9j) Received-SPF: pass (mail158-co9: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Brent.Hirschman@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail158-co9 (localhost.localdomain [127.0.0.1]) by mail158-co9 (MessageSwitch) id 1401977851754608_26792; Thu, 5 Jun 2014 14:17:31 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.249]) by mail158-co9.bigfish.com (Postfix) with ESMTP id A9E48440175 for ; Thu, 5 Jun 2014 14:17:31 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Jun 2014 14:17:28 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s55EHOAe001348 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2014 09:17:26 -0500 Received: from PLSWE13M01.ad.sprint.com (plswe13m01.corp.sprint.com [144.229.214.20]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s55EHOH9014426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Jun 2014 09:17:26 -0500 Received: from PREWE13M19.ad.sprint.com (2002:90e2:8026::90e2:8026) by PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Jun 2014 09:17:24 -0500 Received: from PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a]) by PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a%15]) with mapi id 15.00.0847.030; Thu, 5 Jun 2014 10:17:22 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR Thread-Index: Ac9juBMOQgOoQXQmRW+JZUdT9oQ0cwPuUVNQA1XfXyA= Date: Thu, 5 Jun 2014 14:17:22 +0000 Message-ID: References: <514f538ef4f74db8a2103cc222be5baa@PREWE13M04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.20] Content-Type: multipart/alternative; boundary="_000_f7657f07730c4d7ca9c4f975c715806ePREWE13M19adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8V6BqIsmt3pVaxsa5HRyba9fuyg Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR 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, 05 Jun 2014 14:17:47 -0000 --_000_f7657f07730c4d7ca9c4f975c715806ePREWE13M19adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am sure everyone is starting to prepare for Toronto. I would please requ= est any comments on our draft soon so that I can prepare any special covera= ge of these topics in our discussion at the Toronto meeting. Thanks, Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: Hirschman, Brent B [CTO] Sent: Monday, May 19, 2014 9:55 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: RE: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-0= 0 - ECE and CWR Our request for comments on this draft issue has not had any responses yet.= Please take a look at this straightforward, 6 page draft and provide comm= ents. I know the overload work is of high importance to the working group. We fe= el this draft is complete and need everyone's quick review to capture any a= reas that need refinement. Your assistance is appreciated. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Tuesday, April 29, 2014 9:34 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - = ECE and CWR At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 1. First discussion topic, whether ECE and CWR flags needed to be added to thi= s draft. After further investigation, these flags are already included as = part of Section 4.1.8.10 or RFC5777. The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and specifies the TCP control flag types that must be matched. The first 16 bits match the TCP header format defined in [RFC3168], and the subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 are unused and bits 4 to 15 are managed by IANA under the TCP Header Flag registry as defined in [RFC3168= ]. The support of ECN flags (in this draft) are needed since they were omitted= in RFC5777: The ECN flags are still required and here is why. The prob= lem is that RFC 2474 (DSCP) update was made prior to 3168. They studied an= d made recommendations for this situation in RFC 3260 Section 4. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bi= ts. ... It has been pointed out that this leads to inconsistencies and ambiguities. In particular, the "Currently Unused" (CU) bits of the DS Field have not been assigned to Diffserv, and subsequent to the publication of RFC 2474, they were a= ssigned for explicit congestion notification, as defined in RFC 3168= [4] ... Therefore, for use in future documents, including the next update to RFC 2474, the following definitions = should apply: - the Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet. - the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards. The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv. When RFC 2474 is updated, considerat= ion should be given to changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor). Note here they are essentially dropping the "CU" bits in the definition its= elf. This removes overlap in ECN 3186. For RFC 5777, the authors wrote the AVP definition for DSCP in such a way t= hat it is not impacted so long as the registry is correct from 2474 and its= successors. Below is the RFC 5777 definition for DSCP. 4.1.8.1. Diffserv-Code= -Point AVP The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry as defined in [RFC2474]. The registry is to be updated to exclude the LU/Exp DSCPs from 2474. This = is specified in RFC 3260. 8. IANA Considerations IANA has requested clarification of a point in RFC 2474, concerning registration of experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6: IANA is requested to maintain a registry of RECOMMENDED DSCP values assigned by standards action. EXP/LU values are not to be registered. In summary the ECN flags are no longer considered DSCP "CU" bits. They are= also not covered any IANA value. This results in a gap in 5777 and requir= es the update. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ 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. ________________________________ 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_f7657f07730c4d7ca9c4f975c715806ePREWE13M19adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am sure everyone is = starting to prepare for Toronto.  I would please request any comments = on our draft soon so that I can prepare any special coverage of these topic= s in our discussion at the Toronto meeting.

 

Thanks,

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: Hirschma= n, Brent B [CTO]
Sent: Monday, May 19, 2014 9:55 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: RE: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attri= butes-00 - ECE and CWR

 

Our request for commen= ts on this draft issue has not had any responses yet.  Please take a l= ook at this straightforward, 6 page draft and provide comments.

I know the overload wo= rk is of high importance to the working group.  We feel this draft is = complete and need everyone’s quick review to capture any areas that n= eed refinement.  Your assistance is appreciated.

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Tuesday, April 29, 2014 9:34 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attribute= s-00 - ECE and CWR

 

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 1.

First discussion topic, whether ECE and CWR flags ne= eded to be added to this draft.  After further investigation, these fl= ags are already included as part of Section 4.1.8.10 or RFC5777.=

The TC= P-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and

 =   specifies the TCP control flag types that must be matched.  The= first

 =   16 bits match the TCP header format defined in [RFC3168], and the

 =   subsequent 16 bits are unused.  Within the first 16 bits, bits = 0 to 3

 =   are unused and bits 4 to 15 are managed by IANA under the TCP Header=

   Flag regis= try as defined in [R= FC3168].

The support of ECN flags (in this draft) are needed = since they were omitted in RFC5777:

        &nbs= p;       The ECN flags are still required and= here is why.  The problem is that RFC 2474 (DSCP) update was made pri= or to 3168.  They studied and made recommendations for this situation = in RFC 3260 Section 4.

The DS Field has a six bit Diffserv Codepoint a= nd two "currently unused" bits.

…

It has been pointed out that this leads to inconsist= encies and

   ambiguities.  In particular, the &= quot;Currently Unused" (CU) bits of the

   DS Field have not been assigned to Diff= serv, and subsequent to the

   publication of RFC 2474, they were assigned for explicit congestion

   notification, as defined in RFC 3168 [= 4]

…

   Therefore, for use in future documents,= including the next update to

   RFC 2474, the following definitions should apply:

 

      -  the Different= iated Services Field (DSField) is the six most

         sig= nificant bits of the (former) IPV4 TOS octet or the (former)

         IPV= 6 Traffic Class octet.

 

      -  the Different= iated Services Codepoint (DSCP) is a value which

         is = encoded in the DS field, and which each DS Node MUST use to

         sel= ect the PHB which is to be experienced by each packet it

         for= wards.

   The two least significant bits of the I= PV4 TOS octet and the IPV6

   Traffic Class octet are not used by Dif= fserv.

 

   When RFC 2474 is updated, consideration should be given to chan= ging

   the designation "currently unused = (CU)" to "explicit congestion

   notification (ECN)" and referencin= g RFC 3168 (or its successor).

 

Note here they are essentially dropping the “C= U” bits in the definition itself.  This removes overlap in ECN 3= 186.

 

For RFC 5777, the authors wrote the AVP definition f= or DSCP in such a way that it is not impacted so long as the registry is co= rrect from 2474 and its successors.  Below is the RFC 5777 definition = for DSCP.

4.1.8.1.  Diffserv-C= ode-Point AVP

 

   The Diffserv-Code-Point AVP (AVP Code 5= 35) is of type Enumerated and

   specifies the Differentiated Services F= ield Codepoints to match in

   the IP header.  The values are man= aged by IANA under the

   Differentiated Services Field Codepoint= s registry as defined in

   [RFC2474].

 

The registry is to be updated to exclude the LU/Exp = DSCPs from 2474.  This is specified in RFC 3260.

8. IANA Considerations=

 

   IANA has requested clarification of a p= oint in RFC 2474, concerning

   registration of experimental/local use = DSCPs.  When RFC 2474 is

   revised, the following should be added = to Section 6:

 

      IANA is requested to = maintain a registry of RECOMMENDED DSCP

      values assigned by st= andards action.  EXP/LU values are not to be

      registered.

 

In summary the ECN flags are no longer considered DS= CP “CU” bits.  They are also not covered any IANA value.&n= bsp; This results in a gap in 5777 and requires the update.

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

 


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.



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_f7657f07730c4d7ca9c4f975c715806ePREWE13M19adsprintcom_-- From nobody Fri Jun 6 07:53:23 2014 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 4E51C1A04A8; Fri, 6 Jun 2014 07:53:09 -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 udsUbalnKGpc; Fri, 6 Jun 2014 07:53:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A46F71A04B0; Fri, 6 Jun 2014 07:53:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140606145302.8187.53255.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 07:53:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/l-lcLcQUjUJqqOijSw-qfBzia1A Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Applications Design Guidelines) to Best Current Practice X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:53:09 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Applications Design Guidelines' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Futhermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jun 17 23:42:42 2014 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 2B0E01A0026 for ; Tue, 17 Jun 2014 23:42:41 -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 RinrOv-hsIDu for ; Tue, 17 Jun 2014 23:42:40 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CEA1A001D for ; Tue, 17 Jun 2014 23:42:39 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id hz20so228830lab.0 for ; Tue, 17 Jun 2014 23:42:38 -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=5vQM/SBrm/UybxvqZhhdubVpo6Limqr0D8RnQSpwpOA=; b=dCDMuv3WSAZW5dLw98/D7xHap+VIrPd5E4Rl9jluujwL8g61Z8j/j3m8P10YXvlDuP rT72Zuvmh0g/OPPH2dZjDxusrIeY6HuhFO6lDNO/KGUpbKqz0M4wPlUs/EdBtcSIxOcG /T8s/XlfNcl5vxaNhvLwPxGVbyjPtwgccLaeNFEoClot8o3UO0bSV/t+WwblTYlNe1Kz +AhVtClL1WnybKfVLdqgUYbEecT4DPYogY6L25gOtIo5UBPduSanidgDPEfO4UXxdZLy FtB6eGEADg3kRzOi32ulwixoposxy5F5Dvv2Q17ZTFt8Jrk8qRpeLv5SbFUxUH9GLCfT aC5w== X-Received: by 10.112.185.105 with SMTP id fb9mr41093lbc.72.1403073757975; Tue, 17 Jun 2014 23:42:37 -0700 (PDT) Received: from [192.168.250.57] ([194.100.71.98]) by mx.google.com with ESMTPSA id o1sm840574lbw.27.2014.06.17.23.42.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 23:42:37 -0700 (PDT) Message-ID: <53A134DC.4050000@gmail.com> Date: Wed, 18 Jun 2014 09:42:36 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gzS6ArMKA4cdpvEYQDvvaaT396Q Subject: [Dime] Important dates - IETF90 getting close 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, 18 Jun 2014 06:42:41 -0000 Folks, Just to remind you.. 4 July: Internet Draft submission - both -00 and revisions. 7 July: WG chairs upload WG agendas. 11 July: Early Bird registration and payment cut-off; the cost to register goes up. 18 July: Last day to pre-register and pre-pay. 20-25 July: 90th IETF Meeting in Toronto, ON, Canada. We have requested one meeting slots. From nobody Wed Jun 18 12:52:07 2014 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 C47CE1A0132 for ; Wed, 18 Jun 2014 12:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 tl0Jjw_cqCym for ; Wed, 18 Jun 2014 12:51:48 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2911A02B7 for ; Wed, 18 Jun 2014 12:51:47 -0700 (PDT) Received: from mail82-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Jun 2014 19:51:47 +0000 Received: from mail82-co9 (localhost [127.0.0.1]) by mail82-co9-R.bigfish.com (Postfix) with ESMTP id EC7144007C0 for ; Wed, 18 Jun 2014 19:51:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(z579ehz9371I9f17Rc85fhd838h4015Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL1df219h17326ah8275bh8275dh18c673h1de097h186068hz2fh87h109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h27e2h9a9j1151h) Received-SPF: pass (mail82-co9: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=Brent.Hirschman@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail82-co9 (localhost.localdomain [127.0.0.1]) by mail82-co9 (MessageSwitch) id 1403121104781792_30223; Wed, 18 Jun 2014 19:51:44 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.236]) by mail82-co9.bigfish.com (Postfix) with ESMTP id BBBFA3E004B for ; Wed, 18 Jun 2014 19:51:44 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Jun 2014 19:51:43 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s5IJpgwT022579 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2014 14:51:42 -0500 Received: from PREWE13M01.ad.sprint.com (prewe13m01.corp.sprint.com [144.226.128.20]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s5IJpfSX026433 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Jun 2014 14:51:42 -0500 Received: from PREWE13M19.ad.sprint.com (2002:90e2:8026::90e2:8026) by PREWE13M01.ad.sprint.com (2002:90e2:8014::90e2:8014) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 18 Jun 2014 15:51:41 -0400 Received: from PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a]) by PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a%15]) with mapi id 15.00.0847.030; Wed, 18 Jun 2014 15:51:40 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR Thread-Index: AQHPc3JzeBkJkp59PEKDAD+tXdKpZpt3ddDA Date: Wed, 18 Jun 2014 19:51:39 +0000 Message-ID: References: <514f538ef4f74db8a2103cc222be5baa@PREWE13M04.ad.sprint.com> <6280831f07cf4db08ac5edd756ff1ad9@PREWE13M04.ad.sprint.com> In-Reply-To: <6280831f07cf4db08ac5edd756ff1ad9@PREWE13M04.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.28] Content-Type: multipart/alternative; boundary="_000_e65855b37ece4985af2b5f8077d86c7cPREWE13M19adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprintrewards.sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dQv-PMbSwovSEXRoiuJSw4j4SOA Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR 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, 18 Jun 2014 19:51:59 -0000 --_000_e65855b37ece4985af2b5f8077d86c7cPREWE13M19adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we approach the Toronto meeting, I would appreciate any comments you mi= ght have on the Working Group draft document. I would like to make any rev= isions necessary prior to the meeting so the group can review and comment. Thanks, Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Monday, May 19, 2014 9:55 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-0= 0 - ECE and CWR Our request for comments on this draft issue has not had any responses yet.= Please take a look at this straightforward, 6 page draft and provide comm= ents. I know the overload work is of high importance to the working group. We fe= el this draft is complete and need everyone's quick review to capture any a= reas that need refinement. Your assistance is appreciated. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Tuesday, April 29, 2014 9:34 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - = ECE and CWR At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 1. First discussion topic, whether ECE and CWR flags needed to be added to thi= s draft. After further investigation, these flags are already included as = part of Section 4.1.8.10 or RFC5777. The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and specifies the TCP control flag types that must be matched. The first 16 bits match the TCP header format defined in [RFC3168], and the subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 are unused and bits 4 to 15 are managed by IANA under the TCP Header Flag registry as defined in [RFC3168= ]. The support of ECN flags (in this draft) are needed since they were omitted= in RFC5777: The ECN flags are still required and here is why. The prob= lem is that RFC 2474 (DSCP) update was made prior to 3168. They studied an= d made recommendations for this situation in RFC 3260 Section 4. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bi= ts. ... It has been pointed out that this leads to inconsistencies and ambiguities. In particular, the "Currently Unused" (CU) bits of the DS Field have not been assigned to Diffserv, and subsequent to the publication of RFC 2474, they were a= ssigned for explicit congestion notification, as defined in RFC 3168= [4] ... Therefore, for use in future documents, including the next update to RFC 2474, the following definitions = should apply: - the Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet. - the Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards. The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv. When RFC 2474 is updated, considerat= ion should be given to changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor). Note here they are essentially dropping the "CU" bits in the definition its= elf. This removes overlap in ECN 3186. For RFC 5777, the authors wrote the AVP definition for DSCP in such a way t= hat it is not impacted so long as the registry is correct from 2474 and its= successors. Below is the RFC 5777 definition for DSCP. 4.1.8.1. Diffserv-Code= -Point AVP The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry as defined in [RFC2474]. The registry is to be updated to exclude the LU/Exp DSCPs from 2474. This = is specified in RFC 3260. 8. IANA Considerations IANA has requested clarification of a point in RFC 2474, concerning registration of experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6: IANA is requested to maintain a registry of RECOMMENDED DSCP values assigned by standards action. EXP/LU values are not to be registered. In summary the ECN flags are no longer considered DSCP "CU" bits. They are= also not covered any IANA value. This results in a gap in 5777 and requir= es the update. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ 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. ________________________________ 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. ________________________________ 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_e65855b37ece4985af2b5f8077d86c7cPREWE13M19adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we approach the Tor= onto meeting, I would appreciate any comments  you might have on the W= orking Group draft document.  I would like to make any revisions neces= sary prior to the meeting so the group can review and comment.

 

Thanks,

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Monday, May 19, 2014 9:55 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attri= butes-00 - ECE and CWR

 

Our request for commen= ts on this draft issue has not had any responses yet.  Please take a l= ook at this straightforward, 6 page draft and provide comments.

I know the overload wo= rk is of high importance to the working group.  We feel this draft is = complete and need everyone’s quick review to capture any areas that n= eed refinement.  Your assistance is appreciated.

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Tuesday, April 29, 2014 9:34 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attribute= s-00 - ECE and CWR

 

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 1.

First discussion topic, whether ECE and CWR flags ne= eded to be added to this draft.  After further investigation, these fl= ags are already included as part of Section 4.1.8.10 or RFC5777.=

The TC= P-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and

 =   specifies the TCP control flag types that must be matched.  The= first

 =   16 bits match the TCP header format defined in [RFC3168], and the

 =   subsequent 16 bits are unused.  Within the first 16 bits, bits = 0 to 3

 =   are unused and bits 4 to 15 are managed by IANA under the TCP Header=

   Flag regis= try as defined in [R= FC3168].

The support of ECN flags (in this draft) are needed = since they were omitted in RFC5777:

        &nbs= p;       The ECN flags are still required and= here is why.  The problem is that RFC 2474 (DSCP) update was made pri= or to 3168.  They studied and made recommendations for this situation = in RFC 3260 Section 4.

The DS Field has a six bit Diffserv Codepoint a= nd two "currently unused" bits.

…

It has been pointed out that this leads to inconsist= encies and

   ambiguities.  In particular, the &= quot;Currently Unused" (CU) bits of the

   DS Field have not been assigned to Diff= serv, and subsequent to the

   publication of RFC 2474, they were assigned for explicit congestion

   notification, as defined in RFC 3168 [= 4]

…

   Therefore, for use in future documents,= including the next update to

   RFC 2474, the following definitions should apply:

 

      -  the Different= iated Services Field (DSField) is the six most

         sig= nificant bits of the (former) IPV4 TOS octet or the (former)

         IPV= 6 Traffic Class octet.

 

      -  the Different= iated Services Codepoint (DSCP) is a value which

         is = encoded in the DS field, and which each DS Node MUST use to

         sel= ect the PHB which is to be experienced by each packet it

         for= wards.

   The two least significant bits of the I= PV4 TOS octet and the IPV6

   Traffic Class octet are not used by Dif= fserv.

 

   When RFC 2474 is updated, consideration should be given to chan= ging

   the designation "currently unused = (CU)" to "explicit congestion

   notification (ECN)" and referencin= g RFC 3168 (or its successor).

 

Note here they are essentially dropping the “C= U” bits in the definition itself.  This removes overlap in ECN 3= 186.

 

For RFC 5777, the authors wrote the AVP definition f= or DSCP in such a way that it is not impacted so long as the registry is co= rrect from 2474 and its successors.  Below is the RFC 5777 definition = for DSCP.

4.1.8.1.  Diffserv-C= ode-Point AVP

 

   The Diffserv-Code-Point AVP (AVP Code 5= 35) is of type Enumerated and

   specifies the Differentiated Services F= ield Codepoints to match in

   the IP header.  The values are man= aged by IANA under the

   Differentiated Services Field Codepoint= s registry as defined in

   [RFC2474].

 

The registry is to be updated to exclude the LU/Exp = DSCPs from 2474.  This is specified in RFC 3260.

8. IANA Considerations=

 

   IANA has requested clarification of a p= oint in RFC 2474, concerning

   registration of experimental/local use = DSCPs.  When RFC 2474 is

   revised, the following should be added = to Section 6:

 

      IANA is requested to = maintain a registry of RECOMMENDED DSCP

      values assigned by st= andards action.  EXP/LU values are not to be

      registered.

 

In summary the ECN flags are no longer considered DS= CP “CU” bits.  They are also not covered any IANA value.&n= bsp; This results in a gap in 5777 and requires the update.

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

 


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.

 


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.



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_e65855b37ece4985af2b5f8077d86c7cPREWE13M19adsprintcom_-- From nobody Wed Jun 18 12:53:45 2014 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 434881A025E for ; Wed, 18 Jun 2014 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ANOgAni7z-7G for ; Wed, 18 Jun 2014 12:53:38 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A45B1A0132 for ; Wed, 18 Jun 2014 12:53:38 -0700 (PDT) Received: from mail219-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.22; Wed, 18 Jun 2014 19:53:37 +0000 Received: from mail219-co9 (localhost [127.0.0.1]) by mail219-co9-R.bigfish.com (Postfix) with ESMTP id A3CF12C04F7 for ; Wed, 18 Jun 2014 19:53:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.229.32.57; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(z579ehz9371I9f17Rc85fhd838h4015Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL1df219h17326ah8275bh8275dh18c673h1de097h186068hz2fh87h109h2a8h839hbe3hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h27e2h9a9j1151h) Received-SPF: pass (mail219-co9: domain of sprint.com designates 144.229.32.57 as permitted sender) client-ip=144.229.32.57; envelope-from=Brent.Hirschman@sprint.com; helo=pdaasdm2.corp.sprint.com ; p.sprint.com ; X-FB-DOMAIN-IP-MATCH: fail Received: from mail219-co9 (localhost.localdomain [127.0.0.1]) by mail219-co9 (MessageSwitch) id 1403121215204310_23903; Wed, 18 Jun 2014 19:53:35 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.248]) by mail219-co9.bigfish.com (Postfix) with ESMTP id 2ED70A0060 for ; Wed, 18 Jun 2014 19:53:35 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 18 Jun 2014 19:53:34 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s5IJrWlt009622 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Jun 2014 14:53:33 -0500 Received: from PREWE13M01.ad.sprint.com (prewe13m01.corp.sprint.com [144.226.128.20]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s5IJrWQ5027810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Jun 2014 14:53:32 -0500 Received: from PREWE13M19.ad.sprint.com (2002:90e2:8026::90e2:8026) by PREWE13M01.ad.sprint.com (2002:90e2:8014::90e2:8014) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 18 Jun 2014 15:53:31 -0400 Received: from PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a]) by PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a%15]) with mapi id 15.00.0847.030; Wed, 18 Jun 2014 15:53:30 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: AQHPgMjgQIqA03W4qkeKHhg9XOh8TJt3XBDA Date: Wed, 18 Jun 2014 19:53:30 +0000 Message-ID: <6ba6fbf6d2af46d6b06d38d4ca709250@PREWE13M19.ad.sprint.com> References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> <123bcb87dd964139b5ad73b7454fe55f@PREWE13M19.ad.sprint.com> In-Reply-To: <123bcb87dd964139b5ad73b7454fe55f@PREWE13M19.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.28] Content-Type: multipart/alternative; boundary="_000_6ba6fbf6d2af46d6b06d38d4ca709250PREWE13M19adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprintrewards.sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dime/d3u3VRCHtVdzFOeQ6JwDT1A-fyI Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases 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, 18 Jun 2014 19:53:42 -0000 --_000_6ba6fbf6d2af46d6b06d38d4ca709250PREWE13M19adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Still looking for comments on the Working Group Draft that I can address pr= ior to the Toronto meeting. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Thursday, June 05, 2014 9:17 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-0= 0 - Use Cases I am sure everyone is starting to prepare for Toronto. I would please requ= est any comments on our draft soon so that I can prepare any special covera= ge of these topics in our discussion at the Toronto meeting. Thanks, Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: Hirschman, Brent B [CTO] Sent: Monday, May 19, 2014 9:56 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: RE: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-0= 0 - Use Cases Our request for comments on this draft issue has not had any responses yet.= Please take a look at this straightforward, 6 page draft and provide comm= ents. I know the overload work is of high importance to the working group. We fe= el this draft is complete and need everyone's quick review to capture any a= reas that need refinement. Your assistance is appreciated. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [= CTO] Sent: Tuesday, April 29, 2014 9:36 AM To: dime@ietf.org Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Subject: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - = Use Cases At IETF 89 in London, during the discussion of the draft-ietf-dime-congesti= on-flow-attributes-00.txt, Two areas were requested to be investigated furt= her. We will be addressing them in separate email threads to keep the disc= ussion focused on each topic. This is Topic 2: Second, we were requested to investigate providing example use cases of ECN= . RFC5777 already provides a set of use cases for reporting and ECN is jus= t one of many such reporting parameters such as byte count. Adding a parag= raph of text such as the following may add some information but the authors= feel little incremental information is needed because of the work already = in RFC 5777. "Diameter nodes along the bearer path can implement filters to collect acco= unting and policy control information based on these congestion parameters = similar to byte count information. These filters on flows and overall node = congestion for these AVPs can report a measure of quality of byte counts to= collection points in the network where decisions can be made to mitigate o= r mediate any congestion conditions for accounting or real time policy cont= rol. These AVPs provide supplemental information as described in the use c= ases discussed in RFC5777." Thus, the authors are proposing no modification to the working group draft = at this time. Comments are welcome. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ 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. ________________________________ 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. ________________________________ 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_6ba6fbf6d2af46d6b06d38d4ca709250PREWE13M19adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Still looking for comm= ents on the Working Group Draft that I can address prior to the Toronto mee= ting.

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Thursday, June 05, 2014 9:17 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attri= butes-00 - Use Cases

 

I am sure everyone is = starting to prepare for Toronto.  I would please request any comments = on our draft soon so that I can prepare any special coverage of these topic= s in our discussion at the Toronto meeting.

 

Thanks,

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: Hirschma= n, Brent B [CTO]
Sent: Monday, May 19, 2014 9:56 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: RE: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attri= butes-00 - Use Cases

 

Our request for commen= ts on this draft issue has not had any responses yet.  Please take a l= ook at this straightforward, 6 page draft and provide comments.

I know the overload wo= rk is of high importance to the working group.  We feel this draft is = complete and need everyone’s quick review to capture any areas that n= eed refinement.  Your assistance is appreciated.

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Hirschman, Brent B [CTO]
Sent: Tuesday, April 29, 2014 9:36 AM
To: dime@ietf.org
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attribute= s-00 - Use Cases

 

At IETF 89 in London, during the discussion of the d= raft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were requested = to be investigated further.  We will be addressing them in separate em= ail threads to keep the discussion focused on each topic.  This is Topic 2:

 

Second, we were requested to investigate providing e= xample use cases of ECN.  RFC5777 already provides a set of use cases = for reporting and ECN is just one of many such reporting parameters such as= byte count.  Adding a paragraph of text such as the following may add some information but the authors feel little= incremental information is needed because of the work already in RFC 5777.=

“D= iameter nodes along the bearer path can implement filters to collect accoun= ting and policy control information based on these congestion parameters si= milar to byte count information. These filters on flows and overall node congestion for these AVPs can report a measure o= f quality of byte counts to collection points in the network where decision= s can be made to mitigate or mediate any congestion conditions for accounti= ng or real time policy control.  These AVPs provide supplemental information as described in the use cases = discussed in RFC5777.”

 

Thus, the authors are proposing no modification to t= he working group draft at this time.  Comments are welcome.=

 

 

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

 


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.

 


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.



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_6ba6fbf6d2af46d6b06d38d4ca709250PREWE13M19adsprintcom_--