comments on problem-issue-statement-02

[John C Klensin]

--On Monday, 11 August, 2003 14:39 +0300 Pekka Savola 
<pekkas at netcore.fi> wrote:

>...
> Normative References
>
>     [1]  Huston, G. and M. Rose, "A Proposal to Improve IETF
> Productivity", draft-huston-ietf-pact-00 (work in progress),
> October 2002.
>
>     [2]  Blanchet, M., "Suggestions to Streamline the IETF
> Process",
> draft-blanchet-evolutionizeietf-suggestions-00 (work in
> progress), November 2002.
>
>     [3]  Hardie, T., "Working Groups and their Stuckees",
> draft-hardie-wg-stuckees-00 (work in progress), February 2003.
>
> ==> all of these should probably be informative references, as
> this  document couldn't be published without them getting
> published otherwise..

Let's be very careful here, lest we create and illustrate a 
problem that then belongs, recursively, on the list.

Something is a normative reference or not depending on how the 
text that uses the reference actually does so.  If the text is 
written such that understanding and, if appropriate, conforming 
to, the text of the reference is necessary to understanding or 
implementing the present text, then the reference is normative, 
period. Conversely, something is informative only if the usage 
in the text has the character of, e.g., "you don't need to know 
this, but, if you want to learn more about it, see [4]" or "for 
examples of how this is done, see [7]".  And the second of those 
becomes normative if the text itself fails to provide a complete 
specification but, instead, relies on the examples for important 
information.

Sorry to pick on you Pekka, but your comment above, which 
implies that one can simply move the references from one section 
to another in order to avoid the "publication first" rule, 
illustrates either that

	* The normative/informative rule fails to solve the
	problem for which it was announced.   Instead, it
	replaces the old problem ("careful effort must go into
	examination of a document to determine which references
	are actually normative") with a new, and harder, problem
	("documents must be examined to ensure that actual
	normative references are not disguised as informative
	ones in the hope of earlier publication (or of making
	publication possible)").
	
	* The IESG and RFC Editor have made a procedural rule
	that is sufficiently ill-defined that even people acting
	with good intent cannot determine what it actually means.

or perhaps both.

To be fair to Pekka, simply changing things to avoid a rule is 
probably not what he intended.    But, I have certainly seen 
documents in which references that were almost certainly 
normative were listed as informative and then published.  Had 
those references been listed as normative, the documents in 
question would still be sitting in queue.  So this makes a 
useful example.

I suggest that the document be expanded to include something 
like:

In generating procedural rules to supplement written, 
community-approved procedures, the IESG (and others) sometimes 
underspecify those rules, leading to

	(i) an additional requirement for case-by-case,
	seemingly-arbitrary, decisions and to
	
	(ii) the development of a subtle "oral tradition" around
	those rules, and to
	
	(iii) an opportunity and incentive for people to "game"
	the rules, in the hope of escaping (or imposing)
	whatever burdens they imply.

The first of these results is a cause of "late surprises" and 
wasted time, since a document editor, other individual IETF 
participant, or WG, acting in good faith, often cannot know how 
things will be handled without picking an approach, completing 
the work, and  then seeing how things work out.   It is also one 
of the causes (or enabling mechanisms) of people --ADs or not-- 
trying to influence the decisions of a WG by making "the IESG 
will never accept..." or "the IESG will require..." statements 
that seem plausible given the rules.

The second acts as a barrier to effective and efficient 
participation by those who are relatively new to the IETF and, 
often has greater impact on non-native speakers of English than 
on those who are good at discerning subtle meanings and intent.

And the third wastes everyone's time -- that of the participant 
who is trying to find a loophole and exploit it, that of 
reviewers trying to detect any such exploits, and that of the 
community when the exploits get through the system anyway -- and 
leads to unnecessary delays.  And, of course, when they do get 
through, they can be a source of lower quality than we would 
like (also discussed elsewhere).

regards,
    john