From spencer@wonderhamster.org Tue Mar 3 12:46:31 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8823A6B05 for ; Tue, 3 Mar 2009 12:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.947, 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 Wp8mGncG1GRt for ; Tue, 3 Mar 2009 12:46:30 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id AED7A3A6ABD for ; Tue, 3 Mar 2009 12:46:30 -0800 (PST) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LebVu34Tt-000Tfg; Tue, 03 Mar 2009 15:46:57 -0500 Message-ID: From: "Spencer Dawkins" To: References: <072c01c99151$b007ced0$c2f0200a@cisco.com> Date: Tue, 3 Mar 2009 14:46:32 -0600 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+U2wJjNZNhrzm4vutKcKY+3w/N67QFLOfW9md pEGzmp4qdaieZNJxXzLrhZj1kzC9b2dpAQjJDKFQfFyLU7Yoy1 i+TkJ5bmUMxdV6o4AZjc5IyLTSHK069H8e2EV1j8ak= Cc: James M Galvin Subject: [Tools-discuss] www.fenron.com offline? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:46:31 -0000 This is pretty remotely tied to ietf-tools, but I thought I'd ask in case anyone has a suggestion... I use Bill Fenner's very helpful XML2FRC validator at http://www.fenron.com/~fenner/ietf/xml2rfc-valid/, but that website isn't reachable for me right now (tracert dying about 20 hops away, in static.etheric.net). Is there an alternative online validator that anyone can point me to? Thanks, Spencer, one day before 00 cutoff... From bortzmeyer@nic.fr Fri Mar 6 05:49:46 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20A43A6A0B for ; Fri, 6 Mar 2009 05:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.105 X-Spam-Level: X-Spam-Status: No, score=-5.105 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 07Ta4smCP2fO for ; Fri, 6 Mar 2009 05:49:45 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 408A63A6989 for ; Fri, 6 Mar 2009 05:49:45 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id BA05B1C013E for ; Fri, 6 Mar 2009 14:45:14 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id B56381C011B for ; Fri, 6 Mar 2009 14:45:14 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id A980DA1D95C for ; Fri, 6 Mar 2009 14:45:14 +0100 (CET) Date: Fri, 6 Mar 2009 14:45:14 +0100 From: Stephane Bortzmeyer To: tools-discuss@ietf.org Message-ID: <20090306134514.GA12315@nic.fr> References: <20090304000226.A429223D29E@bosco.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090304000226.A429223D29E@bosco.isi.edu> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Tools-discuss] RFC 5485 on Digital Signatures on Internet-Draft Documents X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 13:49:46 -0000 On Tue, Mar 03, 2009 at 04:02:26PM -0800, rfc-editor@rfc-editor.org wrote a message of 53 lines which said: > RFC 5485 > > Title: Digital Signatures on Internet-Draft Documents Does anyone have information about the implementation calendar? I find no ".p7s" file in the I-D directory. And will I find the certificate of the IETF secretariat? From brian@innovationslab.net Fri Mar 6 12:13:07 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F5E3A69C9 for ; Fri, 6 Mar 2009 12:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 4kHTsEzNDRy3 for ; Fri, 6 Mar 2009 12:13:06 -0800 (PST) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 5F8133A69B5 for ; Fri, 6 Mar 2009 12:13:06 -0800 (PST) Received: from ([128.244.206.11]) by pilot.jhuapl.edu with ESMTP with TLS id 5502123.137525904; Fri, 06 Mar 2009 15:13:14 -0500 Message-ID: <49B183DA.8040107@innovationslab.net> Date: Fri, 06 Mar 2009 15:13:14 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Spencer Dawkins References: <072c01c99151$b007ced0$c2f0200a@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James M Galvin , tools-discuss@ietf.org Subject: Re: [Tools-discuss] www.fenron.com offline? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:13:07 -0000 Spencer, It may be a blip in the routing between you and fenron. I can load that page just fine. Regards, Brian Spencer Dawkins wrote: > This is pretty remotely tied to ietf-tools, but I thought I'd ask in > case anyone has a suggestion... > > I use Bill Fenner's very helpful XML2FRC validator at > http://www.fenron.com/~fenner/ietf/xml2rfc-valid/, but that website > isn't reachable for me right now (tracert dying about 20 hops away, in > static.etheric.net). > > Is there an alternative online validator that anyone can point me to? > > Thanks, > > Spencer, one day before 00 cutoff... > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From spencer@wonderhamster.org Fri Mar 6 12:24:21 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADF03A659C for ; Fri, 6 Mar 2009 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 qoM5QsDeHUzo for ; Fri, 6 Mar 2009 12:24:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 71AD83A6923 for ; Fri, 6 Mar 2009 12:24:20 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Lfgav3qXv-000d3w; Fri, 06 Mar 2009 15:24:37 -0500 Message-ID: From: "Spencer Dawkins" To: "Brian Haberman" References: <072c01c99151$b007ced0$c2f0200a@cisco.com> <49B183DA.8040107@innovationslab.net> Date: Fri, 6 Mar 2009 14:24:06 -0600 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.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18oKhezEGF0SGEhf+c4l3bEvId0vHTeQNrzh/B tRwaYuJTksXvLHE6ZHNOaylSdWRGBbDhDCyGghe17iMBQciM3W EF8OFSSHp4ZMBcp0yIKOzYsvlOvoa3IdeNRyHuewAo= Cc: James M Galvin , tools-discuss@ietf.org Subject: Re: [Tools-discuss] www.fenron.com offline? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:24:21 -0000 Hi, Brian, Thanks for the feedback - it's working for me now, too. I was trying to help someone with XML that didn't XML2RFC on ID cutoff day - but he chopped up the input until he found the problem! Spencer > Spencer, > It may be a blip in the routing between you and fenron. I can load > that page just fine. > > Regards, > Brian > > Spencer Dawkins wrote: >> This is pretty remotely tied to ietf-tools, but I thought I'd ask in case >> anyone has a suggestion... >> >> I use Bill Fenner's very helpful XML2FRC validator at >> http://www.fenron.com/~fenner/ietf/xml2rfc-valid/, but that website isn't >> reachable for me right now (tracert dying about 20 hops away, in >> static.etheric.net). >> >> Is there an alternative online validator that anyone can point me to? >> >> Thanks, >> >> Spencer, one day before 00 cutoff... >> >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss > > From galvin@elistx.com Fri Mar 6 12:38:31 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B683A67F5 for ; Fri, 6 Mar 2009 12:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 xud5HScBZpM2 for ; Fri, 6 Mar 2009 12:38:30 -0800 (PST) Received: from ee01.elistx.com (ee01.elistx.com [67.154.239.222]) by core3.amsl.com (Postfix) with ESMTP id 590253A659C for ; Fri, 6 Mar 2009 12:38:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by elistx.com (PMDF V6.3-2x2 #31546) with ESMTP id <0KG300KDYQOA0I@elistx.com> for tools-discuss@ietf.org; Fri, 06 Mar 2009 15:38:34 -0500 (EST) Date: Fri, 06 Mar 2009 14:40:06 -0600 From: James M Galvin In-reply-to: <49B183DA.8040107@innovationslab.net> To: Brian Haberman , Spencer Dawkins Message-id: <0DC730056573F60239ACAC48@eList-eXpress-LLC.local> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline References: <072c01c99151$b007ced0$c2f0200a@cisco.com> <49B183DA.8040107@innovationslab.net> X-Mailman-Approved-At: Sun, 08 Mar 2009 07:27:31 -0700 Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] www.fenron.com offline? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:38:31 -0000 At the time Spencer sent the note, he was helping me. As it turns out, I couldn't load the page either. I've been in Mexico all week and it has not worked at all, Monday through Thursday. I'm now back in the office, near Washington, DC, and it works fine. I guess "blip" depends on your point of view. :-) Jim -- On March 6, 2009 3:13:14 PM -0500 Brian Haberman wrote regarding Re: [Tools-discuss] www.fenron.com offline? -- > Spencer, > It may be a blip in the routing between you and fenron. I can > load that page just fine. > > Regards, > Brian > > Spencer Dawkins wrote: > > This is pretty remotely tied to ietf-tools, but I thought I'd ask > > in case anyone has a suggestion... > > > > I use Bill Fenner's very helpful XML2FRC validator at > > http://www.fenron.com/~fenner/ietf/xml2rfc-valid/, but that website > > isn't reachable for me right now (tracert dying about 20 hops away, > > in static.etheric.net). > > > > Is there an alternative online validator that anyone can point me > > to? > > > > Thanks, > > > > Spencer, one day before 00 cutoff... From rjsparks@nostrum.com Mon Mar 9 15:01:08 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBDB3A6CBA; Mon, 9 Mar 2009 15:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 4MbIEhnfF51M; Mon, 9 Mar 2009 15:01:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8FA503A6811; Mon, 9 Mar 2009 15:01:05 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n29M1bGW086720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Mar 2009 17:01:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Tools Discuss , IETF Discussion Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 17:01:37 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9082/Mon Mar 9 14:45:18 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Tools-discuss] Reminder: Tools codesprint at IETF74 X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 22:01:08 -0000 If you are planning to join the codesprint at IETF74, please add yourself to the wiki page at to help us build a rough idea of how many folks will be present. More information about this sprint can be found at If you can't work with the wiki for some reason, please drop me a note. Thanks, RjS From duerst@it.aoyama.ac.jp Tue Mar 10 20:06:09 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC093A69BF for ; Tue, 10 Mar 2009 20:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] 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 bzA4nw8tWgXZ for ; Tue, 10 Mar 2009 20:06:08 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id ECED03A6970 for ; Tue, 10 Mar 2009 20:06:07 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id n2B36guZ019828 for ; Wed, 11 Mar 2009 12:06:42 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 70b8_a58022c2_0de9_11de_aefa_0019b9e2b3d9; Wed, 11 Mar 2009 12:06:42 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:46825) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Mar 2009 11:58:11 +0900 Message-Id: <6.0.0.20.2.20090311112613.094e6c88@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Mar 2009 11:33:25 +0900 To: tools-discuss@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:06:10 -0000 Dear IETF Tools experts, [If this is the wrong list, please tell me where else to go.] Partly due to my own activity, partly due to the recent copyright discussions, I have two drafts that were resubmitted some weeks/months after having been expired: draft-duerst-iri-bis and draft-duerst-mailto-bis In the status tracker, the first appears as dead, the second one is alive. See: https://datatracker.ietf.org/idtracker/?search_filename=duerst It seems that the reason for the difference is that the former (now dead) one was in "AD Watching" before. It seems reasonable that a resubmitted draft would e.g. go back to "exist" rather than "AD Watching" after being expired for some time, but having an existing draft in status "dead" really looks strange. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From brian.e.carpenter@gmail.com Tue Mar 10 20:47:46 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979DC3A6870 for ; Tue, 10 Mar 2009 20:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 5ISauea2fMa3 for ; Tue, 10 Mar 2009 20:47:44 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 5FCBF3A6833 for ; Tue, 10 Mar 2009 20:47:44 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id b2so1532326ana.4 for ; Tue, 10 Mar 2009 20:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tty14XluwwxLsuK6BXjq84TRlzj/7A0vw8SDBPHqzjM=; b=wBJlNG/dSeF2qFlN2u8p12c6pai438XJwOy52p/QzCTu+thqBo8e34DZ5cLUAOPAgl qbi54RwkrGNt1UaY65P0nhcybKyrxv7rE6vQ7ojRe7M3sZ0n0UCUD+X/c25CZ/LLcPDA vlJUzxNf/WdC3pbkiA0hdUTjFbTauctIYYxqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vBtvWVxaKa0JBqNAvda+dF7dlg86VgBQG586Bk6jPSss4Iog+c+HzxDyyZv6q67zCr oD5tW5u397XDWj6L6wJlOsoeT+LbnQ4RQnS0WLDVWhTSkGQzfFP2y05C7Wp0cZoUBb1U +g3Zk2L3KuFdgt48jeiQjvS6UzdmcjA/xIjnI= Received: by 10.142.223.4 with SMTP id v4mr3465826wfg.11.1236743299386; Tue, 10 Mar 2009 20:48:19 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm12611545wfg.3.2009.03.10.20.48.18 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Mar 2009 20:48:18 -0700 (PDT) Message-ID: <49B7348F.4000601@gmail.com> Date: Wed, 11 Mar 2009 16:48:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Duerst References: <6.0.0.20.2.20090311112613.094e6c88@localhost> In-Reply-To: <6.0.0.20.2.20090311112613.094e6c88@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:47:46 -0000 Martin, If I recall correctly, resuscitation from "Dead" is only possible as a manual operation requested by an AD. I think the idea is that if a document has left "AD is watching" due to prolonged inactivity, it should be a human, not a robot, who brings it back to the AD's active list. At https://datatracker.ietf.org/idtracker/help/state/ you can see that the next possible state is "Publication requested". So you need to write to the AD again. None of this is a comment on your document, obviously. Brian On 2009-03-11 15:33, Martin Duerst wrote: > Dear IETF Tools experts, > > [If this is the wrong list, please tell me where else to go.] > > Partly due to my own activity, partly due to the recent > copyright discussions, I have two drafts that were resubmitted > some weeks/months after having been expired: > draft-duerst-iri-bis and draft-duerst-mailto-bis > In the status tracker, the first appears as dead, the > second one is alive. See: > https://datatracker.ietf.org/idtracker/?search_filename=duerst > > It seems that the reason for the difference is that the former > (now dead) one was in "AD Watching" before. It seems reasonable > that a resubmitted draft would e.g. go back to "exist" rather > than "AD Watching" after being expired for some time, but > having an existing draft in status "dead" really looks strange. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > From duerst@it.aoyama.ac.jp Tue Mar 10 22:48:00 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3E83A6784 for ; Tue, 10 Mar 2009 22:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] 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 UbF-26TWlKUP for ; Tue, 10 Mar 2009 22:47:59 -0700 (PDT) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 8CE2C3A6767 for ; Tue, 10 Mar 2009 22:47:59 -0700 (PDT) Received: from scmse3.scbb.aoyama.ac.jp ([133.2.253.23]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n2B5mYNs014841 for ; Wed, 11 Mar 2009 14:48:34 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse3.scbb.aoyama.ac.jp with smtp id 5136_4220b662_0e00_11de_aa61_001d0969ab06; Wed, 11 Mar 2009 14:48:33 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:57857) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 11 Mar 2009 14:40:01 +0900 Message-Id: <6.0.0.20.2.20090311140004.08d55f00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 Mar 2009 14:26:18 +0900 To: Brian E Carpenter From: Martin Duerst In-Reply-To: <49B7348F.4000601@gmail.com> References: <6.0.0.20.2.20090311112613.094e6c88@localhost> <49B7348F.4000601@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 05:48:00 -0000 At 12:48 09/03/11, Brian E Carpenter wrote: >Martin, > >If I recall correctly, resuscitation from "Dead" is only possible >as a manual operation requested by an AD. Apparently, not so, as my second example (draft-duerst-mailto-bis) shows. This is at "I-D Exists", at least according to https://datatracker.ietf.org/idtracker/. >I think the idea is that >if a document has left "AD is watching" due to prolonged inactivity, >it should be a human, not a robot, who brings it back to the AD's >active list. I fully agree here. If I were an AD, I wouldn't want an I-D to go back to "AD is watching" without my approval. But there are many other states available, and "I-D Exists" seems much more appropriate for the current case than dead. >At https://datatracker.ietf.org/idtracker/help/state/ >you can see that the next possible state is "Publication requested". According to the table, yes. According to the diagram (https://datatracker.ietf.org/images/state_diagram.gif), there is nothing after 'dead', which makes sense in the usual sense of the word. Also, according to the diagram, the only state from which to get into 'dead' is "DNP - announcement to be sent" (whatever that means). According to the table, there are two more states from which to get to 'dead': "Publication Requested" and "RFC Published". In actual practice, potentially any state can be followed by 'dead', possibly with the exception of "RFC Published" (which means eternal life, rather than death, for an I-D :-). In actual practice, a dead I-D should be allowed to get back to the state it was in, or otherwise simply go back to "I-D Exists" (which currently seems to happen for I-Ds that have been in "I-D Exists", at least according to my own sample of one). I'm not sure to what extent the above is a process issue, to what extent it is a tools issue,... But I strongly feel that labeling an actually existing document as "dead" is wrong, and >So you need to write to the AD again. Will do. This mail is more about trying to fix the problem in the general case than about my specific draft. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From Pasi.Eronen@nokia.com Wed Mar 11 03:44:46 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E453A6B57 for ; Wed, 11 Mar 2009 03:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DcxJOPd7ZyU5 for ; Wed, 11 Mar 2009 03:44:45 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 152383A6B82 for ; Wed, 11 Mar 2009 03:44:44 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2BAjAqv012389; Wed, 11 Mar 2009 12:45:14 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 12:45:10 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 12:44:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 12:44:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 11 Mar 2009 11:44:49 +0100 From: To: , Date: Wed, 11 Mar 2009 11:44:46 +0100 Thread-Topic: [Tools-discuss] dead or alive? Thread-Index: AcmiDQ0bkjFw9fjgTL6Qn4yNeN1IfwAEfl7g Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com> References: <6.0.0.20.2.20090311112613.094e6c88@localhost> <49B7348F.4000601@gmail.com> <6.0.0.20.2.20090311140004.08d55f00@localhost> In-Reply-To: <6.0.0.20.2.20090311140004.08d55f00@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2009 10:44:49.0871 (UTC) FILETIME=[671DCDF0:01C9A236] X-Nokia-AV: Clean Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 10:44:46 -0000 Martin Duerst wrote: > In actual practice, a dead I-D should be allowed to get back to > the state it was in, or otherwise simply go back to "I-D Exists" > (which currently seems to happen for I-Ds that have been in > "I-D Exists", at least according to my own sample of one). I agree that going back to "I-D Exists" would be much more logical than "Dead"... =20 The explanation here is historical: The database has two different tables containing information about Internet-Drafts. All drafts have a row in one of those tables. When the web page says "state: I-D Exists", it actually means that the draft does *not* exist in the second table yet (and that's the table that actually has the "state" field). If the draft is in the 2nd table, the value shown on the web page is the value from the "state" field of that table. Currently, "I-D Exists" is not one of the possible values for that field, so once a draft is added to the 2nd table (by AD/secretariat), it can never go back to "I-D Exists". That's clearly stupid. There's ongoing work to redesign the database schema (lead by Henrik), re-think the "state diagram" to better match what happens today (I've been doing this, with input from rest of the IESG), and update the code that uses the database (by various people), but let's just say it might take a while before these are in use. But help is welcome :-) http://www.ietf.org/mail-archive/web/tools-discuss/current/msg01752.html Best regards, Pasi= From brian.e.carpenter@gmail.com Wed Mar 11 14:00:04 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDB93A6873 for ; Wed, 11 Mar 2009 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 LxakHspWGy7r for ; Wed, 11 Mar 2009 14:00:04 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id E1BDF3A6BCB for ; Wed, 11 Mar 2009 14:00:03 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id m33so98772wag.5 for ; Wed, 11 Mar 2009 14:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oNKMvUbVIOh/3W1gUmCGLIwOA7LZ4shekkhUlfySNTI=; b=a85TZ9QqJBZmceTSWnS5Q45/N1Udg5fCtR/pOxvrOTVZmGKchjf3gYUsfMoZGBf3KB 6O2/fT2Nn2p/li+pUngOBpiPHY1VDsTwgm0/WOCz/dGuBeriV35hxLO2WJzEAaHRKoE+ K84EO0SnqWiX/lwKjyJmJ5U2REFpy1XgvFSIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=AJNdaiyICCnOSX0FxDD8yxob8yIvKu/rQxC/BsvPtS/jb9hx/A+vM/IcAtUL4QINJt kZQCFqheg+0bAYVaVHP1PF6cBygMuuCL8arbGhqlfpRKC/Pg77A9oUhropY+3E3yeu2L Zy3OZC6FZWikVKKB4MWgMOC+fnz12SN4M7ROA= Received: by 10.114.37.1 with SMTP id k1mr5434936wak.172.1236805240487; Wed, 11 Mar 2009 14:00:40 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l28sm279176waf.65.2009.03.11.14.00.39 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 14:00:40 -0700 (PDT) Message-ID: <49B82675.90605@gmail.com> Date: Thu, 12 Mar 2009 10:00:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <6.0.0.20.2.20090311112613.094e6c88@localhost> <49B7348F.4000601@gmail.com> <6.0.0.20.2.20090311140004.08d55f00@localhost> <808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:00:04 -0000 On 2009-03-11 23:44, Pasi.Eronen@nokia.com wrote: > I agree that going back to "I-D Exists" would be much more logical > than "Dead"... Both of these states mean that no AD has this document on his or her plate; but "Dead" means that it was previously added to the IESG tracker by an AD. So there is a difference in semantics, and there are in fact four states to consider: 1. I-D exists, and has never been considered by an AD 2. I-D expired, and has never been considered by an AD 3. I-D expired, and was previously considered by an AD 4. I-D exists (again), and was previously considered by an AD (but died) Obviously, mapping these to two states (exists and dead) plus a non-state is a problem. The non-state is that a draft in state 2 (expired and never considered by an AD) simply has no state in the IESG tracker. Sorting this out would be a Good Thing. Brian From spencer@wonderhamster.org Wed Mar 11 14:26:48 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0DB3A6B56 for ; Wed, 11 Mar 2009 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, STOX_REPLY_TYPE=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 lJLA6uhSwA94 for ; Wed, 11 Mar 2009 14:26:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B22AC3A6915 for ; Wed, 11 Mar 2009 14:26:47 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LhVxM0akH-000gAD; Wed, 11 Mar 2009 17:27:20 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian E Carpenter" , References: <6.0.0.20.2.20090311112613.094e6c88@localhost> <49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com> <49B82675.90605@gmail.com> Date: Wed, 11 Mar 2009 16:27:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/F5xWmlsCVgsgrmuN4b91r8z3+l+JAC+XXxPz cnZMeUBzsI4/O21VtdZUeVJNaqDEvbM5LIbRf2po/k6vOzXZ8c 07mLS2U0rl+hchCXXA1HG7Nx+RI/ri2hGk7lZmTEZ8= Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:26:48 -0000 Did I understand Pasi's previous note in this thread to say that if all drafts had entries in the table that's used by the IESG tracker, all the cool things that work for these drafts (like having a page that shows all the versions of a draft, with diffs between each version, etc) would automagically start working? If that's the case, this kind of sorting out could be a really good thing... Thanks, Spencer > Both of these states mean that no AD has this document on his > or her plate; but "Dead" means that it was previously added to the > IESG tracker by an AD. So there is a difference in semantics, > and there are in fact four states to consider: > > 1. I-D exists, and has never been considered by an AD > 2. I-D expired, and has never been considered by an AD > 3. I-D expired, and was previously considered by an AD > 4. I-D exists (again), and was previously considered by an AD (but died) > > Obviously, mapping these to two states (exists and dead) > plus a non-state is a problem. The non-state is that a draft > in state 2 (expired and never considered by an AD) simply > has no state in the IESG tracker. > > Sorting this out would be a Good Thing. From lmartini@cisco.com Mon Mar 9 11:59:10 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DC93A67AF for ; Mon, 9 Mar 2009 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] 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 bDTWX3a8QvZe for ; Mon, 9 Mar 2009 11:59:07 -0700 (PDT) Received: from napoleon.monoski.com (black.monoski.com [63.227.123.238]) by core3.amsl.com (Postfix) with ESMTP id A3CA43A6C96 for ; Mon, 9 Mar 2009 11:58:29 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n29Ivt0h012255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Mar 2009 12:57:55 -0600 (MDT) Message-ID: <49B566B3.7040901@cisco.com> Date: Mon, 09 Mar 2009 12:57:55 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: tools-discuss@ietf.org Content-Type: multipart/mixed; boundary="------------080009070008030808080902" X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 X-Mailman-Approved-At: Wed, 11 Mar 2009 17:21:38 -0700 Subject: [Tools-discuss] Idnits-2.11.04 Bug ... X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:59:10 -0000 This is a multi-part message in MIME format. --------------080009070008030808080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The attached document passes idnits 1 out of 3 times .... when it fails : idnits 2.11.05 tmp/draft-ietf-pwe3-dynamic-ms-pw-09.txt: Showing Errors (**), Warnings (==), and Comments (--). Errors MUST be fixed before draft submission. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack an IETF Trust Provisions (12 Feb 2009) Section 6.b License Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? trust-12-feb-2009 Section 6.b paragraph 3 text: "This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document." ... text found in draft: "This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/licenseinfo). Please review ....................................................^ these documents carefully, as they describe your rights and restrictions with respect to this document." Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Running in submission checking mode -- *not* checking nits according to http://www.ietf.org/ID-Checklist.html. ---------------------------------------------------------------------------- Summary: 1 error (**), 0 warnings (==), 0 comments (--). when it passes : idnits 2.11.04 tmp/draft-ietf-pwe3-dynamic-ms-pw-09.txt: Showing Errors (**), Warnings (==), and Comments (--). Errors MUST be fixed before draft submission. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Running in submission checking mode -- *not* checking nits according to http://www.ietf.org/ID-Checklist.html. ---------------------------------------------------------------------------- No nits found. I think this document should always pass , as I cannot see anything wrong with the section in question. Thanks. Luca --------------080009070008030808080902 Content-Type: text/plain; name="draft-ietf-pwe3-dynamic-ms-pw-09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-pwe3-dynamic-ms-pw-09.txt" Network Working Group Luca Martini (Ed.) Internet Draft Cisco Systems Inc. Expiration Date: September 2009 Matthew Bocci (Ed.) Intended status: Standards Track Florin Balus (Ed.) Alcatel-Lucent March 9, 2009 Dynamic Placement of Multi Segment Pseudo Wires draft-ietf-pwe3-dynamic-ms-pw-09.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2009 Abstract There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. Martini, et al. [Page 1] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Table of Contents 1 Specification of Requirements ........................ 3 2 Major Co-authors ..................................... 3 3 Acknowledgements ..................................... 3 4 Introduction ......................................... 3 4.1 Scope ................................................ 3 4.2 Terminology .......................................... 4 4.3 Architecture Overview ................................ 4 5 Applicability ........................................ 6 5.1 Requirements Addressed ............................... 6 5.2 Changes to Existing PW Signaling ..................... 6 6 PW layer 2 addressing ................................ 6 6.1 Attachment Circuit Addressing ........................ 7 6.2 S-PE addressing ...................................... 7 7 Dynamic placement of MS-PWs .......................... 8 7.1 Pseudo wire routing procedures ....................... 8 7.1.1 AII PW routing table Lookup aggregation rules ........ 8 7.1.2 PW Static Route ...................................... 9 7.1.3 Dynamic advertisement with BGP ....................... 9 7.2 LDP Signaling ........................................ 10 7.2.1 MS-PW Bandwidth Signaling ............................ 10 7.2.2 Active/Passive T-PE Election Procedure ............... 12 7.2.3 Detailed Signaling Procedures ........................ 12 7.2.4 Support for Explicit PW Path ......................... 13 8 Failure Handling Procedures .......................... 14 8.1 PSN Failures ......................................... 14 8.2 S-PE Reachability Failures ........................... 14 9 Operations and Maintenance (OAM) ..................... 14 10 Security Considerations .............................. 15 11 IANA Considerations .................................. 15 11.1 LDP Status Codes ..................................... 15 11.2 BGP SAFI ............................................. 16 12 Normative References ................................. 16 13 Informative References ............................... 16 14 Author's Addresses ................................... 17 Martini, et al. [Page 2] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Major Co-authors The editors gratefully acknowledge the following additional co- authors: Mustapha Aissaoui, Nabil Bitar, Mike Loomis, David McDysan, Chris Metz, Andy Malis, Jason Rusmeisel, Himanshu Shah, Jeff Sugimoto. 3. Acknowledgements The editors also gratefully acknowledge the input of the following people: Mike Ducket, Paul Doolan, Prayson Pate, Ping Pan, Vasile Radoaca, Yeongil Seo, Yetik Serbest, Yuichiro Wada. 4. Introduction 4.1. Scope [MS-REQ] describes the service provider requirements for extending the reach of pseudo-wires across multiple PSN domains. This is achieved using a Multi-segment Pseudo-Wire (MS-PW). A MS-PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This architecture is described in [MS-ARCH]. The procedures for establishing PWs that extend across a single PWE3 domain are described in [RFC4447], while procedures for setting up PWs across multiple domains, or control planes are described in [PW- SEG]. The purpose of this draft is to specify extensions to the PWE3 control protocol [RFC4447], and [PW-SEG] procedures, to enable multi-segment PWs to be automatically placed. The proposed procedures follow the guidelines defined in [RFC5036] and enable the reuse of existing TLVs, and procedures defined for SS-PWs in [RFC4447]. Martini, et al. [Page 3] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 4.2. Terminology [MS-ARCH] provides terminology for multi-segment pseudo wires. This document defines the following additional terms: - Source Terminating PE (ST-PE). A Terminating PE (T-PE), which assumes the active signaling role and initiates the signaling for multi-segment PW. - Target Terminating PE (TT-PE). A Terminating PE (T-PE) that assumes the passive signaling role. It waits and responds to the multi-segment PW signaling message in the reverse direction. - Forward Direction: ST-PE to TT-PE. - Reverse Direction: TT-PE to ST-PE - Forwarding Direction: Direction of control plane, signaling flow - Pseudo wire Routing (PW routing). The dynamic placement of SS-PWs that compose an MS-PW, as well as the automatic selection of S- PEs. 4.3. Architecture Overview The following figure describes the reference models which are derived from [MS-ARCH] to support PW emulated services across multi-segment PWs. Martini, et al. [Page 4] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Native |<-------------Pseudo Wire----------->| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|.....PW.Seg't1........PW Seg't3......|----------| | | CE1| | | | | | | | | |CE2 | | |-------|.....PW.Seg't2.......|PW Seg't4......|----------| | +----+ | | |=========| |=========| | | +----+ ^ +-----+ +-----+ +-----+ ^ | Provider Edge 1 ^ Provider Edge 2 | | | | | | | | PW switching point | | | |<---------------- Emulated Service -------------------->| Figure 1: PW switching Reference Model Figure 1 shows the architecture for a simple multi-segment case. T- PE1 and T-PE2 provide PWE3 to CE1 and CE2. These PEs reside in different PSNs. A PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PWs are used to connect the attachment circuits (ACs) attached to T-PE1 to the corresponding AC attached to T-PE2. A PW on the tunnel across PSN1 is connected to a PW in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and will be referred to as the switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are segments of the same MS-PW while PW Segment 2 and PW Segment 4 are segments of another MS-PW. PW segments of the same MS-PW (e.g., PW segment 1 and PW segment 3) MUST be of the same PW type, and PSN tunnels (e.g., PSN1 and PSN2) can be the same or different technology. An S-PE switches an MS-PW from one segment to another based on the PW identifiers. ( PWid , or AII ) How the Pw PDUs are switched at the S-PE depends on the PSN tunnel technology: in case of an MPLS PSN to another MPLS PSN PW switching the operation is a standard MPLS label switch operation. Note that although Figure 1 only shows a single S-PE, a PW may transit more one S-PE along its path. For instance, in the multi- provider case, there can be an S-PE at the border of one provider domain and another S-PE at the border of the other provider domain. Martini, et al. [Page 5] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 5. Applicability In this document we describe the case where the PSNs carrying the SS-PW are only MPLS PSNs using the generalized FEC 129. Interactions with an IP PSN using L2TPv3 as described in [PW-SEG] section 7.4 are left for further study. 5.1. Requirements Addressed Specifically the following requirements are addressed [MS-REQ]: - Dynamic End-to-end Signaling - Scalability and Inter-domain Signaling and Routing - Minimal number of provisioning touches (provisioning only at the T-PEs) - Same set of T-PEs/S-PEs for both directions of a MS-PWs - QoS Signaling, Call Admission Control - Resiliency - End-to-end negotiation of OAM Capability 5.2. Changes to Existing PW Signaling The procedures described in this document make use of existing LDP TLVs and related PW signaling procedures described in [RFC4447] and [PW-SEG]. Only an optional Bandwidth TLV is added to address the QoS Signaling requirements (see "MS-PW Next Hop Bandwidth Signaling" section for details). 6. PW layer 2 addressing Single segment pseudo wires on an MPLS PSN use Attachment circuit identifiers for a PW using FEC 129. In the case of an automatically placed MS-PW, there is a requirement to have individual global addresses assigned to PW attachment circuits, for reachability , and manageability of the PW. Referencing figure 1 above, individual globally unique addresses MUST be allocated to all the ACs , and S- PEs composing an MS-PW. Martini, et al. [Page 6] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 6.1. Attachment Circuit Addressing The attachment circuit addressing is derived from [RFC5003] AII type 2 shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type=02 | Length | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID (contd.) | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (contd.) | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Implementations of the following procedure MUST interpret the AII type to determine the meaning of the address format of the AII, irrespective of the number of segments in the MS-PW. A unique combination Global ID, Prefix, and AC ID parts of the AII type 2 will be assigned to each AC. In general the same global ID and prefix will be assigned for all ACs belonging to the same T-PE, however this is not a strict requirement. A particular T-PE might have more than one prefix assigned to it, and likewise a fully qualified AII with the same Global ID/Prefix but different AC IDs might belong to different T-PEs. For the purpose of MS-PW the AII MUST be globally unique across all interconnected PW domains. 6.2. S-PE addressing The T-PE may elect to select a known specific path along a set of S- PEs for a specific PW. This requires that each S-PE be uniquely addressable in terms of pseudo wires. For this purpose at least one AI address of the format similar to AII type 2 [RFC5003] composed of the Global ID, and Prefix part only MUST be assigned to each S-PE. Martini, et al. [Page 7] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 7. Dynamic placement of MS-PWs [PW-SEG] describes a procedure for connecting multiple pseudo wires together. This procedure requires each S-PE to be manually configured with the information required to terminate and initiate the SS-PW part of the MS-PW. The procedures in the following sections describe an method to extend [PW-SEG] by allowing the automatic selection of pre-defined S-PEs, and automatically setting up a MS-PW between two T-PEs. 7.1. Pseudo wire routing procedures The AII type 2 described above contains a Global ID, Prefix, and AC ID. The TAII is used by S-PEs to determine the next SS-PW destination for LDP signaling. Once an S-PE receives a MS-PW label mapping message containing a TAII with an AII that is not locally present, the S-PE performs a lookup in a local Layer 2 AII PW routing table. If this lookup results in an IP address of the next PE that advertised reachability information for the AII in question, then the S-PE will initiate the necessary LDP messaging procedure for setting up the next PW segment. If the AII PW routing table lookup does not result in a IP address of the next PE, the destination AII has become unreachable, and the PW MUST fail to setup. In this case the next PW segment is considered unprovisioned, and a label release MUST be returned to the T-PE with a status message of "AII Unreachable". If the TAI of a MS-PW label mapping message, received by a PE, contains the prefix of a locally provisioned prefix on that PE, but an AC ID that is not provisioned, then the LDP liberal label retention procedures apply, and the label mapping message is retained. To allow for dynamic end-to-end signaling of MS-PWs, information must be present in S-PEs to support the determination of the next PW signaling hop. Such information can be provisioned (static route equivalent) on each S-PE system or disseminated via regular routing protocols (e.g. BGP). 7.1.1. AII PW routing table Lookup aggregation rules All PEs capable of dynamic multi segment pseudowire path selection, must build a PW routing table to be used for PW next hop selection. The PW addressing scheme (AII type 2 in [RFC5003]) consists of a Martini, et al. [Page 8] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Global Id, a 32 bit prefix and a 32 bit Attachment Circuit ID. An aggregation scheme similar with the one used for classless IPv4 addresses can be employed. An (8 bits) length mask is specified as a number ranging from 0 to 96 that indicates which Most Significant Bits (MSB) are relevant in the address field when performing the PW address matching algorithm. 0 31 32 63 64 95 (bits) +-----------+--------+--------+ | Global ID | Prefix | AC ID | +-----------+--------+--------+ During the signaling phase, the content of the (fully qualified) TAII type 2 field from the FEC129 TLV is compared against routes from the PW Routing table. Similar with the IPv4 case, the route with the longest match is selected, determining the next signaling hop and implicitly the next PW Segment to be signaled. 7.1.2. PW Static Route For the purpose of determining the next signaling hop for a segment of the pseudo wire, the PEs MAY be provisioned with fixed route entries in the PW next hop routing table. The static PW entries will follow all the addressing rules and aggregation rules described in the previous sections. The most common use of PW static provisioned routes is this example of the "default" route entry as follows: Global ID = 0 Prefix = 0 AC ID = 0 , Prefix Length = 0 Next Signaling Hop = S-PE1 7.1.3. Dynamic advertisement with BGP Any suitable routing protocol capable of carrying external routing information may be used to propagate MS-PW path information among S- PE, and T-PE. However, T-PE, and S-PEs, MAY choose to use Boundary Gateway Protocol (BGP) [RFC4760] to propagate PW address information throughout the PSN. Contrary to other l2vpn signaling methods that use BGP [L2- SIGNALING], in the case of the dynamically placed MS-PW if the source T-PE knows a priori (by provisioning) the address of the terminating T-PE. Hence there is no need to advertise a "fully qualified" 96 bit address on a per PW Attachment Circuit basis. Only the T-PE Global ID, Prefix, and prefix length needs to be advertised as part of well Martini, et al. [Page 9] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 known BGP procedures - see [RFC4760]. As PW Endpoints are provisioned in the T-PEs. The ST-PE will use this information to obtain the first S-PE hop (i.e., first BGP next hop) to where the first PW segment will be established. Any subsequent S- PEs will use the same information (i.e. the next BGP next-hop(s)) to obtain the next-signaling-hop(s) on the path to the TT-PE. The PW dynamic path NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=25, SAFI=6 (pending IANA allocation)). The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address, whenever the length of the NextHop address is 4 octets, and as a IPv6 address, whenever the length of the NextHop address is 16 octets. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 96 bits encoded as defined in section 4 of [RFC4760]. This prefix is structured as follows: 0 31 32 63 64 95 (bits) +-----------+--------+--------+ | Global ID | Prefix | AC ID | +-----------+--------+--------+ Except for the default PW route, which is encoded as a 0 length prefix, the minimum prefix length is 32 bits. Prefix lengths of 65 to 95 are invalid as the AC ID field cannot be aggregated. 7.2. LDP Signaling The LDP signaling procedures are described in [RFC4447] and expanded in [PW-SEG]. No new LDP Signaling components are required for setting up a dynamically placed MS-PW. However some optional signaling extensions are described below. 7.2.1. MS-PW Bandwidth Signaling In the SS-PW case the PW QoS requirements may easily be met by selecting a MPLS PSN tunnel at the S-PE that meets the PW QoS requirements. However in the case of an automatically placed MS-PW the QoS requirements for a SS-PW not initiating on a T-PE MAY need to Martini, et al. [Page 10] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 be indicated along with the MS-PW addressing. This is accomplished by including an OPTIONAL PW Bandwidth TLV. The PW Bandwidth TLV is specified as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW BW TLV (0x096E) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forward SENDER_TSPEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse SENDER_TSPEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The complete definitions of the content of the SENDER_TSPEC objects are found in [TSPEC] section 3.1. The forward SENDER_TSPEC refers to the data path in the direction of ST-PE to TT-PE. The reverse SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE. In the forward direction, after a next hop selection is determined, a T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine an appropriate PSN tunnel towards the next signaling hop. If such a tunnel exists, the MS-PW signaling procedures are invoked with the inclusion of the PW Bandwidth TLV. When the PE searches for a PSN tunnel, any tunnel which points to a next hop equivalent to the next hop selected will be included in the search.(The LDP address TLV is used to determine the next hop equivalence) When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is selected, the S/T-PE MUST request the appropriate resources from the PSN. The resources described in the reverse SENDER_TSPEC are allocated from the PSN toward the originator of the message or previous hop. When resources are allocated from the PSN for a specific PW, then the PSN SHOULD account for the PW usage of the resources. In the case where PSN resources towards the previous hop are not available the following procedure MUST be followed: -i. The PSN MAY allocate more QoS resources, e.g. Bandwidth, to the PSN tunnel. -ii. The S-PE MAY attempt to setup another PSN tunnel to accommodate the new PW QoS requirements. -iii. If the S-PE cannot get enough resources to setup the segment in the MS-PW a label release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable" Martini, et al. [Page 11] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 In the latter case, the T-PE receiving the status message MUST also withdraw the corresponding PW label mapping for the opposite direction if it has already been successfully setup. If an ST-PE receives a label mapping message the following procedure MUST be followed: If the ST-PE has already sent a label mapping message for this PW then the ST-PE must check that this label mapping message originated from the same LDP peer to which the corresponding label mapping message for this particular PW was sent. If it is the same peer, the the PW is established. If it is a different peer, then ST-PE MUST send a label release message, with a status code of "Duplicate AII" to the PE that originate the LDP label mapping message. If the PE has not yet sent a label mapping message for this particular PW , then it MUST send the label mapping message to this same LDP peer, regardless of what the PW TAII routing lookup result is. 7.2.2. Active/Passive T-PE Election Procedure When a MS-PW is signaled, Each T-PE might independently start signaling the MS-PW, this could result in a different path selected for each T-PE PW. To avoid this situation one of the T-PE MUST start the PW signaling (active role), while the other waits to receive the LDP label mapping before sending the respective PW LDP label mapping message. (passive role). The Active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be identified before signaling is initiated for a given MS-PW. The determination of which T-PE assume the active role SHOULD be done as follows: the SAII and TAII are compared as unsigned integers, if the SAII is bigger then the T-PE assumes the active role. The selection process to determine which T-PE assumes the active role MAY be superseded by manual provisioning. 7.2.3. Detailed Signaling Procedures On receiving a label mapping message, the S-PE MUST inspect the FEC TLV. If the receiving node has no local AII matching the TAII for that label mapping then the S-PE will check if the FEC is already installed for the forward direction: Martini, et al. [Page 12] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 - If it is already installed, and the received mapping was received from the same LDP peer where the forward LDP label mapping was sent, then this label mapping represents signaling in the reverse direction for this MS-PW segment. - Otherwise this represents signaling in the forward direction. For the forward direction: -i. Determine the next hop S-PE or T-PE according to the procedures above. -ii. Check that a PSN tunnel exists to the next hop S-PE or T-PE. If no tunnel exists to the next hop S-PE or T-PE the S-PE MAY attempt to setup a PSN tunnel. -iii. Check that a PSN tunnel exists to the previous hop. If no tunnel exists to the previous hop S-PE or T-PE the S-PE MAY attempt to setup a PSN tunnel. -iv. If the S-PE cannot get enough PSN resources to setup the segment to the next or previous S-PE or T-PE, a label release MUST be returned to the T-PE with a status message of "Resources Unavailable". -v. If the label mapping message contains a Bandwidth TLV, allocate the required resources on the PSN tunnels in the forward and reverse directions according to the procedures above. -vi. Allocate a new PW label for the forward direction. -vii. Install the FEC for the forward direction. -viii. Send the label mapping message with the new forward label and the FEC to the next hop S-PE/T-PE. For the reverse direction: -i. Install the received FEC for the reverse direction. -ii. Determine the next signaling hop by referencing the LDP sessions used to setup the LSP in the Forward direction. -iii. Allocate a new PW label for the reverse direction. -iv. Install the FEC for the reverse direction. -v. Send the label mapping message with a new label and the FEC to the next hop S-PE/ST-PE. 7.2.4. Support for Explicit PW Path The Explicit Route TLV format defined in [RFC3212] section 4.1 MAY be used to signal an explicit path for a MS-PW. An Explicit PW path may be required to provide a simple solution for 1:1 protection with diverse primary and backup path or to enable controlled signaling (strict or loose) for special PWs. Details of its usage to be provided in a future study. Martini, et al. [Page 13] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 8. Failure Handling Procedures 8.1. PSN Failures Failures of the PSN tunnel MUST be handled by PSN mechanisms. If the PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD follow the procedures defined in Section 8 of [PW-SEG]. 8.2. S-PE Reachability Failures For defects in an S-PE, the procedures defined in [PW-SEG] SHOULD be followed. However in general an established MS-PW will not be affected by changes in L2 PW reachability information. T-PEs that receive a label release message with a status of "AII Unreachable" MUST re-attempt to establish the PW immediately. However the T-PE MUST throttle its PW setup message retry attempts with an exponential backoff in situations where PW setup messages are being constantly released. It is also recommended that a T-PE detecting such a situation take action to notify an operator. If there is a change in the L2 PW reachability information in the forward direction only, the T-PE MAY elect to tear down the MS-PW by sending a label withdraw message and re-establish the MS-PW. In the same case, an S-PE MAY do the same by sending a label withdraw message in the forward direction, and a label release message in the opposite direction along the MS-PW. A change in L2 reachability information in the reverse direction has no effect on an MS-PW. 9. Operations and Maintenance (OAM) The OAM procedures defined in [PW-SEG] may be used also for MS-PWs. A PW switching point TLV is used [PW-SEG] to record the switching points that the PW traverses. In the case of a MS-PW where the PW Endpoints are identified though using a globally unique, FEC 129-based AII addresses, there is no PWID defined on a per segment basis. Each individual PW segment is identified by the address of adjacent S-PE(s) in conjunction with the SAI and TAI. In this case, the following type MUST be used in place of type 0x01 in the PW switching point TLV: Martini, et al. [Page 14] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Type Length Description 0x06 10 L2 PW address of PW Switching Point The above field MUST be included together with type 0x02 in the TLV once per individual PW Switching Point following the same rules and procedures as described in [PW-SEG]. 10. Security Considerations This document specifies only extensions to the protocols already defined in [RFC4447], and [PW-SEG]. Each such protocol may have its own set of security issues, but those issues are not affected by the extensions specified herein. Note that the protocols for dynamically distributing PW Layer 2 reachability information may have their own security issues, however those protocols specifications are outside the scope of this document. 11. IANA Considerations This document uses several new LDP TLV types, IANA already maintains a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The following value is suggested for assignment: TLV type Description 0x096E Bandwidth TLV 11.1. LDP Status Codes This document uses several new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following values have been pre-allocated: Range/Value E Description Reference ------------- ----- ---------------------- --------- 0x00000037 0 Bandwidth resources unavailable RFCxxxx 0x00000038 0 Resources Unavailable RFCxxxx 0x00000039 0 AII Unreachable RFCxxxx 0x0000003A 0 PW Loop Detected RFCxxxx Martini, et al. [Page 15] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 11.2. BGP SAFI IANA needs to allocate a new BGP SAFI for "Network Layer Reachability Information used for Dynamic Placement of Multi-Segment Pseudiwires" from the IANA "Subsequence Address Family Identifiers (SAFI)" registry. The following value has been pre-allocated: Value Description Reference ----- ----------- --------- 6 Network Layer Reachability Information used [RFCxxxx] for Dynamic Placement of Multi-Segment Pseudowires 12. Normative References [PW-SEG] Martini et.al. "Segmented Pseudo Wire", draft-ietf-pwe3-segmented-pw-11.txt, IETF Work in Progress, February 2009 [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 [RFC5036] Andersson, Minei, Thomas. "LDP Specification" RFC5036, October 2007 [RFC4447] "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", Martini L.,et al, RFC 4447, June 2005. [RFC5003] "Attachment Individual Identifier (AII) Types for Aggregation", Metz, et al, RFC5003, September 2007 [RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP", RFC3212, January 2002. 13. Informative References [MS-REQ] Martini et al, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC5023, Bitar, Martini, Bocci, October 2008 [MS-ARCH] Bocci at al, "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-06.txt, February 2009, IETF work in progress Martini, et al. [Page 16] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 [RFC4760] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [L2-SIGNALING] E. Rosen, W. Luo, B. Davie, V. Radoaca, "Provisioning, Autodiscovery, and Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt May 3, 2006.(work in progress) 14. Author's Addresses Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 e-mail: lmartini@cisco.com Matthew Bocci Alcatel-Lucent, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel-lucent.co.uk Florin Balus Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 e-mail: florin.balus@alcatel-lucent.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 e-mail: nabil.bitar@verizon.com Himanshu Shah Ciena Corp 35 Nagog Park, Acton, MA 01720 e-mail: hshah@ciena.com Martini, et al. [Page 17] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata ON, Canada e-mail: mustapha.aissaoui@alcatel-lucent.com Jason Rusmisel Alcatel-Lucent 600 March Road Kanata ON, Canada e-mail: Jason.rusmisel@alcatel-lucent.com Yetik Serbest SBC Labs 9505 Arboretum Blvd. Austin, TX 78759 e-mail: Yetik_serbest@labs.sbc.com Andrew G. Malis Verizon 2730 Orchard Parkway San Jose, CA, USA 95134 e-mail: Andy.Malis@tellabs.com Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 e-mail: chmetz@cisco.com David McDysan Verizon 22001 Loudoun County Pkwy Ashburn, VA, USA 20147 e-mail: dave.mcdysan@verizon.com Martini, et al. [Page 18] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Jeff Sugimoto Nortel 3500 Carling Ave. Ottawa, Ontario, CANADA e-mail: sugimoto@nortel.com Mike Duckett Bellsouth Lindbergh Center D481 575 Morosgo Dr Atlanta, GA 30324 e-mail: mduckett@bellsouth.net Mike Loomis Nortel 600, Technology Park Dr Billerica, MA, USA e-mail: mloomis@nortel.com Paul Doolan Mangrove Systems IO Fairfield Blvd Wallingford, CT, USA 06492 e-mail: pdoolan@mangrovesystems.com Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA, USA 94043 e-mail: ppan@hammerheadsystems.com Prayson Pate Overture Networks, Inc. 507 Airport Blvd, Suite 111 Morrisville, NC, USA 27560 e-mail: prayson.pate@overturenetworks.com Vasile Radoaca Alcatel-Lucent Optics Divison, Westford, MA, USA email: vasile.radoaca@alcatel-lucent.com Martini, et al. [Page 19] Internet Draft draft-ietf-pwe3-dynamic-ms-pw-09.txt March 9, 2009 Yuichiro Wada NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuke-ku Tokyo 163-1421, Japan e-mail: yuichiro.wada@ntt.com Yeongil Seo Korea Telecom Corp. 463-1 Jeonmin-dong, Yusung-gu Daejeon, Korea e-mail: syi1@kt.co.kr Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/licenseinfo). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Expiration Date: September 2009 Martini, et al. [Page 20] --------------080009070008030808080902-- From Lisa.Dusseault@messagingarchitects.com Mon Mar 9 14:17:18 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACBB3A68AA; Mon, 9 Mar 2009 14:17:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bTFcV3YEZ0l; Mon, 9 Mar 2009 14:17:17 -0700 (PDT) Received: from mplus1.messagingarchitects.com (bastille.gwtools.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id 01EA53A696F; Mon, 9 Mar 2009 14:17:16 -0700 (PDT) Received: from [192.168.1.100] lisad@messagingarchitects.com [74.95.2.169] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.release; Mon, 09 Mar 2009 17:18:15 -0400 X-MailFrom: Lisa.Dusseault@messagingarchitects.com Message-Id: <541528E2-3BE1-4257-9A24-B8A6F1289B56@messagingarchitects.com> From: Lisa Dusseault To: "iesg@ietf.org IESG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 14:17:46 -0700 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 09 Mar 2009 17:18:16 -0400 engine: XCFAntiVirus1 Engine; version: 3922 (20090309)/1082 (20090213)/1091 (20090309)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5548 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010207.49B5877D.0074,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.release ; timestamp: Mon, 09 Mar 2009 17:18:16 -0400 engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-6050-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.2.1/2009.03.07.23.21.46/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.01.22.21.42.10/2009.03.09.20.01.01/2009.03.09.01.40.00/2009.03.09.20.21.00/0/0/2009.02.14.00.34.21/; level: 1 ref: status: success ;error: none X-Mailman-Approved-At: Wed, 11 Mar 2009 17:21:38 -0700 Cc: tools-discuss@ietf.org Subject: [Tools-discuss] Different handling of RFC Editor submissions X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:17:18 -0000 I just had to handle a new RFC Editor submission. Along with my usual confusion about how to do this, I hate that it appears in my list of sponsored docs - the whole reason this doc is going to the RFC Editor is that we don't have the expertise to review it in APPS. I don't have the expertise. And I got a question from an unnamed AD who saw the doc on the agenda and asked "What's up with that!" It took us 10 minutes of explaining to each other why we didn't have the expertise to review it before I realized that he didn't realize it was an RFC Editor document and thought it was an actual IETF document. And remember the last time you had to fill in a ballot for one of these and were trying to figure out if you were agreeing with the inclusion of the IESG statement that this document does not conflict, or disagreeing with the inclusion of the IESG statement that it does conflict? For these and similar cases of confusion, I would like to find a way to handle RFC Editor submissions that does not involve treating them as IETF documents in the Tracker. It should be a much simpler process and not involve possible states like "Last Call Requested", "IESG Evaluation", and especially not "Approved" [by IESG] attached to the document. Does anybody with more tools exposure have an idea how to do this? If it were up to me, I'd propose using the existing ticket system and agenda management system that's mostly not handled by ADs. - The RFC editor would send an email request to the Secretariat ticket system (could be a sub-address, I don't care). - The Secretariat would automatically put it onto the next agenda at least one week away, but not under the Document Actions header (Management Issues would be fine.) Unless somebody proposed otherwise, the default answer would be "does not conflict". - An email goes out to the IESG saying there's a new RFC3932 evaluation needed. This gives people warning to see if they should propose a wording other than "does not conflict". - At the scheduled telechat agenda, the IESG votes to approve the response "does not conflict" (or another response if somebody prposed one). If the IESG is not ready to decide, the decision can be postponed to the mailing list or to the next telechat at the latest. - The Secretariat emails the chosen response to the RFC Ed and we're done. --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. From henrik@levkowetz.com Wed Mar 11 17:24:51 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4B3A68E3 for ; Wed, 11 Mar 2009 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wi6leJfM60j5 for ; Wed, 11 Mar 2009 17:24:51 -0700 (PDT) Received: from av9-1-sn2.hy.skanova.net (av9-1-sn2.hy.skanova.net [81.228.8.179]) by core3.amsl.com (Postfix) with ESMTP id 0FBCE3A67D4 for ; Wed, 11 Mar 2009 17:24:51 -0700 (PDT) Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id AFE03380C3; Thu, 12 Mar 2009 01:25:26 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8AE6138047; Thu, 12 Mar 2009 01:25:26 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0304B37E42; Thu, 12 Mar 2009 01:25:26 +0100 (CET) Received: from localhost ([127.0.0.1]:42286 helo=chardonnay.local) by shiraz.levkowetz.com with esmtp (Exim 4.69) (envelope-from ) id 1LhYjl-0003Bs-F4; Thu, 12 Mar 2009 01:25:25 +0100 Message-ID: <49B8566A.8040401@levkowetz.com> Date: Thu, 12 Mar 2009 01:25:14 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Luca Martini References: <49B566B3.7040901@cisco.com> In-Reply-To: <49B566B3.7040901@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDCB555C60A49F4B0CB4E7A59" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lmartini@cisco.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Idnits-2.11.04 Bug ... X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 00:24:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDCB555C60A49F4B0CB4E7A59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Luca, On 2009-03-09 19:57 Luca Martini said the following: > The attached document passes idnits 1 out of 3 times .... >=20 > when it fails : >=20 > idnits 2.11.05=20 > when it passes : >=20 > idnits 2.11.04=20 Yes. This was fixed in 2.11.05. I've checked that all instances of idnits are in sync now. Best, Henrik --------------enigDCB555C60A49F4B0CB4E7A59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkm4VnQACgkQeVhrtTJkXCO2cgCZAenZrYG+XThjBD6/d2oMj8RX dowAoNObld68G9qwGvdZrSVll7zBMs2O =FHNf -----END PGP SIGNATURE----- --------------enigDCB555C60A49F4B0CB4E7A59-- From brian.e.carpenter@gmail.com Wed Mar 11 18:04:35 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D93528C151; Wed, 11 Mar 2009 18:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 h9T1Ye8M2LvX; Wed, 11 Mar 2009 18:04:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 3A90928C13D; Wed, 11 Mar 2009 18:04:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g9so3353785rvb.5 for ; Wed, 11 Mar 2009 18:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GnYfaFLRcaPVVV+R6/K/QiYoTlxRZSWiNT9oMGk0vTc=; b=jPpS2X4uMTCIzsdOrsYKmIClW3C8aGmr/SaSzG8y1UpxAfOSZ0mHo/VJwBKrOakmE2 il+tcrmdhWb0ORO21BfBvdFyVeciAy0zFuQzAOgpDw2nILSdQBOlGYafMLV5J7UJgiTH OAmoJ09rJMDMaIeg7+Kfg5dei+uNg8xppPDUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=KtvboS2tKq8d8SuvDIceetXnyUyQYRUdgY7+o5+367TosirnunIJiSXoCnl8z3OHKg t3nVntDLm4xREWU7izFNwCsZ8ryNuJw26A8tyiYDNV4ium/g/B2iR6hEC/U4yuuy77QS 5xyU9w48XhN4qquStAZxb8FdYXy2vsKtadRCo= Received: by 10.114.157.1 with SMTP id f1mr5601211wae.43.1236819910995; Wed, 11 Mar 2009 18:05:10 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v39sm77884wah.40.2009.03.11.18.05.09 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 18:05:10 -0700 (PDT) Message-ID: <49B85FC8.3050703@gmail.com> Date: Thu, 12 Mar 2009 14:05:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault References: <541528E2-3BE1-4257-9A24-B8A6F1289B56@messagingarchitects.com> In-Reply-To: <541528E2-3BE1-4257-9A24-B8A6F1289B56@messagingarchitects.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org IESG" , tools-discuss@ietf.org Subject: Re: [Tools-discuss] Different handling of RFC Editor submissions X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:04:35 -0000 Lisa, These documents are identified in the tracker, and they appear in the IESG agenda in "3.3 Independent Submissions Via RFC Editor". I don't really know how that could be clearer ;-) Certainly the regular ballot never seemed quite right to me. I think it should look different, something like: [No comment] [No Conflict] [Conflicts] [Abstain] I agree that the states and the state diagram should also be different. However, I wouldn't remove the tracker from the picture - just make it do the right thing. Very similar remarks apply to IRTF documents. Brian On 2009-03-10 10:17, Lisa Dusseault wrote: > > I just had to handle a new RFC Editor submission. Along with my usual > confusion about how to do this, I hate that it appears in my list of > sponsored docs - the whole reason this doc is going to the RFC Editor is > that we don't have the expertise to review it in APPS. I don't have the > expertise. And I got a question from an unnamed AD who saw the doc on > the agenda and asked "What's up with that!" It took us 10 minutes of > explaining to each other why we didn't have the expertise to review it > before I realized that he didn't realize it was an RFC Editor document > and thought it was an actual IETF document. > > And remember the last time you had to fill in a ballot for one of these > and were trying to figure out if you were agreeing with the inclusion of > the IESG statement that this document does not conflict, or disagreeing > with the inclusion of the IESG statement that it does conflict? > > For these and similar cases of confusion, I would like to find a way to > handle RFC Editor submissions that does not involve treating them as > IETF documents in the Tracker. It should be a much simpler process and > not involve possible states like "Last Call Requested", "IESG > Evaluation", and especially not "Approved" [by IESG] attached to the > document. > > Does anybody with more tools exposure have an idea how to do this? > > If it were up to me, I'd propose using the existing ticket system and > agenda management system that's mostly not handled by ADs. > - The RFC editor would send an email request to the Secretariat ticket > system (could be a sub-address, I don't care). > - The Secretariat would automatically put it onto the next agenda at > least one week away, but not under the Document Actions header > (Management Issues would be fine.) Unless somebody proposed otherwise, > the default answer would be "does not conflict". > - An email goes out to the IESG saying there's a new RFC3932 evaluation > needed. This gives people warning to see if they should propose a > wording other than "does not conflict". > - At the scheduled telechat agenda, the IESG votes to approve the > response "does not conflict" (or another response if somebody prposed > one). If the IESG is not ready to decide, the decision can be postponed > to the mailing list or to the next telechat at the latest. > - The Secretariat emails the chosen response to the RFC Ed and we're done. > > --- Scanned by M+ Guardian Messaging Firewall --- > Messaging Architects sponsors The Spamhaus Project. > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > From Pasi.Eronen@nokia.com Thu Mar 12 00:30:56 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992FE3A6853 for ; Thu, 12 Mar 2009 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 v9rdx7YipceW for ; Thu, 12 Mar 2009 00:30:55 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 80FF63A69D6 for ; Thu, 12 Mar 2009 00:30:55 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2C7VMbY002171; Thu, 12 Mar 2009 09:31:24 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 09:31:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 09:31:15 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 12 Mar 2009 08:31:14 +0100 From: To: , Date: Thu, 12 Mar 2009 08:31:15 +0100 Thread-Topic: [Tools-discuss] dead or alive? Thread-Index: AcmikDAo/Y53iEQHR5mSr8uIxbYefQAU2vqQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1EF8A8C@NOK-EUMSG-01.mgdnok.nokia.com> References: <6.0.0.20.2.20090311112613.094e6c88@localhost> <49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com> <49B82675.90605@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 07:31:15.0327 (UTC) FILETIME=[86B8C8F0:01C9A2E4] X-Nokia-AV: Clean Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 07:30:56 -0000 Spencer Dawkins wrote: >=20 > Did I understand Pasi's previous note in this thread to say that if > all drafts had entries in the table that's used by the IESG tracker, > all the cool things that work for these drafts (like having a page > that shows all the versions of a draft, with diffs between each > version, etc) would automagically start working? I guess you mean the pages on tools.ietf.org, like this one?=20 http://tools.ietf.org/wg/tls/draft-ietf-tls-extractor/ They're more-or-less independent of the database and IESG tracker;=20 I think the current logic is that all WG documents have such page (even if they don't have entries in the second table -- for example, the tls-extractor draft doesn't have an entry yet). (But I'll be working on something related to this topic during the code sprint -- let's see if I get something shipped :) Best regards, Pasi= From spencer@wonderhamster.org Thu Mar 12 07:04:26 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E28C3A6A03 for ; Thu, 12 Mar 2009 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, STOX_REPLY_TYPE=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 Q2mJWWvLZkLX for ; Thu, 12 Mar 2009 07:04:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 7DB663A6806 for ; Thu, 12 Mar 2009 07:04:20 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LhlWW0QWE-000fkx; Thu, 12 Mar 2009 10:04:41 -0400 Message-ID: <8DB892AC9E6C4FA38D8A468C0DC985FB@china.huawei.com> From: "Spencer Dawkins" To: , References: <6.0.0.20.2.20090311112613.094e6c88@localhost><49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com><49B82675.90605@gmail.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8A8C@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 12 Mar 2009 09:04:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/GbZK1d1hLsPxMI5VQeCkkYFZxMqCWsuytiLs 3ciYwmB/gD4ENgHDwO4B2pQkzAPCpZE6FiWmLFTk8kf7aD0EYJ 38BMTQ3h65Z6E/LiGYTvjSCQTnGeW8WgDw15jJv72c= Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:04:26 -0000 Hi, Pasi, Yes, exactly. Is it imaginable that individual drafts might also have an equivalent page? Both inside and outside the IETF, I cringe when I send someone a link to draft-fred-grommet-03.txt when I know that link will be broken very soon. I'd much prefer to send a link to draft-fred-grommet and say "I'm looking at 03, but if there's an update, you'll see it there, too". Thanks, Spencer ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, March 12, 2009 2:31 AM Subject: RE: [Tools-discuss] dead or alive? Spencer Dawkins wrote: > > Did I understand Pasi's previous note in this thread to say that if > all drafts had entries in the table that's used by the IESG tracker, > all the cool things that work for these drafts (like having a page > that shows all the versions of a draft, with diffs between each > version, etc) would automagically start working? I guess you mean the pages on tools.ietf.org, like this one? http://tools.ietf.org/wg/tls/draft-ietf-tls-extractor/ They're more-or-less independent of the database and IESG tracker; I think the current logic is that all WG documents have such page (even if they don't have entries in the second table -- for example, the tls-extractor draft doesn't have an entry yet). (But I'll be working on something related to this topic during the code sprint -- let's see if I get something shipped :) Best regards, Pasi From Pasi.Eronen@nokia.com Thu Mar 12 07:08:57 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8370E3A6B12 for ; Thu, 12 Mar 2009 07:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Wp50VWf0tCqt for ; Thu, 12 Mar 2009 07:08:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 607663A677D for ; Thu, 12 Mar 2009 07:08:55 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2CE96hY005139; Thu, 12 Mar 2009 16:09:28 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 16:09:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 16:09:14 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 12 Mar 2009 15:09:13 +0100 From: To: , Date: Thu, 12 Mar 2009 15:09:12 +0100 Thread-Topic: [Tools-discuss] dead or alive? Thread-Index: AcmjG4ktASz/urQhTjC4Py3h2yiSPAAADzcQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1EF8EFF@NOK-EUMSG-01.mgdnok.nokia.com> References: <6.0.0.20.2.20090311112613.094e6c88@localhost><49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com><49B82675.90605@gmail.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8A8C@NOK-EUMSG-01.mgdnok.nokia.com> <8DB892AC9E6C4FA38D8A468C0DC985FB@china.huawei.com> In-Reply-To: <8DB892AC9E6C4FA38D8A468C0DC985FB@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2009 14:09:14.0235 (UTC) FILETIME=[1FA8FCB0:01C9A31C] X-Nokia-AV: Clean Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:08:57 -0000 Spencer Dawkins wrote: > Yes, exactly. Is it imaginable that individual drafts might=20 > also have an equivalent page? Depends on Henrik :) > Both inside and outside the IETF, I cringe when I send someone a > link to draft-fred-grommet-03.txt when I know that link will be > broken very soon. I'd much prefer to send a link to > draft-fred-grommet and say "I'm looking at 03, but if there's an > update, you'll see it there, too". Although non-WG drafts don't currently have draft history pages, the permanent links (to the latest version) still work: ASCII version: http://tools.ietf.org/id/draft-dawkins-nomcom-dont-wait HTMLized version: http://tools.ietf.org/html/draft-dawkins-nomcom-dont-wait Best regards, Pasi= From spencer@wonderhamster.org Thu Mar 12 07:52:31 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C1B3A6864 for ; Thu, 12 Mar 2009 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, STOX_REPLY_TYPE=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 OW0G9HegILYD for ; Thu, 12 Mar 2009 07:52:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 545833A6B8B for ; Thu, 12 Mar 2009 07:52:26 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LhmHF1cFF-000fwt; Thu, 12 Mar 2009 10:52:58 -0400 Message-ID: <2343BE327819454BB0ED79D853F6C528@china.huawei.com> From: "Spencer Dawkins" To: , References: <6.0.0.20.2.20090311112613.094e6c88@localhost><49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com><49B82675.90605@gmail.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8A8C@NOK-EUMSG-01.mgdnok.nokia.com> <8DB892AC9E6C4FA38D8A468C0DC985FB@china.huawei.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8EFF@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 12 Mar 2009 09:52:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19r9uLWufaJPxW91kG8ITEQXyGRsdydlWXnEkS vU0PJd4MSkavd9KidrfEcHjgqk29cQ9NS54Xpk9hYl6RbZSCRW 75q1udTut5Lm8irG2fU1UeO/DmhE2whOUTMbdhHmrU= Cc: duerst@it.aoyama.ac.jp, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 14:52:31 -0000 Hi, Pasi, That is helpful. A draft history page would be even better, but the permanent links solve my biggest problems. Thanks, Spencer ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, March 12, 2009 9:09 AM Subject: RE: [Tools-discuss] dead or alive? Spencer Dawkins wrote: > Yes, exactly. Is it imaginable that individual drafts might > also have an equivalent page? Depends on Henrik :) > Both inside and outside the IETF, I cringe when I send someone a > link to draft-fred-grommet-03.txt when I know that link will be > broken very soon. I'd much prefer to send a link to > draft-fred-grommet and say "I'm looking at 03, but if there's an > update, you'll see it there, too". Although non-WG drafts don't currently have draft history pages, the permanent links (to the latest version) still work: ASCII version: http://tools.ietf.org/id/draft-dawkins-nomcom-dont-wait HTMLized version: http://tools.ietf.org/html/draft-dawkins-nomcom-dont-wait Best regards, Pasi From brian.e.carpenter@gmail.com Thu Mar 12 13:51:54 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2162028C18A for ; Thu, 12 Mar 2009 13:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 PswfmVlazQd3 for ; Thu, 12 Mar 2009 13:51:50 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 3F9363A68FD for ; Thu, 12 Mar 2009 13:51:50 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so1216652rvb.49 for ; Thu, 12 Mar 2009 13:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=f4u0Ohf3J9nZLmmbKvvaqZ+admISD0KAfCSBa4owBDs=; b=rpLGAOO7f8krAu9RjaU8aLJZIYDKTBS/1lDUYkThBrt3C/EdsdNc1OVXxKiDcEfPao PApAgtrAsOrz2fC8JituecHApZ4RdmbwLKi03DuBgNl5myTsfqiLsZzfwp3lhX77oR+e L172rATb4LDSgA+8CQ6OIYt4tccY3lLpWRZD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=PRxiSaK3SJjl7OlU85XzS2H44S/T9wFqKzC48bZMdYN3dC8YbISXv/ppUsnZV8QsBb lB/tJOsMvNJoaskFgENoGEv6irg/pMBO6bR2EQQDUTw7tLolzquMAolCQq2j/1x88mz/ +/4keKEwnxcmQ0ERt0gyJuNTY/+Xw9mp7KFw0= Received: by 10.141.136.4 with SMTP id o4mr132674rvn.13.1236891148091; Thu, 12 Mar 2009 13:52:28 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k2sm3694530rvb.4.2009.03.12.13.52.26 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Mar 2009 13:52:27 -0700 (PDT) Message-ID: <49B97608.3070109@gmail.com> Date: Fri, 13 Mar 2009 09:52:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Spencer Dawkins References: <6.0.0.20.2.20090311112613.094e6c88@localhost><49B7348F.4000601@gmail.com><6.0.0.20.2.20090311140004.08d55f00@localhost><808FD6E27AD4884E94820BC333B2DB7727F1E99667@NOK-EUMSG-01.mgdnok.nokia.com><49B82675.90605@gmail.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8A8C@NOK-EUMSG-01.mgdnok.nokia.com> <8DB892AC9E6C4FA38D8A468C0DC985FB@china.huawei.com> <808FD6E27AD4884E94820BC333B2DB7727F1EF8EFF@NOK-EUMSG-01.mgdnok.nokia.com> <2343BE327819454BB0ED79D853F6C528@china.huawei.com> In-Reply-To: <2343BE327819454BB0ED79D853F6C528@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: duerst@it.aoyama.ac.jp, Pasi.Eronen@nokia.com, tools-discuss@ietf.org Subject: Re: [Tools-discuss] dead or alive? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 20:51:54 -0000 You can even get very cute: http://tinyurl.com/numnum Brian On 2009-03-13 03:52, Spencer Dawkins wrote: > Hi, Pasi, > > That is helpful. A draft history page would be even better, but the > permanent links solve my biggest problems. > > Thanks, > > Spencer > > ----- Original Message ----- From: > To: ; > Cc: ; > Sent: Thursday, March 12, 2009 9:09 AM > Subject: RE: [Tools-discuss] dead or alive? > > > Spencer Dawkins wrote: > >> Yes, exactly. Is it imaginable that individual drafts might >> also have an equivalent page? > > Depends on Henrik :) > >> Both inside and outside the IETF, I cringe when I send someone a >> link to draft-fred-grommet-03.txt when I know that link will be >> broken very soon. I'd much prefer to send a link to >> draft-fred-grommet and say "I'm looking at 03, but if there's an >> update, you'll see it there, too". > > Although non-WG drafts don't currently have draft history pages, > the permanent links (to the latest version) still work: > > ASCII version: > http://tools.ietf.org/id/draft-dawkins-nomcom-dont-wait > > HTMLized version: > http://tools.ietf.org/html/draft-dawkins-nomcom-dont-wait > > Best regards, > Pasi > > From aakhter@cisco.com Wed Mar 18 13:36:12 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED7528C22D for ; Wed, 18 Mar 2009 13:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 34Z439RGgOIV for ; Wed, 18 Mar 2009 13:36:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id CD02428C1FA for ; Wed, 18 Mar 2009 13:36:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,386,1233532800"; d="scan'208,217";a="39903104" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2009 20:36:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2IKat21005858 for ; Wed, 18 Mar 2009 16:36:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2IKatli020796 for ; Wed, 18 Mar 2009 20:36:55 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 16:36:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A809.4693DC6D" Date: Wed, 18 Mar 2009 16:36:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D and RFCs in zotero? Thread-Index: AcmoCUWV1zmdpOC7SVW0Cod+1q4LSw== From: "Aamer Akhter (aakhter)" To: X-OriginalArrivalTime: 18 Mar 2009 20:36:54.0986 (UTC) FILETIME=[46A06AA0:01C9A809] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1395; t=1237408615; x=1238272615; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aakhter@cisco.com; z=From:=20=22Aamer=20Akhter=20(aakhter)=22=20 |Subject:=20I-D=20and=20RFCs=20in=20zotero? |Sender:=20 |To:=20; bh=xNhgzc/7WkF+uSmj/0PP2NCXmiHTKFmoLRdpKcYsnV0=; b=T/dlkx0x4GpqrWJjK2O30bSdq4QaocfF1E9gQJbqTDWbEeuXWOpRrqqarT ropOcmQEpf2DXPt6vh2YaX72S9JHsUDa+qJ6eztg8PpZpqdt5QHr8JOI2SXn 3tlTl5v5wg; Authentication-Results: rtp-dkim-2; header.From=aakhter@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Tools-discuss] I-D and RFCs in zotero? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 20:36:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A809.4693DC6D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Is there an easy (and updated) way to bring references into zotero? -- Aamer Akhter / aa@cisco.com cisco Systems ------_=_NextPart_001_01C9A809.4693DC6D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I-D and RFCs in zotero?

Is there an = easy (and updated) way to bring references into = zotero?

--

Aamer Akhter / = aa@cisco.com

cisco = Systems

------_=_NextPart_001_01C9A809.4693DC6D-- From enrico.marocco@telecomitalia.it Thu Mar 19 09:22:50 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6773C3A6BB6 for ; Thu, 19 Mar 2009 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 pUUqqCi04nUs for ; Thu, 19 Mar 2009 09:22:49 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id EF6653A6B70 for ; Thu, 19 Mar 2009 09:22:48 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 19 Mar 2009 17:23:33 +0100 Received: from [10.229.8.98] (10.229.8.98) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 19 Mar 2009 17:23:32 +0100 Message-ID: <49C27188.5080009@telecomitalia.it> Date: Thu, 19 Mar 2009 17:23:36 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070507090005020206060008" Subject: [Tools-discuss] Yet another I-D stats tool X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 16:22:50 -0000 --------------ms070507090005020206060008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, I've written a bunch of scripts to collect and display some statistics I couldn't find elsewhere, to get a feeling of the amount of activity regarding WG and non-WG documents. The tool is available online at http://ubiq.tilab.com/cgi-bin/idstats.cgi and can be queried through a very simple HTTP interface, just entering in a web browser URLs like http://ubiq.tilab.com/cgi-bin/idstats.cgi?query=draft-*-alto-* Of course I wrote the tool for myself, but if people think that a variant of it could be useful also to others I can help integrate it with other stats tools. Comments are welcome. For the brave: the (poorly written and uncommented) code is available at http://code.google.com/p/idstats/. The database that acts as a back end for the tool takes approximately 70 hours to create from scratch on a ~6K bogomips processor; ask me offlist if you want a dump of the one I'm currently using. -- Ciao, Enrico --------------ms070507090005020206060008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMTkxNjIzMzZaMCMG CSqGSIb3DQEJBDEWBBRDr1Y1P1n6UNH9RzB2z6+Bo31cZzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBADfrJzAq2Oj1 jJY9gh9Cn/a2feU74GZHxmfmfOV1ROQFpiEFR7rpnrM1B7hRfwnqsuW/l0w9i68gAiKKOp9Z GO6BFwBEP9ceFGLG9OkQ8te5FCQg/I8jOQloBaSsQ9claF5LwLNotMj9fV4vlm4gG92zNPL/ 1eeNOQc9t857xplBe33BMcFzXD/IDQSjaGNFa4jSTrvWJPPl/WD8XfRF2/oYlpEjWhPNBlax C8wViVHikRJheWEfbHMggfueEpfouOF305kHe33FUMmt+ER3HczBhneLLkxmo716e6gROAUu GL4aIxxiJ6q+2MJzfkIOEKXuxfa4LIVuFoS3WgveWkoAAAAAAAA= --------------ms070507090005020206060008-- From brian.e.carpenter@gmail.com Thu Mar 19 13:40:24 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34493A6902 for ; Thu, 19 Mar 2009 13:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 PFhzEGLEc-iu for ; Thu, 19 Mar 2009 13:40:23 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id D61CB28C173 for ; Thu, 19 Mar 2009 13:40:23 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so837229wfg.31 for ; Thu, 19 Mar 2009 13:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4EbfL9uG6ONIT1XES1c7hfwud7z92TGl/9rk6vxyQFE=; b=K0K8cCdzb7dzKiGfCWCVTk7iQGaNm+gY1JwIIV44a7JSFarx4pfgpoNK6CeBehVIY/ /lbHNi4udANiC3cEYXblYntULG9n8YuEpcn3Ch1pGXYMGi4vccByZn5QyPNJHY52Au8M NVIMvOtJIsf6p+YJ90A3aTLOdeXO7+aGfQKP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GmqyK4u+V0pi0GWQdQMCpAgJVJDefkwtyfYkL7Pz38mhXZ5sBxyIZhy+ZE3tN96zcB 56CJnx/AvJ2fU1ZIbegBFbDO5ikHg03o4/7N+xDx6BugAeHrDQCG0KusrWyskgJUu9tU kE2xLqu/hYvhJ6bl490uhV/SLjEMt8zx91pTc= Received: by 10.143.1.12 with SMTP id d12mr1106675wfi.189.1237495269530; Thu, 19 Mar 2009 13:41:09 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 30sm2324977wfg.34.2009.03.19.13.41.08 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Mar 2009 13:41:08 -0700 (PDT) Message-ID: <49C2ADCD.1040307@gmail.com> Date: Fri, 20 Mar 2009 09:40:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Enrico Marocco References: <49C27188.5080009@telecomitalia.it> In-Reply-To: <49C27188.5080009@telecomitalia.it> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] Yet another I-D stats tool X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:40:25 -0000 Great fun. http://ubiq.tilab.com/cgi-bin/idstats.cgi?query=draft-templin-autoconf-dhcp* is probably my favourite. Brian On 2009-03-20 05:23, Enrico Marocco wrote: > Folks, > > I've written a bunch of scripts to collect and display some statistics I > couldn't find elsewhere, to get a feeling of the amount of activity > regarding WG and non-WG documents. The tool is available online at > http://ubiq.tilab.com/cgi-bin/idstats.cgi and can be queried through a > very simple HTTP interface, just entering in a web browser URLs like > http://ubiq.tilab.com/cgi-bin/idstats.cgi?query=draft-*-alto-* > > Of course I wrote the tool for myself, but if people think that a > variant of it could be useful also to others I can help integrate it > with other stats tools. Comments are welcome. > > For the brave: the (poorly written and uncommented) code is available at > http://code.google.com/p/idstats/. The database that acts as a back end > for the tool takes approximately 70 hours to create from scratch on a > ~6K bogomips processor; ask me offlist if you want a dump of the one I'm > currently using. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From munjo.yu@gmail.com Wed Mar 25 17:01:37 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB953A6DC0 for ; Wed, 25 Mar 2009 17:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 tOLdl7y0T2JX for ; Wed, 25 Mar 2009 17:01:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 4251E3A67AD for ; Wed, 25 Mar 2009 17:01:36 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so291195qwb.31 for ; Wed, 25 Mar 2009 17:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=SlK3KgkIEDrPBR5t49lmUQSI9wWiMs+wcM5BYDtPMBU=; b=wr0aRUl9MvoewHcJGuWm5ZL+9iO4JLS80oGhsp+6u/Is0tQIf/Js6+wvSpENJJsFtO C/I/HU/1znvFkga5ZC8b0V8zibz54AEVr8PU2AXeHpg5RClaEEHfejd5l9hImkIi11oF fKUNZ7/q0mKEJTllCUmWA6kntaRxSeReCLdjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FA+0DmNg7sDw8TjHNpCuN3XvF5nXONlvcRBcDXyPS+O2qeiDqibCBYK9YeKeHO5sbO 3SZlqvuEm6fNIwuH5RiDwsjqvAaqEJosx/GSKppaDT22JA8xw9Y+gqeFWsu6f3/ZHXaG 2eC5S+0yhVCMGTKf76SZJhe15Rxa2O4ZZPoJA= MIME-Version: 1.0 Received: by 10.229.85.21 with SMTP id m21mr100439qcl.9.1238025748713; Wed, 25 Mar 2009 17:02:28 -0700 (PDT) Date: Thu, 26 Mar 2009 09:02:28 +0900 Message-ID: From: Joe Munjo Yu To: tools-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Mar 2009 09:06:57 -0700 Subject: [Tools-discuss] ABNF parser generator with extensions X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:01:37 -0000 Hello, I am Munjo Yu, an attendee of the 74th IETF. VineGen Inc which I am working with, has an ABNF parser generator. This parser generator generates complete parser code. To achieve this goal of no need for hand coding, we had to add a couple of extensions to ABNF. Dave Crocker, during our chats, suggested me to post an email to the app mailing list. As a parallel effort, I am seeking to have a link on the IETF tools web page, to the ABNF parser generator download page in our web page. So that if anyone in the IETF community needs a "complete" ABNF parser generator, then they can use our parser generator. If you give me some advice about how to proceed, I'll greatly appreciate. Thanks, -Munjo Yu P.S. I'll be somewhere in the 74th meeting - tomorrow and early Friday, so if you let me know your name I'll try to catch you. From henrik@levkowetz.com Thu Mar 26 12:38:17 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADF628C1F0 for ; Thu, 26 Mar 2009 12:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 eUcQbLmUKQeD for ; Thu, 26 Mar 2009 12:38:17 -0700 (PDT) Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by core3.amsl.com (Postfix) with ESMTP id 153213A6C0D for ; Thu, 26 Mar 2009 12:38:17 -0700 (PDT) Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 09ED938573; Thu, 26 Mar 2009 20:39:10 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id B78EC383EB; Thu, 26 Mar 2009 20:39:09 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id A73DB37E44; Thu, 26 Mar 2009 20:39:09 +0100 (CET) Received: from localhost ([127.0.0.1]:34938 helo=dhcp-56fe.meeting.ietf.org) by shiraz.levkowetz.com with esmtp (Exim 4.69) (envelope-from ) id 1LmvPx-0001ZQ-6R; Thu, 26 Mar 2009 20:39:09 +0100 Message-ID: <49CBD9D9.4060007@levkowetz.com> Date: Thu, 26 Mar 2009 12:39:05 -0700 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Joe Munjo Yu References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: munjo.yu@gmail.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] ABNF parser generator with extensions X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:38:17 -0000 Hi, On 2009-03-25 17:02 Joe Munjo Yu said the following: ... > As a parallel effort, I am seeking to have a link on the IETF tools > web page, to the ABNF parser generator download page in our web page. If you let me know the appropriate URL and a paragraph describing the service, I'll add a link to the ABNF parser generator to the appropriate tool pages. Best, Henrik From Martin.Thomson@andrew.com Thu Mar 26 17:05:06 2009 Return-Path: X-Original-To: tools-discuss@core3.amsl.com Delivered-To: tools-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58C93A6BFD for ; Thu, 26 Mar 2009 17:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 fwswokt-grrA for ; Thu, 26 Mar 2009 17:05:05 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BE3513A6BF1 for ; Thu, 26 Mar 2009 17:05:05 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_26_19_26_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 26 Mar 2009 19:26:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 19:05:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 26 Mar 2009 19:05:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ABNF to Regular Expression Tool Thread-Index: Acmub83hwTKwjWPkQ3+Xs0eGxVIRKw== From: "Thomson, Martin" To: X-OriginalArrivalTime: 27 Mar 2009 00:05:59.0008 (UTC) FILETIME=[CEC04600:01C9AE6F] Subject: [Tools-discuss] ABNF to Regular Expression Tool X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:05:06 -0000 SGkgRm9sa3MsDQoNCkNvbnRpbnVpbmcgdGhlIHRoZW1lIG9uIEFCTkYuLi4gQXMgc29tZXRoaW5n IG9mIGEgZ2FtZSwgSSd2ZSBkZXZlbG9wZWQgYSB0b29sIHRoYXQgaXMgYWJsZSB0byB0YWtlIGEg Z3JhbW1hciByZXByZXNlbnRlZCBieSBBQk5GIGFuZCBjb252ZXJ0IGl0IHRvIGEgcmVndWxhciBl eHByZXNzaW9uLg0KDQpUaGVyZSBpcyBvbmx5IG1pbmltYWwgb3B0aW1pemF0aW9uIG9mIHRoZSBy ZWdleCB0aGF0IGl0IHByb2R1Y2VzLCBidXQgaXQgaXMgYWJsZSB0byBwcm9kdWNlIGEgY29tcGxl dGUgcmVnZXggZm9yIHRoZSBiaWcgb25lczogUkZDIDM5ODYsIFJGQyA1MzIyICh0aGUgcmVnZXgg Zm9yIGEgY29tcGxldGUgbWFpbCBtZXNzYWdlIHdhcyBwcm9iYWJseSB0b28gbGFyZ2UgdG8gYmUg dXNlZnVsLCB+NDBrISkuICBJdCBzdHJ1Z2dsZXMgd2hlcmUgdGhlIGdyYW1tYXIgcmVjdXJzZXMs IGZhbGxpbmcgYmFjayB0byAnLionLCBidXQgYXNpZGUgZnJvbSB0aGF0IGl0IHNlZW1zIGFjY3Vy YXRlLiAgDQoNCldoZW4gaXQgY29tZXMgZG93biB0byBpdCwgaXQncyBub3QgdGhhdCB1c2VmdWws IGJ1dCBpdCB3YXMgYSBwbGVhc2FudCBkaXN0cmFjdGlvbi4NCg0KSSBoYXZlIHB1dCBzb3VyY2Ug dXAgb24gZ2l0aHViIHVuZGVyIHRoZSBuYW1lIGFibmYycmVnZXg6DQoNCiAgPGh0dHA6Ly9naXRo dWIuY29tL21hcnRpbnRob21zb24vYWJuZjJyZWdleC90cmVlL21hc3Rlcj4NCg0KQ2hlZXJzLA0K TWFydGluDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFp biBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRp b24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg==