From rpelletier@isoc.org Wed Sep 9 08:40:52 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDCC28C156 for ; Wed, 9 Sep 2009 08:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 z9gW1S5AUAt9 for ; Wed, 9 Sep 2009 08:40:51 -0700 (PDT) Received: from smtp174.iad.emailsrvr.com (smtp174.iad.emailsrvr.com [207.97.245.174]) by core3.amsl.com (Postfix) with ESMTP id 04FF828C231 for ; Wed, 9 Sep 2009 08:40:51 -0700 (PDT) Received: from relay7.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id EFAAA1DD7ED; Wed, 9 Sep 2009 11:41:20 -0400 (EDT) Received: by relay7.relay.iad.mlsrvr.com (Authenticated sender: rpelletier-AT-isoc.org) with ESMTPSA id 0F1011DD844; Wed, 9 Sep 2009 11:41:19 -0400 (EDT) Message-Id: <4CF54D2D-41F9-4102-AA38-12872CD77D90@isoc.org> From: Ray Pelletier To: tools-development@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) X-Priority: 1 Date: Wed, 9 Sep 2009 11:41:16 -0400 X-Mailer: Apple Mail (2.936) Cc: Steve Conte Subject: [TOOLS-DEVELOPMENT] Tools Agenda: 11 Sept 2009 X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:40:52 -0000 All; A reminder of the call scheduled for 11 September at 10:00 EDT (UTC-4) on WebEx (details below). I'll be on WebEx by 9:45 if you'd like to check out audio. Draft Agenda: 1. Database Redesign Update 2. Table of Vol Tools and Next Steps 3. List potential Mission Critical Tools & Services 4. Hiroshima Code Sprint: To Do List 5. Conte Update Talk to you then! Ray Topic: Tools Cmte Date: Friday, September 11, 2009 Time: 9:45 am, Eastern Time (New York, GMT-04:00) Meeting Number: 967 057 620 Meeting Password: (This meeting does not require a password.) 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=128371932&UID=1099779092&RT=MiMxMQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: (This meeting does not require a password.) 4. Click "Join Now". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=128371932&UID=1099779092&ORT=MiMxMQ%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=128371932&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:967 057 620 From rcallon@juniper.net Thu Sep 17 08:51:28 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED043A67AB; Thu, 17 Sep 2009 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 Vmn9Eju0Du4f; Thu, 17 Sep 2009 08:51:27 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id B5E1A3A6848; Thu, 17 Sep 2009 08:51:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSrJbMA8YScgDT09CM/CTLORVlcjrmBTB@postini.com; Thu, 17 Sep 2009 08:52:19 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 17 Sep 2009 08:51:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 17 Sep 2009 11:51:51 -0400 From: Ross Callon To: Adrian Farrel , "tools-development@ietf.org" Date: Thu, 17 Sep 2009 11:51:50 -0400 Thread-Topic: The useful alias addresses Thread-Index: Aco2/d+XNXOD+xTfSo6P+ISsJ2hcdQAsJxhA Message-ID: References: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> In-Reply-To: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> 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-Mailman-Approved-At: Thu, 17 Sep 2009 09:19:07 -0700 Cc: "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 15:51:28 -0000 My reluctance to use these aliases has been based all along on the problem = that I don't know for sure what email addresses they actually go to, and th= us I can't be sure that the email is actually going to the correct authors.= =20 Ross -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: 16 September 2009 14:45 To: tools-development@ietf.org Cc: iesg@ietf.org Subject: The useful alias addresses Hi, I seriously love the draft-ietf-blah@tools.ietf.org email aliases, but they= =20 are getting quite dangerous. A couple of times recently I have sent mail like this and received no=20 response (and no bounce) only to find that all of the authors have moved on= =20 to new addresses. Obviously, the tools aren't psychic, but could they update the alias when a= =20 new revision is submitted. Or perhaps once a month? Would it be possible to implement a way of finding out what an alias=20 currently expands to? Or would that be too easy to harvest? And lastly, a wrinkle that I doubt you can help with. My sponsor=20 (huawei.com) believes that any email coming from a huawei.com address to a= =20 huawei.com address MUST be routed internally. Therefore if such an email=20 arrives on an external port it must be a forgery. Unfortunately, the aliase= s=20 are not mailing lists, but are true aliases so we fall into this problem. I= f=20 you could fix it, I'd love you. But I suspect I have to go beat up Huawei=20 technical support. Cheers, Adrian=20 From adrian@olddog.co.uk Wed Sep 16 11:44:37 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5034D3A6A92; Wed, 16 Sep 2009 11:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_50=0.001, 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 z0fMxLz+KGkP; Wed, 16 Sep 2009 11:44:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 1F2E53A6A79; Wed, 16 Sep 2009 11:44:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8GIj8bG027180; Wed, 16 Sep 2009 19:45:13 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8GIj64k027174; Wed, 16 Sep 2009 19:45:07 +0100 Message-ID: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 16 Sep 2009 19:44:43 +0100 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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Thu, 17 Sep 2009 09:19:30 -0700 Cc: iesg@ietf.org Subject: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 18:44:37 -0000 Hi, I seriously love the draft-ietf-blah@tools.ietf.org email aliases, but they are getting quite dangerous. A couple of times recently I have sent mail like this and received no response (and no bounce) only to find that all of the authors have moved on to new addresses. Obviously, the tools aren't psychic, but could they update the alias when a new revision is submitted. Or perhaps once a month? Would it be possible to implement a way of finding out what an alias currently expands to? Or would that be too easy to harvest? And lastly, a wrinkle that I doubt you can help with. My sponsor (huawei.com) believes that any email coming from a huawei.com address to a huawei.com address MUST be routed internally. Therefore if such an email arrives on an external port it must be a forgery. Unfortunately, the aliases are not mailing lists, but are true aliases so we fall into this problem. If you could fix it, I'd love you. But I suspect I have to go beat up Huawei technical support. Cheers, Adrian From jari.arkko@piuha.net Thu Sep 17 09:25:00 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACC028C2D4; Thu, 17 Sep 2009 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 BKxQyc4MO7Xu; Thu, 17 Sep 2009 09:24:59 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE93C28C2C2; Thu, 17 Sep 2009 09:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3B403D4933; Thu, 17 Sep 2009 19:25:03 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WGtTgvg+FYr; Thu, 17 Sep 2009 19:25:02 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 72B61D4925; Thu, 17 Sep 2009 19:25:02 +0300 (EEST) Message-ID: <4AB262DD.1050708@piuha.net> Date: Thu, 17 Sep 2009 19:25:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ross Callon , Henrik Levkowetz References: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , "tools-development@ietf.org" , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:25:00 -0000 Henrik, How do you update the draft addresses? Upon every new version, right? If so, there's not much to do, than to ask that the people use their right e-mail addresses in the drafts. Tools or not, no one can figure out that the guy moved somewhere else, if the e-mail address in the draft says otherwise. Jari Ross Callon wrote: > My reluctance to use these aliases has been based all along on the problem that I don't know for sure what email addresses they actually go to, and thus I can't be sure that the email is actually going to the correct authors. > > Ross > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 16 September 2009 14:45 > To: tools-development@ietf.org > Cc: iesg@ietf.org > Subject: The useful alias addresses > > Hi, > > I seriously love the draft-ietf-blah@tools.ietf.org email aliases, but they > are getting quite dangerous. > > A couple of times recently I have sent mail like this and received no > response (and no bounce) only to find that all of the authors have moved on > to new addresses. > > Obviously, the tools aren't psychic, but could they update the alias when a > new revision is submitted. Or perhaps once a month? > > Would it be possible to implement a way of finding out what an alias > currently expands to? Or would that be too easy to harvest? > > And lastly, a wrinkle that I doubt you can help with. My sponsor > (huawei.com) believes that any email coming from a huawei.com address to a > huawei.com address MUST be routed internally. Therefore if such an email > arrives on an external port it must be a forgery. Unfortunately, the aliases > are not mailing lists, but are true aliases so we fall into this problem. If > you could fix it, I'd love you. But I suspect I have to go beat up Huawei > technical support. > > Cheers, > Adrian > > > From henrik@levkowetz.com Thu Sep 17 12:54:48 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FA43A6A94 for ; Thu, 17 Sep 2009 12:54:48 -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 jDfAVsUjZt1d for ; Thu, 17 Sep 2009 12:54:47 -0700 (PDT) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by core3.amsl.com (Postfix) with ESMTP id E892C28C10C for ; Thu, 17 Sep 2009 12:54:46 -0700 (PDT) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id DBB1D38B1B; Thu, 17 Sep 2009 21:37:30 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 833DF3882B; Thu, 17 Sep 2009 21:37:30 +0200 (CEST) Received: from [10.177.3.32] (host-217-213-69-99.mobileonline.telia.com [217.213.69.99]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 75DDB37E47; Thu, 17 Sep 2009 21:37:28 +0200 (CEST) From: Henrik Levkowetz To: Jari Arkko In-Reply-To: <4AB262DD.1050708@piuha.net> X-Mailer: iPhone Mail (7C144) References: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> <4AB262DD.1050708@piuha.net> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7C144) Date: Thu, 17 Sep 2009 21:37:10 +0200 Cc: Ross Callon , Adrian Farrel , "tools-development@ietf.org" , "iesg@ietf.org" Subject: Re: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 19:54:48 -0000 Hi Jari, On 17 Sep 2009, at 18:25, Jari Arkko wrote: > Henrik, > > How do you update the draft addresses? Upon every new version, right? Yes, that's correct. > If so, there's not much to do, than to ask that the people use their > right e-mail addresses in the drafts. Tools or not, no one can > figure out that the guy moved somewhere else, if the e-mail address > in the draft says otherwise. Ack, at least short-term. Long-term we should have an Email Address Change Tool which would fix addresses in the datatracker, list subscriptions and the aliases, all from one change entry. Best, Henrik > Jari > > Ross Callon wrote: >> My reluctance to use these aliases has been based all along on the >> problem that I don't know for sure what email addresses they >> actually go to, and thus I can't be sure that the email is actually >> going to the correct authors. >> Ross >> >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >> Behalf Of Adrian Farrel >> Sent: 16 September 2009 14:45 >> To: tools-development@ietf.org >> Cc: iesg@ietf.org >> Subject: The useful alias addresses >> >> Hi, >> >> I seriously love the draft-ietf-blah@tools.ietf.org email aliases, >> but they are getting quite dangerous. >> >> A couple of times recently I have sent mail like this and received >> no response (and no bounce) only to find that all of the authors >> have moved on to new addresses. >> >> Obviously, the tools aren't psychic, but could they update the >> alias when a new revision is submitted. Or perhaps once a month? >> >> Would it be possible to implement a way of finding out what an >> alias currently expands to? Or would that be too easy to harvest? >> >> And lastly, a wrinkle that I doubt you can help with. My sponsor (huawei.com >> ) believes that any email coming from a huawei.com address to a huawei.com >> address MUST be routed internally. Therefore if such an email >> arrives on an external port it must be a forgery. Unfortunately, >> the aliases are not mailing lists, but are true aliases so we fall >> into this problem. If you could fix it, I'd love you. But I suspect >> I have to go beat up Huawei technical support. >> >> Cheers, >> Adrian >> >> > From housley@vigilsec.com Thu Sep 17 15:07:25 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294073A6962; Thu, 17 Sep 2009 15:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 YLYrvqF3eLPn; Thu, 17 Sep 2009 15:07:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 274CE3A67E7; Thu, 17 Sep 2009 15:07:24 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 77ECEF2404D; Thu, 17 Sep 2009 18:08:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id CQzanzIBKpVw; Thu, 17 Sep 2009 18:08:15 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-96-241-154-102.washdc.fios.verizon.net [96.241.154.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B483AF2404B; Thu, 17 Sep 2009 18:08:41 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Sep 2009 18:08:01 -0400 To: tools-development@ietf.org From: Russ Housley In-Reply-To: <4CF54D2D-41F9-4102-AA38-12872CD77D90@isoc.org> References: <4CF54D2D-41F9-4102-AA38-12872CD77D90@isoc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090917220841.B483AF2404B@odin.smetech.net> Cc: iaoc@ietf.org Subject: [TOOLS-DEVELOPMENT] Transition to new database structure X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 22:07:25 -0000 I wanted to take a few minutes to capture the things that I heard on the call that took place on 11 Sept 2009 regarding the deployment of the database redesign. I tried to capture the conclusions from the discussion and the actions that need to be taken. 1. The database redesign is nearly complete. The tables associated with the datatracker are stable enough for design work to begin, and in some cases it already has begun. 2. After a discussion of the various deployment approaches, it became clear that the IESG datatracker needs to be rewritten for there to be a smooth transition. The IESG datatracker is currently a collection of perl scripts with embedded SQL command to perform database queries and updates. The public-facing datatracker used to be a collection of perl scripts too, but it was already rewritten using the Django framework. That rewrite was needed to close some serious security holes. The best way forward is to merge the IESG datatracker and the public-facing datatracker, so that both use the Djando framework and a common data model. It is the common data model that will facilitate the incremental transition to the new database structure. This project is too big for a code sprint effort, so a contractor will be needed. 3. There are also many tools used by the Secretariat that use the database. The Secretariat can make their own decisions about the best way for them to transition their own tools to the new database structure. However, it should be pointed out that the Djando admin interface will probably eliminate the need for some of the Secretariat tools. 4. The merge of the IESG datatracker and the public-facing datatracker requires an authorization model. The model needs to accommodate read access from anyone, write access from the IESG members, and write access from the Secretariat. However, we should not be short-sighted. Plans for WG chair support, RFC Editor support, and IANA support should all be considered. The authorization model needs to be sorted out in the next few weeks. 5. The merge of the IESG datatracker and the public-facing datatracker doe not have to keep the user interface exactly as it is today. This is an opportunity for minor improvements; the improvements must not significantly impact the project. 6. The IAOC will be asked to start the process to hire a qualified contractor as soon as the authorization model is sorted out. The process might be able to start before then, but potential contractors cannot offer estimates without this information. 7. Some members of the Tools Team are needed to answer questions for the contractor regarding the existing code, existing database, and new database. Some members of the Tools Team are also needed to perform QA on the contractor's deliverables. From henrik@levkowetz.com Thu Sep 17 17:28:14 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D96F28C0D8; Thu, 17 Sep 2009 17:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 ORwRgc6bx3Yg; Thu, 17 Sep 2009 17:28:13 -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 086A328C11F; Thu, 17 Sep 2009 17:28:13 -0700 (PDT) Received: from 81-232-110-69-no16.tbcn.telia.com ([81.232.110.69]:54255 helo=chardonnay.local) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MoRLS-0001Qg-7D; Fri, 18 Sep 2009 02:29:03 +0200 Message-ID: <4AB2D44D.1050000@levkowetz.com> Date: Fri, 18 Sep 2009 02:29:01 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Adrian Farrel References: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> In-Reply-To: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 81.232.110.69 X-SA-Exim-Rcpt-To: adrian@olddog.co.uk, tools-development@ietf.org, iesg@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Sat, 01 Aug 2009 12:09:26 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: tools-development@ietf.org, iesg@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 00:28:14 -0000 Hi Adrian, Having earlier replied to Jari's comment on this, I however now see there is more that could be said: On 2009-09-16 20:44 Adrian Farrel said the following: > Hi, > > I seriously love the draft-ietf-blah@tools.ietf.org email aliases, but they > are getting quite dangerous. > > A couple of times recently I have sent mail like this and received no > response (and no bounce) only to find that all of the authors have moved on > to new addresses. Ouch. > Obviously, the tools aren't psychic, but could they update the alias when a > new revision is submitted. Or perhaps once a month? The aliases are already being updated as soon as a new draft version is out. I'm also working on improving the extraction of author name and email (this is a side effect of work on a rewritten draft submission tool.) > Would it be possible to implement a way of finding out what an alias > currently expands to? Or would that be too easy to harvest? The alias file is already available, but there isn't a link to it in any easily findable place. I'm not sure if harvesting matters for these addresses -- I suspect they're already very harvestable in drafts and RFCs. But anyway, the file is here: http://tools.ietf.org/draft/aliases > And lastly, a wrinkle that I doubt you can help with. My sponsor > (huawei.com) believes that any email coming from a huawei.com address to a > huawei.com address MUST be routed internally. Therefore if such an email > arrives on an external port it must be a forgery. Unfortunately, the aliases > are not mailing lists, but are true aliases so we fall into this problem. If > you could fix it, I'd love you. But I suspect I have to go beat up Huawei > technical support. Hmm. I see. Well, what I _can_ do manually is to set up a replacement rule which would rewrite any specific @huawei.com address to another specified non-huawei.com address. This does however not scale. In other words: I can do that for a small number of individual addresses, but if you're looking for a general solution, it won't help you... Regards, Henrik From adrian@olddog.co.uk Thu Sep 17 17:33:06 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E1928C0E6; Thu, 17 Sep 2009 17:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.624, 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 A5sFMPYKklRh; Thu, 17 Sep 2009 17:33:05 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id 09C2D28C0DC; Thu, 17 Sep 2009 17:33:04 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8I0Xc5c010249; Fri, 18 Sep 2009 01:33:43 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n8I0Xb2t010245; Fri, 18 Sep 2009 01:33:37 +0100 Message-ID: From: "Adrian Farrel" To: "Henrik Levkowetz" , "Jari Arkko" References: <096051365A994C5D832BA87CB18E896F@your029b8cecfe> <4AB262DD.1050708@piuha.net> Date: Fri, 18 Sep 2009 01:22:17 +0100 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.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Thu, 17 Sep 2009 20:17:08 -0700 Cc: Ross Callon , tools-development@ietf.org, iesg@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] The useful alias addresses X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 00:33:06 -0000 Hi, >> How do you update the draft addresses? Upon every new version, right? > > Yes, that's correct. OK. So if we see emails going to the wrong place, that 's a bug and we should report it to you? Of course, it's hard to see when emails go to the wrong place :-) Any chance of being able to see what the aliases expand to? A From magnus.westerlund@ericsson.com Fri Sep 18 01:25:29 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D8C3A6806; Fri, 18 Sep 2009 01:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_SE=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 Es1HVeqY1mOU; Fri, 18 Sep 2009 01:25:28 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DC6123A69AD; Fri, 18 Sep 2009 01:25:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7baeae000005595-22-4ab3442bb8a2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5F.92.21909.B2443BA4; Fri, 18 Sep 2009 10:26:19 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 10:26:19 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 10:26:19 +0200 Message-ID: <4AB3442B.9040808@ericsson.com> Date: Fri, 18 Sep 2009 10:26:19 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Taylor References: <4AB2EB2D.2060907@rogers.com> In-Reply-To: <4AB2EB2D.2060907@rogers.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Sep 2009 08:26:19.0264 (UTC) FILETIME=[B2821000:01CA3839] X-Brightmail-Tracker: AAAAAA== Cc: wgchairs@ietf.org, tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] Tools a bit chatty X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 08:25:29 -0000 Hi Tom, I will add the tools-development mailing list to this reply as I think this do have to do with requirements for future datatracker development. Tom Taylor skrev: > Three of our AVT documents were approved today and as a result I received a > burst of twenty-one messages. For each document I got: > > - three state change notices: Approved-announcement to be sent, > Approved-announcement sent, and RFC Ed Queue These are not actually automatic. They are handled by the secretariat and are result of their actions. The first one is entered when the secretariat process the ADs approval email. The second when the secretariat has made the announcement email go out, and the third when the RFC-editor has been notified about the document. > > - the IETF-announce notice, copied to AVT Chairs and the AVT list > Yes, these are the public messages. > - the RFC Editor notice Yes, which primarily is intended for the authors, but you as potential document shepherd should ensure that there are a response. > > and of course, it hasn't stopped: I've just started receiving the IANA > action > notices. Yes, another email that usually contains questions that the document shepherd need to ensure are answered. > > I could do without two of the state change notices for sure, since the > sequence > is pretty well fixed and automatic. Obviously I could do without pretty > well all > of the others, too, but I suppose different people have differewnt > requirements. As I said, they are not really automatic as you think. There is human action behind them. I think I have had one case the last 3,5 years when thinks didn't work as expected. > Still, could we discuss what could be omitted? Maybe we can find some > common ground. > Currently the datatracker will send email to everyone on the notification list for all state changes. The default set on the notification list are WG chairs and authors. I think to reduce the number of emails we need to define more roles and define which state transitions are of interest for the different roles. This means a substantial change to the datatracker. I think this part can be considered in the future improvements and extensions. I strongly believe the WG chairs will get a different perspective on things when they actually get a tool that handles the WG process in a reasonable way. I personally do appreciate the mail notifications. Maybe less for documents that I am responsible when I normally anyway have the state easily available on my dashboard and check if often. But for drafts that I am a contributor or otherwise involved I do really like to get the messages. cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From spencer@wonderhamster.org Fri Sep 18 05:52:33 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299F93A69D5; Fri, 18 Sep 2009 05:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.420, 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 wF4zjiidNckH; Fri, 18 Sep 2009 05:52:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 288513A680F; Fri, 18 Sep 2009 05:52:32 -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-1Mocxi26Hy-000OO9; Fri, 18 Sep 2009 08:53:23 -0400 Message-ID: <6A65485361D34DB098C461B6CE28666D@china.huawei.com> From: "Spencer Dawkins" To: "Magnus Westerlund" , "Tom Taylor" References: <4AB2EB2D.2060907@rogers.com> <4AB3442B.9040808@ericsson.com> Date: Fri, 18 Sep 2009 07:53:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: V01U2FsdGVkX19qMg9Mco1fT4jCX/V7R27oY0e30pxnCkzoXsC 3I0zS6VIzEY30ApcvWJI5AkQZXQMfRkgphPPEuSRqze5DCKGlG yhllMyYL/E5vl9oFlBW6vHfZQQ01gtxs7/xobNBoEQ= X-Mailman-Approved-At: Fri, 18 Sep 2009 05:54:26 -0700 Cc: wgchairs@ietf.org, tools-development@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] Tools a bit chatty X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 12:52:33 -0000 I think working group chairs who get enough documents approved for this to be an issue DO deserve our congratulations :-) May we all have this problem! Spencer > Hi Tom, > > I will add the tools-development mailing list to this reply as I think > this do have to do with requirements for future datatracker development. > > Tom Taylor skrev: >> Three of our AVT documents were approved today and as a result I received >> a >> burst of twenty-one messages. For each document I got: >> >> - three state change notices: Approved-announcement to be sent, >> Approved-announcement sent, and RFC Ed Queue > > These are not actually automatic. They are handled by the secretariat > and are result of their actions. The first one is entered when the > secretariat process the ADs approval email. The second when the > secretariat has made the announcement email go out, and the third when > the RFC-editor has been notified about the document. > >> >> - the IETF-announce notice, copied to AVT Chairs and the AVT list >> > > Yes, these are the public messages. > >> - the RFC Editor notice > > Yes, which primarily is intended for the authors, but you as potential > document shepherd should ensure that there are a response. > >> >> and of course, it hasn't stopped: I've just started receiving the IANA >> action >> notices. > > Yes, another email that usually contains questions that the document > shepherd need to ensure are answered. > >> >> I could do without two of the state change notices for sure, since the >> sequence >> is pretty well fixed and automatic. Obviously I could do without pretty >> well all >> of the others, too, but I suppose different people have differewnt >> requirements. > > As I said, they are not really automatic as you think. There is human > action behind them. I think I have had one case the last 3,5 years when > thinks didn't work as expected. > >> Still, could we discuss what could be omitted? Maybe we can find some >> common ground. >> > > Currently the datatracker will send email to everyone on the > notification list for all state changes. The default set on the > notification list are WG chairs and authors. > > I think to reduce the number of emails we need to define more roles and > define which state transitions are of interest for the different roles. > This means a substantial change to the datatracker. I think this part > can be considered in the future improvements and extensions. I strongly > believe the WG chairs will get a different perspective on things when > they actually get a tool that handles the WG process in a reasonable way. > > I personally do appreciate the mail notifications. Maybe less for > documents that I am responsible when I normally anyway have the state > easily available on my dashboard and check if often. But for drafts that > I am a contributor or otherwise involved I do really like to get the > messages. > > cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From jhutz@cmu.edu Fri Sep 18 11:36:03 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C903D3A6B3B; Fri, 18 Sep 2009 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 1SS7qp5TluNE; Fri, 18 Sep 2009 11:36:03 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id E69CA28C20D; Fri, 18 Sep 2009 11:36:01 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8IIaq3k014160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2009 14:36:52 -0400 (EDT) Date: Fri, 18 Sep 2009 14:36:52 -0400 From: Jeffrey Hutzelman To: Magnus Westerlund , Tom Taylor Message-ID: <736285C012D4B3D070449A3E@minbar.fac.cs.cmu.edu> In-Reply-To: <27787_1253262386_n8I8QOY9028785_4AB3442B.9040808@ericsson.com> References: <4AB2EB2D.2060907@rogers.com> <27787_1253262386_n8I8QOY9028785_4AB3442B.9040808@ericsson.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Fri, 18 Sep 2009 11:53:26 -0700 Cc: wgchairs@ietf.org, tools-development@ietf.org, jhutz@cmu.edu Subject: Re: [TOOLS-DEVELOPMENT] Tools a bit chatty X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 18:36:03 -0000 --On Friday, September 18, 2009 10:26:19 AM +0200 Magnus Westerlund wrote: > I think to reduce the number of emails we need to define more roles and > define which state transitions are of interest for the different roles. Or, we could just add headers, when not already present, to indicate things like what document the mail refers to and what the new state is. Then the determination of which messages are "of interest" can be made by each recipient in his or her mail filtering policy, where it belongs. -- Jeff From brian.e.carpenter@gmail.com Fri Sep 18 13:54:54 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7E73A6965; Fri, 18 Sep 2009 13:54:54 -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=[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 7DZfLWm-VRip; Fri, 18 Sep 2009 13:54:53 -0700 (PDT) Received: from mail-pz0-f183.google.com (mail-pz0-f183.google.com [209.85.222.183]) by core3.amsl.com (Postfix) with ESMTP id A511E3A63C9; Fri, 18 Sep 2009 13:54:53 -0700 (PDT) Received: by pzk13 with SMTP id 13so1029520pzk.29 for ; Fri, 18 Sep 2009 13:55:46 -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=ML5nDBWSgXCc1vjfOe5G7PaRXD1AEUBxhRwQXDUhADE=; b=xFQiKodjw2dCVRj6wR+GJa/YanuQzCMgaO9L49zoJO0mkprH3N3pM8PC/Wa8pmtkXt ZRCDe/YAMyRJvKyYR44P0sgvZQdf4Vn+FebILStsPMiRuHbcFRZhNU7PmaBHgNPutx4B cr6/KZcCavcEedHej2QANpIxtQKP0t6ZyRnsg= 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=pl3wWQGO6pupHLB3U4pvNRCRYXpBOBngEUtFi49AFrvn0jkMJwiedUrZY3RPSMW4hp VFDXAASR3gA+FfdYDs2yRv3C/W/yweWXVBa2Em6z3jEaOhJGupxpnbwQ17zVZPKlxYFI uNDeZARRa0wke3WPTh+o/6w6b4YbwGloPPgXs= Received: by 10.114.252.2 with SMTP id z2mr3132622wah.156.1253307345368; Fri, 18 Sep 2009 13:55:45 -0700 (PDT) Received: from ?10.1.1.4? (118-93-22-7.dsl.dyn.ihug.co.nz [118.93.22.7]) by mx.google.com with ESMTPS id 22sm676809pzk.6.2009.09.18.13.55.41 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Sep 2009 13:55:44 -0700 (PDT) Message-ID: <4AB3F3CA.3070705@gmail.com> Date: Sat, 19 Sep 2009 08:55:38 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <4AB2EB2D.2060907@rogers.com> <27787_1253262386_n8I8QOY9028785_4AB3442B.9040808@ericsson.com> <736285C012D4B3D070449A3E@minbar.fac.cs.cmu.edu> In-Reply-To: <736285C012D4B3D070449A3E@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tools-development@ietf.org, Tom Taylor , wgchairs@ietf.org Subject: Re: [TOOLS-DEVELOPMENT] Tools a bit chatty X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 20:54:54 -0000 On 2009-09-19 06:36, Jeffrey Hutzelman wrote: > --On Friday, September 18, 2009 10:26:19 AM +0200 Magnus Westerlund > wrote: > >> I think to reduce the number of emails we need to define more roles and >> define which state transitions are of interest for the different roles. I don't think the number of times this happens in one's life, either as a document author or as a shepherd, is enough to call it a real problem. As a gen-art reviewer, I'd actually like to get all state change messages for each document that I've reviewed, so I'm asking for more, please. > > Or, we could just add headers, when not already present, to indicate > things like what document the mail refers to and what the new state is. > Then the determination of which messages are "of interest" can be made > by each recipient in his or her mail filtering policy, where it belongs. All I ask is that the draft name is always in the subject field. I actually find the IESG "Protocol Action" and "Document Action" announcements fairly useless, because they don't include the draft name in the subject, so automatic or one-glance filtering is impossible. Brian From Pasi.Eronen@nokia.com Mon Sep 28 04:42:28 2009 Return-Path: X-Original-To: tools-development@core3.amsl.com Delivered-To: tools-development@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9333A6855 for ; Mon, 28 Sep 2009 04:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 08T+Zv7Pd9-R for ; Mon, 28 Sep 2009 04:42:26 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 569A83A67EC for ; Mon, 28 Sep 2009 04:42:26 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8SBhX8g012999 for ; Mon, 28 Sep 2009 14:43:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 14:43:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 14:43:17 +0300 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; Mon, 28 Sep 2009 13:43:16 +0200 From: To: Date: Mon, 28 Sep 2009 13:43:15 +0200 Thread-Topic: Notes about tools authentication model Thread-Index: AcpAMN2aGEdFpiOFTna1j3Kn4bkrLw== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09758B3F@NOK-EUMSG-01.mgdnok.nokia.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2009 11:43:17.0336 (UTC) FILETIME=[DEC23D80:01CA4030] X-Nokia-AV: Clean Subject: [TOOLS-DEVELOPMENT] Notes about tools authentication model X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 11:42:28 -0000 Here's my summary from the call on Friday (with Glen, Karen, Alexa, Russ, Henrik, and me). I might have gotten something wrong, so please yell if this doesn't match your recollection :) Best regards, Pasi -------------------- - We're beginning to add access-controlled functionality to the Django datatracker code, since it makes no sense to have totally separate "public tracker" and "non-public tracker" code. The first access-controlled functionality will be common tasks done by IESG (such as balloting). - When moving access-controlled functionality to Django, the first priority is given to functionality used by several community members (as opposed to functionality used only by the secretariat) that is used often (not just once a month) and that's relatively simple. The amount and complexity of the code should be kept limited, since bugs in code that modifies the database could have more serious consequences than public read-only pages. - For authentication, the existing Apache htpasswd files will be used. These files are maintained by the secretariat the same way as currently (change requests via email/RT). For the time being, there won't be any automatic functionality for creating accounts or resetting lost passwords. - The Django code will not access the htpasswd files in any way; the actual authentication is done by Apache. Apache configuration needs to be modified so that "/login/" URL (or something -- details TBD) requires a password. Django's authentication framework gets the user name from the REMOTE_USER environment variable set by Apache (this requires Django version 1.1). - Apache will not request authentication for any other URLs; instead, access control is done by Django code (based on a cookie set by the login page). Pages that absolutely require authentication would redirect the client to /login/; other pages might show different views to unauthenticated users (e.g., anyone can view the ballot page, but the "Edit" button is visible only for IESG members). - For authorization information (who is allowed to do what), Django will use the existing database tables (used by current Perl CGI scripts) that tell e.g. which users are IESG members, who is chairing what WG, and so on. It would also be possible to read the Apache's .perms file, but it's not clear if this would be needed. - I have not yet worked out all the details how this will be implemented, especially how this works with Django's Group and Permission objects. The next actions will be=20 - Henrik and Pasi will work on getting the current functionality (without authentication) working with Django 1.1, and deploying it (possibly even before Hiroshima). - Pasi will modify the Django authentication code to implement the above, and do one simple access-controlled functionality (probably IESG balloting) as an example/test. - Henrik will talk with Glen about using Django's admin framework to replace some of the current secretariat tools. ------------------------