Subject: RE: [Techspec] Comments on techspec from a user perspective

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 26 Oct 2005 15:12:48 +0200

Speaking as an individual

I personally think that our primary requirement is that an approved
document gets formally published ASAP. In my view I'd even like to
state that we would want it published within a week or two at most.
And so then all the "early stable references issues" go away.

The discussion about "early stable references" in my view is caused
by the fact that we currently have a lag-time of what 4-6 months
(or sometimes even more) for approved documents.

Only if it turns out that our primary requirement of "get the RFC
published within a week or two after approval" cannot be met by
any publication-service-provider, only then do I think we should
have this discussion.

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Stephen Hayes (TX/EUS)
> Sent: Tuesday, October 25, 2005 17:56
> To: [email-masked]
> Subject: RE: [Techspec] Comments on techspec from a user perspective 
> 
> 
> I'm not sure my point 5 was clear.  
> 
> One requirement on a technical publisher is that they 
> generally verify the references in a document to be published 
> are valid.  The stable reference plan proposed in the 
> experiment should be adequate to satisfy that criteria and 
> will allow SDOs to go ahead with approval and publication of 
> documents with a RFC reference even before a RFC is formally 
> published (provided they are willing to accept a small risk).
> 
> My question, should the IETF technical publisher also follow 
> this practice with respect to RFC references?  This policy 
> would allow documents to be published earlier, however the 
> risk is compounded within IETF as it would be possible to 
> create reference chains where few of the documents actually 
> are RFCs.  I single failure in the chain would lead to problems. 
> 
> In analogy, most other SDOs assign their stable references 
> early in the process.  They also often approve clumps of 
> documents at a time.  References between the documents in the 
> group are quite common.  The publisher typically does not 
> publish any of the documents until all the references (within 
> that SDO) have been or are ready to be published.
> 
> Stephen
> 
> > > 5. Will IETF itself use the stable references?  For 
> > example, if a draft is in 
> > > the RFC editor queue waiting for dependencies, can it be 
> > published as soon as 
> > > those dependencies have stable references or will it need 
> > to wait for the 
> > > references to be actually published.  Not waiting for 
> > actual publication will 
> > > speed things up, but raises the risk of major ripple 
> > effects if a RFC-TO-BE 
> > > ever has to be withdrawn.  
> > > 
> > > IMHO, The RFC editor itself shouldn't publish a RFC until 
> > all required 
> > > references es are also published.  Thus when you finally 
> > get the RFC, 
> > > you can be sure that it is solid.
> > > 
> > 
> > Figure 1 distinguishes the technical publisher pretty clearly
> > from the IETF.  But the draft probably should do so better.
> > 
> > Your point though is that the RFC Editor (to go back to
> > the experiment) would not push out a document which
> > has still in the form of permanent stable identifiers.
> > That's right.  So we may still have an IETF request to make
> > of the RFC Editor, to get these documents published when there
> > are clusters of them waiting on the queue for periods of time.
> > 
> > As far as withdrawal of documents:  the reference issue (the
> > formal part) is the tip of the iceberg.  If there's an appeal
> > or other problem, the AD and WG shepherds in technology
> > dependent on that need to be alert to substantive fallout -
> > this is a tiny aspect.
> > 
> > 
> > 
> 
> _______________________________________________
> Techspec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/techspec
> 

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 26 Oct 2005 07:15:25 -0700

My thought (speaking out of turn because I haven't read the techspec draft):

- We need to have our approved texts referencable and findable
- This needs to be true SOON after approval (the urgency varies from 
document to document)
- The ideal way to do this is to have it published in our permanent 
document series (RFCs) the day after approval. This may be unrealistic.
- The current way is to use draft name + knowledge of approval in the 4 
months until the RFC pops out. That is painful.

One note about our current "expedited number" process:
The formal request from the IESG to the RFC Editor is for an early number 
assignment (permanent identifier). The RFC Editor has chosen to accelerate 
publication of these documents on such a request, because the RFC Editor 
believes that this lessens the chance of problems that might derail the 
publication of the doucment.

Assigning permanent identifiers is not the heart of the problem.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Oct 2005 18:54:48 +0300 (EEST)

Hi,

> any publication-service-provider, only then do I think we should

I've stated this point offlist before the mailing list was set up but 
will do so again (I think I agree with Bert):

It doesn't seem that the procedure in section 5.2 ("Stable Permanent 
Identifier at Approval") buys much compared to the complexity.  I feel 
for the same amount of energy used in the extra steps one could 
actually just simply publish the document and the whole point would be 
moot.

One tricky thing the doc raises is the two-month appeals timeout after 
the approval.  Does that need to pass before a document should be 
published?  If it does, any "permanent identifier immediately" scheme 
for faster than 2-month service seems invalid. (Personally, I don't 
think it should pass; if there is a problem with the approval and the 
RFC has already been published, the category of the RFC can just be 
changed later.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings