WG Last Call on IETF Problem Statement (small proposal to expand text in sections 2.2 and 2.3)

Mon Sep 15 19:16:15 CEST 2003

Although I note that a few people have already said we should "just ship
it", may I please make two, small, last minute, proposals to add to this
draft covering a pair of issues concerning problems effecting
inter-relationships between WGs and between IETF and other bodies?  For
each issue, I offer some background notes and then specific wording to add
to sections 2.2 and 2.3 respectively.

1) Need for IETF to improve communications between WGs and between IETF and
outside organisation when working on common issues

Background:
More and more other standards bodies are now looking to IETF to develop
Internet related protocols and/or extensions to existing protocols to help
them complete an overall system level solution in their domain. Obvious
examples are 3GPP (sip, mobileip, cops, dhcpv6, etc.), ITU-T (megaco, sip,
gmpls, etc.), CableLabs (mgcp, cops, radius), etc.

In each case we see a clear model of these other bodies defining
requirements and an overall architecture and then when they start detailed
protocol work they realise that an obvious solution is to start with a
protocol developed by IETF.  At this point they either choose to simply
develop their own extensions (and hence endanger the goal of common
protocols and confuse the market with non-compliant versions) or they send
experts to IETF to get their requirements included into the ongoing work of
improving WG I-D.  The second route is obviously better and should be
encouraged by the IETF but this will only be successful if we recognise
that we now have sister organisations that are effectively our "customers"
and hence the WGs should have a means of clearly acknowledging these
customers and their dependencies on WG outputs.  Such an environment should
be based on open collaboration and, sometimes, the IETF must be ready to
explain why our "customers" requests are not reasonable and so work with
them to develop a more appropriate solution.

This same problem also exists between different WGs within IETF and so we
could cover both aspects (WG<>WG and WG<>external dependencies) with the
same  text.

To cover this issue I propose we add to section 2.2 a new dot point under
problems list and make a corresponding addition later on in the same
section.  This would complement the existing text in section 2.3 which
covers the complex problem handling aspect of this issue.

Specific proposed changes are :
"2.2 The IETF does not Consistently use Effective Engineering Practices

.....
Some of the contributory problems which interfere with effective
engineering in WGs include:
.....
   o  Failure to identify and articulate engineering trade-offs that may
      be needed to meet the deadlines that the WG has set without
      inappropriately reducing the 'fitness for purpose' for the
      intended customers.

AU - add here>>   o  Difficulty in identify dependencies and respecting
milestones between WG outputs and work planning and the work of other WGs
and/or other standards developing bodies outside IETF which are
collaborating with WGs on common issues

   o  Continued refinement of the solution beyond the point at which it
      is adequate to meet the requirements placed on it by the intended
      purpose.

....

   In addition, IETF processes, and Working Group processes in
   particular, suffer because commonly accepted Project Management
   techniques are not regularly applied to the progress of work in the
   organization.

   o  Project entry, goal setting, and tracking processes are all either
      missing or implemented less effectively than the norm for
      commercial organizations in related activities.

AU - replace with>>
   o  Project entry, goal setting, dependency identification and tracking
      processes are all either missing or implemented less effectively than
      the norm for commercial organizations in related activities."

2) - Lack of "undated" references covering IETF outputs

Background:
One of the techniques used by many standards bodies to break up large and
complex problems is to make the distinction between "dated" and "undated"
references to other standards.  "Dated" references are best used when the
specification must align with a specific feature covered by a reference
while "undated" references are used to simply imply "use the latest
version".

Within IETF we tend to only use references to nominated RFCs and hence only
use "dated" references.  This came lead to delays in publishing new RFCs
since the RFC editor offer needs to complete a set of inter-linked drafts,
assign each a RFC number and finally adjust the references in each prior to
final release.  A corresponding delay is also occuring when other standards
bodies are developing specifications that reference IETF outputs that are
currently not yet released as RFC.  Obviously, both cases would be improved
if IETF could develop some form of "undated" reference to its work which
allows other WGs and outside bodies to refer to "the latest RFC that covers
subject XXX" (this issue has also been discussed at length on the solutions
list)

To cover this issue I propose we add a new dot point to the list in section
2.3.

Specific proposed text is:

"2.3 The IETF has Difficulty Handling Large and/or Complex Problems
....
   Part of the cause of this difficulty may be that the formal reporting
   structure of the IETF emphasises communication between the IESG
   through the ADs and the WGs and does not place much reliance on
   inter-WG communications:
.....

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

AU - add text>>o  The IETF does not have an effective means for WGs and
outside standards bodies to refer to "work in progress" on new subjects and
RFC revisions by means of "undated" references and/or other methods that
allow work to progress independently on individual components of a complex
problem."

yours,

Alistair URIE

                      avri <avri at psg.com>                                                                                                          
                      Sent by:                             To:      problem-statement at alvestrand.no                                                
                      problem-statement-bounces at al         cc:      Melinda Shore <mshore at cisco.com>                                               
                      vestrand.no                          Subject: WG Last Call on IETF Problem Statement                                         

                      31/08/2003 04:51                                                                                                             

This note marks the beginning of the WG Last call for:

>            Title                         : IETF Problem Statement
>            Author(s)         : E. Davies
>            Filename          : draft-ietf-problem-issue-statement-03.txt
>            Pages                         : 24
>            Date                    : 2003-8-26
>

The document can be found at:

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-
03.txt

Because of the US holiday on Monday ,  1- Sept, the last call will
extend from now, 31 August until 16 September (any time zone).

Please send your comments to the WG mailing list
problem-statement at alvestrand.no

thanks

a.

Avri Doria
co-chair