Re: [iola-conversion-tool] Bug when Adding a document to the tracker

Sean Turner <turners@ieca.com> Thu, 23 February 2012 05:46 UTC

Return-Path: <turners@ieca.com>
X-Original-To: iola-conversion-tool@ietfa.amsl.com
Delivered-To: iola-conversion-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881C121F85EE for <iola-conversion-tool@ietfa.amsl.com>; Wed, 22 Feb 2012 21:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.868
X-Spam-Level:
X-Spam-Status: No, score=-100.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPi5txzbt14G for <iola-conversion-tool@ietfa.amsl.com>; Wed, 22 Feb 2012 21:46:31 -0800 (PST)
Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.94.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1372621F85AC for <iola-conversion-tool@ietf.org>; Wed, 22 Feb 2012 21:46:29 -0800 (PST)
Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id D087ED1A5A733; Wed, 22 Feb 2012 23:46:27 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id C30EBD1A5A713 for <iola-conversion-tool@ietf.org>; Wed, 22 Feb 2012 23:46:27 -0600 (CST)
Received: from [125.213.237.22] (port=49587 helo=[192.168.242.90]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <turners@ieca.com>) id 1S0RVa-0003su-0G; Wed, 22 Feb 2012 23:46:27 -0600
References: <4F4415E7.9080608@nostrum.com> <CANb2OvKXRUarNY-Vp+CkA+7P5FZ1=_OfqyO67gOnKfx2bAARCQ@mail.gmail.com> <4F455B47.3040305@nostrum.com> <F3883977-5295-48A7-A226-ABCA5563A2A3@vigilsec.com>
In-Reply-To: <F3883977-5295-48A7-A226-ABCA5563A2A3@vigilsec.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-66C1E2D9-13B8-4F39-B017-F27578164913"; protocol="application/pkcs7-signature"
Message-Id: <0F90CEAB-3312-48E8-9AF0-F794F09CDFE2@ieca.com>
X-Mailer: iPhone Mail (9A405)
From: Sean Turner <turners@ieca.com>
Date: Thu, 23 Feb 2012 12:46:21 +0700
To: Russ Housley <housley@vigilsec.com>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.242.90]) [125.213.237.22]:49587
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
X-Mailman-Approved-At: Thu, 23 Feb 2012 08:04:47 -0800
Cc: Ole Laursen <olau@iola.dk>, The IESG <iesg@ietf.org>, "iola-conversion-tool@ietf.org" <iola-conversion-tool@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-BeenThere: iola-conversion-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <iola-conversion-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-conversion-tool>
List-Post: <mailto:iola-conversion-tool@ietf.org>
List-Help: <mailto:iola-conversion-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2012 05:46:39 -0000

Maybe we could use it to figure out which area errata should be assigned to?  Especially useful for ad sponsored drafts.

Spt

Sent from my iPhone

On Feb 23, 2012, at 5:52 AM, Russ Housley <housley@vigilsec.com> wrote:

> This should not be true.  A telechat agenda indicates which AD has the token, and it shows an Area.  I believe that when Jari was the token holder for -two-maturity-level, the area was still "(Gen)".
> 
> Russ
> 
> 
> On Feb 22, 2012, at 4:16 PM, Robert Sparks wrote:
> 
>> IESG :
>> 
>> Cindy and I stumbled over what we first thought was a bug, but it turned out to be a surprising
>> feature/side-effect of the conversion effort.
>> 
>> The data we've been collecting on the edit-info-form (what we have been using to add a document to the
>> tracker or to change it's IESG state/telechat date, etc.) about which area a document belongs to is not being
>> used by any part of the production datatracker other than that form.
>> 
>> <ceficbhd.png>
>> 
>> So, it will not appear on the form in the new system (and the data collected in the old system is 
>> not being migrated I believe).
>> 
>> That really surprised me, but after digging through the code and discussing it with Ole, I'm convinced it's
>> correct.
>> 
>> If we find a need to start collecting that data again in the future, it won't be hard to add.
>> 
>> RjS
>> 
>> 
>> On 2/22/12 11:18 AM, Ole Laursen wrote:
>>> 
>>> 2012/2/21 Robert Sparks <rjsparks@nostrum.com>
>>> The biggest is that the form didn't ask for the area the document should be associated with.
>>> It occasionally happens that an AD from outside the area takes the shepherd role for a document, so
>>> you can't infer this from which AD is assigned.
>>> 
>>> Right. At the moment, we don't store an area at all. Grepping for it, the only place I managed to find using the attribute apart from the edit form is the agenda document template where the proxy wrapper will infer the area from the WG (if there's a WG) or else from the shepherding AD.
>>> 
>>> The search page looks for the area of the WG in the old schema if you do a search for area, not the area attribute which is perhaps not surprising if it's only set for documents in the IESG process.
>>> 
>>> So do you think this is a problem still?
>>>  
>> <snip/>
>