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

[sginoza at amsl.com (Sandy Ginoza)]

Hi Paul, 

Thank you for raising this issue with us and the community.  Please see comments inline.

> [rfc-i] Future interaction of the Datatracker and the RFC Editor's tracker
> 
> Paul Hoffman  <paul.hoffman at vpnc.org>
> Mon Jun 28 15:48:14 PDT 2010
> 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.
Thank you for the pointer.  We will send comments on draft-hoffman-alt-streams-tracker in a separate message.

We appreciate your bringing these issues up for discussion, but we are not quite clear on why updates to the mentioned I-Ds might be dependent on the outcome of discussion here.  Our understanding from looking at http://tools.ietf.org/html/draft-hoffman-alt-streams-tracker and https://datatracker.ietf.org/doc/draft-juskevicius-datatracker-wgdocstate-reqts is that the documents provide the requirements for extensions to the tracker to hold states for documents prior to approval for publication as an RFC.  Why wouldn't the tracker continue to point to the RFC Editor queue for additional information as it does now, until our queue states are updated?

> 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.
We agree that this data should appear separately from the documents that have already been approved for publication.  We will be in communication with the ISE about the decision to remove this data from the RFC Editor, once it is adequately captured elsewhere.  Currently, the RFC Editor database is where the ISE tracks this state information.

> - 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.
We are not sure about implementing states such as EDITIETF, EDITIAB, EDITISE, and EDITIRSG if the stream of origin is indicated in the I-D tracker and on the RFC Editor queue page (especially if we implement your suggestion to include stream information for each queue entry).  It seems that "EDIT" is stream-neutral and is simpler to read than EDITIETF, for example.

Additionally, please note that changing state names in this way (at this time) has serious side-effects in term s of our statistics and reporting.  Updates to the states in the queue also require updates to our database and the scripts producing our statistics.  It's a significant project that is on the horizon, but it is not something we can commit to having completed when the WG/alternate streams extensions are completed.  Is there a timeline available for tracker expansion updates? This would be helpful.

> - 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".
Something like this seems appropriate and will be considered.  However, we believe that the suggestions are for further discussion and implementation at a later date.  As mentioned, we are planning an overhaul of the internal RFC Editor statistics & reporting machinery, and it makes sense to coordinate those changes with any changes to the state machine (and state names).

> 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.
The format of the current RFC Editor queue is the result of discussion with various (past) I* members, who requested that it be separated by stream.  It may be sufficient that the documents individually indicate their stream; this will be discussed as we plan our database/queue updates.

Thanks,

Sandy Ginoza, Director
RFC Production Center
Association Management Solutions, LLC
48377 Fremont Blvd, Ste #117 / Fremont, CA 94538 / USA
Telephone: [phone], Fax: [phone]


> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20100712/298b73a1/attachment-0001.htm>