Working Group chartering

Jeffrey,

(I have changed the subject line, so that this discussion is explicitly NOT 
about any current IETF chartering activities.  I hope folks will not take my 
comments as having any implication about any of those efforts or discussions 
about them...)

> I think a lot of people might be missing a key point about how our 
> process works.  

What makes things particularly challenging is the difference between Procrustean 
 attention to documented rules, versus applying them in an integrated manner 
with subjective assessment of the pragmatics of being productive.  Any 
organization that strictly resolves disputes based on the letter of its laws 
quickly alienates is workforce.
When we wrote the rules regarding chartering, the intent was to have the 
cognizant AD conduct whatever discussion were needed to create a working group 
that would be productive.  This is inherently a fuzzy process, so it was -- and 
remains -- important to avoid over-documenting the procedure.
For example, an AD who entirely ignores the concerns and desires of those who 
will do the bulk of the work risks having a working group without workers.
The pragmatics, therefore, require the AD to try to juggle various political, 
technical and project management concerns, and put forward a charter that they 
feel will offer the best chance at productive working group output.
Frequently -- maybe usually -- this is primarily through a private dialogue 
among those who will form the small core of the working group effort, including 
likely chairs.  However it is not uncommon for a public dialogue to be 
conducted.  For example, a BOF usually includes a review of candidate charter 
text.  That the open group's consensus is not binding on the AD merely indicates 
the delicate nature of chartering, rather than the irrelevance of that consensus.

> This ability to determine what work will be done and under what terms is 
> a fundamental part of what it means to "steer"; without it, the IESG 
> would not be much of a "steering group".
Actually, this highlights why "steering group" is exactly the wrong term for the 
IETF process management team.  They do not initiate work and they are not 
primary contributors to that work.  Hence, they do not really "steer" anything. 
 When the IESG tries to act like it does, they often find no workers and a mass 
of dissatsfaction.
The job of the IESG is to facilitate the initiatives of others and to ensure 
enforcement of useful quality assurance.

>     It's beneficial to apply 
> constraints like only considering solutions with domain-level 
> granularity, or only addressing how to _provide_ identity information 
> and not what to do with it.  Particularly given the IETF's previous 
> experience with attempted anti-spam work, I think such constraints are 
> necessary to narrow the problem space to one for which a working group 
> will produce something in a finite time.
> Besides being necessary, those constraints are also acceptable because 
> while they limit _this_ working group to solving one piece of the 
> problem, there is no implication that other working groups will not be 
> chartered to work on other pieces.  And, while _this_ working group is 
> constrained to a particular approach, there is no implication that other 
> approaches might not also be tried.  
all of the above is nicely said, as comments about a class of working group 
startup efforts.

> What I do _not_ think is reasonable is a demand that the working group 
> be constrained to produce exactly the protocol proposed, making changes 
> only if absolutely necessary.  
And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an idea. 
Some with a detailed proposal.  Some with a detailed specification and some with 
existing and deployed technology.  When a working group starts, it must make the 
strategic decision about how much prior work to preserve, versus how much new 
work to encourage or require.
There are obvious and significant trade-offs in this choice.  What is essential 
is that the trade-offs get serious consideration and that the choice be 
appropriate to the particular situation.  It absolutely is NOT true that all 
chartered working groups must be allowed to throw away any and all prior work. 
The loss of invested community effort and the loss of momentum would be disastrous.
At the least, an effort that seeks to use existing technology needs to explain 
clearly and convincingly what needs to be preserved.  Equally, any efforts to 
deny the stability of re-using that work must make a compelling and concrete 
case for the changes that are needed.

> Note that the XMPP case is somewhat different from this one.
Remembering that this new thread is about a general issue, rather than debating 
a particular working group effort, I'll comment on the particulars of your 
reference:
  In that
> case, a working group was formed to "adopt" an existing technology from 
> another process, and develop an Internet standard.  High value was 
> placed on compatibility with the existing widely-deployed protocol, 
> which is appropriate and the same treatment we'd give to our own 
> existing standards, or expect other SDO's to give them.
> As I understand it, DKIM is _not_ a widely-deployed protocol developed 
> by another SDO; it is a proposal developed by a design team with the 
> specific intent of bringing it to the IETF.  There is absolutely nothing 
> wrong with that approach.  However, the normal next step is to bring the 
> design team output back to a working group, or to the IETF as a whole, 
> and ask for comments and/or consensus to use the design team's output as 
> input to the next step in the process.
Jabber did not come from another SDO.  Even if it had, I fail to see why that 
imparts special status.  DKIM came from a substantial -- albeit informal -- 
industry initiative with quite a few organizations participating. Nothing about 
Jabber's or DKIM's origins automatically make the technical quality of the work 
good or bad, or necessarily of interest to the IETF.
(Well, ok, I'll indulge in a particular, in order to correct a factual error: 
Mis-statements about DKIM's deployed base have been corrected quite a few times. 
 Suffice it to say that your understanding is incorrect.)

> In this case, it appears that instead of doing that, the design team is 
> asking the _IESG_ to make the decision that the design team's work will 
> be used for the next step in the process, without the benefit of working 
> group or unconstrained consensus. 
(Damn.  Have to correct another one:  I have been boringly pedantic about citing 
the TWO rounds of OPEN, online consensus effort surrounding the draft charter. 
This was not a tiny cabal or even a larger, albeit closed, group or 
organizations.  The draft charter text was produced by a highly open and 
responsive process over the course of months.)

d/
--

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

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