Re: Uneccesary slowness.

Hi Dave,

Dave Crocker wrote:
> 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.)
Yes, I understand.  My point is that the analogy is strained.  Please 
see below.
> Contracts typically DO have an out.  So, dissolution of the relationship is not 
> at all uncommon. 
> Yes, having steps for first attempting to cure the problem is, equally, typical, 
> but cures often do not work.
First I agree that terms of dissolution are important, and I probably 
wasn't as clear as I could have been.  I meant that one shouldn't start 
with the nuclear option, if you'll pardon the use of the term.
> 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.)
Yes.  You and I differ on what "timely" means.  We also differ about the 
nature of work done in WGs.

> 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.
We have a working group that did something unexpected.  It wasn't 
against its charter, but it doesn't sit well with various IESG members. 
 What should happen?  Should the IESG suffer the choice?  If so, why do 
they exist?  Keep in mind, by the way, that IESG members change.  What 
happens then?  Should the new member let such a concern go just because 
the old guy didn't catch it earlier?  All of this just happened in ISMS.
> 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.
I guess my concern is that we're not building cookie cut houses.  We're 
not a fab factory.  Companies who have hierarchical control can't 
predict the exact release of a product when new techniques are used. 
They can't do this precisely because the techniques are new.  Who knew, 
for instance, that going into ietf-smtp we would end up with MIME?  Not 
I.  Who knew going into the IPng effort we'd end up with a 16 byte 
address.  Definitely not I.  Why?  Because some of this stuff is Hard.
While recognizing that good is the enemy of great, I would hate if a WG 
felt so under the gun to complete in order to get shlock out the door. 
I can demonstrate several examples of that.
Regards,

Eliot

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