Comments below.
Stephen
> -----Original Message-----
> From: Thomas Narten [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 17, 2006 8:07 AM
> To: Wijnen, Bert (Bert)
> Cc: Stephen Hayes (TX/EUS); [email protected]
> 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 protected]
https://www1.ietf.org/mailman/listinfo/techspec
