From db3546@att.com Fri Aug 9 08:57:31 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C592611E8192 for ; Fri, 9 Aug 2013 08:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.109 X-Spam-Level: X-Spam-Status: No, score=-105.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 qr0+Pt7J2JFi for ; Fri, 9 Aug 2013 08:57:25 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7821F94FA for ; Fri, 9 Aug 2013 08:50:14 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6bf05025.0.1342448.00-493.3766845.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 09 Aug 2013 15:50:14 +0000 (UTC) X-MXL-Hash: 52050fb67ab6b77c-9055d604e1907b47ed7b5a7e8c9d3d970c890f84 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79FoDC6008593 for ; Fri, 9 Aug 2013 11:50:14 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r79Fo9fL008569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Aug 2013 11:50:12 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Fri, 9 Aug 2013 15:49:52 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 11:49:52 -0400 From: "BRUNGARD, DEBORAH A" To: "routing-discussion@ietf.org" Subject: Draft RA Minutes available Thread-Topic: Draft RA Minutes available Thread-Index: Ac6VGBXmnVdRQZaUSxCarYjSJ+Ba5Q== Date: Fri, 9 Aug 2013 15:49:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8355E00MISOUT7MSGUSR9OIT_" 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.20.146] X-AnalysisOut: [v=2.0 cv=IuiphsDg c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=wprclI3mA-8A:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=RrM97I9IWwLljWQlSksA:9 a=CjuIK1q_8ugA:10 a=kk31F_J] X-AnalysisOut: [wVz8A:10 a=_tvmUrcsnrYA:10 a=sm8-sL-lF3q0XnXJMn8A:9 a=_W_S] X-AnalysisOut: [_7VecoQA:10 a=frz4AuCg-hUA:10 a=S9Lg1WnX5smN1rQr:21] X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:57:31 -0000 --_000_F64C10EAA68C8044B33656FA214632C8355E00MISOUT7MSGUSR9OIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft RA minutes are available: http://www.ietf.org/proceedings/87/minutes/minutes-87-rtgarea Let me know if any comments. Thanks to all who sent in their summaries. Deborah --_000_F64C10EAA68C8044B33656FA214632C8355E00MISOUT7MSGUSR9OIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The draft RA minutes are available:
 
Let me know if any comments. Thanks to all who sent in their summaries= .
 
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C8355E00MISOUT7MSGUSR9OIT_-- From adrian@olddog.co.uk Tue Aug 20 09:56:18 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95F11E826A for ; Tue, 20 Aug 2013 09:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 M6Zk2oVLQ-vL for ; Tue, 20 Aug 2013 09:56:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC221F8607 for ; Tue, 20 Aug 2013 09:55:18 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KGtHt3002143 for ; Tue, 20 Aug 2013 17:55:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7KGtGv8002124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Aug 2013 17:55:17 +0100 From: "Adrian Farrel" To: Subject: FW: Internal WG Review: Active Queue Management and Packet Scheduling (aqm) Date: Tue, 20 Aug 2013 17:55:14 +0100 Message-ID: <00de01ce9dc6$0b71dce0$225596a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6dxZPL/Sob7eZIRiqROzj8kVL/gw== Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:56:19 -0000 Hi, There was a brief presentation on AQM at the Routing Area meeting in = Berlin (see the slides). This idea definitely impinges on people who make routers! A working group is being proposed. Please review the draft charter and = comment to me or the IESG with any issues. Note the deadline is just one week! Cheers, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of IESG > Secretary > Sent: 20 August 2013 17:33 > To: iesg@ietf.org; iab@iab.org > Subject: Internal WG Review: Active Queue Management and Packet = Scheduling > (aqm) >=20 > A new IETF working group is being considered in the Transport Area. = The > draft charter for this working group is provided below for your review > and comment. >=20 > Review time is one week. >=20 > The IETF Secretariat >=20 > Active Queue Management and Packet Scheduling (aqm) > -------------------------------------------------- > Current Status: Proposed Working Group >=20 > Chairs: TBD > Area Director: Martin Stiemerling >=20 > Mailing List > Address: aqm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/aqm > Archive: = http://www.ietf.org/mail-archive/web/aqm/current/maillist.html >=20 > Charter: >=20 > Internet routers, lower-layer switches, end-host operating > systems, device drivers, and many types of additional > middleboxes include memory buffers in which they implement > queues to hold packets that require processing or otherwise > need to wait for forwarding to the next hop. >=20 > The queues are intended to absorb bursts of traffic that may > naturally occur, and avoid unneccessary losses. However, queues > also cause latency and jitter in the eventual arrival times of > packets. This can create issues and complications for interactive > applications. >=20 > Extremely large unmanaged buffers have been noticed in some > software and equipment. When these buffers fill, interactive > applications and other traffic can be severely impacted or > completely broken, due to high and potentially oscillating delays. >=20 > The Active Queue Management and Packet Scheduling working group > (AQM) works on algorithms for managing queues in order to: >=20 > (1) minimize standing queues; helping to reduce delay for > interactive applications >=20 > (2) help flow sources control their sending rates without > unnecessary losses, e.g. through ECN >=20 > (3) consider the merits of various techniques to protect flows > from negative impacts of other more aggressive or misbehaving > flows >=20 > (4) help avoid global synchronization of flows sharing a > bottleneck >=20 > The AQM working group will publish Informational and Best Current > Practices documents that cover the design, use, and configuration > of algorithms for managing queues in Internet devices and software. > The scope includes both how to best configure existing equipment > and software, as well as recommendations on designing new equipment > and software. >=20 > The AQM working group will also publish algorithm specifications > that are found to be broadly applicable and beneficial. Evaluating > these algorithms shall be done in coordination with the Internet > Congestion Control Research Group (ICCRG) in order to select and > assess the relevant criteria, scenarios, and metrics. >=20 > The working group will also explore the merits of whether to > isolate flows, and mechanisms for performing this function. Note > that isolation and potentially policing of flows implies some policy > beyond what is required to simply minimize queues. This topic > requires significant attention in the working group. >=20 > AQM algorithms do not have to be implemented universally in order > to be effective. Specifications will aid in producing proper > implementations that avoid potential ambiguities and corner cases. > "Interoperability" of algorithms and implementations of them is > not the reason for creating these specifications; correctness is > the primary motivation. >=20 > The working group will not make changes to ECN, DiffServ, or other > IETF protocols, though existing ECN, DiffServ, and other mechanisms > may be used within the algorithms proposed. As their implementation > is likely to be entwined with AQM algorithms, there is expected to = be > close coordination between both TSVWG and AQM groups. >=20 > Many AQM algorithms have been proposed in academic literature, but > a smaller number are widely implemented and deployed. The goal of = the > working group is to produce recommendations that will actually be = used, > and algorithms that will actually be implemented, deployed in = equipment, > and enabled. Towards these ends, the group actively encourages > participation from operators and implementers, and will coordinate = with > the IETF OPS area and other relevant parts of the IETF and Internet > community. Wider research and evaluation of AQM mechanisms shall be > coordinated with the IRTF/ICCRG, and significant participation in = this > WG from the academic and research community is highly desirable, = when it > is directly relevant to implementation and deployment. >=20 > Combined Queue Management / Packet Scheduling algorithms are = in-scope, > provided their benefit have been evaluated against the established > requirements for an AQM algorithm. It is expected that some classes = of > algorithms will focus on software implementations, while others on > existing or new hardware deployments, and algorithms may be specific > to distinct scenarios. >=20 > Proposed Milestones: >=20 > Jan 2014 Submit AQM recommendations to IESG for publication as BCP > obsoleting RFC 2309 > Jul 2014 Submit AQM evaluation guidelines to IESG for publication as > Informational > Dec 2014 Submit first algorithm specification to IESG for publication > as Proposed Standard From adrian@olddog.co.uk Fri Aug 23 02:53:00 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12B21F9AD2 for ; Fri, 23 Aug 2013 02:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799] 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 kwYMuhXb7bHm for ; Fri, 23 Aug 2013 02:52:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00621F9B58 for ; Fri, 23 Aug 2013 02:52:55 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7N9qrIC011978 for ; Fri, 23 Aug 2013 10:52:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7N9qp51011944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 23 Aug 2013 10:52:52 +0100 From: "Adrian Farrel" To: References: <20130822235511.22351.9423.idtracker@ietfa.amsl.com> In-Reply-To: <20130822235511.22351.9423.idtracker@ietfa.amsl.com> Subject: FW: 88th IETF - Working Group/BOF/IRTF Scheduling Date: Fri, 23 Aug 2013 10:52:48 +0100 Message-ID: <041301ce9fe6$868c7710$93a56530$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgSRCmhI+RGyuIT/6e3eDBZXbaCZn/OetQ Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 09:53:00 -0000 Here we go again. Only a few weeks back from Berlin and it is time to prepare for = Vancouver. Adrian > -----Original Message----- > From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On = Behalf > Of IETF Agenda > Sent: 23 August 2013 00:55 > To: Working Group Chairs > Cc: irsg@irtf.org > Subject: 88th IETF - Working Group/BOF/IRTF Scheduling >=20 >=20 > ----------------------------------------------------------------- > 88th IETF =E2=80=93 Vancouver, BC, Canada > Meeting Dates: November 3 =E2=80=93 8, 2013 > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday afternoon = (13:30). >=20 > We are accepting scheduling requests for all Working Groups, BOFs, and = Research > Groups starting today. The milestones and deadlines for = scheduling-related > activities are as follows: >=20 > NOTE: cutoff dates are subject to change. >=20 > - 2013-08-19 (Week of): Working Group and BOF scheduling begins. To = request a > Working Group session, use the IETF Meeting Session Request Tool. = (updated > from 5 August). > - 2013-09-23 (Monday): Cutoff date for requests to schedule Working = Group > meetings at UTC 24:00. To request a Working Group session, use the = IETF > Meeting Session Request Tool. > - 2013-09-23 (Monday): Cutoff date for BOF proposal requests to Area = Directors > at UTC 24:00. To request a BOF, please see instructions on Requesting = a BOF. > - 2013-09-26 (Thursday): Cutoff date for Area Directors to approve = BOFs at UTC > 24:00. > - 2013-10-03 (Thursday): Preliminary agenda published for comment. > - 2013-10-07 (Monday): Cutoff date for requests to reschedule Working = Group > and BOF meetings UTC 24:00. > - 2013-10-11 (Friday): Final agenda to be published. > - 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC = 24:00, > upload using IETF Meeting Materials Management Tool. > - 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, > upload using IETF Meeting Materials Management Tool. > - 2013-12-06 (Friday): Proceedings submission cutoff date by UTC = 24:00, upload > using IETF Meeting Materials Management Tool. > - 2013-12-25 (Wednesday): Proceedings submission corrections cutoff = date by > UTC 24:00, upload using IETF Meeting Materials Management Tool. >=20 > Submitting Requests for Working Group and BOF Sessions >=20 > Please submit requests to schedule your Working Group sessions using = the "IETF > Meeting Session Request Tool," a Web-based tool for submitting all of = the > information that the Secretariat requires to schedule your sessions. >=20 > The URL for the tool is: >=20 > https://pub.ietf.org/sreq/ >=20 > Please send requests to schedule your BOF sessions to agenda@ietf.org. = Please > include the acronym of your BOF in the subject line of the message, = and include > all of the information specified in item (4) of "Requesting Meeting = Sessions at > IETF Meetings" in the body. (This document is included below.) >=20 > Submitting Session Agendas >=20 > For the convenience of meeting attendees, we ask that you submit the = agendas > for your Working Group sessions as early as possible. Draft Working = Group > agendas are due Wednesday, October 23rd, 2013 at UTC 24:00. Revised = Working > Group agendas are due no later than Monday, October 28, 2013 at UTC = 24:00. > The proposed agenda for a BOF session should be submitted along with = your > request for a session. Please be sure to copy your Area Director on = that > message. >=20 > Please submit the agendas for your Working Group sessions using the = "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the = community > before, during, and after an IETF meeting. If you are a BOF chair, = then you may > use the tool to submit a revised agenda as well as other materials for = your BOF > once the BOF has been approved. >=20 > The URL for the tool is: >=20 > https://pub.ietf.org/proceedings/ >=20 > Additional information about this tool is available at: >=20 > http://www.ietf.org/instructions/meeting_materials_tool.html >=20 > Agendas submitted via the tool will be available to the public on the = "IETF > Meeting Materials" webpage as soon as they are submitted. >=20 > The URL for the "IETF 88 Meeting Materials" Web page is: >=20 > https://datatracker.ietf.org/meeting/88/materials.html >=20 > If you are a Working Group chair, then you already have accounts on = the "IETF > Meeting Session Request Tool" and the "IETF Meeting Materials = Management > Tool." The same User ID and password will work for both tools. If = you are a BOF > chair who is not also a Working Group chair, then you will be given an = account on > the "IETF Meeting Materials Management Tool" when your BOF has been > approved. If you require assistance in using either tool, or wish to = report a bug, > then please send a message to: > ietf-action@ietf.org. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 88 is presented below: >=20 > 1. Requests to schedule Working Group sessions should be submitted = using the > "IETF Meeting Session Request Tool," a Web-based tool for submitting = all of the > information required by the Secretariat to schedule your sessions. = The URL for > the tool is: >=20 > https://pub.ietf.org/sreq/ >=20 > Instructions for using the tool are available at: >=20 > http://www.ietf.org/instructions/session_request_tool_instruction.html >=20 > If you require an account on this tool, or assistance in using it, = then please send a > message to ietf-action@ietf.org. If you are unable to use the tool, = then you may > send your request via e-mail to agenda@ietf.org, with a copy to the = appropriate > Area Director(s). >=20 > Requests to schedule BOF sessions must be sent to agenda@ietf.org with = a copy > to the appropriate Area Director(s). >=20 > When submitting a Working Group or BOF session request by e-mail, = please > include the Working Group or BOF acronym in the Subject line. >=20 > 2. BOFs will NOT be scheduled unless the Area Director approves the = BOF. The > proponents behind a BOF need to contact a relevant Area Director, = preferably > well in advance of the BOF approval deadline date. The AD needs to = have the full > name of the BOF, its acronym, suggested names of chairs, an agenda, = full > description of the BOF and the information covered in item 4. Please = read RFC > 5434 for instructions on how to drive a successful BOF effort. The = approval > depends on, for instance, Internet-Drafts and list discussion on the = suggested > topic. BOF agenda requests, if approved, will be submitted to the IETF = Secretariat > by the ADs. >=20 > 3. A Working Group may request either one or two sessions. If your = Working > Group requires more than two sessions, then your request must be = approved by > an Area Director. Additional sessions will be assigned, based on = availability, after > Monday, October 7, 2013, the cut-off date for requests to reschedule a = session. >=20 > 4. You MUST provide the following information before a Working Group = or BOF > session will be scheduled: >=20 > a. Working Group or BOF full name with acronym in brackets: >=20 > b. AREA under which Working Group or BOF appears: >=20 > c. CONFLICTS you wish to avoid, please be as specific as possible: >=20 > d. Expected Attendance: >=20 > e. Special requests: >=20 > f. Number of sessions: >=20 > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours >=20 > For more information on scheduling Working Group and BOF sessions, = please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and = Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D > For your convenience please find here a list of the IETF Area = Directors with their > e-mail addresses: >=20 > IETF Chair > Jari Arkko >=20 > Applications Area (app) > Barry Leiba > Pete Resnick >=20 > Internet Area (int) > Brian Haberman > Ted Lemon >=20 > Operations & Management Area (ops) > Benoit Claise > Joel Jaeggli >=20 > Real-time Applications and Infrastructure Area (rai) > Gonzalo Camarillo > Richard Barnes >=20 > Routing Area (rtg) > Stewart Bryant > Adrian Farrel >=20 > Security Area (sec) > Stephen Farrell > Sean Turner >=20 > Transport Area (tsv) > Martin Stiemerling > Spencer Dawkins > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > 87th IETF Meeting Attendance Numbers >=20 > 6lo - 127 > 6man - 166 > 6tsch BoF - 101 > abfab - 22 > alto - 73 > appsawg - 98 > aqm BoF - 86 > avtcore - 64 > avtext - 37 > behave - 61 > bmwg - 20 > ccamp - 53 > ccamp (2nd session) - 59 > cdni - 73 > cdni (2nd session) - 38 > cfrg (RG) - 40 > clue - 46 > clue (2nd session) - 33 > conex - 67 > core - 107 > core (2nd session) - 46 > dane - 92 > dhc (joint session with sunset4) - 110 > dhc (2nd session) - 54 > dice BoF - 112 > dime - 17 > dmarc BoF - 47 > dmm - 30 > dnsop - 116 > dnssdext BoF - 137 > dtnrg (RG) - 44 > dtnrg (RG) (2nd session) - 44 > ecrit - 45 > eman - 43 > emu - 36 > forces - 69 > grow - 63 > homenet - 128 > httpauth - 59 > httpbis - 93 > httpbis (2nd session) - 72 > i2rs - 257 > iccrg (RG) - 68 > iccrg (RG) (2nd session) - 77 > icnrg (RG) - 86 > idr - 64 > insipid - 35 > intarea (AG) - 93 > ipfix - 35 > ippm - 64 > iprbis (BoF) - 26 > ipsecme - 48 > IRTF Open Meeting - 121 > isis - 28 > jose - 55 > json - 36 > karp - 31 > kitten - 25 > l2vpn - 64 > l3vpn - 81 > lmap - 76 > lwig - 55 > manet - 49 > mboned - 12 > mif - 41 > mile - 43 > mmusic - 76 > mmusic (2nd session) - 85 > mpls - 129 > mpls (2nd session) - 78 > mptcp - 108 > multimob - 29 > ncrg (RG) - 38 > netconf - 52 > netext - 40 > netmod - 52 > nfsv4 - 22 > nmrg (RG) - 59 > nsc BoF - 281 > nvo3 - 182 > nwcrg (PRG) - 49 > oauth - 62 > opsawg - 62 > opsec - 52 > ospf - 21 > p2psip - 20 > paws - 22 > pce - 82 > pcp - 29 > pcp (2nd session) - 40 > pim - 18 > posh BoF - 87 > ppsp - 14 > precis - 19 > pwe3 - 33 > radext - 22 > rmcat - 91 > rtcweb - 127 > rtcweb (2nd session) - 132 > rtgarea (AG) - 118 > rtgwg - 51 > saag (AG) - 148 > sacm - 45 > scim - 26 > sdnrg (RG) - 288 > sidr - 62 > sidr (2nd session) - 58 > siprec - 27 > softwire - 78 > status BoF - 214 > stir - 126 > stox - 34 > sunset4 - 99 > sunset4 (joint session with dhc) - 110 > tcmtf BoF - 89 > tcpm - 68 > tictoc - 22 > tls - 63 > trill - 31 > tsvarea (AG) - 112 > tsvwg - 59 > tsvwg (2nd session) - 50 > urnbis - 9 > v6ops - 110 > v6ops (2nd session) - 118 > websec - 68 > weirds - 65 > xrblock - 26 From adrian@olddog.co.uk Wed Aug 28 04:49:39 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE021F9E80 for ; Wed, 28 Aug 2013 04:49:39 -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=[AWL=0.000, 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 ydPLMy-6-uf5 for ; Wed, 28 Aug 2013 04:49:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7221F9D68 for ; Wed, 28 Aug 2013 04:49:31 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7SBnUIu032031 for ; Wed, 28 Aug 2013 12:49:31 +0100 Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r7SBnPZN031972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Aug 2013 12:49:29 +0100 From: "Adrian Farrel" To: Subject: New rules for IANA early allocation Date: Wed, 28 Aug 2013 12:49:26 +0100 Message-ID: <052a01cea3e4$a8470260$f8d50720$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6j5FenyiejcAjDRzSqZP7ALlhjmA== Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:49:39 -0000 All, Please review this document during IETF last call. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 27 August 2013 22:52 > To: IETF-Announce > Subject: Last Call: (Early IANA Allocation of > Standards Track Code Points) to Best Current Practice > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Early IANA Allocation of Standards Track Code Points' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > This memo describes the process for early allocation of code points > by IANA from registries for which "Specification Required", "RFC > Required", "IETF Review", or "Standards Action" policies apply. This > process can be used to alleviate the problem where code point > allocation is needed to facilitate desired or required implementation > and deployment experience prior to publication of an RFC that would > normally trigger code point allocation. > > This document obsoletes RFC 4020. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D.