From internet-drafts@ietf.org Wed Sep 4 08:14:24 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863AC21E80EA; Wed, 4 Sep 2013 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMj+Xvl0FQB3; Wed, 4 Sep 2013 08:14:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E2021F99E9; Wed, 4 Sep 2013 08:14:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130904151423.22946.8120.idtracker@ietfa.amsl.com> Date: Wed, 04 Sep 2013 08:14:23 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:14:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Realm-Based Redirection In Diameter Author(s) : Tina Tsou Ruibing Hao Tom Taylor Filename : draft-ietf-dime-realm-based-redirect-12.txt Pages : 9 Date : 2013-09-04 Abstract: Message redirection is a basic capability provided by the Diameter base protocol. In its conventional form, message redirection is performed by an application-independent "redirect agent", which returns one or more individual hosts to the message sender as possible destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved when S-NAPTR is not used for dynamic peer discovery. New applications may incorporate this capability by reference to the present document. Because the redirection mechanism is application-specific, it must be performed by a Diameter server or proxy rather than a basic redirect agent as defined in the Diameter base protocol. A new term, "Realm- based Redirect Server", is introduced in this document to differentiate the application-specific nature of realm-based redirection from the conventional Diameter redirection performed by a basic redirect agent. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-realm-based-redirect-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-12 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 chandu.valesh@gmail.com Sat Sep 7 11:17:08 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2311E8177 for ; Sat, 7 Sep 2013 11:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clvoHUg-WzRb for ; Sat, 7 Sep 2013 11:17:07 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id AB4E711E80E2 for ; Sat, 7 Sep 2013 11:17:07 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so5195357oag.8 for ; Sat, 07 Sep 2013 11:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2dm1PmuXqm3g27qau6FxXI48+VfpEvXx7ESMCFZOFzk=; b=UuKqaseQ5rTeblc+RdbXSmCFZuMTWIx6p7uzWTgzQP76wHqm5US2TRLVNFUGrAfXhp CIbZYlNRwRIEdbXF+EMuOQd3aGPFk0OwU1ruGRd3OGi2jX5vg6sbgIgdWWldvlz+/sDo xeACZ6V8MbaCx3iubhI4uZFc3h+XTBC0gUZLhN0ceDLoUGIow+jKlxT6vSDbG1Q97Z3D b0Nz93dkpbnPGJOB3B6VmqPht37VHeLx1xnK2xTYTGih1y4l0LbjXb4y1B1EcVajQKyN xlivDkZswPz8W/GygNUzcsuDv6q6ijrG7Gwk7LR/DaJrlq5XdLICeFu8s0XOShhmpmvf ZwxA== MIME-Version: 1.0 X-Received: by 10.182.38.228 with SMTP id j4mr6166275obk.94.1378577827221; Sat, 07 Sep 2013 11:17:07 -0700 (PDT) Received: by 10.182.189.73 with HTTP; Sat, 7 Sep 2013 11:17:07 -0700 (PDT) Date: Sat, 7 Sep 2013 23:47:07 +0530 Message-ID: From: chandu valesh To: dime@ietf.org Content-Type: multipart/alternative; boundary=001a11c2f3a6afd77904e5cf2922 X-Mailman-Approved-At: Sun, 08 Sep 2013 04:14:36 -0700 Subject: [Dime] Clarification on sending CER on Open connection with SCTP association restart X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 18:23:31 -0000 --001a11c2f3a6afd77904e5cf2922 Content-Type: text/plain; charset=ISO-8859-1 Hello all, I have a query/doubt on below section of RFC 6733: 1.1.3 . Changes from RFC 3588 : " Deprecated the exchange of CER/CEA messages in the open state. This feature was implied in the peer state machine table of RFC 3588 , but it was not clearly defined anywhere else in that document." Scenario: In case a diameter node using SCTP association and does a restart procedure according to RFC 4960, section 5.2.4.1. Can the node (the one restarted the association) send CER on the association? >From the above RFC-6733 description it looks to me that the node which restart the association should not send CER, is my understanding correct? please comment on this! Thanks and best regards, Chandu Valesh --001a11c2f3a6afd77904e5cf2922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,

I have a query/doubt on belo= w section of RFC 6733:

1.1.3. <=
/h4>Changes from RFC 3588:

"=A0Deprecated the exchange of CER/CEA messages in the open st= ate.
      This feature was implied in the peer state machine table of RFC
      3588, but it was n=
ot clearly defined anywhere else in that
      document."

Scenario: In cas= e a diameter node using SCTP=A0association and does a restart procedure=A0=A0acco= rding to RFC=A04960, section 5.2.4.1.
= Can the node (the one restarted the=A0associ= ation)=A0send =A0CER on the association?

From the above RFC-6733 description it looks to me th= at the node which=A0restart=A0 the association should not send CER, is my unders= tanding correct?

=
please comment on this!=A0


=
Thanks and best regards,
Chandu Valesh
--001a11c2f3a6afd77904e5cf2922-- From internet-drafts@ietf.org Tue Sep 10 07:23:25 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA53811E81BD; Tue, 10 Sep 2013 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWSzHfyT11Hn; Tue, 10 Sep 2013 07:23:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0B11E81B6; Tue, 10 Sep 2013 07:23:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130910142324.13882.76061.idtracker@ietfa.amsl.com> Date: Tue, 10 Sep 2013 07:23:24 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:23:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-ietf-dime-overload-reqs-12.txt Pages : 28 Date : 2013-09-10 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in congestion collapse. The existing Diameter mechanisms are not sufficient for this purpose. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-12 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 jouni.nospam@gmail.com Wed Sep 11 17:01:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B31021F8E85 for ; Wed, 11 Sep 2013 17:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, SARE_RECV_IP_211216=0.978] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3suHR2fr19n9 for ; Wed, 11 Sep 2013 17:01:46 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1614011E811D for ; Wed, 11 Sep 2013 17:01:45 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so9931552pdj.15 for ; Wed, 11 Sep 2013 17:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=90AooGdS5agAZF9i84jskORxTir6fn4BmWGQg/hInWY=; b=cTwvZy3utaNjcmhKi1uZejLEiTUf6119c5Sn9aw7ZogWW7x97az5ExNuw4dLoS93jh l1AXg9ieJvaaCT4Oo2U5kjkZ+/chhKE0h9mOMGUgJboLrRi9wyqqBEY2L9RO7p+sfSya dSiBoyFKDrEObGoUTHn5qqBIk1vbCHtTEMeBWq6c1lvUQNjdc7QTePMfIh+Ot9/5STVC MrLJNBXi8tmo9JxVQRFQxshyJDo5S94Pgcam8DU1BQP9+AqXov/d/WoidutX3M8X8Lta 6BtDhMBYxavPkbJFoyIo7yBAOYC2+j+v8L1faK4vI+q6MPqLj3newoZB5nJDuCRApsbA 1Wrg== X-Received: by 10.68.225.99 with SMTP id rj3mr4162050pbc.122.1378944105585; Wed, 11 Sep 2013 17:01:45 -0700 (PDT) Received: from [10.5.8.117] ([211.219.0.130]) by mx.google.com with ESMTPSA id ta10sm6415655pab.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 17:01:44 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Sep 2013 03:01:40 +0300 Message-Id: To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "dime-chairs@tools.ietf.org" Subject: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 00:01:46 -0000 Folks, As briefly discussed in IETF#87 we are calling for an adoption of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a two week call for adoption. The call ends 26th Sep. 2013. Express you support for or against the adoption in the mailing list. The end-to-end security requirements is part of our current charter: "Aug 2012 Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item" - Chairs From ben@nostrum.com Wed Sep 11 18:14:53 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50811E8227 for ; Wed, 11 Sep 2013 18:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnf4XqrVou9Q for ; Wed, 11 Sep 2013 18:14:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB9C211E8169 for ; Wed, 11 Sep 2013 18:14:52 -0700 (PDT) Received: from [10.0.1.9] (cpe-76-187-89-238.tx.res.rr.com [76.187.89.238]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8C1EmO0062328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Sep 2013 20:14:48 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ben Campbell In-Reply-To: Date: Wed, 11 Sep 2013 20:14:55 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Received-SPF: pass (shaman.nostrum.com: 76.187.89.238 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 01:14:53 -0000 On Sep 11, 2013, at 7:01 PM, Jouni Korhonen wrote: > Folks, > > As briefly discussed in IETF#87 we are calling for an adoption > of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a > two week call for adoption. The call ends 26th Sep. 2013. Express > you support for or against the adoption in the mailing list. > > The end-to-end security requirements is part of our current charter: > "Aug 2012 Submit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item" I support adoption. Thanks! Ben. From lionel.morand@orange.com Thu Sep 12 00:20:16 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ACE21F9F00 for ; Thu, 12 Sep 2013 00:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln92ElCXUXuc for ; Thu, 12 Sep 2013 00:20:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9E721F9EF2 for ; Thu, 12 Sep 2013 00:20:10 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1DB122DC6EB for ; Thu, 12 Sep 2013 09:20:09 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F16CE23805E for ; Thu, 12 Sep 2013 09:20:08 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 12 Sep 2013 09:20:08 +0200 From: To: "dime@ietf.org" Thread-Topic: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 Thread-Index: AQHOr0tImN7iME/gJEqyq+30CNp8wZnBKt2AgACHTVA= Date: Thu, 12 Sep 2013 07:20:07 +0000 Message-ID: <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> In-Reply-To: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 07:20:16 -0000 As individual, I support the adoption of this draft. Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: jeudi 12 septembre 2013 03:15 =C0=A0: Jouni Korhonen Cc=A0: dime@ietf.org; dime-chairs@tools.ietf.org Objet=A0: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 On Sep 11, 2013, at 7:01 PM, Jouni Korhonen wrote: > Folks,=20 >=20 > As briefly discussed in IETF#87 we are calling for an adoption > of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a > two week call for adoption. The call ends 26th Sep. 2013. Express > you support for or against the adoption in the mailing list. >=20 > The end-to-end security requirements is part of our current charter: > "Aug 2012 Submit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item" I support adoption. Thanks! Ben. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From srdonovan@usdonovans.com Thu Sep 12 04:33:04 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B811E820E for ; Thu, 12 Sep 2013 04:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j+CEuqe7ZNd for ; Thu, 12 Sep 2013 04:32:59 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) by ietfa.amsl.com (Postfix) with ESMTP id BA91111E8185 for ; Thu, 12 Sep 2013 04:32:59 -0700 (PDT) Received: from rrcs-24-227-213-50.sw.biz.rr.com ([24.227.213.50]:63834 helo=sdmac.tengointernet.com) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VK58s-0004Pt-Ph for dime@ietf.org; Thu, 12 Sep 2013 04:32:59 -0700 Message-ID: <5231A66B.5030300@usdonovans.com> Date: Thu, 12 Sep 2013 06:32:59 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dime@ietf.org References: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:33:04 -0000 +1 On 9/12/13 2:20 AM, lionel.morand@orange.com wrote: > As individual, I support the adoption of this draft. > > Lionel > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoyé : jeudi 12 septembre 2013 03:15 > À : Jouni Korhonen > Cc : dime@ietf.org; dime-chairs@tools.ietf.org > Objet : Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 > > On Sep 11, 2013, at 7:01 PM, Jouni Korhonen wrote: > >> Folks, >> >> As briefly discussed in IETF#87 we are calling for an adoption >> of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a >> two week call for adoption. The call ends 26th Sep. 2013. Express >> you support for or against the adoption in the mailing list. >> >> The end-to-end security requirements is part of our current charter: >> "Aug 2012 Submit 'problem statement and requirements for Diameter >> end-to-end security framework' as Dime working group item" > > I support adoption. > > Thanks! > > Ben. > _______________________________________________ > 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 > From md3135@att.com Thu Sep 12 05:05:56 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95B511E8228 for ; Thu, 12 Sep 2013 05:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhIVjATX63ew for ; Thu, 12 Sep 2013 05:05:51 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9B04B11E820E for ; Thu, 12 Sep 2013 05:05:50 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e1ea1325.0.1193357.00-349.3300352.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 12 Sep 2013 12:05:50 +0000 (UTC) X-MXL-Hash: 5231ae1e5302c7d4-5f9cf99844fbc5e97d2f11d3eeff62a66b231d88 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8CC5nVT009546; Thu, 12 Sep 2013 08:05:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8CC5Wn1009335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 08:05:44 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 12 Sep 2013 12:05:17 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Thu, 12 Sep 2013 08:05:17 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 Thread-Index: AQHOr6vc5BV9Z+cObkmDs/LOwZWtFZnCAGXw Date: Thu, 12 Sep 2013 12:05:17 +0000 Message-ID: References: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5231A66B.5030300@usdonovans.com> In-Reply-To: <5231A66B.5030300@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.216] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=bSTxKu84jhkA:10 a=WcrjICGhTNIA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=VrIez1F9i7sA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=pGLkceISAAAA:8 a=Pc-YckH47eLR-2a5Q14A:9 a=wPNLvfGTeEIA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=MSl-tDqOz04A:10 a] X-AnalysisOut: [=S5ZLvGTMJQP9o87J:21 a=5Q4gcCrlwI2D6JzC:21] Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 12:05:57 -0000 +1 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ste= ve Donovan Sent: Thursday, September 12, 2013 7:33 AM To: dime@ietf.org Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 +1 On 9/12/13 2:20 AM, lionel.morand@orange.com wrote: > As individual, I support the adoption of this draft. > > Lionel > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell > Envoy=E9 : jeudi 12 septembre 2013 03:15 > =C0 : Jouni Korhonen > Cc : dime@ietf.org; dime-chairs@tools.ietf.org > Objet : Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-0= 1 > > On Sep 11, 2013, at 7:01 PM, Jouni Korhonen wrot= e: > >> Folks, >> >> As briefly discussed in IETF#87 we are calling for an adoption >> of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a >> two week call for adoption. The call ends 26th Sep. 2013. Express >> you support for or against the adoption in the mailing list. >> >> The end-to-end security requirements is part of our current charter: >> "Aug 2012 Submit 'problem statement and requirements for Diameter >> end-to-end security framework' as Dime working group item" > > I support adoption. > > Thanks! > > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From R.Jesske@telekom.de Fri Sep 13 02:10:56 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A9D21F9F9B for ; Fri, 13 Sep 2013 02:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq0dB1GsuRa2 for ; Fri, 13 Sep 2013 02:10:51 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 151DE21F9F50 for ; Fri, 13 Sep 2013 02:10:50 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 13 Sep 2013 11:10:26 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Fri, 13 Sep 2013 11:10:26 +0200 From: To: , Date: Fri, 13 Sep 2013 11:10:24 +0200 Thread-Topic: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 Thread-Index: AQHOr0tImN7iME/gJEqyq+30CNp8wZnBKt2AgACHTVCAAbFf8A== Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DD50B60C8B@HE113667.emea1.cds.t-internal.com> References: <1AFF22FB-AAC9-4951-B515-356DA13EE23D@nostrum.com> <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <16321_1378970409_52316B29_16321_1666_1_6B7134B31289DC4FAF731D844122B36E26EC6B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 09:10:56 -0000 +1 BR Roland -----Urspr=FCngliche Nachricht----- Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im Auftrag von li= onel.morand@orange.com Gesendet: Donnerstag, 12. September 2013 09:20 An: dime@ietf.org Betreff: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 As individual, I support the adoption of this draft. Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: jeudi 12 septembre 2013 03:15 =C0=A0: Jouni Korhon= en Cc=A0: dime@ietf.org; dime-chairs@tools.ietf.org Objet=A0: Re: [Dime] ca= ll for adoption: draft-tschofenig-dime-e2e-sec-req-01 On Sep 11, 2013, at 7:01 PM, Jouni Korhonen wrote: > Folks, >=20 > As briefly discussed in IETF#87 we are calling for an adoption of the=20 > draft-tschofenig-dime-e2e-sec-req-01. This email starts a two week=20 > call for adoption. The call ends 26th Sep. 2013. Express you support=20 > for or against the adoption in the mailing list. >=20 > The end-to-end security requirements is part of our current charter: > "Aug 2012 Submit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item" I support adoption. Thanks! Ben. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From david.black@emc.com Thu Sep 19 16:57:58 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A5C21F89F7; Thu, 19 Sep 2013 16:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlDQ-IPf8iKn; Thu, 19 Sep 2013 16:57:53 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id A409F21F89A5; Thu, 19 Sep 2013 16:57:53 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8JNvchv027110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 19:57:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com r8JNvchv027110 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1379635060; bh=O4o1xvgJu8r0pJ7E0MISY8vfpSI=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vL7nL/yeGd5jlnmx0TzXyzBPZ10GMjGq8mYdIkqMK/sevBxDlH9Ay0LpF+oVZUAcd QYBZtBQAtDX3cHaEnn+Ffqn9/MNOAbNMVigcPW5tG4OtGwhTsvhkkMeSSUqfdJjnJW OhERfMpPrdcEnCyxfAY/eVoRCWxAslNo3yOz9pH0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com r8JNvchv027110 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 19 Sep 2013 19:57:33 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8JNvWnN028689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 19:57:33 -0400 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub09.corp.emc.com (10.254.92.104) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 19 Sep 2013 19:57:32 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Thu, 19 Sep 2013 19:57:32 -0400 From: "Black, David" To: Ben Campbell Date: Thu, 19 Sep 2013 19:57:31 -0400 Thread-Topic: Gen-ART review of draft-ietf-dime-overload-reqs-12 Thread-Index: Ac61lAC/2Ib8lY0HR+qxUxnYbPjA3A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DA1C7B5@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-EMM-GWVC: 1 X-RSA-Classifications: DLM_1, public X-EMM-McAfeeVC: 1 X-Mailman-Approved-At: Thu, 19 Sep 2013 21:31:41 -0700 Cc: "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "dime@ietf.org" , "Black, David" Subject: [Dime] Gen-ART review of draft-ietf-dime-overload-reqs-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:57:58 -0000 And the -12 version is likewise ready for publication as an Informational R= FC. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, August 27, 2013 12:41 PM > To: Ben Campbell > Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); ietf@ietf.= org; > dime@ietf.org; bclaise@cisco.com; Black, David > Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11 >=20 > The -11 version of this draft addresses all of the nits and editorial com= ments > noted in the Gen-ART review of the -10 version. It's ready for publicati= on as > an Informational RFC. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:ben@nostrum.com] > > Sent: Thursday, August 22, 2013 4:50 PM > > To: Black, David > > Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); > ietf@ietf.org; > > dime@ietf.org; bclaise@cisco.com > > Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 > > > > Hi David, > > > > We agree on all your points, and will make the updates in the next vers= ion, > > pending shepherd instructions. > > > > Thanks! > > > > Ben. > > > > On Aug 22, 2013, at 2:50 PM, "Black, David" wrote= : > > > > > Hi Eric, > > > > > > This looks good - comments follow ... > > > > > >>> a) I assume that overload control development work will derive more > > specific > > >>> security requirements - e.g., as REQ 27 is stated at a rather high > level. > > >>> The discussion in security considerations section seems reasonable. > > >> > > >> We agree with this. The thinking here was that we didn't want to sp= ecify > this > > >> in a way that would be specific to a particular type of mechanism. = It > might > > >> not hurt to state that assumption, either as a note on Req 27 or in = the > sec > > >> considerations. > > > > > > That would be good to add as a note on REQ 27. > > > > > >> The intent was very much as you say, where requirements on individua= l > node > > >> capabilities are hoped to result in better overall system behaviors. > There are > > >> also some requirements that are stated more at the system level (e.g= . 7 > and > > >> 17.) Also the text in section 2.2 that discusses Figure 5 talks abou= t how > > >> insufficient server capacity at a cluster of servers behind a Diamet= er > agent > > >> can be treated as if the agent itself was overloaded. > > >> > > >> On the other hand, any mechanism we design will have to focus on act= ions > of > > >> individual nodes, so the numbered requirements tend to focus on that= . I'm > not > > >> sure where to change the balance here--do you have specific suggesti= ons? > > > > > > I noted this as editorial rather than a minor issue, as I was mostly > concerned > > > that the actual design work will be informed by a sufficient architec= tural > "clue" > > > that the goal is "better overall system behaviors", which your respon= se > indicates > > > will definitely be the case ;-). > > > > > > Rather than edit individual requirements, how about adding the follow= ing > sentence > > > immediately following the introductory sentence in Section 7?: > > > > > > These requirements are stated primarily in terms of individual node > > > behavior to inform the design of the improved mechanism; > > > that design effort should keep in mind that the overall goal is > > > improved overall system behavior across all the nodes involved, > > > not just improved behavior from specific individual nodes. > > > > > >>> This inadequacy may, in turn, contribute to broader congestion coll= apse > > >>> > > >>> "collapse" is not the right word here - I suggest "issues", "impact= s", > > >>> "effects" or "problems". > > >> > > >> We are fine with any of those alternatives. How about impacts. > > > > > > That's fine. FWIW, "congestion collapse" has a specific (rather seve= re) > > > meaning over in the Transport Area, and that meaning was not intended > here. > > > > > >> 23.843 is the least stable reference. I don't have any issue with > pointing > > >> that out. The part of it we are referencing is historical front mat= ter > > >> though. > > > > > > I'd note the reference as work in progress, and put the statement abo= ut > stable > > > front matter (historical is a bad work to use here) in the body of th= e > draft > > > that cites the reference. > > > > > >> I tried the web and downloaded versions of 2.12.17 and was not able = to > get the > > >> warnings you saw (about the references). What did it say? > > > > > > Sorry, I didn't mean to send you on a wild goose chase :-). The idni= ts > confusion > > > manifested right at the top of the output, where everyone ignores it = ... > > > > > > Attempted to download rfc272 state... > > > Failure fetching the file, proceeding without it. > > > > > > You didn't reference RFC 272, so that output's apparently courtesy of > idnits > > > misinterpreting this reference: > > > > > > 1195 [TS29.272] > > > 1196 3GPP, "Evolved Packet System (EPS); Mobility > Management > > > 1197 Entity (MME) and Serving GPRS Support Node (SGSN) > related > > > 1198 interfaces based on Diameter protocol", TS 29.272 > 11.4.0, > > > 1199 September 2012. > > > > > > I was amused :-). > > > > > > Thanks, > > > --David > > > > > >> -----Original Message----- > > >> From: Eric McMurry [mailto:emcmurry@computer.org] > > >> Sent: Thursday, August 22, 2013 3:06 PM > > >> To: Black, David > > >> Cc: ben@nostrum.com; General Area Review Team (gen-art@ietf.org); > > >> ietf@ietf.org; dime@ietf.org; bclaise@cisco.com > > >> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 > > >> > > >> Hi David, > > >> > > >> Thank you for the review. Your time and comments are appreciated! > > >> > > >> comments/questions inline. > > >> > > >> > > >> Eric > > >> > > >> > > >> > > >> On Aug 17, 2013, at 9:18 , "Black, David" wrot= e: > > >> > > >>> > > >>> I am the assigned Gen-ART reviewer for this draft. For background o= n > > >>> Gen-ART, please see the FAQ at > > >>> > > >>> . > > >>> > > >>> Please resolve these comments along with any other Last Call commen= ts > > >>> you may receive. > > >>> > > >>> Document: draft-ietf-dime-overload-reqs-10 > > >>> Reviewer: David L. Black > > >>> Review Date: August 17, 2013 > > >>> IETF LC End Date: August 16, 2013 > > >>> IESG Telechat date: (if known) > > >>> > > >>> Summary: > > >>> This draft is basically ready for publication, but has nits that sh= ould > be > > >>> fixed before publication. > > >>> > > >>> This draft describes scenarios in which Diameter overload can occur= and > > provides > > >>> requirements for development of new overload control functionality = in > > Diameter. > > >>> It is well written, and the inclusion of scenarios in which overloa= d can > > occur, > > >>> both in terms of the relationships among types of Diameter nodes an= d > > actual mobile > > >>> network experience is very helpful. > > >>> > > >>> I apologize for this review being a day late, as I've been on vacat= ion > for > > most > > >>> of this draft's IETF Last Call period. > > >>> > > >>> Major issues: (none) > > >>> > > >>> Minor issues: (none) > > >>> > > >>> Nits/editorial comments: > > >>> > > >>> The following two comments could be minor issues, but I'm going to = treat > > them > > >>> as editorial, as I expect that they will be addressed in developmen= t of > > the > > >>> actual overload functionality: > > >>> > > >>> a) I assume that overload control development work will derive more > > specific > > >>> security requirements - e.g., as REQ 27 is stated at a rather high > level. > > >>> The discussion in security considerations section seems reasonable. > > >> > > >> We agree with this. The thinking here was that we didn't want to sp= ecify > > this > > >> in a way that would be specific to a particular type of mechanism. = It > > might > > >> not hurt to state that assumption, either as a note on Req 27 or in = the > sec > > >> considerations. > > >> > > >>> > > >>> b) The draft, and especially its requirements in Section 7 are stro= ngly > > >>> focused on individual Diameter node overload. That's necessary, bu= t > > overload > > >>> conditions can be broader, affecting an entire service or applicati= on, > or > > >>> multiple instances of either/both, even if not every individual Dia= meter > > node > > >>> involved is overloaded. A number of the requirements, starting wit= h REQ > > 22 > > >>> could be generalized to cover broader overload conditions. > > >>> > > >>> This (b) has implications for other requirements, e.g., REQ 13 shou= ld > also > > be > > >>> generalized beyond a single node to avoid increased traffic in an > overload > > >>> situation, even from a node that is not overloaded by itself. Ther= e are > > limits > > >>> on what is reasonable here, as the desired overload functionality i= s > > TCP/SCTP- > > >>> like reaction to congestion where individual actions taken by nodes > based > > on > > >>> the information they have (which is not the complete state of the > network) > > >>> results in an overall reduction of load. > > >> > > >> The intent was very much as you say, where requirements on individua= l > node > > >> capabilities are hoped to result in better overall system behaviors. > There > > are > > >> also some requirements that are stated more at the system level (e.g= . 7 > and > > >> 17.) Also the text in section 2.2 that discusses Figure 5 talks abou= t how > > >> insufficient server capacity at a cluster of servers behind a Diamet= er > > agent > > >> can be treated as if the agent itself was overloaded. > > >> > > >> On the other hand, any mechanism we design will have to focus on act= ions > of > > >> individual nodes, so the numbered requirements tend to focus on that= . I'm > > not > > >> sure where to change the balance here--do you have specific suggesti= ons? > > >> > > >>> > > >>> Section 1.2, 2nd paragraph: > > >>> > > >>> as network congestion, network congestion can reduce a Diameter no= des > > >>> > > >>> "nodes" -> "node's" > > >> > > >> good catch. > > >> > > >>> > > >>> Section 5, 1st paragraph: > > >>> > > >>> This inadequacy may, in turn, contribute to broader congestion coll= apse > > >>> > > >>> "collapse" is not the right word here - I suggest "issues", "impact= s", > > >>> "effects" or "problems". > > >> > > >> We are fine with any of those alternatives. How about impacts. > > >> > > >>> > > >>> Section 7 > > >>> > > >>> The long enumerated list of requirements is not an easy read. It w= ould > be > > >>> better if these could somehow be grouped by functional category, e.= g., > > >>> security, transport interactions, operational/administrative, etc. > > >> > > >> agree. It is actually in sections in the XML (denoted by comments),= we > > just > > >> did not promote those to visible sections in the txt. I recall ther= e > being > > >> some issue with xml2rfc and numbering, but now that the numbers are = set, > > this > > >> would not be hard to do. > > >> > > >> > > >>> > > >>> idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - this= is > > fine, > > >>> as the boilerplate has been appropriately modified for this draft t= hat > > >>> expresses requirements (as opposed to a draft that specifies a > protocol). > > >>> > > >>> idnits 2.12.17 got confused by the 3GPP and GSMA Informative Refere= nces. > > >>> I assume that they're all sufficiently stable to be informative > > references. > > >>> However, [TR23.843] is a work in progress, and should be noted as s= uch > in > > >>> its reference - is this needed for any of the other 3GPP or GSMA > > references? > > >> > > >> 23.843 is the least stable reference. I don't have any issue with > pointing > > >> that out. The part of it we are referencing is historical front mat= ter > > >> though. > > >> > > >> > > >> I tried the web and downloaded versions of 2.12.17 and was not able = to > get > > the > > >> warnings you saw (about the references). What did it say? > > >> > > >> > > >>> > > >>> Thanks, > > >>> --David > > >>> ---------------------------------------------------- > > >>> David L. Black, Distinguished Engineer > > >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 > > >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > >>> david.black@emc.com Mobile: +1 (978) 394-7754 > > >>> ---------------------------------------------------- > > >>> > > >> > > > > > From jouni.nospam@gmail.com Fri Sep 20 02:40:27 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825B421F8F2E; Fri, 20 Sep 2013 02:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkmGDHzBBIXS; Fri, 20 Sep 2013 02:40:26 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 82A7021F8F2A; Fri, 20 Sep 2013 02:40:25 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so159659lab.31 for ; Fri, 20 Sep 2013 02:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Hk/vx7Ju5kU9r85d10u8XHmJ+a2mHTvE6s2zyS6t9DM=; b=coVbJWPt+gM6elkfPGMBIl3L7KhvNhtc4rpOuti6uITyi1rKFR0v//ntGMPhMaBC/S EuEWw48qMpkodQoNpRZZ02eAswYRNqAqnr1E0v3bpeQFUuTLyK+a4NMo/lvCVSj4r3o6 +I4Yfal04ued4ooBaliQ+setRuNRMmhLvTAJ/YqMi9RXGGntyoXRJx+Q2n4A0Wsw2dfX p+NWula6jaXlYqrR9OLKzaBP6GsW1w6gBdCPAUfN+jLu7+jbGwUIMFCTeoo2xdn+kTb+ ld2tdYwIzbLzL3OIXJ6zGui7Sfmk4ByFRXXXEdknJ9J+T4TGQWA0c08yl43UAI1DhQ2k kp0w== X-Received: by 10.152.30.74 with SMTP id q10mr5404932lah.27.1379670024464; Fri, 20 Sep 2013 02:40:24 -0700 (PDT) Received: from [192.168.250.220] ([194.100.71.98]) by mx.google.com with ESMTPSA id f17sm5714409lbo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 02:40:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712025DA1C7B5@MX15A.corp.emc.com> Date: Fri, 20 Sep 2013 12:40:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <86EF9C2C-9FDC-4046-B7D1-323C0122C0C2@gmail.com> References: <8D3D17ACE214DC429325B2B98F3AE712025DA1C7B5@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1510) Cc: "General Area Review Team \(gen-art@ietf.org\)" , "dime@ietf.org" , "ietf@ietf.org" Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-overload-reqs-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 09:40:27 -0000 Thanks David. - JOuni On Sep 20, 2013, at 2:57 AM, "Black, David" wrote: > And the -12 version is likewise ready for publication as an = Informational RFC. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Black, David >> Sent: Tuesday, August 27, 2013 12:41 PM >> To: Ben Campbell >> Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); = ietf@ietf.org; >> dime@ietf.org; bclaise@cisco.com; Black, David >> Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11 >>=20 >> The -11 version of this draft addresses all of the nits and editorial = comments >> noted in the Gen-ART review of the -10 version. It's ready for = publication as >> an Informational RFC. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Thursday, August 22, 2013 4:50 PM >>> To: Black, David >>> Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); >> ietf@ietf.org; >>> dime@ietf.org; bclaise@cisco.com >>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 >>>=20 >>> Hi David, >>>=20 >>> We agree on all your points, and will make the updates in the next = version, >>> pending shepherd instructions. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> On Aug 22, 2013, at 2:50 PM, "Black, David" = wrote: >>>=20 >>>> Hi Eric, >>>>=20 >>>> This looks good - comments follow ... >>>>=20 >>>>>> a) I assume that overload control development work will derive = more >>> specific >>>>>> security requirements - e.g., as REQ 27 is stated at a rather = high >> level. >>>>>> The discussion in security considerations section seems = reasonable. >>>>>=20 >>>>> We agree with this. The thinking here was that we didn't want to = specify >> this >>>>> in a way that would be specific to a particular type of mechanism. = It >> might >>>>> not hurt to state that assumption, either as a note on Req 27 or = in the >> sec >>>>> considerations. >>>>=20 >>>> That would be good to add as a note on REQ 27. >>>>=20 >>>>> The intent was very much as you say, where requirements on = individual >> node >>>>> capabilities are hoped to result in better overall system = behaviors. >> There are >>>>> also some requirements that are stated more at the system level = (e.g. 7 >> and >>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks = about how >>>>> insufficient server capacity at a cluster of servers behind a = Diameter >> agent >>>>> can be treated as if the agent itself was overloaded. >>>>>=20 >>>>> On the other hand, any mechanism we design will have to focus on = actions >> of >>>>> individual nodes, so the numbered requirements tend to focus on = that. I'm >> not >>>>> sure where to change the balance here--do you have specific = suggestions? >>>>=20 >>>> I noted this as editorial rather than a minor issue, as I was = mostly >> concerned >>>> that the actual design work will be informed by a sufficient = architectural >> "clue" >>>> that the goal is "better overall system behaviors", which your = response >> indicates >>>> will definitely be the case ;-). >>>>=20 >>>> Rather than edit individual requirements, how about adding the = following >> sentence >>>> immediately following the introductory sentence in Section 7?: >>>>=20 >>>> These requirements are stated primarily in terms of individual = node >>>> behavior to inform the design of the improved mechanism; >>>> that design effort should keep in mind that the overall goal is >>>> improved overall system behavior across all the nodes involved, >>>> not just improved behavior from specific individual nodes. >>>>=20 >>>>>> This inadequacy may, in turn, contribute to broader congestion = collapse >>>>>>=20 >>>>>> "collapse" is not the right word here - I suggest "issues", = "impacts", >>>>>> "effects" or "problems". >>>>>=20 >>>>> We are fine with any of those alternatives. How about impacts. >>>>=20 >>>> That's fine. FWIW, "congestion collapse" has a specific (rather = severe) >>>> meaning over in the Transport Area, and that meaning was not = intended >> here. >>>>=20 >>>>> 23.843 is the least stable reference. I don't have any issue with >> pointing >>>>> that out. The part of it we are referencing is historical front = matter >>>>> though. >>>>=20 >>>> I'd note the reference as work in progress, and put the statement = about >> stable >>>> front matter (historical is a bad work to use here) in the body of = the >> draft >>>> that cites the reference. >>>>=20 >>>>> I tried the web and downloaded versions of 2.12.17 and was not = able to >> get the >>>>> warnings you saw (about the references). What did it say? >>>>=20 >>>> Sorry, I didn't mean to send you on a wild goose chase :-). The = idnits >> confusion >>>> manifested right at the top of the output, where everyone ignores = it ... >>>>=20 >>>> Attempted to download rfc272 state... >>>> Failure fetching the file, proceeding without it. >>>>=20 >>>> You didn't reference RFC 272, so that output's apparently courtesy = of >> idnits >>>> misinterpreting this reference: >>>>=20 >>>> 1195 [TS29.272] >>>> 1196 3GPP, "Evolved Packet System (EPS); = Mobility >> Management >>>> 1197 Entity (MME) and Serving GPRS Support Node = (SGSN) >> related >>>> 1198 interfaces based on Diameter protocol", TS = 29.272 >> 11.4.0, >>>> 1199 September 2012. >>>>=20 >>>> I was amused :-). >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Eric McMurry [mailto:emcmurry@computer.org] >>>>> Sent: Thursday, August 22, 2013 3:06 PM >>>>> To: Black, David >>>>> Cc: ben@nostrum.com; General Area Review Team (gen-art@ietf.org); >>>>> ietf@ietf.org; dime@ietf.org; bclaise@cisco.com >>>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 >>>>>=20 >>>>> Hi David, >>>>>=20 >>>>> Thank you for the review. Your time and comments are appreciated! >>>>>=20 >>>>> comments/questions inline. >>>>>=20 >>>>>=20 >>>>> Eric >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Aug 17, 2013, at 9:18 , "Black, David" = wrote: >>>>>=20 >>>>>>=20 >>>>>> I am the assigned Gen-ART reviewer for this draft. For background = on >>>>>> Gen-ART, please see the FAQ at >>>>>>=20 >>>>>> . >>>>>>=20 >>>>>> Please resolve these comments along with any other Last Call = comments >>>>>> you may receive. >>>>>>=20 >>>>>> Document: draft-ietf-dime-overload-reqs-10 >>>>>> Reviewer: David L. Black >>>>>> Review Date: August 17, 2013 >>>>>> IETF LC End Date: August 16, 2013 >>>>>> IESG Telechat date: (if known) >>>>>>=20 >>>>>> Summary: >>>>>> This draft is basically ready for publication, but has nits that = should >> be >>>>>> fixed before publication. >>>>>>=20 >>>>>> This draft describes scenarios in which Diameter overload can = occur and >>> provides >>>>>> requirements for development of new overload control = functionality in >>> Diameter. >>>>>> It is well written, and the inclusion of scenarios in which = overload can >>> occur, >>>>>> both in terms of the relationships among types of Diameter nodes = and >>> actual mobile >>>>>> network experience is very helpful. >>>>>>=20 >>>>>> I apologize for this review being a day late, as I've been on = vacation >> for >>> most >>>>>> of this draft's IETF Last Call period. >>>>>>=20 >>>>>> Major issues: (none) >>>>>>=20 >>>>>> Minor issues: (none) >>>>>>=20 >>>>>> Nits/editorial comments: >>>>>>=20 >>>>>> The following two comments could be minor issues, but I'm going = to treat >>> them >>>>>> as editorial, as I expect that they will be addressed in = development of >>> the >>>>>> actual overload functionality: >>>>>>=20 >>>>>> a) I assume that overload control development work will derive = more >>> specific >>>>>> security requirements - e.g., as REQ 27 is stated at a rather = high >> level. >>>>>> The discussion in security considerations section seems = reasonable. >>>>>=20 >>>>> We agree with this. The thinking here was that we didn't want to = specify >>> this >>>>> in a way that would be specific to a particular type of mechanism. = It >>> might >>>>> not hurt to state that assumption, either as a note on Req 27 or = in the >> sec >>>>> considerations. >>>>>=20 >>>>>>=20 >>>>>> b) The draft, and especially its requirements in Section 7 are = strongly >>>>>> focused on individual Diameter node overload. That's necessary, = but >>> overload >>>>>> conditions can be broader, affecting an entire service or = application, >> or >>>>>> multiple instances of either/both, even if not every individual = Diameter >>> node >>>>>> involved is overloaded. A number of the requirements, starting = with REQ >>> 22 >>>>>> could be generalized to cover broader overload conditions. >>>>>>=20 >>>>>> This (b) has implications for other requirements, e.g., REQ 13 = should >> also >>> be >>>>>> generalized beyond a single node to avoid increased traffic in an >> overload >>>>>> situation, even from a node that is not overloaded by itself. = There are >>> limits >>>>>> on what is reasonable here, as the desired overload functionality = is >>> TCP/SCTP- >>>>>> like reaction to congestion where individual actions taken by = nodes >> based >>> on >>>>>> the information they have (which is not the complete state of the >> network) >>>>>> results in an overall reduction of load. >>>>>=20 >>>>> The intent was very much as you say, where requirements on = individual >> node >>>>> capabilities are hoped to result in better overall system = behaviors. >> There >>> are >>>>> also some requirements that are stated more at the system level = (e.g. 7 >> and >>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks = about how >>>>> insufficient server capacity at a cluster of servers behind a = Diameter >>> agent >>>>> can be treated as if the agent itself was overloaded. >>>>>=20 >>>>> On the other hand, any mechanism we design will have to focus on = actions >> of >>>>> individual nodes, so the numbered requirements tend to focus on = that. I'm >>> not >>>>> sure where to change the balance here--do you have specific = suggestions? >>>>>=20 >>>>>>=20 >>>>>> Section 1.2, 2nd paragraph: >>>>>>=20 >>>>>> as network congestion, network congestion can reduce a Diameter = nodes >>>>>>=20 >>>>>> "nodes" -> "node's" >>>>>=20 >>>>> good catch. >>>>>=20 >>>>>>=20 >>>>>> Section 5, 1st paragraph: >>>>>>=20 >>>>>> This inadequacy may, in turn, contribute to broader congestion = collapse >>>>>>=20 >>>>>> "collapse" is not the right word here - I suggest "issues", = "impacts", >>>>>> "effects" or "problems". >>>>>=20 >>>>> We are fine with any of those alternatives. How about impacts. >>>>>=20 >>>>>>=20 >>>>>> Section 7 >>>>>>=20 >>>>>> The long enumerated list of requirements is not an easy read. It = would >> be >>>>>> better if these could somehow be grouped by functional category, = e.g., >>>>>> security, transport interactions, operational/administrative, = etc. >>>>>=20 >>>>> agree. It is actually in sections in the XML (denoted by = comments), we >>> just >>>>> did not promote those to visible sections in the txt. I recall = there >> being >>>>> some issue with xml2rfc and numbering, but now that the numbers = are set, >>> this >>>>> would not be hard to do. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - = this is >>> fine, >>>>>> as the boilerplate has been appropriately modified for this draft = that >>>>>> expresses requirements (as opposed to a draft that specifies a >> protocol). >>>>>>=20 >>>>>> idnits 2.12.17 got confused by the 3GPP and GSMA Informative = References. >>>>>> I assume that they're all sufficiently stable to be informative >>> references. >>>>>> However, [TR23.843] is a work in progress, and should be noted as = such >> in >>>>>> its reference - is this needed for any of the other 3GPP or GSMA >>> references? >>>>>=20 >>>>> 23.843 is the least stable reference. I don't have any issue with >> pointing >>>>> that out. The part of it we are referencing is historical front = matter >>>>> though. >>>>>=20 >>>>>=20 >>>>> I tried the web and downloaded versions of 2.12.17 and was not = able to >> get >>> the >>>>> warnings you saw (about the references). What did it say? >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>> ---------------------------------------------------- >>>>>> David L. Black, Distinguished Engineer >>>>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>> ---------------------------------------------------- >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >=20 From jouni.nospam@gmail.com Thu Sep 26 01:29:12 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AAE21E8086 for ; Thu, 26 Sep 2013 01:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv233ORTDNp8 for ; Thu, 26 Sep 2013 01:29:11 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A400821F9929 for ; Thu, 26 Sep 2013 01:29:07 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so353102eek.40 for ; Thu, 26 Sep 2013 01:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k3NX+D/ozQolt0DE4YFLKQmH/D117yC4LifGE6O6FmU=; b=0avc9e2W0TNrH+tgvWAi9Lwo4lCcwkJntllPMoxpzZwce+mD751TAgelM9loPiU2bI c5SAn40wb170dag6fAGnJt72wLdvtJPq8BYIPTPHMY/S4rMVmmOltPWapVdb+3fTmk6y FRvDBTmdnlufCgDQaKAoF4evBj4ihz/qMPF/Nq6r5eu3cGad/Pa/v3MQ4/ttwOfAVz3W 99s5JBSLJkqJ+eQwW/MABoRVFStS+zlbCmHNbsyTYkitafpVM3iN0cKtjgYyHMpDR68V wQOR5TLKpvAwB9StvghguIwwDPNNUDLEdujD2+NkwssTFt1ADd+QHS3ajbhE76bVwvK2 MIcQ== X-Received: by 10.14.220.195 with SMTP id o43mr1806423eep.57.1380184146731; Thu, 26 Sep 2013 01:29:06 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id b45sm1227461eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 01:29:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Thu, 26 Sep 2013 11:29:02 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: dime@ietf.org X-Mailer: Apple Mail (2.1510) Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] call for adoption: draft-tschofenig-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 08:29:12 -0000 Folks, The adoption call ends today. We got good support to adopt this document as a WG document (and none against). Authors, please submit -00 version of the document as the WG draft. - Jouni & Lionel On Sep 12, 2013, at 3:01 AM, Jouni Korhonen wrote: > Folks, > > As briefly discussed in IETF#87 we are calling for an adoption > of the draft-tschofenig-dime-e2e-sec-req-01. This email starts a > two week call for adoption. The call ends 26th Sep. 2013. Express > you support for or against the adoption in the mailing list. > > The end-to-end security requirements is part of our current charter: > "Aug 2012 Submit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item" > > - Chairs From internet-drafts@ietf.org Thu Sep 26 05:37:43 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87621F943C; Thu, 26 Sep 2013 05:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25SIEOaOXGmk; Thu, 26 Sep 2013 05:37:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF621F99B0; Thu, 26 Sep 2013 05:37:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926123741.29653.58286.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 05:37:41 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:37:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter AVP Level Security: Scenarios and Requirements Author(s) : Hannes Tschofenig Jouni Korhonen Glen Zorn Kervin Pillay Filename : draft-ietf-dime-e2e-sec-req-00.txt Pages : 8 Date : 2013-09-26 Abstract: This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-00 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 jari.arkko@piuha.net Thu Sep 26 05:42:02 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517C11E80F8; Thu, 26 Sep 2013 05:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4F11TurF7Tl; Thu, 26 Sep 2013 05:41:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A969211E8101; Thu, 26 Sep 2013 05:41:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F178E2CC6F; Thu, 26 Sep 2013 15:41:56 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GalmnV8GaTnA; Thu, 26 Sep 2013 15:41:55 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1C9152CC48; Thu, 26 Sep 2013 15:41:55 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: <86EF9C2C-9FDC-4046-B7D1-323C0122C0C2@gmail.com> Date: Thu, 26 Sep 2013 15:41:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A44CABA-64DF-4BCB-B4DE-16643BBCEE43@piuha.net> References: <8D3D17ACE214DC429325B2B98F3AE712025DA1C7B5@MX15A.corp.emc.com> <86EF9C2C-9FDC-4046-B7D1-323C0122C0C2@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Cc: David Black , dime@ietf.org, "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Dime] [Gen-art] Gen-ART review of draft-ietf-dime-overload-reqs-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:42:02 -0000 Indeed, thank you. Jari On Sep 20, 2013, at 12:40 PM, Jouni Korhonen = wrote: >=20 > Thanks David. >=20 > - JOuni >=20 >=20 > On Sep 20, 2013, at 2:57 AM, "Black, David" = wrote: >=20 >> And the -12 version is likewise ready for publication as an = Informational RFC. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Black, David >>> Sent: Tuesday, August 27, 2013 12:41 PM >>> To: Ben Campbell >>> Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); = ietf@ietf.org; >>> dime@ietf.org; bclaise@cisco.com; Black, David >>> Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11 >>>=20 >>> The -11 version of this draft addresses all of the nits and = editorial comments >>> noted in the Gen-ART review of the -10 version. It's ready for = publication as >>> an Informational RFC. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Thursday, August 22, 2013 4:50 PM >>>> To: Black, David >>>> Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); >>> ietf@ietf.org; >>>> dime@ietf.org; bclaise@cisco.com >>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 >>>>=20 >>>> Hi David, >>>>=20 >>>> We agree on all your points, and will make the updates in the next = version, >>>> pending shepherd instructions. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>> On Aug 22, 2013, at 2:50 PM, "Black, David" = wrote: >>>>=20 >>>>> Hi Eric, >>>>>=20 >>>>> This looks good - comments follow ... >>>>>=20 >>>>>>> a) I assume that overload control development work will derive = more >>>> specific >>>>>>> security requirements - e.g., as REQ 27 is stated at a rather = high >>> level. >>>>>>> The discussion in security considerations section seems = reasonable. >>>>>>=20 >>>>>> We agree with this. The thinking here was that we didn't want to = specify >>> this >>>>>> in a way that would be specific to a particular type of = mechanism. It >>> might >>>>>> not hurt to state that assumption, either as a note on Req 27 or = in the >>> sec >>>>>> considerations. >>>>>=20 >>>>> That would be good to add as a note on REQ 27. >>>>>=20 >>>>>> The intent was very much as you say, where requirements on = individual >>> node >>>>>> capabilities are hoped to result in better overall system = behaviors. >>> There are >>>>>> also some requirements that are stated more at the system level = (e.g. 7 >>> and >>>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks = about how >>>>>> insufficient server capacity at a cluster of servers behind a = Diameter >>> agent >>>>>> can be treated as if the agent itself was overloaded. >>>>>>=20 >>>>>> On the other hand, any mechanism we design will have to focus on = actions >>> of >>>>>> individual nodes, so the numbered requirements tend to focus on = that. I'm >>> not >>>>>> sure where to change the balance here--do you have specific = suggestions? >>>>>=20 >>>>> I noted this as editorial rather than a minor issue, as I was = mostly >>> concerned >>>>> that the actual design work will be informed by a sufficient = architectural >>> "clue" >>>>> that the goal is "better overall system behaviors", which your = response >>> indicates >>>>> will definitely be the case ;-). >>>>>=20 >>>>> Rather than edit individual requirements, how about adding the = following >>> sentence >>>>> immediately following the introductory sentence in Section 7?: >>>>>=20 >>>>> These requirements are stated primarily in terms of individual = node >>>>> behavior to inform the design of the improved mechanism; >>>>> that design effort should keep in mind that the overall goal is >>>>> improved overall system behavior across all the nodes involved, >>>>> not just improved behavior from specific individual nodes. >>>>>=20 >>>>>>> This inadequacy may, in turn, contribute to broader congestion = collapse >>>>>>>=20 >>>>>>> "collapse" is not the right word here - I suggest "issues", = "impacts", >>>>>>> "effects" or "problems". >>>>>>=20 >>>>>> We are fine with any of those alternatives. How about impacts. >>>>>=20 >>>>> That's fine. FWIW, "congestion collapse" has a specific (rather = severe) >>>>> meaning over in the Transport Area, and that meaning was not = intended >>> here. >>>>>=20 >>>>>> 23.843 is the least stable reference. I don't have any issue = with >>> pointing >>>>>> that out. The part of it we are referencing is historical front = matter >>>>>> though. >>>>>=20 >>>>> I'd note the reference as work in progress, and put the statement = about >>> stable >>>>> front matter (historical is a bad work to use here) in the body of = the >>> draft >>>>> that cites the reference. >>>>>=20 >>>>>> I tried the web and downloaded versions of 2.12.17 and was not = able to >>> get the >>>>>> warnings you saw (about the references). What did it say? >>>>>=20 >>>>> Sorry, I didn't mean to send you on a wild goose chase :-). The = idnits >>> confusion >>>>> manifested right at the top of the output, where everyone ignores = it ... >>>>>=20 >>>>> Attempted to download rfc272 state... >>>>> Failure fetching the file, proceeding without it. >>>>>=20 >>>>> You didn't reference RFC 272, so that output's apparently courtesy = of >>> idnits >>>>> misinterpreting this reference: >>>>>=20 >>>>> 1195 [TS29.272] >>>>> 1196 3GPP, "Evolved Packet System (EPS); = Mobility >>> Management >>>>> 1197 Entity (MME) and Serving GPRS Support Node = (SGSN) >>> related >>>>> 1198 interfaces based on Diameter protocol", TS = 29.272 >>> 11.4.0, >>>>> 1199 September 2012. >>>>>=20 >>>>> I was amused :-). >>>>>=20 >>>>> Thanks, >>>>> --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Eric McMurry [mailto:emcmurry@computer.org] >>>>>> Sent: Thursday, August 22, 2013 3:06 PM >>>>>> To: Black, David >>>>>> Cc: ben@nostrum.com; General Area Review Team (gen-art@ietf.org); >>>>>> ietf@ietf.org; dime@ietf.org; bclaise@cisco.com >>>>>> Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 >>>>>>=20 >>>>>> Hi David, >>>>>>=20 >>>>>> Thank you for the review. Your time and comments are = appreciated! >>>>>>=20 >>>>>> comments/questions inline. >>>>>>=20 >>>>>>=20 >>>>>> Eric >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Aug 17, 2013, at 9:18 , "Black, David" = wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> I am the assigned Gen-ART reviewer for this draft. For = background on >>>>>>> Gen-ART, please see the FAQ at >>>>>>>=20 >>>>>>> . >>>>>>>=20 >>>>>>> Please resolve these comments along with any other Last Call = comments >>>>>>> you may receive. >>>>>>>=20 >>>>>>> Document: draft-ietf-dime-overload-reqs-10 >>>>>>> Reviewer: David L. Black >>>>>>> Review Date: August 17, 2013 >>>>>>> IETF LC End Date: August 16, 2013 >>>>>>> IESG Telechat date: (if known) >>>>>>>=20 >>>>>>> Summary: >>>>>>> This draft is basically ready for publication, but has nits that = should >>> be >>>>>>> fixed before publication. >>>>>>>=20 >>>>>>> This draft describes scenarios in which Diameter overload can = occur and >>>> provides >>>>>>> requirements for development of new overload control = functionality in >>>> Diameter. >>>>>>> It is well written, and the inclusion of scenarios in which = overload can >>>> occur, >>>>>>> both in terms of the relationships among types of Diameter nodes = and >>>> actual mobile >>>>>>> network experience is very helpful. >>>>>>>=20 >>>>>>> I apologize for this review being a day late, as I've been on = vacation >>> for >>>> most >>>>>>> of this draft's IETF Last Call period. >>>>>>>=20 >>>>>>> Major issues: (none) >>>>>>>=20 >>>>>>> Minor issues: (none) >>>>>>>=20 >>>>>>> Nits/editorial comments: >>>>>>>=20 >>>>>>> The following two comments could be minor issues, but I'm going = to treat >>>> them >>>>>>> as editorial, as I expect that they will be addressed in = development of >>>> the >>>>>>> actual overload functionality: >>>>>>>=20 >>>>>>> a) I assume that overload control development work will derive = more >>>> specific >>>>>>> security requirements - e.g., as REQ 27 is stated at a rather = high >>> level. >>>>>>> The discussion in security considerations section seems = reasonable. >>>>>>=20 >>>>>> We agree with this. The thinking here was that we didn't want to = specify >>>> this >>>>>> in a way that would be specific to a particular type of = mechanism. It >>>> might >>>>>> not hurt to state that assumption, either as a note on Req 27 or = in the >>> sec >>>>>> considerations. >>>>>>=20 >>>>>>>=20 >>>>>>> b) The draft, and especially its requirements in Section 7 are = strongly >>>>>>> focused on individual Diameter node overload. That's necessary, = but >>>> overload >>>>>>> conditions can be broader, affecting an entire service or = application, >>> or >>>>>>> multiple instances of either/both, even if not every individual = Diameter >>>> node >>>>>>> involved is overloaded. A number of the requirements, starting = with REQ >>>> 22 >>>>>>> could be generalized to cover broader overload conditions. >>>>>>>=20 >>>>>>> This (b) has implications for other requirements, e.g., REQ 13 = should >>> also >>>> be >>>>>>> generalized beyond a single node to avoid increased traffic in = an >>> overload >>>>>>> situation, even from a node that is not overloaded by itself. = There are >>>> limits >>>>>>> on what is reasonable here, as the desired overload = functionality is >>>> TCP/SCTP- >>>>>>> like reaction to congestion where individual actions taken by = nodes >>> based >>>> on >>>>>>> the information they have (which is not the complete state of = the >>> network) >>>>>>> results in an overall reduction of load. >>>>>>=20 >>>>>> The intent was very much as you say, where requirements on = individual >>> node >>>>>> capabilities are hoped to result in better overall system = behaviors. >>> There >>>> are >>>>>> also some requirements that are stated more at the system level = (e.g. 7 >>> and >>>>>> 17.) Also the text in section 2.2 that discusses Figure 5 talks = about how >>>>>> insufficient server capacity at a cluster of servers behind a = Diameter >>>> agent >>>>>> can be treated as if the agent itself was overloaded. >>>>>>=20 >>>>>> On the other hand, any mechanism we design will have to focus on = actions >>> of >>>>>> individual nodes, so the numbered requirements tend to focus on = that. I'm >>>> not >>>>>> sure where to change the balance here--do you have specific = suggestions? >>>>>>=20 >>>>>>>=20 >>>>>>> Section 1.2, 2nd paragraph: >>>>>>>=20 >>>>>>> as network congestion, network congestion can reduce a Diameter = nodes >>>>>>>=20 >>>>>>> "nodes" -> "node's" >>>>>>=20 >>>>>> good catch. >>>>>>=20 >>>>>>>=20 >>>>>>> Section 5, 1st paragraph: >>>>>>>=20 >>>>>>> This inadequacy may, in turn, contribute to broader congestion = collapse >>>>>>>=20 >>>>>>> "collapse" is not the right word here - I suggest "issues", = "impacts", >>>>>>> "effects" or "problems". >>>>>>=20 >>>>>> We are fine with any of those alternatives. How about impacts. >>>>>>=20 >>>>>>>=20 >>>>>>> Section 7 >>>>>>>=20 >>>>>>> The long enumerated list of requirements is not an easy read. = It would >>> be >>>>>>> better if these could somehow be grouped by functional category, = e.g., >>>>>>> security, transport interactions, operational/administrative, = etc. >>>>>>=20 >>>>>> agree. It is actually in sections in the XML (denoted by = comments), we >>>> just >>>>>> did not promote those to visible sections in the txt. I recall = there >>> being >>>>>> some issue with xml2rfc and numbering, but now that the numbers = are set, >>>> this >>>>>> would not be hard to do. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - = this is >>>> fine, >>>>>>> as the boilerplate has been appropriately modified for this = draft that >>>>>>> expresses requirements (as opposed to a draft that specifies a >>> protocol). >>>>>>>=20 >>>>>>> idnits 2.12.17 got confused by the 3GPP and GSMA Informative = References. >>>>>>> I assume that they're all sufficiently stable to be informative >>>> references. >>>>>>> However, [TR23.843] is a work in progress, and should be noted = as such >>> in >>>>>>> its reference - is this needed for any of the other 3GPP or GSMA >>>> references? >>>>>>=20 >>>>>> 23.843 is the least stable reference. I don't have any issue = with >>> pointing >>>>>> that out. The part of it we are referencing is historical front = matter >>>>>> though. >>>>>>=20 >>>>>>=20 >>>>>> I tried the web and downloaded versions of 2.12.17 and was not = able to >>> get >>>> the >>>>>> warnings you saw (about the references). What did it say? >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> --David >>>>>>> ---------------------------------------------------- >>>>>>> David L. Black, Distinguished Engineer >>>>>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>>> ---------------------------------------------------- >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From internet-drafts@ietf.org Mon Sep 30 11:53:48 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867B921F856A; Mon, 30 Sep 2013 11:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+VRT-6IRw+1; Mon, 30 Sep 2013 11:53:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C946121F9D9C; Mon, 30 Sep 2013 11:53:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130930185337.31558.77133.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 11:53:37 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:53:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-ietf-dime-overload-reqs-13.txt Pages : 28 Date : 2013-09-30 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively more severe overload condition. The existing Diameter mechanisms are not sufficient for this purpose. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-13 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/