[rfc-i] Fwd: Future interaction of the Datatracker and the RFC Editor's tracker

Paul,
   It's not yet clear to me what if any impact the proposed datatracker extensions might have on the
systems employed by the RFC Editor (and AMS), or our plans for future changes (some of which
have not yet been determined).  However, if changes do end up looking like they will be required,
let's all please be sure to respect the RFC Editor's areas of responsibility, practices, and planning
cycles. I think that also suggests we be careful to avoid:
	- local optimizations that have significant negative impact or impose costs on other areas, or
	- short-term improvements that increase the cost of a more general or long-term solution (or
              possibly even make a broader solution significantly more difficult). 

This is not to say that I think this is happening.  Rather, I wanted to call this out on this list to be sure
we don't accidentally end up in such a situation.  Let's keep this in mind as we go over the details.

thanks,
Glenn
___

Begin forwarded message:

> From: Glenn Kowack <Glenn at RiverOnce.com>
> Date: July 6, 2010 6:40:11 PM PDT
> To: Paul Hoffman <paul.hoffman at vpnc.org>
> Cc: RFC Interest <rfc-interest at rfc-editor.org>, RFC Editor <rfc-editor at rfc-editor.org>
> Subject: Re: [rfc-i] Future interaction of the Datatracker and the RFC Editor's tracker
> 
> Paul,
>     Members of the RFC Editor and I, including Production Center staff, are looking into your suggestions and will get back to you shortly.  Thanks very much for bringing this to our attention.  
> 
> thanks,
> Glenn
> Transitional RFC Series Editor
> ___
> 
> 
> On Jun 28, 2010, at 3:48 PM, Paul Hoffman wrote:
> 
>> Greetings again. As many of you may know, the IAOC intends to update the Internet Drafts part of the IETF Datatracker to have better granularity of states. The Datatracker will have different state information for the four streams that feed into the RFC Editor (IETF, IAB, ISE, and IRTF). When implemented, the Datatracker will cover the entire life of an Internet Draft until the time that the stream requests the RFC Editor publish it.
>> 
>> This message is not to discuss what those states should be; if you are interested in that, please see:
>> 
>> - <http://tools.ietf.org/html/draft-juskevicius-datatracker-wgdocstate-reqts> and <http://tools.ietf.org/html/draft-ietf-proto-wgdocument-states> for the IETF stream; these two documents are in IETF Last Call
>> 
>> - <http://tools.ietf.org/html/draft-hoffman-alt-streams-tracker> for the IAB, ISE, and IRTF streams
>> 
>> Both Ed and I quite interested in more input on the documents.
>> 
>> When these documents are finished and implementation in the Datatracker is deployed, some Internet Drafts will have their status being carried in the two different trackers, possibly with conflicting information (because the information will be being updated by two very different sets of people working on the document in different ways). I propose that this that would be a bad situation, but one that can be easily fixed by the RFC Editor being prepared to change their tracker at the same time as the Datatracker is being updated.
>> 
>> The current list of RFC Editor tracker states is:
>> 
>> AUTH = Awaiting Author Action
>> AUTH48 = Awaiting final author approval
>> EDIT = Approved by IESG, awaiting processing and publishing,
>> no "APPR" note means that it was approved on date received
>> I = Independent Submission
>> IANA = RFC-Editor/IANA Registration Coordination
>> IESG = Holding for IESG Action
>> ISR = Independent Submission Review by the RFC Editor
>> ISR-AUTH = Independent Submission awaiting author update,
>> or in discussion between author and RFC Editor
>> REF = Holding for normative reference (followed by I-D
>> string of referenced document)
>> RFC-EDITOR = Awaiting final rfc-editor review before AUTH48
>> TO = Time-out period during which the IESG reviews document
>> for conflict/concurrence with other IETF working group work
>> (followed by date)
>> MISSREF = Awaiting missing normative reference.
>> 
>> Based on the drafts that Ed and I are writing, I believe that the following needs to happen simultaneously with the Datatracker being updated:
>> 
>> - The "I", "ISR", "ISR-AUTH", and "TO" statuses be eliminated because they will be completely covered in the IETF Datatracker.
>> 
>> - The "EDIT" status description needs to be stream-neutral, such as "Submitted by the stream owner, awaiting...". Alternately, the status needs to be split into four, such as EDITIETF, EDITIAB, EDITISE, and EDITIRSG.
>> 
>> - The "IESG" status must only be put on IETF stream documents that have been sent back for IESG review. A better alternative is that this status be replaced by something like "STREAMREVIEW" whose definition is "Holding for action of the stream owner".
>> 
>> Also, I propose that each entry the RFC Editor's tracker should be updated to show the the stream origin. Right now, you have to read up to find the heading of the document; it would be better to have this in each entry.
>> 
>> 
>> --Paul Hoffman, Director
>> --VPN Consortium
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 