Techspec minutes Taken by Paul Hoffman March 23, 2006 9:00 AM Dallas TX See the slides; these notes go along with them Leslie Daigle So, what is this? Ongoing effort Review of requirements of IETF technical specification requirements Draft is in -05 version, with an active mailing list Intention is to produce a community-reviewed document One piece of a larger puzzle She has posted a timeline for next steps We should be timely so the IAOC can put out their request for interest The times are theoretical but hopefully reasonable Brian Carpenter asked if this would be an IAB or GenArea document Leslie said "probably GenArea" Quick review of what this area is not Status of draft-mankin-pub-req-05.txt Steven Hayes presented for he and Allison Mankin What the document covers Questions on the mailing list about this Covers IETF and IRTF but not independent submissions Doesn't cover what they do leading up to submission, only what the publisher does Document was extensively restructured Long list of publisher tasks, collected from lots of SDOs Some of the requirements are controversial Scott Bradner mentioned that there is also an interface to the public (reading and responding to email) There are performance metrics for how well a publisher is doing Post-approval timeframes Throughput Number of changes generated during publication Author changes that need to be incorporated Allison Mankin mentioned that not having backlogs is a throughput measurement might be useful Eric Rescorla said this is typical IETF micromanagement Why should we tell them which numbers need to be published Wants verbal targets "publish in a timely fashion, don't have a long queue, and turn out reasonable documents" Leslie asked are these the right metrics, or the right kind of metrics Aaron Falk said it is hard to make commitments like this without knowing what the load will be Thomas Narten echoed what Eric said How much of this is high-level BCPish stuff and how much Is administrative stuff Brian said this could be considered informative, not normative Agreed with Eric, should not be coded into an RFC Other SDO have general targets that are reevaluated on an annual basis The metrics should be guidance to the people creating the contract Leslie summarized that the document needs to be clearer that some of these metrics are informative, but some will be normative The community might want to address specifics of what they want There may be some dependencies on some numbers Thomas said he wanted more fuzzy words like "most documents should be published in about a month" Would prefer that the document said "for example" more The contract might use different words than what is in this document Ray Pelletier (IAD) says that we are looking for a steady-flow state This document has gross processing times and net processing times Asks what happens when the input rate goes up? Are we willing to pay more when the time gets longer? Allison said that for some number of documents per year, these are the expected timeframes, but if the number goes up, the timeframes will change These are reasonable numbers that are not micromanagement that are based on gut feelings from people who have to deal with this work Leslie summaries that these number should be in RFP, but a small number will be specific for our work needs Eric says that the things we care about are not the same as the metrics we collect Metrics are a proxy for what we really want If we offer more load, the rates go up because we are having a greater backlog Suggested that maybe use per dollar used per document given to the publisher We should specify which axes we think is important, and the publisher should create reports on those axes John Klensin wants this document to have a 5-10 year lifespan It should have principles and guidelines Stick to the long-term goals Understand that you can't divorce these from the costs Aaron points out that the process is full of exceptions All the parties might have issues that take time to resolve themselves Within each stage, the document can get bogged down The publisher is not the only party who causes delay Expectation have to be set appropriately Only one participant (the publisher) is under contract Leslie wants text Express crisply the invariable metrics, components Frame the overall process with specific text Allison says that there will be some number of documents which have problems that are not under the control of the publisher, but the IETF wants most documents to meet these numbers Leslie isn't sure if this document is the right place to get this nailed down Lucy Lynch wants to deal with the RFP needs to be sensitive to the irregularity of the input to the publisher Brian says this is a standard service contract with expected stochastic inputs We need further documentation on specific services we want from the technical publisher Open issues Style guide Proposal: publish 2223bis instead Aaron said that publishing the style guide as an RFC is a bad idea; have it be a living document in a stable location John said that our style guide is "look at recent RFCs and do things like that" They are lots of pages of small type Brian points to Harald's ipod draft We currently have a problem with not having a stable link Eric said that the most interesting question is should the publisher enforce the style guide, and if so, how Two lists: suggestions for clarity, what will be enforced Ray said the first question will be "what style guide will you want us to use?" Leslie reminds us to focus on what is invariable and what will change over time Who should decide which things are enforced? John said that recent tendency is greater non-technical editing This affects budgets of time for writers and budget for the publisher How much latitude to make stylistic changes? Paul Hoffman said that the style guide will allow authors to reduce the number of diffs in final review Leslie suggested that the RFC Editor needs to say what they are using and how much they are using it, but we don't need to tell them what to use Format Is xml2rfc allowed as input Yaakov Stein asks whether this will completely block drafts that will have PDF Elwyn Davies this has knock-on effect back to the style guide because tools induce some style Stewart Bryant wants to be sure that the contract does not require that we stay in the current format for the duration of the contract Taken off the table by Leslie Can publisher refuse "late changes" Some people felt that the publisher shouldn't be able to make that call Proposal: alert the IESG when it feels that the request is unreasonable; suspend until hearing how to proceed Early allocation of stable identifiers Proposal: have ID allocation as a safety valve, replace the expedited handling process Aaron points out that the ID might be allocated before the appeals timer is out Brian says that that is something we have to do anyway since we expect some RFCs to be out in under two months Leslie says that once something has been approved, you can point to the actual text with an identifier Different from either an ID or RFC state Captures the text that was approved We tie semantics to the name because you know that Internet Drafts are variable and RFCs are permanent Eric is not convinced there is a not a need to exist because it is fiction that you can't point to a particular draft Leslie says it is about our official rules A lot of other organizations will not reference I-Ds, they will copy the whole draft into an annex We're talking about early allocations of RFC numbers Allison suggested the publisher would create a pointer to the place where the document will be published Pointed out that drafts in the RFC Editor queue have expiration dates, confusing users about their status Leslie: we have three states; to what extent do we want to identify the intermediate state? John points out that NewTrack is dealing with additional states and identifiers Scott says that we may be dealing with effects of the long queue, but we're trying to shorten the queue We should not do this Leslie does a straw poll: should we drop the requirement for early permanent identifiers from the document It was a 60/40 split Refined question: how many people would be satisfied in some other venue if we drop it here? Brian points out there is a problem because we get expedited requests with greater frequency Proposed leaving it in but never using it Leslie pushes back on an existing rule that "is never used", takes the issue off the table until there is more clarity Documentation of changes to IETF process Additional drafts might be needed if there are process gaps (such as allocated of early identifiers) Brian pointed out that these are mostly operational Allison says that there needs to be IETF procedural documents that are not part of the RFP Not appropriate to expand the current document Leslie says we just don't worry about them here Remove "potential" and "current" requirements prefix in the document Agreement in the room Aaron has two further open issues RFC Editor has index of what documents update or obsolete other documents Usually/often that is in the document action, but not always Wants the IETF to formalize this and pass it to the publisher Scott asks if the this really the publisher's job vs. the IETF's job? It might not be the right concept Difference between maintaining and publishing such a table John points out that NewTrack has active proposals about this Brian points out that we have to contract this out It might be the technical publisher, or someone else John points out that we have multiple indexes that we have folded together Should the document publisher be allowed to unpublish a document Scott points out that we must be able to take down for some legal reasons People agreed to change "unpublish" to something like "rescind" Paul said that all publishers should be able to do this We don't need to be talking about this Allison disagrees and says we should be listing them Steve says that the requirement is to be able to update status and metadata of the document What more is left to do? Leslie reiterates the schedule No one had issues with the current dates Everyone silently agreed to bring all issues to the mailing list in a timely fashion