The "verbatim" text is intended to address situations where
there are specific sets of words achieved by negotiation,
and perhaps used elsewhre (e.g., something that effectively
becomes boilerplate for certain situations). This *has*
happened when there are particular phrasings necessary
to get agreement between, say, an IETF WG and a working
party in some other organization.
In that light: yes, verbatim.
If there were spelling errors, editorial concerns, text perceived as
unclear -- I imagine that, in an ongoing collegial environment,
the document publisher could *flag* those as issues to the
originators who could then *elect* to make changes, but the
important feature is that the default outcome is no change.
That's the reason (IMO) for which it has to be used very
sparingly.
Any text that could make that clearer would be appreciated!
Leslie.
Bob Braden wrote:
*>
*> 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.
*>
Let's explore this.
Suppose that the contribution in question:
(1) contains a spelling error.
(2) contains typographic content, e.g., capitalization or punctuation,
which is inconsistent with the same usage in the rest of the
document.
(3) contains typographic content, e.g., capitalization or punctuation,
which is inconsistent with the established usage in th
document series.
(4) contains a blatant grammatical error, e.g., it is not a sentence.
(5) contains language which unbiased observers would say was ambiguous
in meaning.
Are you saying that in NONE of these cases do you want the text changed?
Are you saying that having carefully negotiated deficient text, you want
to protect it, no matter what?
I might suggest that such careful negotiation concerns the MEANING and
CONTENT, not editorial nits.
The last point is the most interesting... are you saying that you want
a WG to be able to negotiate and preserve language that is DELIBERATELY
ambiguous, to make everyone happy? If so, I claim that IETF standards
process is seruously broken, and not in the publication process.
*> 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.
*>
It appears to me that this provision is likely to lead to attempts to
micro-manage the contractor who fills the IETF technical publisher
function after this year.
If you want cooperation with the IETF technical publisher, you are
going to need to bring them into the discussion at an early stage and
get their agreement on the foundation of the proposal. I have seen a
lot of really bad ideas go by in the past year. If they were imposed
on the technical publisher, you would not have a very happy
relationship
I think you will need a more formal, less "bottom up" process than the
current process experiment procedure. For example, such experiments
may affect contractual agreements between the ISOC and the technical
publisher, so representatives of all concerned parties will need to be
involved.
Bob Braden
*>
*> Stephen Hayes
*>
*>
*> _______________________________________________
*> Techspec mailing list
*> [email protected]
*> https://www1.ietf.org/mailman/listinfo/techspec
*>
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
_______________________________________________
Techspec mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/techspec
