[proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker

Henrik Levkowetz <henrik@levkowetz.com> Sun, 14 May 2006 12:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfG0e-0007JG-OI; Sun, 14 May 2006 08:47:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfG0R-0007EJ-3i; Sun, 14 May 2006 08:47:31 -0400
Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfG0Q-0005yg-HJ; Sun, 14 May 2006 08:47:31 -0400
Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9DDDE38CFE; Sun, 14 May 2006 14:47:29 +0200 (CEST)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9054238AAE; Sun, 14 May 2006 14:47:29 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id BCE3937E5C; Sun, 14 May 2006 14:47:28 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from <henrik@levkowetz.com>) id 1FfG0N-0002ak-NA; Sun, 14 May 2006 14:47:27 +0200
Message-ID: <446726DE.8040904@levkowetz.com>
Date: Sun, 14 May 2006 14:47:26 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308)
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
References: <E1FdpF4-0007xU-Fk@megatron.ietf.org> <446715D7.7080701@zurich.ibm.com>
In-Reply-To: <446715D7.7080701@zurich.ibm.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: Aaron Falk <falk@isi.edu>, proto-team@ietf.org, rpelletier@isoc.com, iesg@ietf.org, mankin@psg.com
Subject: [proto-team] Re: PROTO - proceeding on adding PROTO shepherds to the tracker
X-BeenThere: proto-team@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process and Tools Team <proto-team.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proto-team@ietf.org>
List-Help: <mailto:proto-team-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/proto-team>, <mailto:proto-team-request@ietf.org?subject=subscribe>
Errors-To: proto-team-bounces@ietf.org

Hi Brian,

Comments inline.  I've put up new working documents (-01.a and -01.b,
respectively, at

http://www1.tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/

and

http://www1.tools.ietf.org/wg/proto/draft-ietf-proto-iab-irtf-tracker-ext/

but note that more input is needed related to some comments below:


on 2006-05-14 13:34 Brian E Carpenter said the following:
> Thanks. Here are my comments on the two drafts.
> 
> One general question: has Michael Lee reviewed them
> for gotchas?

No, not yet.  I'll send a note asking him to check out the -00
versions.

> One general suggestion: let's not waste time in the RFC queue
> with these. Once they're agreed, just do it. You can post
> <?rfc private ?> versions on the PROTO site for the record.

Works for me.

>     Brian
> 
> draft-ietf-proto-wgchair-tracker-ext-00
> 
>> 2.  I-D Tracker Write Access
> ...
>>    *  Identification of the actions and information which may not be
>>       accessed by all users (R-002).  Such actions and information will
>>       be called 'restricted features' in the following.  Some known
>>       restricted features are:
> 
> It would be good to see an updated and marked-up state table and
> state diagram, with the restricted features clearly identified.

Ok.  What about an additional bullet and requirement:

   *  An updated state table and state diagram, with restricted
      features clearly identified in both (R-010).

>> 3.1.  WG Document States
> ...
>> 
>>    *  WG Document Awaiting Reviews
>>       This document needs reviews (possibly a certain number of reviews,
>>       at a minimum) before a WG last call will be done.
>> 
>>       Possible next states: "Active WG Document", "Parked WG Document",
>>       "Publication Requested", "In WG Last Call", "Dead"
>> 
>>       Permitted sub-states: "0 reviews", "1 reviews", "2 reviews", "3
>>       reviews", "4 reviews", "5 reviews", "Awaiting MIB Doctor Review",
>>       *** More special review states ***
>>       (R-008)
> 
> This will be very useful for the proposed early cross-area review
> mechanism. (Since the recent IESG retreat, Lisa owns that topic.)
> Can we have a substate "Awaiting cross-area review"?

Certainly. Added.

> Linked to that, what happens about state change notifications?
> For example, the dispatcher for cross-area reviews needs to get
> a trigger when the sub-state "Awaiting cross-area review" is set.

If the tracker currently supports notification triggers, I'd add
that here - but I don't think it does, and in that case I'd suggest
we pull this information from the tracker in the review support tool
which Tero Kivinen is currently working on.  I'll forward a copy of
this mail to him, for information.

>> 5.  Modification of Existing States
>> 
>>    One existing sub-state in the tracker should be modified to reflect
>>    the role of the WG document shepherds.
>> 
>>    The sub-state "AD Followup" is defined as generic and may be used for
>>    many purposes by an Area Director.  However, the tracker
>>    automatically assigns this sub-state when a document which has been
>>    in the "Revised ID Needed" sub-state is updated.  The "AD Followup"
>>    sub-state shall continue to exist for the first purpose, but when a
>>    document is in "IESG Evaluation - Revised ID Needed" and an update
>>    arrives, it shall receive an automatic state change to a new sub-
>>    state instead: "Doc Shepherd Followup" (R-022).
> 
> But not for non-WG documents, which should still get "AD Followup."

Proposed revision, specifying 'working group document is in "IESG Eval...'
and adding a clarifying sentence at the end:

   The sub-state "AD Followup" is defined as generic and may be used for
   many purposes by an Area Director.  However, the tracker
   automatically assigns this sub-state when a document which has been
   in the "Revised ID Needed" sub-state is updated.  The "AD Followup"
   sub-state shall continue to exist for the first purpose, but when a
   working group document is in "IESG Evaluation - Revised ID Needed"
   and an update arrives, it shall receive an automatic state change to
   a new sub-state instead: "Doc Shepherd Followup" (R-022).  Non-WG
   documents continue to change state to "AD Followup" as before.


> draft-ietf-proto-iab-irtf-tracker-ext-00
> 
> You don't mention access control.

Not sure I know exactly what you think of here - this document
was only supposed to describe the additional IAB and IRTF states
needed, and having little knowledge of their process, I expect
someone else to provide the needed text adjustment for those.
But I get the impression that you also expect special access
control restrictions associated with the IAB and IRTF states?

> I'm surprised you don't expect "Revised ID Needed" to be used.

I'm sure it should - I've added it in a couple of places in rev. 01.b,
but my confidence that these states are accurate until we get text
from the IAB / IRTF is still low...


	Henrik


_______________________________________________
proto-team mailing list
proto-team@ietf.org
https://www1.ietf.org/mailman/listinfo/proto-team