Subject: [Techspec] RE: New reuirement: Must publish within 2 months after approval

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Tue, 17 Jan 2006 10:10:32 -0600

Comments below.

Stephen
> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]]
> Sent: Tuesday, January 17, 2006 8:07 AM
> To: Wijnen, Bert (Bert)
> Cc: Stephen Hayes (TX/EUS); [email-masked]
> Subject: Re: New reuirement: Must publish within 2 months 
> after approval
> [ was : [Techspec] New version o f mankin-pub-req available] 
> 
> 
> > 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)
> 
> 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 ??

There is currently a statistical requirement in section 4.1

   o  Potential Req-TIMEFRAMES-1 - The IETF technical publisher should 
      have an goal of 90% of documents published within x weeks of 
      approval.  Documents held up due to references or due to a 
      protocol action should be excluded from this statistic. 

Where the x was intended to be filled in after discussion.  It could be modified as:

Potential Req-TIMEFRAMES-1 - The IETF technical publisher should 
      have an goal of 90% of documents published within 4 weeks of 
      approval and all of the documents published within 8 weeks.  
	Documents held up due to references or due to a 
      protocol action should be excluded from this statistic. 

There are lots of ways to document a performance goal 
(avg, + 95% done by goal), tiered percentage goals.  They all work better
than a "should".

> 
> Yes.
> 
> > Or a normatibve reference not being available.
> > or some such,
> 
> 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
> 
I don't think we should penalize the technical publisher if the 
necessary references are not available.  However I agree that we need a
way of making the blocking points visible.  The following requirements were
taken from section 3.11.  Do they address your concerns?

   o  Current Req-STATUSTRK-1 - The IETF technical publisher should 
      provide state information for each document in the publication 
      process. 

   o  Potential Req-STATUSTRK-2 - The IETF technical publisher should 
      integrate its state information with the IETF tools to provide 
      end-to-end status tracking of documents.  IETF documents should be 
      able to move seamlessly from the IETF tracking system into the 
      technical publication tracking system.   

   o  Potential Req-STATUSTRK-3  - The IETF technical publisher should 
      provide external visibility of not only the fact that a document 
      is in an extended waiting period, but also the token-holder and 
      circumstances of the wait. 

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

---

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

> There is currently a statistical requirement in section 4.1

In the real world of variable workloads, it can only be statistical.
Anything else is unrealistic.

>       protocol action should be excluded from this statistic. 

I don't think that can be done except in the context of a bidding process.
There will be a direct tradeoff between the contract price and this goal,
and so it's not something that can be set in concrete except in the final
contract.

Also, because of the two month timeout in the RFC 2026 appeal process, it turns
out that our standards process actually implies that an RFC MUST NOT be published
until two months after approval.

     Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Jan 2006 13:28:44 +0100

> until two months after approval.

I don't see that that follows - we can always declare the mis-published RFC 
Historical and publish a fixed one later, as we did with (for instance) the 
RFCs for RADIUS that came out with the wrong port numbers in them, or the 
SNMPv3 RFCs that turned out to have the wrong encrypted-values in the 
examples.

I don't think the harm from a couple of dead RFCs is big enough that we 
need to insist on the wait.

                  Harald

---

From: Thomas Narten <[email-masked]>
Date: Wed, 18 Jan 2006 08:40:16 -0500

> > Also, because of the two month timeout in the RFC 2026 appeal
> > process, it turns out that our standards process actually implies
> > that an RFC MUST NOT be published until two months after approval.

> SNMPv3 RFCs that turned out to have the wrong encrypted-values in the 

I strongly concur. Our processes should (by default) be forward
looking. We should not be adding extra (and harmful) delay to our
processes in order to facilitate appeals, or those that would raise
them. Let's not have the cost outweigh the benefit!

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2006 13:33:36 +0100

> them. Let's not have the cost outweigh the benefit!

I can buy this argument, but note that it is at least a clarification
if not an actual update to RFC 2026. And the notion of a withdrawn RFC
is new. So we have to be very clear about that.

     Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 19 Jan 2006 13:39:21 +0100

> is new. So we have to be very clear about that.

There should be no reason to *withdraw* ("unpublish") the RFC, as I said in 
my previous mail. And the status for a superseded RFC is pretty clear: It's 
called "Historic".

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 19 Jan 2006 19:17:30 -0500

This is an important question to get sorted out.  And, it impacts
the (motivation for) the discussion of permanent stable identifiers
post-approval.

(STD series numbering is not the issue under discussion in
that requirement.  I had assumed/understood NEWTRK was going to
sort out what our document series are called/how they are handled,
and techspec should follow from that).

Leslie.

Brian E Carpenter wrote:
>>> I don't see that that follows - we can always declare the 
>>> mis-published RFC Historical and publish a fixed one later, as we did 
>>> with (for instance) the RFCs for RADIUS that came out with the wrong 
>>> port numbers in them, or the SNMPv3 RFCs that turned out to have the 
>>> wrong encrypted-values in the examples.
>>
>>
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2006 13:24:33 +0100

Leslie Daigle wrote:
...
> and techspec should follow from that).

True - the techspec requirement is that the publisher should do
what the IETF process requires in the way of assigning STD and
BCP type designations.

    Brian

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 20 Jan 2006 12:29:58 -0500

Agreed -- *whatever* designations are appropriate and
required for the technical specification process: "high fibre"
"so-5minutes-ago" "STD-Gold" "not-an-RFC", "BCP", whatever.

Leslie.