[rfc-i] Future interaction of the Datatracker and the RFC Editor's tracker
Joel M. Halpern
jmh at joelhalpern.com
Mon Jun 28 18:04:09 PDT 2010
I do not see how the I, ISR, ISR-AUTH, and TO states are covered by the
If they are covered, they are covered somewhere I have not seen. The
ISR, ISR-AUTH, and TO states are states that should be entered by the
ISE. As far as I know, the ISE does not update the IETF datatracker, so
I do not see how those states can be duplicated in there. (You even say
that these states are created by separate people.)
There has to be some way to record that the ISE has been formally asked
to publish an I-D as an independent submission, and to track tohe
progress of that. WHere would that be in this proposal?
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
More information about the rfc-interest