17 Jan 2006 17:10
RE: New reuirement: Must publish within 2 months after approval
Stephen Hayes (TX/EUS <stephen.hayes <at> ericsson.com>
2006-01-17 16:10:32 GMT
2006-01-17 16:10:32 GMT
Comments below. Stephen > -----Original Message----- > From: Thomas Narten [mailto:narten <at> us.ibm.com] > Sent: Tuesday, January 17, 2006 8:07 AM > To: Wijnen, Bert (Bert) > Cc: Stephen Hayes (TX/EUS); techspec <at> ietf.org > 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.