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

[paul.hoffman at vpnc.org (Paul Hoffman)]

At 11:20 AM -0700 7/12/10, Sandy Ginoza wrote:
>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>http://tools.ietf.org/html/draft-hoffman-alt-streams-tracker and <https://datatracker.ietf.org/doc/draft-juskevicius-datatracker-wgdocstate-reqts>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?

If the response of the RFC Editor task was "the ISE should be tracked only in the RFC Editor's tracker", that would have had a major impact on a third of the document that the IAOC asked me to write. Fortunately, that is not what you said. :-)

>>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.

Thanks!

>>- 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.

Fully agree that the "EDIT" state tag should be sufficient. Please consider rewording the description of the EDIT state tag to not indicate that the IESG approved the RFC-to-be, but that a stream did. Clearly, the exact wording should be up to you folks.

>Is there a timeline available for tracker expansion updates? This would be helpful.

That is a question for the IAOC, not for me. They asked me to come up with the requirements for the the new states for the three streams, not to do any coding or even predicting what would be needed for the new coding.

>>- 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).

Sounds good.

>>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.

Ah, that makes sense. Thanks!

--Paul Hoffman, Director
--VPN Consortium