Subject: [Techspec] DRAFT Techspec minutes

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Mar 2006 23:18:53 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/techspec