Stephen Hayes (TX/EUS) wrote:
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
In the real world of variable workloads, it can only be statistical.
Anything else is unrealistic.
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.
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
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
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
