Open Issues/State of Play for issues draft (v02)

Mon Jul 14 08:27:24 CEST 2003

Hi.

Looking at the document (draft-ietf-problem-issue-statement-02.txt) and the
traffic on the mailing since this document went to the I-D editor, I believe
that the following eight items may need to be updated or added to
incorporate the discussions that were in progress at 30 June or have
surfaced since:

---------------------------------
Mailing list discussion: Further traffic on 'ISSUE: Determinants for
timeliness in Section 2.1'

This discussion centres on managing coordination and dependencies between
the work of different WGs (including ensuring that dependencies between
charters are appropriate and clearly understood by all parties).

This appears to be a further manifestation of the problem documented in 2.3
relating the poor handling of large and complex problems.  I suggest that
the points could be summarised by modifying the following bullet point in
2.3:

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

as follows

   o  The IETF does not posess effective formal mechanisms for inter-WG
      cooperation, coordination or communication, including the handling
      of dependencies between the deliverables and processes specified in
      WG charters.

----------------------------------------

Ongoing mailing list discussion/Document drop-off: 'Re: appeal mechanisms
was Re: Ombuds-process'

Due to finger trouble during last minute editing the intended body of the
section which addressed this problem was omitted.  The intended text that
follows appears to document the issue as it has  been discussed:

2.6.8 Difficulty making technical and process appeals

   When an individual thinks that the process has produced a result that
   is harmful to the Internet or thinks that IETF processes have not
   been adhered to, there is no mechanism to aid that individual in
   seeking to change that result.

-----------------------------------------

Further discussion of: 'Re: The need for smaller protocol specifications'

This appears to be covered by the last para  in section 2.3 and the second
bullet point in 2.4, but a few  extra words may be needed.  Views?

-----------------------------------------

Mailing list discussion: 'ADs who are also WG chairs'
Potential open issue: Are 'barriers to concensus formation' adequately
covered?

This thread has strayed considerably from its ostensible title, which is
covered fully by the discussion in the last para of section 2.6.6.  The
later discussions which appear to be about other consequences of the
concentration of influence are, I believe, covered - so far as the problem
at issue is concerned, as opposed to a solution to the problems - by section
2.6.6.  It appears to me that the thread does not actually offer any
concrete evidence that resolving the philsophical objection to the current
'rough concensus determined by WG chairs' mode of operation (by replacing it
by some 'more democratic' process) would actually improve the quality, take
up or timeliness of IETF standards.  So, I don't think that it is proved
that lack of democracy is a root  cause problem, but that does not mean that
some or all of the points made should not be considered when solutions are
being considered.  Accordingly I don't think we need to change the issues
document in this direction.

However it is possible that the coverage of problems with the WG concensus
process is inadequate.  The points raised by John Klensin in a thread
started back on 7 March regarding ways in which the conscensus process can
be subverted by off topic mail storms leading to concensus by exhaustion,
effective exclusion of knowledgeable participants and unrepresentative
solutions, may not be adequately covered.  Views?

------------------------------------------

Mailing list discussion: MAJOR ISSUE: Causes of "problems"

The original thrust of this issue is that the expansion of scope of the
IETF's problem domain may be  in itself a problem.  This appears to be
discussed right at the start of section 1 and section 2.1 notes as a problem
that the IETF doesn't actually know what its scope ought to be at present.
The problem of the space having got larger seems (IMHO) to pervade several
of the succeeding issues, and I would therefore take the view that no
further action is needed.

-------------------------------------------

Mailing list discussion: 'Accommodating ESL speakers'

This point is mentioned in section 2.6.6 as part of the matters that
conspire to leave influence concentrated in too few hands.  It should
probably also be mentioned in the discussion of education in seection 2.8:
Participants should be made aware that they are not just talking to mother
tongue English speakers with a North American (esp. US) cultural outlook,
and given guidance in how best to make their presentations comprehensible to
the largest number of participants.

-------------------------------------------

Mailing list discussion: 'Fixed font vs multiple fonts' etc

The much flogged and thoroughly mortified equine of alternatives to ASCII
documents has once again been resurrected and subjected to yet another
painful and humiliating death. [Sorry: There has been yet another attempt to
reopen the ASCII document decision without compelling new evidence of  a
wrong decision.]  I think the discussion makes it clear that this is not a
root cause of any problems that currently beset the IETF.

However, there do seem to be a couple of points that might be considered as
part of process improvement:

1.  The archival format is effectively the final ASCII document rather than
the original source which would be needed to recreate the document or form
the basis of a revised version - at one point documents were almost all
derived from nroff sources and could be submitted in this form (I seem to
remember).  I don't know if the RFC editor keeps these versions in case of
later need (when maybe the original editor is no longer contactable, or has
lost the sources), but this has become irrelevant when many documents are
originated in different ways, in formats that are not acceptable to the I-D
or RFC editors.  So the RFC archives are based on a format which is not
easily re-editable.  This does not appear to be good engineering practice.  
<Solution> 
Marshall Rose's XML format seems to be a good start on a new re-editable
format whilst still being all ASCII and having many of the good
characteristics of the old nroff format plus providing semantic clues which
make generation of derivative documents and alternative formatting
reasonably easy. [HTML as an archival format is much less good than nroff -
no semantics and uncertainty about tag meanings. Word is a total non-starter
because there is little guarantee of backwards compatibility apart from
anything else.]
<Solution />

2.  The lack of a standard way of archiving editable versions high
resolution graphics (such as are sometimes exhibited only in Postscript (or
PDF) versions of drafts) does seem to be a constraint on communication.  
<Solution>
The requirement to produce an ASCII version might  be  provided by
generating a  'preview' version (such as is often available in EPS -
embedded PostScript images).
<Solution />

------------------------------------

Mailing list discussion: 'Plenary decision?'
Potential Open Issue: 'There does not seem to be a satisfactory way of
testing concensus across a large portion of the
stakeholders/participants/'members'.'

Certain items of general interest to IETF stakeholders (such as the problem
WG output) should be the subject of organization-wide (rough) concensus.
Such items are usually presented to a plenary session at a f2f meeting, and
the  I* take the input as guidance towards a decision but it is not clear
that the whole constituency is really made aware of the decision to be made
so that all possible views can be heard  -  some of the IETF general mailing
lists are the best vehicle for this  but it is not clear that this system is
used in a way that everybody knows about.

--------------------------------------

A message has  been received  from Harald Alvestrand indicating that he is
happy with the resolutions of the issues which he originally raised on v01
of the draft.

Comments on the matters above or the issues which were already supposedly
addressed either here or at the WG  session on Tuesday morning please.  We
would like to get out a new version and go to last call on the issue
document asap if at all possible.

Regards,
Rlwyn
----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime
        Portfolio Integration			Solutions Ready		

        Nortel Networks plc			Email:
elwynd at nortelnetworks.com
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    		Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======