Problem: Resolution mechanisms for when working group consensus and IETF consensus or principles are not the same (was Re: what are the real problems)

[hardie at qualcomm.com]

I think John has made a very important point here, and want to pull it up
to the named problem level (though I'm not sure I've written the right name
above).  Here's the critical text for me:

>
>We have both seen situations in which a relatively well-organized, 
>but very narrowly-focused, group comes to the IETF wanting either 
>ratification, or an umbrella organization for, standards it wants to 
>produce.  These groups have critical mass by any objective measure 
>we could apply. What they often lack is a strong sense of 
>responsibility to and for the Internet as a whole as distinct from 
>their narrow efforts and focus. Sometimes they can be educated, 
>sometimes they can't.  But they routinely argue "critical mass" 
>(often in the form of how many people they can get to hum loudly at 
>a BOF) as evidence for their entitlement to have a WG.  If they get 
>such a WG, it often requires superhuman efforts on the part of the 
>relevant AD to get and keep their work on-track with basic 
>functionality and interoperability goals on the public Internet, and 
>the ADs are often damned for those efforts when we, as a community, 
>should be thanking them.

Another way to put this is that what is a rational decision for a 
working group may not
be the right decision for the IETF as a whole.  From some 
perspectives, it may be rational
to resist change to deployed clients, even though they contribute to 
congestion or lack security.
It may be rational to avoid interoperability with competing systems, 
so that a larger
scope for the current effort may be planned.  It may even be rational 
for the working
group to replicate at one layer a suite of services developed or 
being developed
at another, so as to avoid dependencies.  Looked at from a broader 
perspectives,
these are rarely the right choices, but we have to acknowledge the 
tension between
the needs of a single effort and the needs of the network as a whole.

At the moment, we have poor mechanisms to deal with those tensions, even though
I believe most IETF participants would agree that congestion control, 
security, interoperability,
and the reuse of a common core set of services are all laudable 
design goals.   The
community reviews charters and constrains them such that efforts are 
expected to
meet certain design goals.  There can be pushback during IETF Last 
Call or during
the IESG's review.  Fundamentally, though, we lack a clear way of handling this
tension as working groups go through the process.  We trust that 
participants have internalized
the issues and that they, therefore, will handle the tension 
themselves.  That can
and does work, but we need other mechanisms to reinforce it:  some of those may
be training, some may be structural reviews at periodic intervals, 
and some may be
creating methods to ensure that cross-speciality expertise is more consistently
available.  But I believe this is one of the key issues at stake in 
our reform efforts:
keeping in balance the global and local.

Just my opinion,
				regards,
					Ted Hardie