comments on problem-issue-statement-02

[Pekka Savola]

On Thu, 14 Aug 2003, John C Klensin wrote:
> --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 for my bad wording.

There is a problem worth discussing, yes, but in this particular case I 
was just (poorly) stating that those three references IMHO were clearly 
informative; they concentrate on solutions, not the problems.

In this case, I believe they actually should have been Informative
references.

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

True, this may be a problem.  See below.
 	
> 	* 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.

I think it's not that difficult to read through normative and informative 
reference lists and state "OK, I think some of these belong the the other 
category".  So the split seems useful, because instead of everyone forming
their own opinion on what is normative/informative, there is one split 
shown which people should agree to (or if disagree, send in comments to 
change the fact).
 
> 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.

Certainly, there are cases like these.
 
> I suggest that the document be expanded to include something 
> like:

No comment on this proposal.
 
> 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
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings