From ietfdbh@comcast.net Mon Sep 13 11:10:16 2010 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 E9AEA3A6A94 for ; Mon, 13 Sep 2010 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.906 X-Spam-Level: X-Spam-Status: No, score=-100.906 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_50=0.001, 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 B+EtW55GP92Y for ; Mon, 13 Sep 2010 11:10:16 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 1DD233A6A92 for ; Mon, 13 Sep 2010 11:10:12 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id 6AjX1f00617dt5G5AJAfcS; Mon, 13 Sep 2010 18:10:39 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id 6JAe1f00G2JQnJT3ZJAe8i; Mon, 13 Sep 2010 18:10:39 +0000 From: "David Harrington" To: Date: Mon, 13 Sep 2010 14:10:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActTbuX9xV4nmYqoQzaVXWecpRFrlw== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: [Tools-discuss] wiki-trac 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, 13 Sep 2010 18:10:17 -0000 Hi, Can we get some sort of SCCS lock capability on wiki-trac? I just entered a BOF Request, which was rather slow and time-consuming given the arcane formatting we use, and the difficulty of cutting and pasting due to the way the cursor keeps repositioning the page while you edit. And somebody went in while I was previewing my changes, did an edit, and I lost all my work. I cannot tell when somebody else is editing, so I don't know when it is safe to go back and do my edits again, so that I don't interrupt their editing session. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From ietfdbh@comcast.net Tue Sep 14 11:20:19 2010 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 9BDFA3A6A2C for ; Tue, 14 Sep 2010 11:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 kJ6bw0hRsa1Y for ; Tue, 14 Sep 2010 11:20:18 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 8424F3A6870 for ; Tue, 14 Sep 2010 11:20:18 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta06.westchester.pa.mail.comcast.net with comcast id 6aoG1f00416LCl056iLlHc; Tue, 14 Sep 2010 18:20:45 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta06.westchester.pa.mail.comcast.net with comcast id 6iLk1f00C2JQnJT3SiLlz9; Tue, 14 Sep 2010 18:20:45 +0000 From: "David Harrington" To: Date: Tue, 14 Sep 2010 14:19:48 -0400 Message-ID: <14CD4106120343C28507C4642C95AF3C@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActUOWpC7K5N/WuxSy2KjtzXC6xApQ== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: [Tools-discuss] email aliases 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, 14 Sep 2010 18:20:19 -0000 Hi, any chance we can migrate the aliases@tools.ietf.org to aliases@ietf.org, so I don't have to keep trying to remember which aliases fall within which domain? I getting old, and my memory ain't what it is used to be. I'm getting tired of bounced messages because we have two different domains to do alias resolution. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From henrik@levkowetz.com Thu Sep 16 03:52:16 2010 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 28D5A3A68E3 for ; Thu, 16 Sep 2010 03:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sVtiw73etDEz for ; Thu, 16 Sep 2010 03:52:12 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 3F35A3A68CD for ; Thu, 16 Sep 2010 03:52:12 -0700 (PDT) Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:62811 helo=dyn-fg124.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OwC4n-0001Kd-Qe; Thu, 16 Sep 2010 12:52:26 +0200 Message-ID: <4C91F6E9.8040102@levkowetz.com> Date: Thu, 16 Sep 2010 12:52:25 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e X-SA-Exim-Rcpt-To: ietfdbh@comcast.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] wiki-trac 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, 16 Sep 2010 10:52:16 -0000 Hi David, On 2010-09-13 20:10 David Harrington said: > Hi, > > Can we get some sort of SCCS lock capability on wiki-trac? > I just entered a BOF Request, which was rather slow and time-consuming > given the arcane formatting we use, and the difficulty of cutting and > pasting due to the way the cursor keeps repositioning the page while > you edit. > And somebody went in while I was previewing my changes, did an edit, > and I lost all my work. Ouch. But maybe not necessary, see below... > I cannot tell when somebody else is editing, so I don't know when it > is safe to go back and do my edits again, so that I don't interrupt > their editing session. The handling already implemented in Trac is to 1) keep the edited text in a text box in the view which tells you that the page has been modified by somebody else, so you can copy it out and then fix things in a new edit, and 2) at the bottom of the page, provide 'Merge changes' button which you can use to merge in your changes to the modified page. I think this is a reasonable handling? Best, Henrik From henrik@levkowetz.com Thu Sep 16 03:57:33 2010 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 D74B53A6924 for ; Thu, 16 Sep 2010 03:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 xbAbA3I6p9Pj for ; Thu, 16 Sep 2010 03:57:33 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id BFE4D3A6899 for ; Thu, 16 Sep 2010 03:57:32 -0700 (PDT) Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:62972 helo=dyn-fg124.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OwCA0-00028O-Hi; Thu, 16 Sep 2010 12:57:48 +0200 Message-ID: <4C91F82C.1060405@levkowetz.com> Date: Thu, 16 Sep 2010 12:57:48 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: David Harrington References: <14CD4106120343C28507C4642C95AF3C@23FX1C1> In-Reply-To: <14CD4106120343C28507C4642C95AF3C@23FX1C1> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e X-SA-Exim-Rcpt-To: ietfdbh@comcast.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] email aliases 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, 16 Sep 2010 10:57:33 -0000 Hi David, On 2010-09-14 20:19 David Harrington said: > Hi, > > any chance we can migrate the aliases@tools.ietf.org to > aliases@ietf.org, so I don't have to keep trying to remember which > aliases fall within which domain? > > I getting old, and my memory ain't what it is used to be. I'm getting > tired of bounced messages because we have two different domains to do > alias resolution. I don't mind in the least, quite the other way around. But somebody has to do the work, I've got a backlog which is ploughing me under and I'm trying to prioritise as best I can... Because things are continually changing, the alias lists have to be re-generated frequently (currently it's done hourly) and the main IETF mail server doesn't have the infrastructure (files, directories, etc.) which the current scripts expect. This means that new scripts need to be written to generate the alias lists from the database, rather than from the flat text files which are used on the tools servers. Best, Henrik From ietfdbh@comcast.net Thu Sep 16 07:50:49 2010 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 D06863A6B61 for ; Thu, 16 Sep 2010 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.478 X-Spam-Level: X-Spam-Status: No, score=-101.478 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_05=-1.11, 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 8x0+U8xZEvJR for ; Thu, 16 Sep 2010 07:50:48 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 7D7183A6B62 for ; Thu, 16 Sep 2010 07:50:12 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id 7NnN1f0021ei1Bg5ASqeRo; Thu, 16 Sep 2010 14:50:38 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id 7Sqd1f00H2JQnJT3kSqdwC; Thu, 16 Sep 2010 14:50:38 +0000 From: "David Harrington" To: "'Henrik Levkowetz'" References: <4C91F6E9.8040102@levkowetz.com> Date: Thu, 16 Sep 2010 10:49:48 -0400 Message-ID: <1EFECC703E94443286289B0616CB60BD@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-index: ActVjUgvRvHXg4kmQCeNbOSoMH5JmQAH67FQ In-Reply-To: <4C91F6E9.8040102@levkowetz.com> Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] wiki-trac 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, 16 Sep 2010 14:50:50 -0000 Hi Henrik, Well, I saw the merge button, and I am used to CVS merge handling. But I have no experience with Trac merge handling, and bluntly I didn't trust it because I lacked experience with it. If I had done the merge it would have occurred while somebody else was apparently actively editing the same page. Given that the merge is calculated based on a snapshot of the page at the time of the merge, if it is a moving target, I'm not sure how well the merge would work. I did actually cut and paste my work into a file so I didn't lose it. But I could not tell when somebody else was editing, so I could not tell when it was safe for me to re-submit without causing a merge problem. (and I think the edits being done did not overlap with mine, which I think would have been fine with a CVS system). A little indicator that somebody else was actively editing the page would have been wonderful. But, given the frequency that this problem occurs, it certainly is not one of the higher priority items. Thanks, dbh > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Thursday, September 16, 2010 6:52 AM > To: David Harrington > Cc: tools-discuss@ietf.org > Subject: Re: [Tools-discuss] wiki-trac > > Hi David, > > On 2010-09-13 20:10 David Harrington said: > > Hi, > > > > Can we get some sort of SCCS lock capability on wiki-trac? > > I just entered a BOF Request, which was rather slow and > time-consuming > > given the arcane formatting we use, and the difficulty of > cutting and > > pasting due to the way the cursor keeps repositioning the > page while > > you edit. > > And somebody went in while I was previewing my changes, did > an edit, > > and I lost all my work. > > Ouch. But maybe not necessary, see below... > > > I cannot tell when somebody else is editing, so I don't > know when it > > is safe to go back and do my edits again, so that I don't interrupt > > their editing session. > > The handling already implemented in Trac is to 1) keep the > edited text in a text box in the view which tells you that > the page has been modified by somebody else, so you can copy > it out and then fix things in a new edit, and 2) at the > bottom of the page, provide 'Merge changes' button which you > can use to merge in your changes to the modified page. I > think this is a reasonable handling? > > > Best, > > Henrik > From henrik@levkowetz.com Thu Sep 16 08:27:35 2010 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 D02DC3A698A for ; Thu, 16 Sep 2010 08:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Am0pgvT64S2V for ; Thu, 16 Sep 2010 08:27:34 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 6BA4D3A6B4D for ; Thu, 16 Sep 2010 08:27:34 -0700 (PDT) Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:55214 helo=dyn-fg124.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OwGNJ-0007yV-0Q; Thu, 16 Sep 2010 17:27:50 +0200 Message-ID: <4C923774.8010606@levkowetz.com> Date: Thu, 16 Sep 2010 17:27:48 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: David Harrington References: <4C91F6E9.8040102@levkowetz.com> <1EFECC703E94443286289B0616CB60BD@23FX1C1> In-Reply-To: <1EFECC703E94443286289B0616CB60BD@23FX1C1> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e X-SA-Exim-Rcpt-To: ietfdbh@comcast.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] wiki-trac 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, 16 Sep 2010 15:27:35 -0000 Hi David, On 2010-09-16 16:49 David Harrington said: > Hi Henrik, > > Well, I saw the merge button, and I am used to CVS merge handling. > But I have no experience with Trac merge handling, and bluntly I > didn't trust it because I lacked experience with it. Ah, well. The only way to get experience is to try it. Trac maintains all back revisions, so it's easy enough to revert to an earlier version if the merge proves catastrophic. > If I had done the merge it would have occurred while somebody else was > apparently actively editing the same page. Not necessarily so; you received the conflict warning because someone else had completed an edit meanwhile. If you had done your merge, and they had continued to work on another edit, they would have received a conflict message and merge offer in turn, which should also have turned out well if you hadn't been editing the same piece of text... > Given that the merge is > calculated based on a snapshot of the page at the time of the merge, > if it is a moving target, I'm not sure how well the merge would work. The merge is between the new version and the most recently committed version; I think it should be just fine as long as the edits don't overlap. > I did actually cut and paste my work into a file so I didn't lose it. Ah. Good. > But I could not tell when somebody else was editing, so I could not > tell when it was safe for me to re-submit without causing a merge > problem. (and I think the edits being done did not overlap with mine, > which I think would have been fine with a CVS system). And the same should be the case here. > A little indicator that somebody else was actively editing the page > would have been wonderful. But that would also require everybody to tell the system when they abandon an edit (which not everybody are going to do) or rely on a reasonable timeout, which would let you sit and wait for maybe 5 or 15 minutes before you could submit your edit. I think the merge approach is a rather good solution, and as mentioned above, the ability to revert to earlier versions of the page makes sure that no merge can be catastrophic. > But, given the frequency that this problem occurs, it certainly is not > one of the higher priority items. Also true. Best, Henrik From dwing@cisco.com Sat Sep 18 13:14:54 2010 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 9735A3A6825 for ; Sat, 18 Sep 2010 13:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.381 X-Spam-Level: X-Spam-Status: No, score=-110.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 KgFovEUFShpk for ; Sat, 18 Sep 2010 13:14:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DA1FA3A6804 for ; Sat, 18 Sep 2010 13:14:51 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABu7lEyrR7Ht/2dsb2JhbACVZoxScaRXm26FQQSETg X-IronPort-AV: E=Sophos;i="4.56,387,1280707200"; d="scan'208";a="591380560" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2010 20:15:16 +0000 Received: from dwingWS ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8IKFGWZ026460; Sat, 18 Sep 2010 20:15:16 GMT From: "Dan Wing" To: "'Henrik Levkowetz'" , "'David Harrington'" References: <14CD4106120343C28507C4642C95AF3C@23FX1C1> <4C91F82C.1060405@levkowetz.com> In-Reply-To: <4C91F82C.1060405@levkowetz.com> Date: Sat, 18 Sep 2010 13:15:15 -0700 Message-ID: <0a3701cb576e$353cfec0$9fb6fc40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActVjg15+HA93So8Rt++WHF/MYKvXwB3xuZQ Content-Language: en-us Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] email aliases 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: Sat, 18 Sep 2010 20:14:54 -0000 > -----Original Message----- > From: tools-discuss-bounces@ietf.org [mailto:tools-discuss- > bounces@ietf.org] On Behalf Of Henrik Levkowetz > Sent: Thursday, September 16, 2010 3:58 AM > To: David Harrington > Cc: tools-discuss@ietf.org > Subject: Re: [Tools-discuss] email aliases > > Hi David, > > On 2010-09-14 20:19 David Harrington said: > > Hi, > > > > any chance we can migrate the aliases@tools.ietf.org to > > aliases@ietf.org, so I don't have to keep trying to remember which > > aliases fall within which domain? > > > > I getting old, and my memory ain't what it is used to be. I'm getting > > tired of bounced messages because we have two different domains to do > > alias resolution. > > I don't mind in the least, quite the other way around. But somebody > has to do the work, I've got a backlog which is ploughing me under and > I'm trying to prioritise as best I can... > > Because things are continually changing, the alias lists have to be > re-generated frequently (currently it's done hourly) and the main IETF > mail server doesn't have the infrastructure (files, directories, etc.) > which the current scripts expect. This means that new scripts need to > be written to generate the alias lists from the database, rather than > from the flat text files which are used on the tools servers. Could the main ietf.org servers simply route messages to draft-* and *-wg (etc.) to tools.ietf.org? They appear to be running postfix and a virtual alias map should do the trick, something like this, /^draft-(.*)@ietf.org$/ draft-${1}@tools.ietf.org /^(.*)-chairs@ietf.org$/ ${1}-chairs@tools.ietf.org and so on. The tools server would get the messages and deliver them or bounce them, as necessary. Only drawback seems to be NDN blow- back because ietf.org won't reject the messages for invalid destinations (it will accept the message, attempt to deliver to tools, which will reject it, and ietf.org's mailservers will have to generate an NDN message). -d From henrik@levkowetz.com Mon Sep 20 02:02:13 2010 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 4C7003A69AB for ; Mon, 20 Sep 2010 02:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 TKWLERPUxMsU for ; Mon, 20 Sep 2010 02:02:12 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 2C5223A69A5 for ; Mon, 20 Sep 2010 02:02:12 -0700 (PDT) Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:57108 helo=dyn-fg124.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OxcGQ-00043h-3a; Mon, 20 Sep 2010 11:02:19 +0200 Message-ID: <4C972319.9020702@levkowetz.com> Date: Mon, 20 Sep 2010 11:02:17 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dan Wing References: <14CD4106120343C28507C4642C95AF3C@23FX1C1> <4C91F82C.1060405@levkowetz.com> <0a3701cb576e$353cfec0$9fb6fc40$@com> In-Reply-To: <0a3701cb576e$353cfec0$9fb6fc40$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e X-SA-Exim-Rcpt-To: dwing@cisco.com, ietfdbh@comcast.net, tools-discuss@ietf.org, glen@amsl.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: 'David Harrington' , tools-discuss@ietf.org, Glen Subject: Re: [Tools-discuss] email aliases 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, 20 Sep 2010 09:02:13 -0000 Hi Dan, Adding Cc: to Glen to this thread, for possible action. On 2010-09-18 22:15 Dan Wing said: ... >> Because things are continually changing, the alias lists have to be >> re-generated frequently (currently it's done hourly) and the main IETF >> mail server doesn't have the infrastructure (files, directories, etc.) >> which the current scripts expect. This means that new scripts need to >> be written to generate the alias lists from the database, rather than >> from the flat text files which are used on the tools servers. > > Could the main ietf.org servers simply route messages to draft-* > and *-wg (etc.) to tools.ietf.org? Yes, this is possible, and it's actually already being done for the *-chairs@ aliases. But this has its own problems, which has become apparent for the chairs aliases on several occasions. But if people think it's better than the current situation, I think it could be done. > They appear to be running postfix > and a virtual alias map should do the trick, something like this, > > /^draft-(.*)@ietf.org$/ draft-${1}@tools.ietf.org > /^(.*)-chairs@ietf.org$/ ${1}-chairs@tools.ietf.org > > and so on. The tools server would get the messages and deliver them > or bounce them, as necessary. Only drawback seems to be NDN blow- > back because ietf.org won't reject the messages for invalid > destinations (it will accept the message, attempt to deliver to > tools, which will reject it, and ietf.org's mailservers will have > to generate an NDN message). Yes. The setup is also a bit more complicated because we want to have also the forwarded aliases protected by postconfirm. I believe we've set this up for the *-chairs@ aliases, so there isn't anything new to to figure out for this, it's just that the setup is slightly more involved than just the alias maps you propose. Best, Henrik From glen@amsl.com Mon Sep 20 08:40:42 2010 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 04F8C3A69DB for ; Mon, 20 Sep 2010 08:40:42 -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=[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 a7xrRjrvsuxT for ; Mon, 20 Sep 2010 08:40:38 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 98F8C3A68E1 for ; Mon, 20 Sep 2010 08:39:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 8A110E08C0; Mon, 20 Sep 2010 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0aMtk-d2Ftf; Mon, 20 Sep 2010 08:39:57 -0700 (PDT) Received: from [192.168.1.101] (173-8-133-91-SFBA.hfc.comcastbusiness.net [173.8.133.91]) by c1a.amsl.com (Postfix) with ESMTPSA id 4B8B9E088C; Mon, 20 Sep 2010 08:39:57 -0700 (PDT) Message-ID: <4C97804A.4080302@amsl.com> Date: Mon, 20 Sep 2010 08:39:54 -0700 From: Glen Barney Organization: AMS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Henrik Levkowetz References: <14CD4106120343C28507C4642C95AF3C@23FX1C1> <4C91F82C.1060405@levkowetz.com> <0a3701cb576e$353cfec0$9fb6fc40$@com> <4C972319.9020702@levkowetz.com> In-Reply-To: <4C972319.9020702@levkowetz.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'David Harrington' , tools-discuss@ietf.org, Dan Wing Subject: Re: [Tools-discuss] email aliases 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, 20 Sep 2010 15:40:42 -0000 I'm good with whatever! Of course, I look to Henrik to steer this effort, but he knows he will have whatever support and work from me that he desires! Glen On 9/20/2010 2:02 AM, Henrik Levkowetz wrote: > Hi Dan, > > Adding Cc: to Glen to this thread, for possible action. > > On 2010-09-18 22:15 Dan Wing said: > ... >>> Because things are continually changing, the alias lists have to be >>> re-generated frequently (currently it's done hourly) and the main IETF >>> mail server doesn't have the infrastructure (files, directories, etc.) >>> which the current scripts expect. This means that new scripts need to >>> be written to generate the alias lists from the database, rather than >>> from the flat text files which are used on the tools servers. >> >> Could the main ietf.org servers simply route messages to draft-* >> and *-wg (etc.) to tools.ietf.org? > > Yes, this is possible, and it's actually already being done for the *-chairs@ > aliases. But this has its own problems, which has become apparent for the > chairs aliases on several occasions. But if people think it's better than > the current situation, I think it could be done. > >> They appear to be running postfix >> and a virtual alias map should do the trick, something like this, >> >> /^draft-(.*)@ietf.org$/ draft-${1}@tools.ietf.org >> /^(.*)-chairs@ietf.org$/ ${1}-chairs@tools.ietf.org >> >> and so on. The tools server would get the messages and deliver them >> or bounce them, as necessary. Only drawback seems to be NDN blow- >> back because ietf.org won't reject the messages for invalid >> destinations (it will accept the message, attempt to deliver to >> tools, which will reject it, and ietf.org's mailservers will have >> to generate an NDN message). > > Yes. The setup is also a bit more complicated because we want to have > also the forwarded aliases protected by postconfirm. I believe we've > set this up for the *-chairs@ aliases, so there isn't anything new to > to figure out for this, it's just that the setup is slightly more involved > than just the alias maps you propose. > > > Best, > > Henrik > From dwing@cisco.com Mon Sep 20 10:42:39 2010 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 5F8D53A676A for ; Mon, 20 Sep 2010 10:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.392 X-Spam-Level: X-Spam-Status: No, score=-110.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 z+Mq2OenYgVD for ; Mon, 20 Sep 2010 10:42:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3304B3A6AB7 for ; Mon, 20 Sep 2010 10:42:38 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEk5l0yrR7Hu/2dsb2JhbACVSYxScaY3nA2FQQSETg X-IronPort-AV: E=Sophos;i="4.56,394,1280707200"; d="scan'208";a="363601915" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2010 17:43:02 +0000 Received: from dwingWS ([10.32.240.196]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8KHh18O017584; Mon, 20 Sep 2010 17:43:01 GMT From: "Dan Wing" To: "'Henrik Levkowetz'" References: <14CD4106120343C28507C4642C95AF3C@23FX1C1> <4C91F82C.1060405@levkowetz.com> <0a3701cb576e$353cfec0$9fb6fc40$@com> <4C972319.9020702@levkowetz.com> In-Reply-To: <4C972319.9020702@levkowetz.com> Date: Mon, 20 Sep 2010 10:43:02 -0700 Message-ID: <0cce01cb58eb$45fe3e80$d1fabb80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActYopgagTlhBO/NQGqT1oOplssf7AASKNPg Content-Language: en-us Cc: 'David Harrington' , tools-discuss@ietf.org, 'Glen' Subject: Re: [Tools-discuss] email aliases 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, 20 Sep 2010 17:42:39 -0000 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Monday, September 20, 2010 2:02 AM > To: Dan Wing > Cc: 'David Harrington'; tools-discuss@ietf.org; Glen > Subject: Re: [Tools-discuss] email aliases > > Hi Dan, > > Adding Cc: to Glen to this thread, for possible action. > > On 2010-09-18 22:15 Dan Wing said: > ... > >> Because things are continually changing, the alias lists have to be > >> re-generated frequently (currently it's done hourly) and the main > IETF > >> mail server doesn't have the infrastructure (files, directories, > etc.) > >> which the current scripts expect. This means that new scripts need > to > >> be written to generate the alias lists from the database, rather > than > >> from the flat text files which are used on the tools servers. > > > > Could the main ietf.org servers simply route messages to draft-* > > and *-wg (etc.) to tools.ietf.org? > > Yes, this is possible, and it's actually already being done for the *- > chairs@ > aliases. But this has its own problems, which has become apparent for > the > chairs aliases on several occasions. But if people think it's better > than > the current situation, I think it could be done. > > > They appear to be running postfix > > and a virtual alias map should do the trick, something like this, > > > > /^draft-(.*)@ietf.org$/ draft-${1}@tools.ietf.org > > /^(.*)-chairs@ietf.org$/ ${1}-chairs@tools.ietf.org > > > > and so on. The tools server would get the messages and deliver them > > or bounce them, as necessary. Only drawback seems to be NDN blow- > > back because ietf.org won't reject the messages for invalid > > destinations (it will accept the message, attempt to deliver to > > tools, which will reject it, and ietf.org's mailservers will have > > to generate an NDN message). > > Yes. The setup is also a bit more complicated because we want to have > also the forwarded aliases protected by postconfirm. I believe we've > set this up for the *-chairs@ aliases, so there isn't anything new to > to figure out for this, it's just that the setup is slightly more > involved > than just the alias maps you propose. That sounds like a win. -d