ietf
[Top] [All Lists]

Re: Uneccesary slowness.

2005-05-28 00:41:02
Eliot,


interesting note.  it is always provocative to challenge long-standing precepts,
in this case as per section 2.2 of RFC 2418, Working Group Guidelines, first
published as RFC 1603, in 1994.  That does not guarantee that your challenge is
mis-placed but rather that it is fundamental to the long-established view (or
that it isn't so much as a challenge but rather a call to make sure we know what
we have been meaning.)


 1.  A contract requires due consideration from all parties, meaning that
 nobody performs without an expectation of receiving some sort of
 benefit.  What are the benefits to the WG and what are the benefits to
 the rest of the community?

I suspect each of us might answer this differently.  My own answer is that the
working group gets the IETF imprimatur on its work and the IETF gets work to put
its imprimatur on.  (There is a more elaborate and less glib way of saying it,
but if you think about the implications of each side of the statement, I trust
it will be obvious that each is, in fact, a significant benefit.)


 2.  Most contracts don't require the dissolution of a party should it
 default.  Rather there are remedies, often times monetary.  Sometimes
 there are bonuses.  My point: dissolving a working group because they're
 late would often be imprudent and short of replacing the chair there are
 very few other viable remedies.

Contracts typically DO have an out.  So, dissolution of the relationship is not
at all uncommon.  In this case, the dissolution is of the entity within the
IETF, not of the collection of people within the working group.

At any rate, (eventual) termination for non-performance is more than just
'typical' in contracts, it is very nearly mandatory for a competent contract in
which one party authorizes work to be done by the other.

Yes, having steps for first attempting to cure the problem is, equally, typical,
but cures often do not work.


 3.  A contract in which one of the parties cannot reasonably be expected
 to carry out his or her obligations is not a contract at all.  Again, if
 the WG is a party and the community is a party, what is the expectation
 of the community and is it reasonable?  But even with the WG is it
 reasonable to ever expect innovation as part of the solution under such
 a circumstance?

Sorry, but I don't understand any of this one.  The best I can think to respond
is to the question of mutual expectations, which certainly is needed for a
legitimate, formal relationship.

The community expects working groups to produce material that is timely,
relevant -- to the targeted consumer base -- and useful.  (For anyone who hasn't
been tracking the ietf list recently, these 3 items are my own mantra, though I
think they are entirely or largely compatible with the views of many others.)

The working group expects that it will have the support of the IETF community
(such as by receiving the IETF imprimatur) for wg output that conforms to the
requirements I cited.

Timely performance is a typical expectation for a contract.  Therefore one might
reasonably view a lack of timeliness on either side as a contractual violation.
The same hold for imposition of whimsical requirements at the end of the effort,
or other impositions that are unproductive to the generation of timely, relevant
and useful documents.


 4.  Contracts generally have limitations when it comes to unforeseen
 circumstances, force majeure, etc.  One such unforeseen circumstance is
 where a working group comes up with a solution and the IESG finds
 sufficient fault with it to require a review.  In this case, the terms
 of the contract need to allow for a resetting of the charter.

As much as the IESG does, indeed, seem to be a force of nature, your example
nicely underscores the problem of last-minute requirements-creation by the iesg.
 They have a choice in the matter.  It does not come from some external,
uncontrollable source.

Let's keep the contractual model and pursue the exercise from a purely pedantic
standpoint for this matter:

The IESG is supposed to perform oversight of the on-going working group, on
behalf of the larger IETF community.  At the end of the wg's effort, if the IESG
suddenly decides that some new requirement is to be imposed, then the IESG is
demonstrating that it did not do the on-going oversight that is normal for any
contract.  If the wg submits something that suddenly contains something that is
new and problematic, then it has not been coordinating properly with the agent
providing it with oversight.

(I am trying to explore these sort of things as having mutual obligations.  It
is a point you stressed and I think it applies quite helpfully to the
relationship between the IETF/IESG and the wg.


 As I wrote above, I don't think the contract analogy is perfect.  I
 think we want a cross between a research proposal a'la NSF etc. and a
 contract, where we allow for changes in direction based on developments
 within the working group.  I'm not saying we should ignore
 non-performing or under-performing groups, but we should certainly allow
 some flexibility.

In an earlier and simpler time, it was entirely safe to permit this, since the
*real* oversight of a working group's effort came from within the working group.

In the larger and more diverse IETF, I must entirely disagree with any
suggestion that IETF working groups can operate in a research mode of any sort.
That's what the IRTF is for.  The IETF side of things is for developing a
community consensus about the engineering of a technology or practise for the
global Internet.

(and on that, my *own* provocative note...)

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>