Re: [rtcweb] Protesting the QoS document decision

Magnus Westerlund <> Tue, 07 January 2014 12:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37EBC1ADFA2 for <>; Tue, 7 Jan 2014 04:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8NxYfsCH7J_Z for <>; Tue, 7 Jan 2014 04:06:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 303F81ADFB1 for <>; Tue, 7 Jan 2014 04:06:13 -0800 (PST)
X-AuditID: c1b4fb31-b7fa78e0000005dd-ef-52cbedac288f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A6.40.01501.CADEBC25; Tue, 7 Jan 2014 13:06:04 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Tue, 7 Jan 2014 13:05:29 +0100
Message-ID: <>
Date: Tue, 7 Jan 2014 13:06:07 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: <>, Harald Alvestrand <>, "" <>, <>, <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvre6at6eDDI63qFj8/vSBzeJYXxeb xd7t8xgt1v5rZ7eYNu8jowOrx5UJV1g9Lu08yeaxZMlPJo8vlz+zBbBEcdmkpOZklqUW6dsl cGUsfDuJtWC+QcXHJy8ZGxhXqXUxcnBICJhIdE4t72LkBDLFJC7cW8/WxcjFISRwglHiwPwr jBDOMkaJVxsWMYNU8QpoS5w89IAdxGYRUJFYP3k+mM0mYCFx80cjG4gtKhAscWsaRA2vgKDE yZlPWEBsEYF5jBKdZzlAbGEBK4kHt05CbVvFKPFw9yOwIk4BHYlfCxtYIK4Tl+hpDAIJMwvo SUy52sIIYctLNG+dDXaPENA9DU0drBMYBWchWTcLScssJC0LGJlXMUoWpxYn5aYbGerlpueW 6KUWZSYXF+fn6RWnbmIEBvrBLb8NdzBOvGZ/iFGag0VJnJdhemeQkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsZC6+3H7zxZ1Byw7Vhn8bdUpVtzd2yb/2RhQef044KsDacS87hqn5fLMWae 2izTWCO345ikyr2i1zOU+0tPlHqEzv59/MW0N69mXfF3q5KSYnn89KKT5RX1wJK9olJe1Ttv Hd/fLpN3xLZmmUTdj1Cm6W/+vfbcaFaWdvtquSNHzh6ZJvenDJ5KLMUZiYZazEXFiQDBPIqX QgIAAA==
Subject: Re: [rtcweb] Protesting the QoS document decision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2014 12:06:33 -0000


See inline.

On 2013-12-20 18:43, Dave Crocker wrote:
> 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:
> 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.

I would note that my above statement says, what I think should have
happened in this case. The reasons for this was the WG having a document
with large parts of the document outside of our charter. We also had a
proposed home for the work.

I think if you reviewed the WG's communication on the various decisions
that has been made during the WG history I think you will see both
methods been applied depending on our judgment on of the issues. For
example in all cases we expected to be controversial we have gone with
ensure approval. The tricky part I to find a good balance for the truly
no-controversial issues that people would find time wasting to seek
approval for and the ones where people should have their say.

I will keep in mind the need for ensuring approval going forward.

> 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.

I would note that this WG is trying to do something that isn't that
common in IETF. We are actually doing what I refer to us umbrella
standardization. Putting a large number of components together into a
system. I at least are not surprised that it has taken this amount of
time to get where we are now. I wished we where further along and that
some high attention topics wouldn't have taken the amount of energy it has.

I would also note that it has been quit an interesting process, which
had made us question the choices made in individual components in a
number of places. I think dealing with these issues of putting things
together and wanting to fix or change things is what contributes to the
delay in producing output.

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

Noted, I disagree with you in this particular case due to the reasons
for the request to move it.

> 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.

I think the ADs have the authority to manage their WGs and point out
charter violations in their area's and other WGs.

I agree that ADs don't have final authority on this. This move is not
violating this either. I hope the call for adoption in TSVWG will start
very soon for the document prompting this discussion and its topics that
falls within TSVWG charter.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: