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

Russ Housley <housley@vigilsec.com> Thu, 23 February 2012 15:22 UTC

Return-Path: <housley@vigilsec.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 BF8CB21F8671; Thu, 23 Feb 2012 07:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level:
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 fP8zABy6Kmkx; Thu, 23 Feb 2012 07:22:08 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0148E21F866D; Thu, 23 Feb 2012 07:22:08 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 56205F24068; Thu, 23 Feb 2012 10:22:13 -0500 (EST)
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 UnO9u7hvsu1k; Thu, 23 Feb 2012 10:22:07 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 23BBFF2404D; Thu, 23 Feb 2012 10:22:13 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <4F465849.5020707@levkowetz.com>
Date: Thu, 23 Feb 2012 10:22:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B873F24E-E867-4028-A80C-F95FE1B7727D@vigilsec.com>
References: <4F4415E7.9080608@nostrum.com> <CANb2OvKXRUarNY-Vp+CkA+7P5FZ1=_OfqyO67gOnKfx2bAARCQ@mail.gmail.com> <4F455B47.3040305@nostrum.com> <F3883977-5295-48A7-A226-ABCA5563A2A3@vigilsec.com> <4F45B07F.7080508@nostrum.com> <CANb2OvKJy=HT34KNFXFzN+3V6L33SgxUfxrrh_H2XufXPe6nXQ@mail.gmail.com> <4F465849.5020707@levkowetz.com>
To: iola-conversion-tool@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: The IESG <iesg@ietf.org>
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 15:22:08 -0000

>>> 3.2.1 New Items   draft-snell-atompub-tombstones<https://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/>
>>> [txt] <http://www.ietf.org/id/draft-snell-atompub-tombstones-14.txt>
>>> The Atom "deleted-entry" Element (Informational)
>>> Token: Peter Saint-Andre (gen area)
>>> 
>> 
>> Ah, hang on there. This is actually the single place I was referring to
>> before where the set area_acronym is used. So it says "gen" because "gen"
>> was set when it was added. You can't see this elsewhere, and it won't work
>> for searching either (actually, searching for gen area in the production
>> system does find this document but this is because it's an invididual
>> submission, and those are classified under gen for some reason).
>> 
>> I think there used to be a special handling of area in the edit form in
>> the Perl code base and the first port of it, that would put individual
>> submissions in gen and hide the area if it had already been assigned. So if
>> you're wondering why it's in gen and not in app, that may be the cause.
> 
> Ok, so if this is used by the IESG or some ADs during the IESG processing,
> we should support it.  Do we have a straightforward way of associating a
> non-WG document with an area independently of who the sponsoring AD is?

In cases like two-maturity-level, the AD is helping another area.  We need this info.

In addition, as Sean said on the IESG list, the RFC Editor can use this to determine which are ought to handle errata for the document.

Russ