Re: [rtcweb] Protesting the QoS document decision

Dave Crocker <dhc@dcrocker.net> Fri, 20 December 2013 17:44 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497901AE0AB for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 09:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYJvAwu1o64c for <rtcweb@ietfa.amsl.com>; Fri, 20 Dec 2013 09:44:34 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC31AE043 for <rtcweb@ietf.org>; Fri, 20 Dec 2013 09:44:34 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBKHiLCA031071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Dec 2013 09:44:24 -0800
Message-ID: <52B481A9.6010008@dcrocker.net>
Date: Fri, 20 Dec 2013 09:43:05 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>, rai-ads@tools.ietf.org, tsv-ads@tools.ietf.org
References: <5283DF61.9060807@alvestrand.no> <52B31AF0.60107@ericsson.com> <52B32AE7.1080100@dcrocker.net> <52B40A1E.6030308@ericsson.com>
In-Reply-To: <52B40A1E.6030308@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 20 Dec 2013 09:44:26 -0800 (PST)
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 17:44:36 -0000

On 12/20/2013 1:13 AM, Magnus Westerlund wrote:
> What in my mind should have occurred, but didn't in this case, would be
> to do the following:
>
> 1. Send an email to the WG stating an intention to move the document.
> Including the main motivations for the action. Provide a dead-line when
> this will be done unless objections have been raised.
>
> 2. When the dead-line has been reached, assuming no objections document
> it as the decided.
>
> Do you think I as a chair is overstepping my authority if I follow the
> above process in these cases where discussion is occurring in a smaller
> group and some proposed direction is reached?
>
> I note that in this particular case it could have been the ADs that
> could have made the decision. However, as this wasn't communicated as an
> AD decision, I will not attempt to hide my responsibility behind such a
> line of argumentation.


Magnus,

(I note that Harald has indicated he's now satisfied with the current 
situation.  That moves this exchange farther into the realm of 
hypotheticals.  Still, it might be useful.)


Simple answer:  What you describe would have been 'legal', but I believe 
it also would not have been advisable.


Extended answer:

The IETF list today has a thread about the handling of chair and author 
assignments.  I posted a note into it that is relevant to rtcweb, given 
its history:

 
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=75013&tid=1387560859

That was about wg "structure".  The question here is about process for 
making a decision.

The basic model for IETF wg decision-making is "default no".  That is, a 
working group needs to amass rough consensus IN FAVOR, in order to 
approve a decision.

A common efficiency hack is to assert a default-yes model, for some 
decisions.  That's what you propose.

Default-yes works well in a healthy working group that is nicely making 
progress.  It relies in high trust of the working group chairs, 
participant comfort in being able to raise objections, and good working 
group support for discussing objections.

At the beginning of a working group, the primary goal needs to be to 
establish a pattern of affirmative consensus.  Folks need to get into 
the habit of finding things to actively agree on.  That requires an 
active process.  Passive "no one objected" agreement often isn't really 
agreement.  More importantly, it definitely isn't active support for the 
final output.

Active support for the final output is the single-most important goal 
for IETF work, since it creates a likelihood of adoption in the field.

That's not what you've got in rtcweb.  Quite the opposite.  Just look at 
the wg statistics.  Lots of documents.  1.5 years.  Nothing published. 
Blocked on a decision about a component.   I also hear continuing 
reports of mutual suspicion amongst participants.

So no, I don't think what you propose would have been a good choice, 
even though it might have been legal.

But your ending note about the possibility of an AD decision points to 
an even deeper problem:  ADs don't have that authority.

Working groups decide on what documents they adopt, within the 
constraints of their charters.  To move a document from one working 
group to another requires agreement of both working groups.  AD's do not 
have final authority on this.

If you disagree, please show me where that authority is assigned.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net