Subject: [Techspec] s3.4 Validation of References

From: Ray Pelletier <[email-masked]>
Date: Wed, 12 Apr 2006 10:17:52 -0400

Comment on draft-mankin-techspec-pubreq-06
3.4. Validation of references

   Discussion: The RFC Editor may put a document on hold waiting for 
the  availability of other IETF documents.  Incorrect references are 
handled like any other fault detected in the editorial review.

When the document is put on hold can have significant processing 
impacts.  For example, if the document is placed on hold upon receipt by 
the publisher and sits there for months awaiting trailing docs, the 
editor will experience difficulties engaging authors during editing and 
at AUTH48/AUTHLC.  Whereas, the editor will more often have a responsive 
and document knowledgeable author if engaged within days and weeks of 
receipt by the editor.

Recommend language change as
  s/document on hold/ document awaiting publication announcement on hold

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Apr 2006 10:32:14 -0400

--On Wednesday, 12 April, 2006 10:17 -0400 Ray Pelletier
<[email-masked]> wrote:

>    Discussion: The RFC Editor may put a document on hold
> waiting for the  availability of other IETF documents.
> Incorrect references are handled like any other fault detected
> in the editorial review.
> 
> When the document is put on hold can have significant
> processing impacts.  For example, if the document is placed on
> hold upon receipt by the publisher and sits there for months
> awaiting trailing docs, the editor will experience
> difficulties engaging authors during editing and at
> AUTH48/AUTHLC.  Whereas, the editor will more often have a
> responsive and document knowledgeable author if engaged within
> days and weeks of receipt by the editor.
> 

Ray,

While I see your point, this basically would imply two AUTH48/
AUTHLC cycles.  Not only does the author need to make a check on
the _final_ document, with the problematic references resolved,
but it is not unusual for other references and material to
change during a long window and need to be corrected.  For
example, if the targets of other references are updated or
rendered obsolete, the author, not the publisher/editor needs to
make the final decision as to whether those references are
appropriately updated. 

It is worth remembering that the AUTH48 review was introduced
because authors and the IESG discovered that errors were being
introduced late in the editing process and wanted to shift
responsibility for catching and correcting those errors to the
authors, rather than blaming the RFC Editor after it was too
late to correct them.

In addition, if the dangling reference points to an I-D ("work
in progress"), someone will need to take the final
responsibility for determining that the citation is still valid
or whether it needs additional qualification in the text.
Arguably, if that situation is likely to arise, the document
should be held by the IESG and never passed to the technical
publisher, but neither this document nor existing procedures
require that.   

The thrust of much of this document appears to be to de-skill
the "technical publisher" role.  Whether that is a good idea or
not, one of its consequences is that it is not possible to place
as much reliance on the publisher to just get things right, know
about substantive validity of references, etc., as we have in
the past.  That shifts the burdens to the IESG and the authors,
and we had therefore best not try to shortcut the final review
process.

So I don't think this change would accomplish much of anything
valuable.

 regards,
     john