Subject: [Techspec] Coming soon ... the next version of pub-req

From: "Stephen Hayes (TX/EUS)" <[email-masked]>
Date: Tue, 2 May 2006 10:06:38 -0500

I'm back in the US and planning on generating a new version of pub-req soon.  Here is my take on the consensus for changes for the 07->08 version.  Comments back by end of the week.  Thanks to Sandy and others for the detailed review.

Stephen Hayes

1.  Assignment of parameter values (Sandy Ginoza)

Comment: the draft seems to indicate that the technical publisher will be assigning parameters instead of just inserting assigned parameters.

Proposed change: modify text to indicate the publisher will insert the IANA assigned values.

2. Different boilerplates for pre-approval and post-approval documents (Sandy Ginoza)

Comment: the boilerplates differ, which ones should be checked against?

Proposed change: modify the text to indicate that the checks should be against boilerplate that is appropriate for the document at the current stage of its lifecycle.

3. How to describe the results from the early copy-edit experiment (Sandy Ginoza)

Comment: It is too early to say "concept has been explored with promising results"

Proposed Change: early feedback has been positive, however, the effectiveness of early copy-editing is still being evaluated.

4. Description of ambition levels for post-approval editing (Sandy Ginoza)

Comment: The RFC editor ambition level is mainly correction of errors and alignment of style.

Proposed Change: None - this describes possible ambition levels that could be mandated, not what the RFC editor currently does.

5. Comments on 40-100 substantive changes statistic in section 3.3 (Sandy Ginoza)

Comment: 40-100 may be reasonable.

Proposed Change:  Change to "a substantial number of".

6. Comment on requirement to "refrain from making changes to improve readability" (Sandy Ginoza)

Comment: RFC editor currently finds many errors in documents that require changes.

Proposed Change: None - this is a subjective area and it is asking for restraint from the technical publisher.

7. Allowing technical publisher to reject late changes (Sandy Ginoza)

Comment: Pushing changes to errata probably a bigger headache than just doing the late change

Proposed Change: None - Already fixed in version-06.

8. How is maintenance of errata done (Sandy Ginoza)

Comment: Who verifies the errata?

Proposed Change: None - There is already a bullet (6th bullet) in section 5 saying the IETF needs to develop processes for vetting errata

9. How does early allocation of permanent ID's work? (Sandy Ginoza)

Comment: Do documents not expire, etc.

Proposed Change: None - early perm-id allocation removed in version 07.

10. Maintenance of a  document or database of terms and acronyms (Sandy Ginoza)

Comment: The RFC editor does this

Proposed Change: Add "publicly available" to the sentence.  This wasn't intended to refer to internal documentation.

11. Stats for non-technical publisher generated changes (Sandy Ginoza)

Comment: Stats requested for author generated changes only, what about changes by ADs or WG chairs?

Proposed Change: Change author generated changes to include changes made by ADs or other persons outside of the technical publisher empowered to make changes.

12. Concerns about the timeframes in section 4.1 (Sandy Ginoza)

Comment: What do these stats apply to? What about changes to workload?

Proposed Change: None - In version 07, the timeframes were fuzzed up.  The actual performance goals are to be defined by contract.

13. Monthly editing stats (Sandy Ginoza)

Comment: It may be onerous on the technical publisher to count/categorize all the corrections.

Proposed Change: None - this does not require counting each change.  Sampled statistics are acceptable.

14. Usage of exception handling (Sandy Ginoza)

Comment: Why is exception handling an alternative to fast publication or early perm id allocation

Proposed Change: Change "exception handling" to "expedited handling".  Also early perm id no longer an alternative.

15. How do the results of experiments in technical publication get incorporated into the requirements (Jari Arkko)

Comment: Is the requirement that the technical publisher participate in the change process sufficient to ensure they will address future requirements?

Proposed Change: None - It seems a bit unfair to put in a requirement that the technical publisher will meet any (as of yet unknown) future requirements.  Negotiation will be needed as requirements change.

16. IESG authority to require some or all of a document be publisher verbatim (John Klensin)

Comment: Doesn't this open the door to the IESG bypassing the technical publisher?  Couldn't this turn the IESG into copy-editors?

Proposed Change: Two use cases will be added to the discussion section to illustrate the need of this function:

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

It is not intended to turn into an alternate publication path.  Process safeguards to prevent this are however outside the scope of this document (see item below).

17. Should the documents with text published verbatim have special IETF handling (John Klensin)

Comment: If a document is published with "protected" text should it be flagged for special handling (special notification, appeals process) in the IESG.

Proposed Change: None - Process issues are outside the scope of this document.

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