Here are DRAFT techspec minutes, courtesy Paul Hoffman -- thanks,
Paul!
I've fixed a couple of typos, added a word or two, and fixed
the formatting... or broken it. The original version didn't
fit in 72chars, so the format got lost. I hope I have adequately
recreated it.
At any rate -- I have posted these as provisional minutes, but
fixes still welcome.
Leslie.
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
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
