Subject: comments on problem-issue-statement-02

From: Pekka Savola <[email-masked]>
Date: Mon, 11 Aug 2003 14:39:24 +0300 (EEST)

Hi,

Below are a few comments I scribbled up when reading the problem statement
draft.  I didn't go at it in a lot detail, though.  In general, I think
the document is in a pretty good condition.  I've about 3 more substantial 
issues some of which may be worth discussing, and a few more editorial 
ones.  All of them should be easily fixable.

substantial
-----------

1)

==> general note: there are a few words used in the document that break at
least one principle we've found out, that is, not friendly for non-native
speakers.  At least "stratification", "exacerbate", "cross-pollinating",
"ossification", and "Shibboleth".  Personally I've pretty good idea of 
these, but I always flinch when I see too fancy words used, and I think at 
least these are a symptom of that :-)

2)

   o  The IETF needs to avoid focusing on a too-narrow scope of
      technology because this would be likely to blinker the IETF's view
      of 'the good of the Internet', and will harm the long-term goal of
      making the Internet useful to the greatest number stakeholders;
      this argues for allowing a relatively wide range of topics to be
      worked on in the IETF - cross-fertilization has always been one of
      the IETF's strengths.

==> I think the two-three last lines miss the point completely, or I have 
an entirely different view of "cross-fertilization".  I do not think 
cross-fertilization automatically happens if we allow a wide range of 
topics to be worked at here.  Rather, it will only happen if people have 
the will and the energy to spend looking at and helping the other working 
groups by implanting clue there.

How should this text be edited?  Good question, either it can be fixed up 
slightly or revised at more length.  Thoughts?

3)

2.6.6 Concentration of Influence in Too Few Hands
                                                                                                   
   Until the last couple of years, successive IETF Nominating Committees
   have chosen to give heavy weighting to continuity of IESG and IAB
   membership. Thus, the IETF appeared to have created an affinity group
   system which tended to re-select the same leaders from a limited pool
   of people who had proved competent and committed in the past.

==> I think there is a potential issue in how the NOMCOM goes about it's 
business (the approach has obvious advantages too, of course).  That is, 
providing feedback to NOMCOM is very difficult except about current IESG 
members (whose performance is more or less visiable and known after 2 
years, and who usually agree to continue to serve if necessary), and some 
outstanding new candidates.  People might have a *lot* of feedback to give 
about non-IESG candidates if it was known that those persons have agreed 
to become nominated.  

That way, it may be very difficult to get on at the same level of feedback
than the current members, and it seems to me that if the current members
are willing to continue and haven't done a bad job of it, the process also 
favors their re-instalment pretty well.

But this is both a bug and a feature..

semi-editorial
--------------

   o  Working Groups can potentially be hijacked by sectional interests
      to the detriment of the IETF's mission.

==> I'm not sure what this point is trying to say, in particular regarding
"sectional interests".  That there are a number of separate, tightly
focused interest groups who are only pushing their own agenda (and e.g.
obtaining rough consensus in WGs by room packing) and not advancing the
IETF mission? Re-phrase?

   o  Lack of an explicit feed forward path to drive the improvement of
      the standards development process and success criteria over time
      and to avoid repetition of failures that may occur.

==> what is "an explicit _feed_ forward path"  I've no idea...

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

   [4]  Huitema, C. and P. Gross, "The Internet Standards Process --
        Revision 2", RFC 1602, March 1994.

==> this should be updated to point to RFC2026? :-)

editorial
---------

   o  The sub-section of Section 2.6 dealing with Formal Reconition has
      been moved to Section 2.5.

==> s/Reco/Recog/

      preparation of WG chairs and ADs for conflict resoution is noted.
                                                                                                  
==> s/reso/resol/

   o  The IETF is unsure who its stakeholders are, and consequently has
      managed to drive certain groups of stakeholder, who would

==> s/stakeholder/stakeholders/

  o  Lack of metrics to measure the achievement of the desired quality
      and the performance of WGs and the wider IETF..

==> s/.././

   o  The IETF does not posess effective formal mechanisms for inter-WG
      cooperation or communication.

==> s/posess/possess/ ?

      that subsequent modifications will be minimal as it progresses to
      DS and FS, assuming effort can be found to create the necessary
      applicability and interoperability reports that are needed..

==> s/.././

 Note: Using
   Leadership positions as rewards for good work would probably be
   damaging to the IETF.

==> s/L/l/, maybe even s/U/u/ ?

   o  Effectively providing technical management, people-management and
      project supervision for their WGs

==> s/people-management/people management/ ?

   o  Recruiting shrinkage: The number of people who can imagine taking
      on an IESG post is steadily decreasing.  It is largely limited to
      people who work for large companies who can afford to second IESG
      members to the IETF for the duration of their appointments.

==> use some other word than "second", like "support" (and other 
rewording), the intent is not clear.

   Delay in authorizing a BOF  or chartering a new WG can delay the
   start of the process with similar effects.

==> s/BOF /BOF/ (remove extra space)

  'advising' or 'process' chair to work with an enthusiatic newcomer in
 
==> s/tic/stic/

   The IETF culture of openess also tends to tolerate participants, who,
 
s/openess/openness/

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 Aug 2003 04:52:10 -0400

--On Monday, 11 August, 2003 14:39 +0300 Pekka Savola 
<[email-masked]> wrote:

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Aug 2003 13:43:17 +0300 (EEST)

> specification but, instead, relies on the examples for important 

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.

> 	ones in the hope of earlier publication (or of making

True, this may be a problem.  See below.
 	
> 	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).
 
> question would still be sitting in queue.  So this makes a 

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

No comment on this proposal.