Subject: [Techspec] publication times & stable identifiers

From: Leslie Daigle <[email-masked]>
Date: Wed, 26 Oct 2005 20:08:22 -0400

First, I observe that the -01 draft doesn't seem to
be in the I-D repository yet.  For our discussion
purposes this week, I'll observe that Allison has
made a copy available at:

	http://psg.com/~mankin/draft-mankin-pub-req-01.txt

 From a discussion point of view, I would like us to
keep a the clean separation between discussion of:

1/ Requirement on time from approval to publication

Current text:

	Req-5 Published document at a predictable time after approval

Discussion on list:

	Bert: 1-2 weeks
	Stephen:  doable in 2 weeks, 3 max, at 3GPP *with* dedicated
	  WG secretaries to pursue the document

I'd like to hear what we think is the *requirement* for the *IETF*
in terms of publication times -- is it as it stands now in
the text?  Or is there a specific timeframe in which it is
required (for purposes of implementation, interaction with other
SDOs, etc).  I'd like to explicitly leave aside the discussion of
"how fast do we think we can really do it" for the moment.

2/  Point at which *a* stable reference is available

Current text:

	Req-4 Stable permanent reference one or two months after
	  approval

Discussion on list:

	We need it sooner than that.

So, the question is how soon do we need a stable reference after
approval -- IRRESPECTIVE of whether the document is published
at that time.

We can come back to determining whether this collapses into
"permanent identifier is the published identifier because we publish
fast enough" *after* we discuss them independently.

Leslie.

_______________________________________________
Techspec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/techspec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Oct 2005 18:07:04 -0700

>"how fast do we think we can really do it" for the moment.

It is a requirement for the IETF that a document always be in a 
predictable state. Current practice has shown us where that goes 
wrong. Because the time between approval and publication is almost 
always long (that is, more than three months), "things change" after 
approval.

   a) Small editorial problems are found and are promised to be fixed
      in AUTH48.

   b) Serious technical errors are found.

   c) Implementers start implementing the "standard" even if there are
      values in the Internet Draft that are known to be changing in the RFC.

(a) is not a problem for predictability, unless authors forget some 
of the items (which happens, of course).

(b) is a real problem. There is often pressure to fix non-editorial 
problems in AUTH48 because the alternative is to pull back the draft, 
ask the IESG to rescind the approval, prepare another rev of the 
draft, (possibly) go through IETF last call again, and go through 
IESG approval again.

(c) is also a real problem. It causes jockeying among implementers to 
choose which of the two values they should ship. It causes many 
implementers to delay shipping, which means that the protocol gets 
less use than it might.

Given the requirement that an approved document be in a predictable 
state, I would agree with Bert and Stephen on the 1-2 weeks. That is 
a short enough period where no one would expect absolute stability, 
and if it is a predictable length, implementers will just wait until 
publication. Beyond two weeks, the problems in (c) start to loom.

>approval -- IRRESPECTIVE of whether the document is published

This is impossible to state in general, particularly because 
different outside body have different "needs". Some of them are gated 
to a calendar, and if the IESG approves a standard at one time, the 
outside body might need the stable reference the next week, but if 
the IESG approved the standard two weeks later, the same body might 
not need the stable reference for another three months.

It really depends on the particular path the particular body's own 
documents is taking.

--Paul Hoffman, Director
--VPN Consortium