From dromasca@avaya.com Sun Apr 11 02:22:18 2010 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E35C3A6966 for ; Sun, 11 Apr 2010 02:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg5dGA61z0Dm for ; Sun, 11 Apr 2010 02:22:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A75023A697F for ; Sun, 11 Apr 2010 02:22:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,184,1270440000"; d="scan'208";a="183801571" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Apr 2010 05:22:03 -0400 X-IronPort-AV: E=Sophos;i="4.52,184,1270440000"; d="scan'208";a="450532672" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Apr 2010 05:22:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Apr 2010 11:21:40 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Criteria for Errata Thread-Index: AcrQ3pAAaS1MZEyFSvGrjEvtfQkbyAIeRxvA References: From: "Romascanu, Dan (Dan)" To: "Mark Jones" , Subject: Re: [AAA-DOCTORS] Criteria for Errata X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 09:22:18 -0000 Hi Mark, I apologize for the late response. I was on vacation for the two weeks following the Anaheim meeting.=20 The process of approving an errata is very fast as it depends on the responsible AD and if he is not on vacation of overflown with mails he is pretty responsive :-) I would somehow first require that you make sure that the expert WG (DIME WG in this case) agrees with the proposed Errata and its resolution. I would though recommend that you submit the Errata (erratum?) and then ask the DIME chairs to call for consensus. Dan =20 > -----Original Message----- > From: aaa-doctors-bounces@ietf.org=20 > [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Mark Jones > Sent: Wednesday, March 31, 2010 5:29 PM > To: aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] Criteria for Errata >=20 > Hi Doctors, >=20 > The *-Application-Id AVP error in RFC3588 (AVP MUST be=20 > present in every command) is being propagated into new=20 > Diameter applications. This error caused significant=20 > confusion in 3GPP and will probably cause confusion in WiMAX.=20 >=20 > Looking at the IESG review guideline, I was wondering whether=20 > an Errata to RFC3588 would be approved for this bug (even=20 > though it is fixed in 3588bis).=20 >=20 > I don't want to waste time writing up Errata that will simply=20 > be classed as "Hold for Document Update" in 3588bis.=20 >=20 > How long does the Errata approval process take? Is it better=20 > to wait for 3588bis? >=20 > Thanks > Mark > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors >=20 From dromasca@avaya.com Wed Apr 14 09:35:03 2010 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9D528C14D; Wed, 14 Apr 2010 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1ShAhsezkq2; Wed, 14 Apr 2010 09:35:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9B9013A6359; Wed, 14 Apr 2010 09:35:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="184331873" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:34:53 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451634603" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:34:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:34:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Congestion Exposure (conex) Thread-Index: AcrbMzjH2Bym9zI3StCzu4RjvoXr4AAvQNhg From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: WG Review: Congestion Exposure (conex) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:35:03 -0000 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 13, 2010 9:00 PM To: new-work@ietf.org Subject: WG Review: Congestion Exposure (conex)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. =20 Congestion Exposure (conex) -------------------------------------------------- Current Status: Proposed Working Group Last Updated: 2010-04-08 Chair(s): TBD Transport Area Director(s): Lars Eggert David Harrington Transport Area Advisor: Lars Eggert =20 Mailing Lists: TBD Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements, The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the IP layer, such that the total level of congestion is visible to all IP devices along the path. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Experiments on such use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. Milestones Mar 2011 Submit abstract specification for the congestion exposure mechanism to IESG as Informational Mar 2011 Submit use case description to IESG as Informational Sep 2011 Submit specification of IPv6 packet structure to IESG as Experimental Sep 2011 Submit specification for modification to TCP to IESG as Experimental From dromasca@avaya.com Wed Apr 14 09:35:05 2010 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9458428C2AF; Wed, 14 Apr 2010 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4fdhByLHj-y; Wed, 14 Apr 2010 09:35:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 123B228C0F7; Wed, 14 Apr 2010 09:35:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="184331876" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2010 12:34:54 -0400 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="451634611" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2010 12:34:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 18:34:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: DECoupled Application Data Enroute (decade) Thread-Index: AcrbMzcOb4BDgPh5TTe1JTFo53PqnAAvSi5w From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: WG Review: DECoupled Application Data Enroute (decade) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:35:05 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 13, 2010 9:00 PM To: new-work@ietf.org Subject: WG Review: DECoupled Application Data Enroute (decade)=20 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. =20 =20 DECoupled Application Data Enroute (decade) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-03-26 Chair(s): TBD Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre Applications Area Advisor: * Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the networks. Allowing P2P applications to store and retrieve data from inside networks can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open, standard protocol to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development (and hence, rechartering) is deemed necessary, it is not expected that all work items will be ready for IESG review by that point. However, WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Implementation of policies regarding copyright-protected or illegal content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational From dromasca@avaya.com Fri Apr 16 10:35:05 2010 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D033A6A1B; Fri, 16 Apr 2010 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.057 X-Spam-Level: X-Spam-Status: No, score=-1.057 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVwfTMoJDg+9; Fri, 16 Apr 2010 10:35:04 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E32B43A68BD; Fri, 16 Apr 2010 10:35:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,221,1270440000"; d="scan'208";a="213895217" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Apr 2010 13:34:56 -0400 X-IronPort-AV: E=Sophos;i="4.52,221,1270440000"; d="scan'208";a="452411448" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Apr 2010 13:34:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Apr 2010 19:34:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the April 22, 2010 IESG Teleconference Thread-Index: AcrdBOldcW5WAaHqSyq+2dTpvHILSgAhXrrw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the April 22, 2010 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 17:35:05 -0000 Please find below the preliminary agenda of the 4/22 IESG telechat. Please send me you questions, comments and concerns about the documents and the WG charters on the agenda before 4/21 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-sipping-config-framework-17 A Framework for Session Initiation Protocol User Agent Profile Delivery (Proposed Standard) Token: Robert Sparks o draft-ietf-mmusic-rfc4756bis-07 Forward Error Correction Grouping Semantics in Session Description Protocol (Proposed Standard) Note: Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com) Token: Robert Sparks o draft-ietf-sipcore-info-events-07 Session Initiation Protocol (SIP) INFO Method and Package Framework (Proposed Standard) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Robert Sparks o draft-ietf-netmod-yang-12 YANG - A data modeling language for NETCONF (Proposed Standard) Note: David Partain (david.partain@ericsson.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-netmod-yang-types-08 Common YANG Data Types (Proposed Standard) Note: David Partain (david.partain@ericsson.com) is the document shepherd. Token: Dan Romascanu o draft-freed-sieve-notary-07 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions (Proposed Standard) Note: This is a Sieve WG document, despite the name. Cyrus Daboo is the document shepherd. Token: Alexey Melnikov o draft-ietf-pce-pcep-p2mp-extensions-09 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (Proposed Standard) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-avt-register-srtp-01 Policy for Registering SRTP Transforms (Proposed Standard) Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-opsawg-smi-datatypes-in-xsd-06 Expressing SNMP SMI Datatypes in XML Schema Definition Language (Proposed Standard) Note: Scott Bradner (sob@harvard.edu) is the document shepherd. Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Items o draft-nottingham-http-link-header-09 Web Linking (Proposed Standard) Note: Julian Reschke is the document shepherd Token: Alexey Melnikov o draft-ogud-iana-protocol-maintenance-words-03 Definitions for expressing standards requirements in IANA registries. (BCP) Token: Russ Housley o draft-denenberg-mods-etc-media-types-01 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, application/sru+xml (Proposed Standard) Note: I am aware that the document doesn't pass some formatting nits, but I am thinking that in this case RFC Editor can fix that. An alternative would be to find another co-editor, but I think this would be overkill. Token: Alexey Melnikov o draft-reschke-rfc2231-in-http-11 Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields (Proposed Standard) Note: Graham Klyne is the document shepherd Token: Alexey Melnikov o draft-turner-asymmetrickeyformat-05 Asymmetric Key Packages (Proposed Standard) Note: Carl Wallace (cwallace@cygnacom.com) is the Document Shepherd Token: Tim Polk o draft-turner-asymmetrickeyformat-algs-01 Algorithms for Asymmetric Key Package Content Type (Proposed Standard) Note: Carl Wallace (cwallace@cygnacom.com) is the document Shepherd Token: Tim Polk o draft-haberman-rpsl-reachable-test-03 A Dedicated RPSL Interface Identifier for Operational Testing (Proposed Standard) Token: Ron Bonica 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-nsis-nslp-natfw-24 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) (Experimental) Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi). Token: Lars Eggert o draft-ietf-nsis-rmd-19 RMD-QOSM - The Resource Management in Diffserv QOS Model (Experimental) Note: Jukka Manner (jukka.manner@tkk.fi) is the document shepherd. Token: Lars Eggert o draft-ietf-nsis-ext-07 Using and Extending the NSIS Protocol Family (Informational) Note: Document Shepherd: Martin Stiemerling (martin.stiemerling@neclab.eu) Token: Lars Eggert o draft-ietf-radext-status-server-06 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (Informational) Note: Bernard Aboba (bernard_aboba@hotmail.com) is the document shepherd. Token: Dan Romascanu 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-wallace-using-ta-constraints-02 Using Trust Anchor Constraints During Certification Path Processing (Informational) Token: Tim Polk o draft-mattsson-mikey-ticket-03 MIKEY-TICKET: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) (Informational) Token: Tim Polk 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items o draft-simpson-tcpct-01 TCP Cookie Transactions (TCPCT) (Experimental) Token: Lars Eggert 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Decoupled Application Data Enroute (decade) Token: Alexey o Congestion Exposure (conex) Token: Lars 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE From dromasca@avaya.com Wed Apr 28 04:19:00 2010 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AEF3A6B9A; Wed, 28 Apr 2010 04:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxdYs5u8t9wo; Wed, 28 Apr 2010 04:18:57 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1F3FA3A6907; Wed, 28 Apr 2010 04:18:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="215548976" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Apr 2010 07:18:14 -0400 X-IronPort-AV: E=Sophos;i="4.52,288,1270440000"; d="scan'208";a="468483649" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Apr 2010 07:18:14 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2010 13:17:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: SIP Overload Control (soc) Thread-Index: AcrmL1PVeKox1SUqTKy0ZLuvh715sQAlPYuA From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [AAA-DOCTORS] FW: WG Review: SIP Overload Control (soc) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 11:19:00 -0000 Please let me know if you have any questions or concerns related to the formation of this WG.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 27, 2010 8:30 PM To: new-work@ietf.org Subject: WG Review: SIP Overload Control (soc)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 4, 2010. =20 SIP Overload Control (soc) --------------------------- Current Status: Proposed Working Group Last Modified: 2010-04-22 Chair(s) TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sip-overload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload=20 Archive: http://www.ietf.org/mail-archive/web/sip-overload/ Description of Working Group: As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, input/ output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, the goodput (effective application throughput not counting the overhead of retransmission and redundant data) of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. This is often called congestion collapse. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers.=20 Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their source or destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. The working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. Milestones: Sep 2010 Design Considerations to IESG for publication as Informational Dec 2010 Specification for a SIP overload control mechanism based on=20 implicit/explicit feedback to IESG for publication as Proposed=20 Standard May 2011 Specification for a SIP load filtering mechaism to IESG for=20 publication as Proposed Standard