Re: [rtcweb] Protesting the QoS document decision

James Polk <> Wed, 13 November 2013 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8991E21E8178 for <>; Wed, 13 Nov 2013 14:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.557
X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKArAuFV3eLD for <>; Wed, 13 Nov 2013 14:11:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0062C21F9F77 for <>; Wed, 13 Nov 2013 14:11:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4720; q=dns/txt; s=iport; t=1384380697; x=1385590297; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=EXRNNDx0Tlus2iqGM2mjtZV+Vm04/QhGEyuTjZ0Fyt8=; b=HkDD3bVx0pT6YFHCErUnd9rjEw8J+B/qtjOaHWjVQ7sKLhzwLEob1ux5 YSBWIgt+vhydmH35oJ4rzMMVy0xiVKDY43YsfVTGU6tIhzHK8namWipdy y3B0gu3l1En6xxR8BkQO5yCbPWdxO+7woO/vNK1V5xDq2w6IYE8iI5aAq c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284440942"
Received: from ([]) by with ESMTP; 13 Nov 2013 22:11:36 +0000
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id rADMBaBD011692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Nov 2013 22:11:36 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 13 Nov 2013 16:11:36 -0600
To: Harald Alvestrand <>
From: James Polk <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Cc:, "" <>,
Subject: Re: [rtcweb] Protesting the QoS document decision
X-Mailman-Version: 2.1.12
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: Wed, 13 Nov 2013 22:11:41 -0000

I, speaking at the mic, was merely pointing out that this draft had 
moved to TSVWG back in the Atlanta timeframe (though, thinking back, 
I think I left the timing piece out of my comment), so it wasn't a 
recent decision. I believe this came directly from talks between the 
above mentioned ADs.

As for RTCweb work being more appropriately inside the RTBweb WG 
instead of another group, I'd like to point out that much of the SDP 
work related to this WG is in fact being done in MMUSIC. Much of the 
RTP work being done by this WG is being done in AVTCORE (or AVTEXT?). 
All of the base SCTP work being done by this WG is being done in TSVWG.

(this is not an attack, but...)

...why are you arguing for something as far away down the stack as 
DSCP assignments to be done in RTCweb, and not where all other 
DiffServ work is being done in the IETF (in TSVWG)? Do you not trust 
that TSVWG will do an appropriate just with a DiffServ ID but you 
will trust TSVWG with SCTP IDs?

Color me confused...


BTW - Full disclosure, I'm an listed author of this draft, but had no 
voice in it getting moved between the WGs.

At 02:21 PM 11/13/2013, Harald Alvestrand wrote:
>This mail concerns both administrative and technical issues, which is
>why it is explicitly copied to the ADs of RAI and TSV. I hope I have
>managed to keep them separate in the message.
>Magnus said in an email yesterday, concerning draft-ietf-rtcweb-qos:
> > Okay, we might not have been public enough on this. It was requested by
> > the Transport ADs quite some time ago that doing the QoS document in our
> > WG was not appropriate and requested us to direct the document to TSVWG.
> > Which was done, and where it hasn't made progress.
> >
> > You might have noted that James Polk did comment in the milestone part
> > in the monday session of IETF88 about our QoS milestone should be killed.
>I want to protest this - both practically and formally.
>To get the formal stuff out of the way first:
>Changing the deliverables of the working group *without telling the
>working group* is totally inappropriate in an open, consensus-driven
>Changing the deliverables of the working group *without telling the
>working group why* and *without allowing those reasons to be debated* is
>totally inappropriate in an open, consensus-driven process.
>I protest against this action.
>ACTION REQUEST 1: I request that this decision be declared null and
>void, and that the relevant ADs send out a message to RTCWEB (and TSVWG
>if appropriate) *PROPOSING* such an action, and giving a reasonable
>timeline for when they will make a decision based on mailing list feedback.
>In practice:
>The draft as it existed before its untimely demise consisted of two things:
>- A description of how QoS mechanisms could be useful in the RTCWEB use case
>- A description of existing mechanisms that could be appropriate for the
>RTCWEB use case
>The first one is clearly something that needs RTCWEB consensus. It seems
>to have no need for, nor likelyhood of gathering interest enough for, a
>TSVWG consensus.
>There could be some argument that the second part needs TSVWG consensus,
>especially if it was redefining any mechanisms, or it was making choices
>between mechanisms where TSVWG had strong opinions about which
>mechanisms should be chosen, but had not chosen to document that in any
>document on which IETF consensus had been declared (that is to say,
>existing RFCs).
>My archive shows 36 messages where the title refers to this draft. It
>shows no messages declaring that feedback has been incorporated and
>calling for new review - something that is usually necessary to get a WG
>consensus on any document. The debate hasn't been conclusive, but then,
>it hasn't been pushed hard either.
>The people who know how RTCWEB works are in this working group. Some of
>them may be in TSV, but I think the locus of knowledge for saying what
>QoS mechanisms are appropriate for RTCWEB are here, not in TSV.
>This results in my second request.
>ACTION REQUEST 2: I request that the chairs declare that based on the
>debate about the QoS functionality so far, the document should be
>resurrected, and will continue to be  worked on in the RTCWEB working
>group, bringing in advice from TSVWG as required to make sure the
>descriptions of underlying mechanisms, and the choice of such
>mechanisms, is correct and appropriate.
>Surveillance is pervasive. Go Dark.
>rtcweb mailing list