Problem statement draft comments

[Pekka Savola]

Hi,

I've read the problem statement draft; it's lists a large number of
issues, grouped in some fashion (which is, in some places quite artificial
and may, actually, have adverse effects due to associations made due to
categories), which most seem ok.

I didn't review the draft extensively, "just read it through"; here are a
few observations from a relative newcomer (2 years), and (still!) a
believer in the IETF model..

Specific issues:

A.2.2 How the consensus process works

   o  Waiting for WG meetings at IETF meetings to identify/reach
      consensus sometimes delays the advancement of the WG - this
	happens even though the mailing list should be the prime
      discussion forum. Judging consensus based on the mailing list 
      comments sometimes obscures the silent majority opinion (Marc
      Blanchet: P4) and sometimes reflects exhaustion rather than true
	consensus (Elwyn Davies).

==> this is coupled with the issue of active participation.  If you judge
consensus at IETF meeting, you just get 80-95% of "maybe clueless, maybe
clueful" hums -- the silent majority of the working group (or those who
came in as tourists, either for kicks or looking for electricity for their
laptops) which does not typically participate actively in the w.g. list or
elsewhere.  So, all the options for judging consensus (highlighted if
there is no clear consensus) seem to be bad ones -- especially doing it in
the meeting.


A.2.6 Problems in the Large - Cross fertilization between WGs/Areas and
	System level Thinking

	WGs should be ready to bring in Subject Matter Experts from
	outside the central domain of a WG problem as soon as it becomes
	clear that there will be interactions with other areas, rather
      than at a late stage and only when beaten up by the ADs.
[...]
   o  Experts from areas outside the central domain of a WG problem are
	rarely brought in until late in the WG process which can lead to
	disconnect, reinvention of wheels, incompatibilities and missing
	pieces (Marc Blanchet: P5)

==> I certainly agree with this sentiment, but it does its own problems.  
The biggest of them are, IMO:

 - IETF is a volunteer organization; I certainly wouldn't be interested in
being a SME for all the ridiculous things, spending a lot of valuable time
on efforts which I'm not really interested about (except so that they
don't interfere with my own interests or damage the Internet too badly),
rather on working on things on *my* areas.

 - Trying to inject clue can be a painful experience, also to those who
try to vaccinate against stupidity.  It takes a lot of nerve, long emails,
coffee, etc.etc. to stand up against a seeming (silent/noisy) consensus of
a working group.  In the end, they may just end up ignoring you
altogether.  After spending hours, days, or whatever reviewing the work
and the work being ignored surely doesn't encourage you to spend the time
again.  The same surely happens in the IESG too; squashing bad ideas is
likely to just make it mean More Work For You (with no benefits).

 - (going into the solutions section) it may be that something that might
satisfy the criteria are a few pool of people (experts) which could be
called on to do some analysis if necessary.  Ie. if someone raises a
security concern which people don't agree on, call on X to check it out
(before going to IESG, last call, AD clue injection etc. stages which just
waste time and energy at every level), rather than pushing every
half-baked idea to be reviewed by X (burning out those in X who have 
other things to do).


A.3.2 External Perception of the IETF

   Issues derived from Mailing list:

   o  The IETF is the standards body of last resort: If you can't get
	your standard accepted by some 'more reputable' body, then there
      is 'always the IETF'. (Nortel staff member via Elwyn Davies)

==> uh-oh.  I guess this depends a lot on what you work with.  *My*
perception is that I don't give a damn about most other SDO's and even
less for the rest, much less many of those ridiculous call for papers
advertisements for some research conferences.  I guess there is more
SDO-competition on other layers than ones I'm active at..

==> so, if this is the perception, IETF should really be stopping the 
efforts in these "unpopular" areas. (SubIP?  some apps stuff?)


A.5 IESG processing problems

   Issues derived from Mailing list:

   o  Time from WG finished to IESG approval is too long

==> as many have noted, this is probably partially true, but myself I've
had way too many encounters of really, really broken ideas which have been
at (or close to) the "WG finished" state.  Is it IESG's problem that WG
does not produce good results (but declares victory as soon as possible)?  
I guess it gets to be IESG's problem, somehow, but the core problem is
certainly elsewhere.

==> (solutions section..) perhaps some kind of review process should be 
instantiated at the stage where a document is made a working group item?  
Perhaps that would be the stage where it would still be easier to 
influence the documents, but late enough that it wouldn't increase the 
load of evaluating stupid ideas unnecessarily.

2.2 The IETF does not use Effective Engineering Practices
[...]
   o  The IETF explicitly avoids developing test tools for verifying
	that protocols meet its specifications.

==> one could very much argue whether this is a requirement for effective 
engineering practises.

2.3 IETF contributors appear to be less engaged than in earlier days
[...]
   o  Commitments to write, edit or review a document are not carried
	out in a timely fashion.

==> commitments?? News to me! 

   o  IESG is too picky (won't charter my WG, won't approve my RFC, etc)
      (Brian Carpenter: Issue 3) [This is exact inverse of internal
	perception - see Joel Halpern's comment above]. The presence of
      both views may mean that the IESG is pretty much getting it right
      within its current remit.

==> I'm not sure what this bullet was meant to say.  I recall IESG being 
too picky was considered a feature by some, certainly is by me!





Semi-editorial:
---------------

   o  Need to introduce management by exception (Elwyn Davies)  

==> I didn't know what management by exception means before doing a search 
with google.  Maybe this should be elaborated a bit.

      that internet mainly runs on Proposed Standards (where it is
      running on I-Ds or Informational RFCs) (Brian Carpenter: Issue 5)

==> was this meant as "where it is *NOT* running .."?  That's how it makes 
sense to me..

   o  We as a community are not following the rules we set for ourselves
	(James Luciani)

==> This needs elaboration: unless you've followed the discussion, there 
is no way anyone can understand the specifics of this issue.





Editorial:
----------

   Section 1.1 gives a short explanation of the teams' thinking in

==> s/teams'/team's/ ?

2.1 The IETF does not have a common understanding of its Mission  

==> this and other titles: words need to be mostly uppercase (some titles 
are also a bit long).

	managed to drive certain classes of customer, who would otherwise

==> s/customer/customers/

	no longer possible to fit the whole Internet within a single
	architecture

==> s/architecture/architecture./

   knotty problem, the IETF has extremely ineffective Engineering
   Practices.

==> Is upper-casing engineering practises good thing?  Same goes to
Project Management, later on, at lest.  I'm OK with both, but I'm a bit
unsure about some upper-cased wordings..

      at all or within an acceptable time frame: Lack of process for

==> s/L/l/ ?

   continued attendance at IETF meetings to cost constrained employers.

==> s/cost cons/cost-cons/ ? 

References

==> Split to Informative/Normative; these are all Informative, I guess.

      particpant to carve out a reputation for him/herself by initially

==> s/particpant/participant/

      with this end in view: To that extent, at least, they are beholden
      
==> s/T/t/ ?

	 this respect the IETF does resemble a volunteer organisationm.

==> s/nm/n/

	- business utility or fitness for purpose plays a part as well.

==> s/plays/play/

      thing' (Eric Rescoria)

==> s/ia/la/

      protocols etc where incumbents have experience/influence vs. new

==> s/etc/etc./

      assist the  editors and authors. Quality auditors would be

==> s/the  /the /

   o  The IETF is perceived as unfocussed (Brian Carpenter: Issue 2).

==> s/ss/s/

      The IETF does not use adquate project management mechanisms to 

==> s/adquate/adequate/

	vendor mwrketeers.

==> s/w/a/

   Issues derived from Mailing list:

==> s/M/m/ ?

   o  The process' slowness means that I-Ds take on the force of a

==> use something like "The slowness of the process" (or processes, I 
don't know the intent)

   o  Too many steps in the overall IETF process: No real urgency to

==> s/No/no/



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