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

Henrik Levkowetz <> Thu, 23 February 2012 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6643821F873D; Thu, 23 Feb 2012 13:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b2oMaNWrpXgi; Thu, 23 Feb 2012 13:00:08 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id B975321F86DD; Thu, 23 Feb 2012 13:00:08 -0800 (PST)
Received: from localhost ([]:59134 helo=vigonier.lan ident=henrik) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from <>) id 1S0flO-0004XF-6i; Thu, 23 Feb 2012 21:59:42 +0100
Message-ID: <>
Date: Thu, 23 Feb 2012 21:59:41 +0100
From: Henrik Levkowetz <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Robert Sparks <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Cc: Ole Laursen <>, Russ Housley <>, The IESG <>,
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2012 21:00:09 -0000

Hi Robert, Ole,

On 2012-02-23 21:33 Robert Sparks said the following:
> On 2/23/12 2:20 PM, Ole Laursen wrote:
>> 2012/2/23 Henrik Levkowetz<>:
>>> 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?
>>> Since areas are groups, too, we should be able to have an association with
>>> the area in the same way that wg documents are associated with a WG, I think.
>> Yes. It sounds like we need to keep track of the area for a few
>> individually submitted documents here that conceptually belong to an
>> area, in the same way as WG drafts belong to a WG? Is that correct?
> I think this is mismodeling what we need a bit. Focusing on the
> individually submitted nature of the document may not be right. To
> put stress on it:
> How would you handle a document from a RAI working group that both
> Gonzalo and I needed to recuse on. Some other AD (let say Peter for
> this example) would be the sponsor. The doc should show from RAI and
> as a product of that RAI WG.

Agreed, but that's in line with what I (am trying to, at least!) propose
above.  See more below.

> It seems natural to just have an area associated with a document at
> any time it is identified as IETF stream.

What I'm proposing is that this association can be either indirectly,
through an association with a WG, which would give the area of the WG;
or directly set to an area (which is independent of the area of any 
sponsoring AD).

>> If so, I suggest we just associate the document with the area instead
>> of the phony individual group and be done with it. I can add some UI
>> for that. Does that sound agreeable?

> Treating individual submissions as belonging to a psuedo-group has
> always disturbed me, but I don't know if that first proposal is the
> right fix.

The alternative is to not associate them with a group at all, until they
have been accepted by a WG, or a sponsoring AD.  I think that for the
purpose of code uniformity it's easier to associate them with a group
'Individual Contributions' (or whatever) than to code the equivalent of

  if == None:
     print "Individual"

everywhere we need to show something for such a document.

Best regards,