Subject: [Techspec] Final call before -07 version of mankin-pub-req

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Thu, 13 Apr 2006 11:56:38 -0500

To meet the April 15 deadline, I plan to produce mankin-pub-req-07 at the end of today.

The changes collected so far are:

1. Replace Req-POSTEDIT-5 with 

Req-POSTEDIT-5 In specific instances, where some or all of document text is the result of a careful negotiation of contributions (within or between working groups, reviewers, etc), the IESG or IAB or IRSG will require that the publisher
publish that text verbatim.   It is the expectation of the IETF community that this will not be done often.

2. Add a new requirement to section 3.20:

Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.

Anything else?

Stephen Hayes

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Apr 2006 13:13:35 -0400

--On Thursday, 13 April, 2006 11:56 -0500 "Stephen Hayes
(TX/EUS)" <[email-masked]> wrote:

> Req-POSTEDIT-5 In specific instances, where some or all of
> document text is the result of a careful negotiation of
> contributions (within or between working groups, reviewers,
> etc), the IESG or IAB or IRSG will require that the publisher
> publish that text verbatim.   It is the expectation of the
> IETF community that this will not be done often.
> 
> Req-PROCESSCHG-2 - The IETF technical publisher should
> participate in and support process experiments involving the
> technical publication process.
> 
> Anything else?

Stephen, 

While I think these changes, and some related text, reflect the
consensus of discussion on this list, I'd like to raise a flag
about another point of view... and the possibility that IETF
consensus might possibly lie elsewhere.

Over the years, both before and after the creation of the IETF,
the RFC Editor process has provided an important check on
document quality, at least editorial quality and sometimes
technical quality.   The more we move toward "whatever the IESG
wants, the IESG gets", the more we do two other things:

	* we eliminate that check and reduce the need for a
	publisher function that is capable of applying it.
	
	* we make the IESG the final repository of editorial
	skill and judgment. 

Clearly, there are people in the community who believe that the
first of these would be A Good Thing.  Personally, I think it is
an attempt to solve a set of problems with the bathwater by
discarding both the baby and most of the plumbing in the house.

As to the second, many of us have seen IESG nit-picking over
editorial matters as one of the major roadblocks to rapidly
progressing documents.  Early editing experiments are useful in
addressing some of the issues there, as are IESG efforts to pin
down the justifications for "discuss" positions.    But giving
the IESG the authority to say "publish this as is" pushes the
editorial job back on them, at least for whatever documents
someone can argue are Really Important.  It is not clear to me
that we want to head in that direction without stronger
safeguards than "expectation ... that this will not be done
often".  I'd be much more comfortable with the idea if two
additional things went with it:

(i) The proposal that a document will be fast-tracked in this
way must appear as part of the Last Call announcement so that
the community can comment on the necessity of doing that and on
the editorial readiness for publication "as is" as well as on
the technical substance of the document.  I would hope that we
can trust the IESG to either bounce the document or drop the
fast-track plan if there is significant negative feedback on
expedited publication as-is, rather than trying to rewrite the
document themselves.

(ii) The decision to fast-track a document in this way must be
appealable by any impacted party in the community including, if
the document is judged unsatisfactory under our presumably-high
publication quality, by the technical publisher themselves.

  regards,
      john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2006 14:50:17 +0200

John C Klensin wrote:
...
> expedited publication as-is, rather than trying to rewrite the

I think this is a very reasonable requirement. It's
probably out of scope for techspec as such, since it's upstream
of when the draft is actually handed over for editing.

All it needs is one sentence in the Last Call text, and
any comments on that point would need to be considered
just like any other LC comment.
> publication quality, by the technical publisher themselves.

This seems to be guaranteed by the existing right of appeal
against IESG approvals, which is open to any individual.

      Brian

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 19 Apr 2006 15:57:01 -0400

Reading these comments prompted me to realize that I don't
agree with John's characterization of the requirement.

I don't believe the intent was that the "verbatim" requirement
was for "fast tracking".

I believe the intent was to be able to make it plain when the
text is the way it is for a reason and should not be messed
with:  as a chunk of a document (most likely) or a whole
document.  This may or may not produce a fast track.

Specific use cases:

	. "boilerplate" that's agreed on in an IETF working
	  group to apply to all instances of derivative
	  works (e.g., IANA registration documents, MIBs
	  etc)

	. text referring to other organizations' work -- which
	  has been carefully phrased and arranged with reps
	  of that other organization to deal with some
	  politically sensitive issue.

So -- if the current req reads like fast-tracking, IMO it
is wrong and needs to be fixed.

Which should blow out the requirement for LC announcement
meddling.

Leslie.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Apr 2006 19:16:54 -0400

> document.  This may or may not produce a fast track.

That the suggested requirement can be applied only to a chunk of
a document is also not clear, at least to me, nor is it clear
how the IESG (or whomever) would designate such a thing.

> 	  politically sensitive issue.

These two examples seem perfectly sensible, especially since
both imply other, and serious, efforts to get the text exactly
right.  And both generally require approval of that specific
text in the IETF community.  The "LC announcement" requirement
would presumably be applied at that point, with it being made
clear to the IETF community that the text was intended to be
used verbatim.   Of course, we do not generally Last Call
agreements with other organizations, but the level of scrutiny
is typically similar.

> Which should blow out the requirement for LC announcement

See above.  I don't think it blows it out (or away), but that it
moves it to a much different point in the process.

      john