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

Robert Sparks <> Thu, 23 February 2012 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28F6721E8014 for <>; Thu, 23 Feb 2012 13:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.211
X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1d2Atem9nFoj for <>; Thu, 23 Feb 2012 13:54:06 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 350F121E800F for <>; Thu, 23 Feb 2012 13:54:05 -0800 (PST)
Received: from unexplicable.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q1NLrxK1051613 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 15:54:03 -0600 (CST) (envelope-from
Message-ID: <>
Date: Thu, 23 Feb 2012 15:53:59 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Henrik Levkowetz <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: Ole Laursen <>, Russ Housley <>,
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:54:07 -0000


On 2/23/12 2:59 PM, Henrik Levkowetz wrote:
> 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).

I'm OK with this proposal.
Just to make sure I'm following the thinking -

If I had a Document, I could ask it for its area. If it was an 
IETF-stream document,
it would have something to say, either because it could tell because 
what working
group it came from, or someone would have been required to tell it what 
its area
was when it became IETF stream. If it wasn't IETF stream, area would be 

The only part that bothers me is knowing when to insist that someone 
provide the information,
but that should be reasonably containable.

>>> 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"
>    else:
>       print
> everywhere we need to show something for such a document.
Well, there's more to it than that or you would just bury that bit of 
complexity in
something like doc.displayDocumentSource()

But I have to apologize - I still have to be reminded that "Group" in 
the new
schema is modeling something quite a bit more than an IETF working group.

There are things like nomcoms, and external bodies, and a while bunch of 
other things
that are Groups, so having a Group out there that is the container for 
IETF stream
individual submission documents isn't bad.  What I've cringed at is that 
someone might
want to get/set the chairs of that group.

> Best regards,
> 	Henrik