Subject: Re: Test version of the Parking Area

From: Bruce Lilly <[email-masked]>
Date: Tue, 19 Jul 2005 16:32:45 -0400

>  Date: 2005-07-14 03:30
>  From: Brian E Carpenter <[email-masked]>

> What's the Parking Area? It's the list of all drafts that have been
> approved by the IESG but are not yet published as RFCs.
> 
> You can find the test version at
> 
> http://rtg.ietf.org:8080/Test/parking
[...]
>  Date: 2005-07-15 10:12
>  From: Bill Fenner <[email-masked]>

> >Yes.  And what's the idea ?
> 
> It's the IETF's statement about having approved the documents, as opposed
> to the RFC Editor's statement about having the documents in the queue.

Yes, but what's the intended use?

I'd like to see the date of the status changes; e.g. I see
several listed in AUTH48 that are dated 2003.  But I cannot tell
from the "Parking Area" or from the I-D tracker or from the
RFC-Editor Queue web page how long those documents have been sitting
in AUTH48.

There have been comments that it takes a long time for some
documents to work their way through the RFC-Editor queue, and
that is certainly true.

If the intended use of the data includes either a proposal to
change process or finger-pointing, we don't have enough information.

It would be nice to have something analogous to the I-D tracker
for the RFC-Editor process, recording process state transitions
and their dates.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bill Fenner <[email-masked]>
Date: Tue, 19 Jul 2005 22:11:05 -0400

>for the RFC-Editor process, recording process state transitions

The parking area isn't really meant to be an analysis of the RFC Editor's
queue, just a statement about what the IETF has approved.  However, much
of the followup has been with similar requests.  I've been downloading
snapshots of the RFC Editor's queue web page for a couple of years now;
http://rtg.ietf.org/~fenner/iesg/analyze-rfcq.txt is updated daily and has
the state changes that I've observed.  It also breaks the RFC Editor's
REF state into two seperate states - REF-INT, where all of the REF
documents are also in the queue, and REF-EXT, where one or more is not.
Only REF-EXT is a blocking state.

  Bill

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Jul 2005 05:28:22 +0200

Bill Fenner wrote:

> http://rtg.ietf.org/~fenner/iesg/analyze-rfcq.txt is updated
> daily and has the state changes that I've observed.

That's very interesting.  Apparently you have the raw data to
add a "last time it left IANA or REF state" timestamp to the
"parking area" table.

> It also breaks the RFC Editor's REF state into two seperate
> states - REF-INT, where all of the REF documents are also in
> the queue, and REF-EXT, where one or more is not.  Only
> REF-EXT is a blocking state.

REF-INT could point to REF-EXT, but you probably check this
condition.  For one case I'm watching the editor queue says
"REF draft-crocker-abnf-rfc2234bis-00", your script somehow
decided REF-EXT, maybe it's confused by the trailing -00 (?)

                            Bye, Frank

---

From: Bill Fenner <[email-masked]>
Date: Wed, 20 Jul 2005 13:18:54 -0400

On 7/19/05, Frank Ellermann <[email-masked]> wrote:
> condition.

Yes, and it took me an embarassingly long time to come up with an
algorithm that didn't recurse indefinitely ;-)

>  For one case I'm watching the editor queue says

Indeed, the analysis knows to strip off (-[^-]{1,2})?.txt$ from the
ref; I've changed it to make the .txt optional and your example should
be correct in this afternoon's run.

  Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jul 2005 18:20:36 +0200

Bill Fenner wrote:
> queue, just a statement about what the IETF has approved.

Exactly. "It's in the parking area" is our equivalent of "the check's
in the mail." Seriously, we can point enquiries about the status of
a draft to there.

> However, much

I'd add that the Tools team, with the IAD, are looking at better ways to
present these data, so that we can have at-a-glance status indicators.

    Brian

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 20 Jul 2005 19:39:40 -0400

> in the mail." Seriously, we can point enquiries about the status of

yup.  except that the rfc editor queue is not a FIFO.

hopefully the final result will be able to express the more complex
forms of wedgitude such as "your check was sent two years ago via IESG
express under tracking number XXXX and is currently being held at our
hub until it can be stapled to another check from a different working
group"

						- Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 21 Jul 2005 08:12:28 -0400

>hub until it can be stapled to another check from a different working

So, e.g., for draft-ietf-ospf-2547-dnbit, is it enough to say "Waiting for
draft-ietf-l3vpn-ospf-2547 (IESG Evaluation :: AD Followup)
and draft-ietf-idr-bgp-ext-communities (Approved- Announcement sent)"?
(Note that the 2nd one is a REF that's not there of a REF that is
there).  Is that too much to put on the summary page?

Would it also be useful to put a link to, e.g.,
http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf-l3vpn-ospf-2547&docx=on
for each dependency, to check further dependencies?  (Yes, I should have
a "recurse and check all that dependency's dependencies" option)
(Note that these dependencies are all heuristically extracted and
are a "best case" scenario)

For draft-ietf-ccamp-lmp-mib, is it sufficient to say "REFs cleared
on 2005/04/20", or would you want to see more detail, that it was
draft-ietf-mpls-bundle that was holding it up?

I'm starting to think that for most of the complex relationships, we
want a summary on the top level (e.g., draft-ietf-ospf-2547-dnbit
could say "REF to 2 drafts not in queue") and a detail page that gives
you all the info - otherwise I'm concerned about cluttering up the
top page.

And, of course, a picture is worth a thousand words, perhaps I could
find a way to fit http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf in
there.

  Bill

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Jul 2005 14:50:27 +0200

Bill Fenner wrote:

> http://rtg.ietf.org/~fenner/ietf/deps/index.cgi

Nice, when it says "unknown" it's a potential problem
(= missing reference).
                       Bye, Frank

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Jul 2005 20:13:38 -0400

> there).  Is that too much to put on the summary page?

Probably. 

what I'm hoping for is a clear answer to the question "is there anything
I need to do / anyone I need to remind to get this document out".

> a "recurse and check all that dependency's dependencies" option)

I think that would help, yes. 

> draft-ietf-mpls-bundle that was holding it up?

If you can look at the historic state of a document's dependencies I
don't think it's necessary for the top-level view to mention a resolved 
dependency.. 

> you all the info - otherwise I'm concerned about cluttering up the

yup.