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

Ed Juskevicius edj.etc at gmail.com
Wed Jul 14 19:41:25 PDT 2010


bel>> - Is the tracker intended to be one continuous tracker for I-Ds
>>   (I-D posting --> WG approval --> IESG review/approval --> RFC
submission)
>>   or is there a separation between the WG tracker and IESG tracker?
>
>  The goal is definitely one tracker.

Agreed ... the goal is for the Datatracker to be able to display the status
of every I-D, no matter which state machine
(or production stream) the I-D may be in.  This said, the extensions to the
tracker that I have proposed (for IETG WG
status tracking) should be implemented to display the most recent WG state
of IETF WG I-Ds *and* the current IESG
(or RFC Editor) state of WG I-Ds that have been sent to the IESG for
publication.

I understand that WG status tracking will be implemented via a new state
machine that will operate in parallel with the
existing code that tracks IESG status of documents.  Thus, a document may
have a valid state in more than one state
machine at the same time.  For example, the WG status of an I-D that has
been forwarded to the IESG may be
displayed as "Sent to IESG for Publication" at the same time as the
Datatracker may describe the IESG state of the
same I-D as being in one of the IESG states (e.g. AD Evaluation, In Last
Call, IESG Evaluation .....).

Regards,

Ed  J.

be possible and useful to have the Datatracker keep track
of which
the Datatracker display the implementation of the

On Wed, Jul 14, 2010 at 9:04 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:

> At 11:34 AM -0700 7/12/10, Sandy Ginoza wrote:
> >We see that the following definitions for when a document is passed to the
> RFC Editor for publication:
> >
> >IAB
> >   o  Sent to the RFC Editor -- The IAB processing of this document is
> >      complete and it has been sent to the RFC Editor for publication.
> >      The document may be in the RFC Editor's queue, or it may have been
> >      published as an RFC; this state doesn't distinguish between
> >      different states occurring after the document has left the IAB.
> >IRTF
> >   o  Submitted IRTF Document The document has been submitted for
> >      publication (and not returned to the IRTF for further action).
> >      The document may be in the RFC Editor's queue, or it may have been
> >      published as an RFC; this state doesn't distinguish between
> >      different states occurring after the document has left the IRTF.
> >IS
> >   o  Sent to the RFC Production Center -- The ISE processing of this
> >      document is complete and it has been sent to the RFC Production
> >      Center for publication.  The document may be in the RFC Editor's
> >      queue, or it may have been published as an RFC; this state doesn't
> >      distinguish between different states occurring after the document
> >      has left the ISE.
> >
> >- We suggest that this state name be consistent across the streams, for
> example "Sent to the RFC Production Center."
>
> <mumble><something about hobgoblins> Sounds good to me; I'll ask the stream
> owners.
>
> >- After publication, why wouldn't the tracker show its Status as an RFC as
> it does currently (e.g., "RFC 5766 (Proposed Standard)")?
>
> It might, but that's outside the scope of our requirements documents, I
> believe.
>
> >- Is the tracker intended to be one continuous tracker for I-Ds (I-D
> posting --> WG approval --> IESG review/approval --> RFC submission) or is
> there a separation between the WG tracker and IESG tracker?
>
> The goal is definitely one tracker.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20100714/0ca4512e/attachment.htm>


More information about the rfc-interest mailing list