Subject: New reuirement: Must publish within 2 months after approval [ was : [Techspec] New version o f mankin-pub-req available]

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 17 Jan 2006 12:10:56 +0100

I am really surprised to not see some sort of requirement that
we get a tech spec published within a reasonable amount of time.

SO I would say:

  Potential Requirement:  After IESG approval of a document, 
  the IETF Technical Publisher must publish the document within
  2 months (unless blocking issues come up during that period)

Blocking issues would be non-response on AUTH48 ??
Or a normatibve reference not being available.
or some such,

The idea is to ensure that we get a reasonable processing speed
after document approval. I personally would like 1 month much better,
but am OK with 2 months. Any longer period seems unacceptable to me.

Bert
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Stephen Hayes (TX/EUS)
> > Sent: Friday, January 13, 2006 22:03
> > To: [email-masked]
> > Subject: [Techspec] New version of mankin-pub-req available
> > 
> > 
> > The -02 version of the technical publication requirements is 
> > available at 
> > http://www.ietf.org/internet-drafts/draft-mankin-pub-req-02.tx
> t.  It is an extensive rewrite of the -01 version with an eye 
> to taking a more systematic approach.  The new version is 
> basically a laundry list of requirements (both current and 
> potential) against a technical publisher.  The goal is to 
> provide a framework in which we can decide what the IETF 
> wants a technical publisher to do and what level of 
> performance we want to see.
> 
> Comments eagerly awaited.
> 
> Stephen Hayes
> 
> _______________________________________________
> Techspec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/techspec
> 
> _______________________________________________
> Techspec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/techspec
> 

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Jan 2006 09:06:54 -0500

>   2 months (unless blocking issues come up during that period)

I agree. And to be clear, I'd want the time frames to be something
like:

   SHOULD be published within 4 weeks, MUST be published within 8.

> Blocking issues would be non-response on AUTH48 ??

Yes.

> Or a normatibve reference not being available.

Actually, no.

This is probably getting beyond techspec, but over the years I have
become increasingly uncomfortable with documents that are approved
(i.e., in the RFC editor queue) but that are blocked on normative
references. Some reasons include:

   - by definition, a document isn't complete without its normative
     dependences. One cannot properly evaluate it without its
     dependencies also being available for review. Indeed, in some
     cases, text changes are needed in a document if one of its
     normative dependencies changes.

   - documents in the publication queue that are blocked tend to get
     forgotten (by the WGs), reducing the pressure on getting the
     normative dependencies completed. (Indeed, we want the exact
     opposite!)

   - I think we'd be better served having the equivalent of a new ID
     tracker state called something like "approved, but blocked on
     normative references", so that the document is clearly not in the
     publication queue (yet).

Part of the reason for the above is to make it more clear that once a
document is in the publication queue, "blocking issues" should really
be rare exceptions.

Thomas

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Jan 2006 08:34:43 -0800

>      normative references", so that the document is clearly not in the

Note that the first and third don't fully agree with each other. If 
we believe both of them (and I certainly do), the ID tracker state 
should prevent the IESG from evaluating the document. That is, there 
would be a pre-IESG-evaluation queue. Every document to be evaluated 
by the IESG goes into that queue, and leaves the queue when every 
normative reference is ready (which might be immediately).

There are a number of IESG folks on this list: does that sound 
reasonable? Or are there good reasons to evaluate documents before 
all their normative references are ready?

--Paul Hoffman, Director
--VPN Consortium

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Jan 2006 11:52:22 +0100

--On tirsdag, januar 17, 2006 08:34:43 -0800 Paul Hoffman 
<[email-masked]> wrote:

> reasonable? Or are there good reasons to evaluate documents before all
> their normative references are ready?

Yes; when the normative reference is to a document in the hands of a 
dependable but slow-moving group, and the document under discussion is in 
the hands of a group where the WG chair is begging us to approve the 
document and shut it down before the proponents completely change their 
minds about what they want Once Again..... or when the IESG all has the 
document and its issues clearly in mind, and delaying it 6 months would 
cause it to be swapped out of their active memory...

I think we're reasonably well served with marking the "ref wait" state as 
"waiting on the IETF to do something" rather than "waiting for the 
publisher to do something", and not changing where it occurs in the 
sequence.

                    Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2006 12:31:19 +0100

>>      normative references", so that the document is clearly not in the

Actually, this state does exist in the RFC Editor queue now,
under the name of MISSREF. There's been some debate whether it's better
to have it where it is (head of line) or at the tail of the edit queue,
but there it is. (Also see Potential Req-STATUSTRK-2.)

> Note that the first and third don't fully agree with each other. If we 
> believe both of them (and I certainly do), the ID tracker state should 
> prevent the IESG from evaluating the document. That is, there would be a 
> pre-IESG-evaluation queue. Every document to be evaluated by the IESG 
> goes into that queue, and leaves the queue when every normative 
> reference is ready (which might be immediately).
> 

I think that would remove potential parallelism and would therefore be
a Bad Thing. It's perfectly reasonable to evaluate a draft knowing that
some of its normative dependencies are still being refined; generally
speaking an AD won't bring a draft forward until the dependencies
are getting ready to be ready.

    Brian