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

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Fri, 21 Oct 2005 13:44:46 -0500

I had a look at mankin-pub-req and I applaud the initiative.  From the perspective of a SDO using IETF specs, the the RFC publication process has always been a bit of a black hole. Most other areas of IETF have shown increased transparency, but not the publication process.  

The draft seems well written but I did have a few comments on the stable permanent identifier at approval experiment:

1. This is something that is really needed by external SDOs.  Most SDOs have a very onerous errata process for making an update to insert a RFC reference.  The inability to get this 4 digit number in a timely manner leads to undesirable behaviour such as copying the text into annexes.

2. If you have early allocation of a stable permanent identifier, do you still need fast tracking?  It seems like Fast Tracking was a method to meet external timelines when you didn't have a way of getting an early RFC number. In general SDOs just need a reference and an assurance that it will pop out in a reasonable time. 

3. As soon as a permanent identifier is allocated, the RFC editor should provide a pointer in the RFC database to the pre-publication version (again with appropriate disclaimers), so that the references can be resolved.

4. Is it really necessary to wait for the two month appeal process to assign a stable permanent identifier?  It would seem that the necessary disclaimers could be added to the RFC-TO-BE so that it was clear that references to it carry a risk.

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 are also published.  Thus when you finally get the RFC, you can be sure that it is solid.

Regards,
Stephen Hayes

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

---

From: Allison Mankin <[email-masked]>
Date: Sun, 23 Oct 2005 15:42:02 -0700

Thanks Stephen,

A bit of uncloaking - Stephen was reading very closely on the way
to agreeing to join the document as an author.  Having someone in it
who's a very substantial user/coordinator of the use of IETF 
technical specifications seems like a great way to keep it on track.

Now to some specific responses to these:

>  I had a look at mankin-pub-req and I applaud the initiative.  From
> the perspective of a SDO using IETF specs, the the RFC publication
> process has always been a bit of a black hole. Most other areas of
> IETF have shown increased transparency, but not the publication
> process.
> 
> The draft seems well written but I did have a few comments on the stable 
> permanent identifier at approval experiment:
> 
> 1. This is something that is really needed by external SDOs.  Most SDOs have a 
> very onerous errata process for making an update to insert a RFC reference.  
> The inability to get this 4 digit number in a timely manner leads to undesirable 
> behaviour such as copying the text into annexes.
> 
> 2. If you have early allocation of a stable permanent identifier, do you still 
> need fast tracking?  It seems like Fast Tracking was a method to meet external 
> timelines when you didn't have a way of getting an early RFC number. In general
>  external SDOs just need a reference and an assurance that it will pop out in a
>  reasonable time. 

I will add a comment about the experiment leading to not needing
Fast Tracking.  If the experiment were a success the usage would be 
that the i-d with the permanent-identifier in it would provide
both the stable technical content and the bibliographic constructor
needed by the SDO.

> 
> 3. As soon as a permanent identifier is allocated, the RFC editor should 
> provide a pointer in the RFC database to the pre-publication version (again with 
> appropriate disclaimers), so that the references can be resolved.

Note that in this document we're talking mostly about the technical
publisher, rather than specifically about the RFC Editor service.
But the section is about an experiment that this document proposes,
with the RFC Editor, similar to the Early Copy Edit experiment.  

So I am going to edit the document to ask that in the database of
the RFC Editor, the pending document would be this pre-publication
draft with its permanent identifier.  In at least some cases, this
would happen naturally, because the RFC Editor refers to the IETF's
internet-draft, which would be this new type of draft.

> 
> 4. Is it really necessary to wait for the two month appeal process to assign a 
> stable permanent identifier?  It would seem that the necessary disclaimers 
> could be added to the RFC-TO-BE so that it was clear that references to it carry a 
> risk.

Your question is echoed by several others - the two month delay was
originally proposed to me in a private chat by another AD
but it has been questioned to me privately by others in the IESG.
The case of revoked approval is very rare, though this year very
oddly it occurred twice, in one case due to an
appeal, in another case after an interoperability problem. 
Both cases are expected to result in re-approval.

We should call for explicit consensus on this point for this
part of the document as we progress in discussion.

> 
> 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.

---

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Tue, 25 Oct 2005 10:55:49 -0500

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

---

From: Allison Mankin <[email-masked]>
Date: Wed, 26 Oct 2005 08:12:17 -0700

The basic principle in the draft is that the document
once approved by the IETF has become a standard and
the large community now needs to use it.  

The technical publishing step adds tremendous value to our 
specifications, but it is not responsible for the technical 
standards content and approval, those are done when
IETF sends out the announcements, and the users are ready
to use them then in some form.  

In the draft I point out that our final i-ds include
the statement that they expire.  This signals the users
(naturally) that the documents are not stable.  But
also, like us, and as Stephen stated, our users want
to include references, and they can't reference the
unstable bibliographic reference, the i-d.  It's just like
us with normative references.

As Bert and you stated, this would be made moot if the
technical publication stage completed very quickly.

But since the technical publisher has a different functional
role than the standards developer (IETF), it has different
events that can occur.  It is staffed differently.  It
can have this excellent goal of always gettling the 
every document out in one month, but then a few documents
meet with non-responsive authors, the queue builds up,
some staff turns over, other circumstances arise, and 
if the IETF has hinged providing references on publication,
it is not able to do so quickly.

Separating the functions - making a parallel flow -
seems efficient.  The technical publisher can continue
to work very hard to maintain high throughput on its
production, but meanwhile the IETF can provide its
users with access to reference and stable though not
perfect versions (pre-publication)  of the specifications 
at the time when they become standards.

Allison