ISSUE: Determinants for timeliness missing in section 2.1

[hardie at qualcomm.com]

At 10:07 PM +0200 7/9/03, Dave Crocker the following as proposed problems:
>
>    a) the artificial creation of process dependencies, in the absence of
>    any clear technical dependency, and
>
>    b) post-hoc creation of dependencies, even though a working group has
>    fulfilled its charter and has a ready constituency awaiting
>    publication of its work.
>

Charters do create dependencies, though, both on work that is completed
(as Lemonade on Conneg) and work that is ongoing (as XMPP on IMPP).
Charters are reviewed by the community, and it may well be that some
form of highlighting that there will be dependencies would be useful.  Working
groups also create dependencies (for example, one of the candidate solutions
for CRISP might require an extension for LDAP).  Those dependencies are
on technical output, not "process dependencies" in the sense of "you appeal
to the IAB after the appeal to the IESG has returned".

There may be a judgement call in whether a particular technical output is
or is not required to construct a particular solution and whether or not
it is required to evaluate that solution.  Making those explicit is very
important, so that there is not a "pocket veto" effect of  WG chair or
AD saying to themselves "I'd like to see how FOO comes out before
sending this into the next bucket, so I'll wait".  Explicit statements about
the dependencies mean that the other interested parties can discuss it
when necessary.  This working group is not the place to have those
discussions, though.

On the other, possibly larger question, on the creation of 
dependencies more generally,
I believe we disagree.  In draft-hardie-12-2-1-00.txt, I have this as 
one of the
heresies:

1.6 Dependencies.

      The work of one group must be able to depend on the work of another.

      An organization with expected output of the IETF must be able to
      have the work of one unit depend on the work of another.  Working
      groups commonly divide their work into multiple related documents,
      rather than trying to create a single, monolithic specification.
      The IETF as a larger community needs to be able to do the same
      thing, by allowing specific groups' work to depend on that being
      done at other layers or in other areas.  One advantage the IETF
      has in open review and input is that when one group's lack of
      conclusive output is gating other work, those waiting can add
      their energy to the working group they depend on.

In other words, I see handling of dependencies as something which
presents challenges, but it is not in and of itself a problem in my view.

My opinion,
				Ted Hardie