From rtg-dir-bounces@ietf.org Mon May 08 07:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3TD-0005rP-2O; Mon, 08 May 2006 07:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3TB-0005qa-J8 for rtg-dir@ietf.org; Mon, 08 May 2006 07:00:05 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd3T9-0008Su-7t for rtg-dir@ietf.org; Mon, 08 May 2006 07:00:05 -0400 Received: from frogbits.attlabs.att.com (frogbits.attlabs.att.com [135.197.129.124]) by mail-green.research.att.com (Postfix) with ESMTP id AA2E686BD for ; Mon, 8 May 2006 07:00:02 -0400 (EDT) Received: from frogbits.attlabs.att.com (localhost [127.0.0.1]) by frogbits.attlabs.att.com (8.13.4/8.13.4) with ESMTP id k48B01fi046591 for ; Mon, 8 May 2006 04:00:01 -0700 (PDT) (envelope-from fenner@frogbits.attlabs.att.com) Received: (from fenner@localhost) by frogbits.attlabs.att.com (8.13.4/8.13.4/Submit) id k48B01PS046590 for rtg-dir@ietf.org; Mon, 8 May 2006 04:00:01 -0700 (PDT) (envelope-from fenner) Date: Mon, 8 May 2006 04:00:01 -0700 (PDT) Message-Id: <200605081100.k48B01PS046590@frogbits.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Subject: IESG agenda for 2006-05-11 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2006-05-11). Updated 2:2:24 EDT, May 8, 2006 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date RTG Routing IPv6 with IS-IS (Proposed Standard) - 1 of 7 draft-ietf-isis-ipv6-06.txt [Open Web Ballot] Token: Bill Fenner Definitions of Managed Objects for Asymmetric OPS Digital Subscriber Line 2 (ADSL2) (Proposed Standard) - 2 of 7 draft-ietf-adslmib-adsl2-07.txt [Open Web Ballot] Note: PROTO shpeherd: Menachem.Dodge@ecitele.com Token: Dan Romascanu OPS Mar 8 MIB for Fibre-Channel's Fabric Shortest Path First Protocol (Proposed Standard) - 3 of 7 draft-ietf-imss-fc-fspf-mib-03.txt [Open Web Ballot] Token: Dan Romascanu OPS Mar 8 Fibre-Channel Routing Information MIB (Proposed Standard) - 4 of 7 draft-ietf-imss-fc-rtm-mib-04.txt [Open Web Ballot] Token: Dan Romascanu RAI A Document Format for Expressing Privacy Preferences (Proposed Standard) - 5 of 7 draft-ietf-geopriv-common-policy-09.txt Token: Cullen Jennings Link Management Protocol (LMP) Management RTG Information Base (MIB) (Proposed Standard) - 6 of 7 draft-ietf-ccamp-rfc4327bis-01.txt [Open Web Ballot] Note: [Note: IETF Last Call ends 5/9, 2 days before the telechat; while I don't expect any Last Call comments if there are any substantive ones I may remove it from the telechat to deal with them] Token: Bill Fenner APP SIEVE Email Filtering: IMAP flag Extension (Proposed Standard) - 7 of 7 draft-ietf-sieve-imapflags-04.txt [Open Web Ballot] Token: Lisa Dusseault 2.1.2 Returning Item Area Date RTG Multiprotocol Extensions for BGP-4 (Draft Standard) - 1 of 2 draft-ietf-idr-rfc2858bis-10.txt [Open Web Ballot] Token: Bill Fenner Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical RTG Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (Proposed Standard) - 2 of 2 draft-ietf-ccamp-rfc3946bis-01.txt [Open Web Ballot] Token: Ross Callon 2.2 Individual Submissions 2.2.1 New Item Area Date IPsec Security Policy Database SEC Configuration MIB (Proposed Standard) - 1 of 3 draft-ietf-ipsp-spd-mib-06.txt [Open Web Ballot] Token: Russ Housley GEN The Base16, Base32, and Base64 Data Encodings (Proposed Standard) - 2 of 3 draft-josefsson-rfc3548bis-03.txt [Open Web Ballot] Token: Ted Hardie TSV Example media types for use in documentation (Proposed Standard) - 3 of 3 draft-taylor-types-example-03.txt [Open Web Ballot] Token: Magnus Westerlund 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date Evaluation of existing Routing Protocols RTG against ASON routing requirements (Informational) - 1 of 2 draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt [Open Web Ballot] Token: Ross Callon SEC Design of the MOBIKE Protocol (Informational) - 2 of 2 draft-ietf-mobike-design-08.txt [Open Web Ballot] Note: PROTO Shepherd: Paul Hoffman Token: Russ Housley 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date SEC ECP Groups For IKE and IKEv2 (Informational) - 1 of 3 draft-ietf-ipsec-ike-ecp-groups-02.txt [Open Web Ballot] Token: Russ Housley SEC IKEv2 Clarifications and Implementation Guidelines (Informational) - 2 of 3 draft-eronen-ipsec-ikev2-clarifications-09.txt [Open Web Ballot] Token: Russ Housley APP A URN Namespace for ASD Specification 1000D (Informational) - 3 of 3 draft-rushing-s1000d-urn-00.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date INT Apr 19 IP over IEEE 802.16 Networks (16ng) - 1 of 1 Token: Jari 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Tue May 16 14:53:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4fu-0007YC-LP; Tue, 16 May 2006 14:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4ft-0007Xr-Cf; Tue, 16 May 2006 14:53:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4fr-0006cY-3l; Tue, 16 May 2006 14:53:41 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 14:53:39 -0400 X-IronPort-AV: i="4.05,134,1146456000"; d="scan'208"; a="88689477:sNHT28470500" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4GIrcvF011905; Tue, 16 May 2006 14:53:38 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 14:53:38 -0400 Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 14:53:37 -0400 Message-ID: <446A1FB1.5060909@cisco.com> Date: Tue, 16 May 2006 14:53:37 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner , Ross Callon Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 18:53:37.0861 (UTC) FILETIME=[0A7B6F50:01C6791A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: OSPF List , IESG Secretary , rtg-dir@ietf.org Subject: OSPFv3 Graceful Restart - draft-ietf-ospf-ospfv3-graceful-restart-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org The OSPF WG last call has ended and the comments have been addressed. http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-04.txt Please begin the AD evaluation on this document. Thanks, Acee From rtg-dir-bounces@ietf.org Mon May 22 07:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi88r-0001zk-85; Mon, 22 May 2006 07:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi88q-0001wY-8B for rtg-dir@ietf.org; Mon, 22 May 2006 07:00:04 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi88o-00029x-RL for rtg-dir@ietf.org; Mon, 22 May 2006 07:00:04 -0400 Received: from frogbits.attlabs.att.com (frogbits.attlabs.att.com [135.197.129.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 47D16147B1A for ; Mon, 22 May 2006 07:00:02 -0400 (EDT) Received: from frogbits.attlabs.att.com (localhost [127.0.0.1]) by frogbits.attlabs.att.com (8.13.4/8.13.4) with ESMTP id k4MB01hr054459 for ; Mon, 22 May 2006 04:00:01 -0700 (PDT) (envelope-from fenner@frogbits.attlabs.att.com) Received: (from fenner@localhost) by frogbits.attlabs.att.com (8.13.4/8.13.4/Submit) id k4MB0044054458 for rtg-dir@ietf.org; Mon, 22 May 2006 04:00:00 -0700 (PDT) (envelope-from fenner) Date: Mon, 22 May 2006 04:00:00 -0700 (PDT) Message-Id: <200605221100.k4MB0044054458@frogbits.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Subject: IESG agenda for 2006-05-25 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2006-05-25). Updated 2:2:26 EDT, May 22, 2006 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date TSV NAT Behavioral Requirements for Unicast UDP (BCP) - 1 of 4 draft-ietf-behave-nat-udp-06.txt [Open Web Ballot] Note: Dan Wing in sheperd IETF Last call ends 2006-05-23 Token: Magnus Westerlund RAI Two-Document ballot: [Open Web Ballot] - 2 of 4 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (Proposed Standard) - 2 of 4 draft-ietf-avt-rfc2833bis-13.txt Note: PROTO shepherd Colin Perkins Definition of Events For Modem, FAX, and Text Telephony Signals (Proposed Standard) draft-ietf-avt-rfc2833bisdata-06.txt Note: PROTO shepherd magnus.westerlund@ericsson.com Token: Cullen Jennings TSV Two-Document ballot: [Open Web Ballot] - 3 of 4 DDP/RDMAP Security (Proposed Standard) - 3 of 4 draft-ietf-rddp-security-09.txt Note: PROTO Sherpherd: David Black (Black_David@emc.com) Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) (Informational) draft-ietf-rddp-applicability-06.txt Note: PROTO Shepherd: David Black (Black_David@emc.com) Token: Jon Peterson Encapsulation Methods for Transport of PPP/ INT HDLC Over MPLS Networks (Proposed Standard) - 4 of 4 draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt [Open Web Ballot] Token: Mark Townsley 2.1.2 Returning Item Area Date Classless Inter-Domain Routing (CIDR): The OPS Internet Address Assignment and Aggregation Plan (BCP) - 1 of 1 draft-ietf-grow-rfc1519bis-04.txt [Open Web Ballot] Note: Geoff Huston is the proto shepherd Token: David Kessens 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item Area Date Experimental Values In IPv4, IPv6, ICMPv4, INT ICMPv6, UDP and TCP Headers (Proposed Standard) - 1 of 1 draft-fenner-iana-exp-2780-04.txt [Open Web Ballot] Note: 3/20/06: Waiting for -03 version from Bill Fenner to address discusses. 5/5/06: Waiting for Mark to remove his Discuss and/or talk to Bill. 16/5/06: Bill submits a new revision, document placed on next telechat agenda. Token: Jari Arkko 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date Benchmarking Terminology for Resource OPS Jan 2 Reservation Capable Routers (Informational) - 1 of 8 draft-ietf-bmwg-benchres-term-07.txt [Open Web Ballot] Note: Proto Spepherd: Al Morton Token: David Kessens RTG PCE Communication Protocol Generic Requirements (Informational) - 2 of 8 draft-ietf-pce-comm-protocol-gen-reqs-05.txt [Open Web Ballot] Token: Ross Callon RTG Requirements for Path Computation Element (PCE) Discovery (Informational) - 3 of 8 draft-ietf-pce-discovery-reqs-04.txt [Open Web Ballot] Token: Ross Callon TCP-Friendly Multicast Congestion Control TSV (TFMCC): Protocol Specification (Experimental) - 4 of 8 draft-ietf-rmt-bb-tfmcc-07.txt [Open Web Ballot] Note: PROTO shepherd: lorenzo vicisano lorenzo@cisco.com IETF last call ends 24th of May Token: Magnus Westerlund Terminology for Benchmarking Network-layer OPS Traffic Control Mechanisms (Informational) - 5 of 8 draft-ietf-bmwg-dsmterm-12.txt [Open Web Ballot] Note: Al Morton is the proto shepherd Token: David Kessens OPS IPv6 Transition/Co-existence Security Considerations (Informational) - 6 of 8 draft-ietf-v6ops-security-overview-04.txt [Open Web Ballot] Note: PROTO-SHEPHERDING WG chairs: Kurt Erik Lindqvist, kurtis@kurtis.pp.se Token: David Kessens OPS ISP IPv6 Deployment Scenarios in Broadband Access Networks (Informational) - 7 of 8 draft-ietf-v6ops-bb-deployment-scenarios-04.txt [Open Web Ballot] Note: SHEPHERDING WG chair: Kurt Erik Lindqvist, kurtis@kurtis.pp.se Token: David Kessens OPS IPv6 Network Architecture Protection (Informational) - 8 of 8 draft-ietf-v6ops-nap-02.txt [Open Web Ballot] Note: PROTO-SHEPHERDING WG chair: Kurt Erik Lindqvist, kurtis@kurtis.pp.se Token: David Kessens 3.1.2 Returning Item Area Date INT Accommodating an MTU/MRU greater than 1492 in PPPoE (Informational) - 1 of 1 draft-arberg-pppoe-mtu-gt1492-03.txt [Open Web Ballot] Token: Mark Townsley 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date The Tao of IETF - A Novice's Guide to the GEN Internet Engineering Task Force (Informational) - 1 of 2 draft-hoffman-taobis-07.txt [Open Web Ballot] Token: Brian Carpenter SEC IKEv2 Clarifications and Implementation Guidelines (Informational) - 2 of 2 draft-eronen-ipsec-ikev2-clarifications-09.txt [Open Web Ballot] Token: Russ Housley 3.2.2 Returning Item Area Date Experimental Procedure for Long Term GEN Suspensions from Mailing Lists (Experimental) - 1 of 1 draft-hartman-mailinglist-experiment-03.txt [Open Web Ballot] Note: Last call ended March 15 Token: Brian Carpenter 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item Area Date GEN Server/Application State Protocol v1 (Informational) - 1 of 1 draft-bivens-sasp-03.txt [Open Web Ballot] Token: Magnus Westerlund 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date INT Apr 19 IP over IEEE 802.16 Networks (16ng) - 1 of 1 Token: Jari 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Wed May 24 10:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiuhV-0005lw-TY; Wed, 24 May 2006 10:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiuh9-0005QA-Rj; Wed, 24 May 2006 10:50:43 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiuh7-0002rJ-LI; Wed, 24 May 2006 10:50:43 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id B52198661; Wed, 24 May 2006 10:50:40 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id k4OEoeIT014480; Wed, 24 May 2006 07:50:40 -0700 From: Bill Fenner Message-Id: <200605241450.k4OEoeIT014480@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org, rcallon@juniper.net Date: Wed, 24 May 2006 07:50:40 -0700 Versions: dmail (linux) 2.7/makemail 2.14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: Bill on vacation Wed-Mon X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org If you need anything from me before Tuesday, please let me know with a short message to my pager: fenner@tmomail.net . I'll be driving from California to Pennsylvania (some vacation, eh) - http://pegland.net/EastCoastRoadTrip2006/ Bill From rtg-dir-bounces@ietf.org Fri May 26 18:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjlCg-0001FQ-Uv; Fri, 26 May 2006 18:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjlCQ-0001Er-Tr; Fri, 26 May 2006 18:54:30 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjlCP-0001gQ-HZ; Fri, 26 May 2006 18:54:30 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k4QMsT1Z045049; Fri, 26 May 2006 15:54:29 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.143]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4QMsR502349; Fri, 26 May 2006 15:54:27 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20060526184245.036bbe20@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 26 May 2006 18:52:45 -0400 To: rtg-chairs@ietf.org, rtg-dir@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: fenner@research.att.com, rcallon@juniper.net Subject: Thoughts on Progression of Routing Area Drafts X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org Bill and I have been thinking about how to speed up progression of routing area documents without adversely affecting quality, and would like to suggest two initiatives that we feel will help to improve document quality and speed up progression. We specifically would like to solicit comments from routing area WG chairs and from the routing area directorate on these ideas. First of all, we are requesting that when documents are submitted for publication, that the WG chairs answer the questions from the PROTO WG chair writeup in email to the ADs. The appropriate set of questions is found at: http://rtg.ietf.org/area/procedures/proto_wgchair_writeup While answering these questions is optional, it will help the ADs to review documents and submit them to the IESG more quickly, and thus is strongly recommended (and if not already completed, would be helpful even for documents already submitted). Also, we would like to consider having WG chairs solicit document review at a relatively early stage. The idea is that the WG chairs would determine when documents are ready for wider review (this could occur any time between publication of a -00 working group document, and working group last call, and should occur when documents are relatively complete), and would send a pointer to the document to the routing area directorate and ask for review. The intention is that by having documents reviewed by experienced routing experts prior to submission, this will improve quality, and thereby make AD and IESG review quicker and easier (and hopefully also improve quality of the eventual RFC). If the WG chairs feel that there are issues that warrant review by other area directorates, then we can help coordinate with the ADs from other areas. One question is who should the review go back to? It has been suggested that the reviews go to both working group chairs and authors, and that the WG chairs help the authors to respond appropriately to comments (which includes avoiding over-reaction, with the understanding that there will be some cases where some members of the routing area directorate may disagree with document authors, and this does not necessarily imply that the document always needs to be changed). Comments are appreciated. Thanks, Ross and Bill From rtg-dir-bounces@ietf.org Mon May 29 21:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksjL-0005Dn-Bd; Mon, 29 May 2006 21:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjz7I-0000cf-20; Sat, 27 May 2006 09:46:08 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjz7E-0007NR-Hp; Sat, 27 May 2006 09:46:08 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fjz7J-0001ar-00; Sat, 27 May 2006 14:46:09 +0100 Received: from your029b8cecfe ([217.158.132.223] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 May 2006 14:45:50 +0100 Message-ID: <01cf01c68193$d59c8c60$08849ed9@your029b8cecfe> From: "Adrian Farrel" To: , , "Ross Callon" References: <5.0.0.25.2.20060526184245.036bbe20@zircon.juniper.net> Date: Sat, 27 May 2006 14:43:14 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 27 May 2006 13:45:52.0374 (UTC) FILETIME=[DEBCF960:01C68193] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 29 May 2006 21:09:06 -0400 Cc: fenner@research.att.com, rcallon@juniper.net Subject: Re: Thoughts on Progression of Routing Area Drafts X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org Hi Ross'n'Bill, > Bill and I have been thinking about how to speed up progression of routing > area documents without adversely affecting quality, That's good. > First of all, we are requesting that when documents are submitted for > publication, that the WG chairs answer the questions from the PROTO > WG chair writeup in email to the ADs. The appropriate set of questions > is found at: http://rtg.ietf.org/area/procedures/proto_wgchair_writeup > While answering these questions is optional, it will help the ADs to > review documents and submit them to the IESG more quickly, and > thus is strongly recommended (and if not already completed, would > be helpful even for documents already submitted). No problem with formalising what has become a defacto process for CCAMP, L1VPN and PCE. FWIW, a typical write-up takes about 15 minutes, tops. > Also, we would like to consider having WG chairs solicit document > review at a relatively early stage. The idea is that the WG chairs would > determine when documents are ready for wider review (this could occur > any time between publication of a -00 working group document, and > working group last call, and should occur when documents are relatively > complete), and would send a pointer to the document to the routing area > directorate and ask for review. The intention is that by having documents > reviewed by experienced routing experts prior to submission, this will > improve quality, and thereby make AD and IESG review quicker and > easier (and hopefully also improve quality of the eventual RFC). Of course, all review input is welcome, and having a pool of experts available to call on is great. But is this something we would do for every I-D or just those with some sort of cross-over? For specialist I-Ds produced by a WG either: 1. The expertise is already in the WG 2. The Directorate member who does the review is already in the WG. Perhaps I'm missing something? > If the WG chairs feel that there are issues that warrant review by other > area directorates, then we can help coordinate with the ADs from other > areas. That coordination would be good, otherwise we just float requests into the void. > One question is who should the review go back to? It has been suggested > that the reviews go to both working group chairs and authors, and that > the WG chairs help the authors to respond appropriately to comments > (which includes avoiding over-reaction, with the understanding that there > will be some cases where some members of the routing area directorate > may disagree with document authors, and this does not necessarily > imply that the document always needs to be changed). I strongly feel that WG I-Ds are the product of the WG. Therefore, all comments should be addressed to the WG mailing list. This then makes it the responsiblity of the chiars to moderate the input and guide the responses. Cheers, Adrian From rtg-dir-bounces@ietf.org Wed May 31 15:06:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlW1j-0002uM-JV; Wed, 31 May 2006 15:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlW1N-0002s5-IQ; Wed, 31 May 2006 15:06:21 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlW1M-0004K8-6e; Wed, 31 May 2006 15:06:21 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k4VJ6J1Z097833; Wed, 31 May 2006 12:06:19 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.105]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4VJ6H573821; Wed, 31 May 2006 12:06:18 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20060531145607.047c6460@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 31 May 2006 15:06:14 -0400 To: Adrian Farrel , , From: Ross Callon In-Reply-To: <01cf01c68193$d59c8c60$08849ed9@your029b8cecfe> References: <5.0.0.25.2.20060526184245.036bbe20@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: Re: Thoughts on Progression of Routing Area Drafts X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-dir-bounces@ietf.org At 02:43 PM 5/27/2006 +0100, Adrian Farrel wrote: >... >>Also, we would like to consider having WG chairs solicit document >>review at a relatively early stage. The idea is that the WG chairs would >>determine when documents are ready for wider review (this could occur >>any time between publication of a -00 working group document, and >>working group last call, and should occur when documents are relatively >>complete), and would send a pointer to the document to the routing area >>directorate and ask for review. The intention is that by having documents >>reviewed by experienced routing experts prior to submission, this will >>improve quality, and thereby make AD and IESG review quicker and >>easier (and hopefully also improve quality of the eventual RFC). > >Of course, all review input is welcome, and having a pool of experts >available to call on is great. But is this something we would do for every >I-D or just those with some sort of cross-over? For specialist I-Ds >produced by a WG either: >1. The expertise is already in the WG >2. The Directorate member who does the review is already > in the WG. > >Perhaps I'm missing something? Well, I agree that in most (or all?) cases some members of the routing area directorate are likely to be participating in the WG effort. However, there are likely to be other members who either have been busy elsewhere, or who are not paying close enough attention to know when the drafts have gotten to the point that it is appropriate to spend the time to do a detailed review. Also, the directorate is more likely to actually contribute if explicitly asked to do so. Having more than one person review the document can be valuable, and the small set of people who have been working on a document from day one are likely to be so close to the document that they can miss errors (if only due to having been looking at the error every day for so long). The hope is that by having detailed review by a wider set of experts, prior to submission to the IESG, then many of the things that the IESG catches will have been fixed ahead of time (hopefully both speeding up review and improving eventual quality). I will agree that at least initially this would be an experiment. >>...One question is who should the review go back to? ... > >I strongly feel that WG I-Ds are the product of the WG. Therefore, all >comments should be addressed to the WG mailing list. This then makes it >the responsiblity of the chiars to moderate the input and guide the responses. I think that this is sensible. Perhaps editorial nits should go to the chairs and authors (we don't need 200 people debating the relative meaning of "affect" versus "effect"), and any comments of substance should go to the full WG. Ross