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

From: [email-masked]
Date: Mon, 15 Sep 2003 18:16:15 +0200

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 <[email-masked]>                                                                                                          
                      Sent by:                             To:      [email-masked]                                                
                      problem-statement-bounces@al         cc:      Melinda Shore <[email-masked]>                                               
                      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
[email-masked]

thanks

a.

Avri Doria
co-chair

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 07:22:36 -0700

Alistair,

AUac> Although I note that a few people have already said we should "just ship
AUac> it", may I please make two, small, last minute, proposals to add to this
AUac> draft covering a pair of issues concerning problems effecting

I believe both of the points you raise are interesting.

I believe neither of them is essential to include.

We can never list all of the problems. There are too many.  We need to limit
the list or we will never complete it.

The impetus for this work is to correct major problems with the IETF that are
hurting the timeliness and utility of IETF output.  While there are many, many
things we might do to make improvements, we need to limit the current, formal
effort to major problems.

I believe the two items you have cited are worthy of discussion and may
warrant changes, but I do not believe they warrant further delays to the
working group documents.

d/

ps.
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "todd glassey" <[email-masked]>
Date: Wed, 17 Sep 2003 13:48:50 -0700

Dave
----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Cc: "Melinda Shore" <[email-masked]>; "avri" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 17, 2003 7:22 AM
Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexpand
text in sections 2.2 and 2.3)

> the list or we will never complete it.

Not true - What we need to break the list into several lists. That is to
create listso of associated problems specific to a conceptual area. Like
problems with the "Posting Model" and "Participation Models" in the WG's.
The problem with the current list is that it is all encompassing and as such
it is too large. But if it was broken down into smaller areas of concern the
work-product documents would be more manageable and of a more digestable set
of goals (at least IMHO).

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 17 Sep 2003 16:05:31 -0500

My opinion is not unbiased (I'm on the editor's team), but I would
prefer to actually do something about the problems we've identified in
the more-than-year since Yokohama.

We have added one new root cause since the list was created in March.
This doesn't mean "there are no other problems", and it doesn't mean
we have wasted time in discussions since then, but it does mean that
we have a stable set of root causes as the basis for change. Further
massaging of the list is not required for us to start making changes,
and (since we're unlikely to make one set of perfect changes anyway,
so must keep our eyes open in the future), anything missing probably
isn't on the critical path to making changes.

If it is, and we've missed it in six months of fairly intense mailing
list and face-to-face discussions, I'd be surprised.

The level of rigor for a problem statement for process change does not
need to be as high as it is for a Proposed Standard protocol spec.

IMHO.

Spencer

> >
> > We can never list all of the problems. There are too many.  We
need to
> limit