Re: [iola-wgcharter-tool] A question about the states in RFC 6292

Martin Qvist <martin@iola.dk> Thu, 01 September 2011 08:56 UTC

Return-Path: <martin@iola.dk>
X-Original-To: iola-wgcharter-tool@ietfa.amsl.com
Delivered-To: iola-wgcharter-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B948C21F8A95 for <iola-wgcharter-tool@ietfa.amsl.com>; Thu, 1 Sep 2011 01:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 YqsgJTgOA3k8 for <iola-wgcharter-tool@ietfa.amsl.com>; Thu, 1 Sep 2011 01:56:08 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7391921F8A7A for <iola-wgcharter-tool@ietf.org>; Thu, 1 Sep 2011 01:56:07 -0700 (PDT)
Received: by fxe6 with SMTP id 6so524667fxe.31 for <iola-wgcharter-tool@ietf.org>; Thu, 01 Sep 2011 01:57:39 -0700 (PDT)
Received: by 10.223.99.91 with SMTP id t27mr1375983fan.56.1314867459830; Thu, 01 Sep 2011 01:57:39 -0700 (PDT)
Received: from Martins-MacBook.local (iola-fw.novipark.dk [77.243.62.134]) by mx.google.com with ESMTPS id c4sm321597fac.35.2011.09.01.01.57.38 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 01:57:39 -0700 (PDT)
Message-ID: <4E5F4903.5060400@iola.dk>
Date: Thu, 01 Sep 2011 10:57:39 +0200
From: Martin Qvist <martin@iola.dk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>
References: <4E5D06AE.601@levkowetz.com> <9963548E-4AA4-4D13-8E39-9F2A1541BE4E@vigilsec.com> <4E5DEEEA.5050808@iola.dk> <D738AA11-4CAA-42A8-BC2C-578DD5D42720@vigilsec.com>
In-Reply-To: <D738AA11-4CAA-42A8-BC2C-578DD5D42720@vigilsec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: iola-wgcharter-tool@ietf.org
Subject: Re: [iola-wgcharter-tool] A question about the states in RFC 6292
X-BeenThere: iola-wgcharter-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / WG Charter Tool Project <iola-wgcharter-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-wgcharter-tool>, <mailto:iola-wgcharter-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-wgcharter-tool>
List-Post: <mailto:iola-wgcharter-tool@ietf.org>
List-Help: <mailto:iola-wgcharter-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-wgcharter-tool>, <mailto:iola-wgcharter-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2011 08:56:09 -0000

You can diff any version against any other version of charters under the 
history tab under /wgrecord/.

But would you rather the whole information that's now in /wgrecord/ be 
moved under /wg/wgacronym/charter (and make "sub-tabs")? That would 
collect everything under /wg/ but we would probably have to create an 
Active Charter tab and a Proposed Charter tab so the two aren't confused.

Alternatively, we could copy the "Diffs" section from 
/wgrecord/wgacronym/history so that it also appears under 
/wg/wgacronym/charter. That way you could perform the diffs in either place.

Best,
Martin

On 31/08/2011 16:03, Russ Housley wrote:
> I see that I misunderstood ion my first reading.  This approach works for me, as long as the state on the /wg/wgacronym version is Approved and accessible until it is replaced by the approved recharter.
>
> I alway envisioned the charters and proposed charters being in the same directory to make it easy to perform diff between the various versions.  The most common diffs are:
>
>     - compare most recent proposed recharter to the previous proposal
>
>     - compare most recent proposed recharter to the currently approved charter
>
> Russ
>
>
> On Aug 31, 2011, at 4:20 AM, Martin Qvist wrote:
>
>> Hi
>>
>> The behaviour you describe is already handled (with Henriks proposed states) in the implementation. The active charter is showed under /wg/wgacronym (it shows the charter with the highest revision XX), and the newly proposed charter texts are shown under /wgrecord/wgacronym (the charters with revision XX-00, XX-01, etc.). When the proposed new charter is approved it gets revision XX+1 and is then shown in both /wg/wgacronym and /wgrecord/wgacronym.
>>
>> I hope this is clear enough.
>>
>> Best,
>> Martin
>>
>> On 31/08/2011 00:25, Russ Housley wrote:
>>> Henrik:
>>>
>>> I see a  problem with your proposal as I understand it.
>>>
>>> When there is a charter in place, a recharter is a discussion about replacing that charter.  The potential recharter can take many revisions, and while this is happening, the original charter remain the 'active' one.  When the recharter is approved, it become the 'active' one.  So, during the recharter there are two documents in play.
>>>
>>> Russ
>>>
>>>
>>> On Aug 30, 2011, at 11:50 AM, Henrik Levkowetz wrote:
>>>
>>>> Hi,
>>>>
>>>> While implementing the WG Charter tool, we discovered a potential problem
>>>> with the state description in RFC 6292,
>>>>   http://tools.ietf.org/html/rfc6292
>>>>
>>>> The RFC describes one set of review states for a WG during initial
>>>> chartering, and another set of review states during re-chartering:
>>>>
>>>> Initial:
>>>>    o  Informal IESG review
>>>>    o  Internal review
>>>>    o  External review
>>>>    o  IESG review
>>>>    o  WG exists
>>>>    o  Not currently under review
>>>>
>>>> Rechartering:
>>>>    o  WG exists; Informal IESG recharter review
>>>>    o  WG exists; Internal recharter review
>>>>    o  WG exists; External recharter review
>>>>
>>>> Now, the objects which exists in the database which are relevant for
>>>> the chartering process are two:  A *WG Object* (which before the RFC 6292
>>>> extensions can be in one of two states: 'Active' and 'Concluded'), and a
>>>> *Document Object*, the Charter, which potentially can get any set of
>>>> appropriate states we care to assign it.
>>>>
>>>> There is no 'WG Review' object to hold a 'review state', and there seems
>>>> to be a mixture in what the review states listed above applies to - WG,
>>>> charter, or a review process.
>>>>
>>>> Our suggestion, and the way we have implemented this in the code currently,
>>>> is to split the states up as described below.  From these states, all of
>>>> the 'review states' above can be synthesized if desired, although we would
>>>> propose that it's more straightforward to display the WG state and the
>>>> Charter document state directly:
>>>>
>>>>   * The WG object keeps its current states, and gets a new one:
>>>> 	o Proposed
>>>> 	o Active
>>>> 	o Concluded
>>>>
>>>>   * The Charter Document Object gets the following states:
>>>> 	o Informal IESG Review
>>>> 	o  Informal IESG review
>>>> 	o  Internal review
>>>> 	o  External review
>>>> 	o  IESG review
>>>> 	o  Not currently under review
>>>> 	o Approved
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> 	Henrik
>>>>
>>>>
>>>> _______________________________________________
>>>> iola-wgcharter-tool mailing list
>>>> iola-wgcharter-tool@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/iola-wgcharter-tool
>>>
>>> _______________________________________________
>>> iola-wgcharter-tool mailing list
>>> iola-wgcharter-tool@ietf.org
>>> https://www.ietf.org/mailman/listinfo/iola-wgcharter-tool
>>
>