Re: Uneccesary slowness.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]