Re: [rtcweb] Protesting the QoS document decision

James Polk <> Thu, 14 November 2013 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7177B21E80C3 for <>; Thu, 14 Nov 2013 11:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.563
X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZTf67XUOOXlZ for <>; Thu, 14 Nov 2013 11:31:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 229C321E8105 for <>; Thu, 14 Nov 2013 11:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9062; q=dns/txt; s=iport; t=1384457472; x=1385667072; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=CiMfjoc3bJXH9aTbMnxN4SxURj8SgP7gnHr6OaxPG0o=; b=ltE5AgpNOZMXV35Datp3dfnhxKsQWE14ItdwluC7ui2co3k2WNP0Q1pT dYWKf/owldW4V5Z3hILRwhimrhJLWg4Yfdz61JoQ8CqHSR+i/G53eKP44 5LMwX0gkRLe69/0G8GXIqkOo8sAuS9uESUr1OeRcEg4L9sbR8Y+CA+ReM Q=;
X-IronPort-AV: E=Sophos;i="4.93,701,1378857600"; d="scan'208";a="284934264"
Received: from ([]) by with ESMTP; 14 Nov 2013 19:31:11 +0000
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id rAEJVBn2004230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Nov 2013 19:31:11 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 14 Nov 2013 13:31:11 -0600
To: Harald Alvestrand <>, James Polk <>
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: Gorry Fairhurst <>,, "Black, David" <>, "" <>,
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: Thu, 14 Nov 2013 19:31:24 -0000

At 08:16 PM 11/13/2013, Harald Alvestrand wrote:
>On 11/13/2013 11:11 PM, James Polk wrote:
> > 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.
>This only reinforces my procedural comment. The fact that the decision,
>and the reasons for it, has been hidden from the group for 8 (?) months
>only makes it worse, not better.

it was mentioned during the chair's review of RTCweb documents during 
the Orlando RTCweb meeting. I was there in the front row...

>When ADs make decisions by talking among themselves, they have a special
>duty to make sure those decisions are public and open to the community.
>That duty has not been executed in this case.
>I don't know who dropped the ball - the ADs or the chairs. But the ball
>was definitely dropped.

I think this was announced on the list, but was part of a larger 
email, and not the main topic (i.e., "subject" line)... making 
searching for it difficult at best.

> >
> > 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.
>I have issues with those too. Especially the speed at which they're
>progressing. But those decisions were made and announced in a timely

I figured this was part of the problem, and have nothing good to add here.

>The argument that has been used is that the pieces we need defined
>(BUNDLE, MSID, circuit-breakers, RMCAT) have general applicability, and
>should therefore be processed by groups that are chartered to define
>extensions with general applicability.

it was RMCAT (also in Transport) that was the main interaction from 
my pov, and I think from the TSVWG chairs pov, as RMCAT's chairs said 
to TSVWG (paraphrasing) "we don't think we're going to need anything 
new or existing work wrt DiffServ to solve RMCAT's solution". This 
effective told the TSVWG chairs they could table/postpone/whatever 
the DiffServ draft from RTCweb until RMCAT was through deciding which 
solution they were going to go with. I think, perhaps, the TSVWG 
chairs (me included) thought there was more of a direct link between 
RMCAT and RTCweb than there really was. If there was, and we were 
talking past each other, then  apologize, as I clearly didn't get that memo.

> >
> > (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?
>My understanding of the QoS draft has always been that it should define
>no new codepoints.

It shouldn't and doesn't, it's merely a profile doc for RTCweb (said 
as an author and as a TSVWG chair).

>It should point out the language we need to translate
>RTCWEB requirements ("audio should go faster than video, except when the
>app says that it should be the other way around") into already-defined
>DSCP code points.

that's my understanding (of the requirements) too

>I have not seen anyone arguing for new DSCP codepoints

nor should they have

>, so I really
>wonder what work there is for TSVWG to do.

to make sure that no one specifies anything stupid in the profile.

What RTCweb doesn't know, except for Magnus and Colin, is that TSVWG 
is in the process of bis-ing our DiffServ guidelines RFC (4594). 
We've reached WG consensus on most of the proposed changes, by the 
author/editor has a couple of changes he hasn't reach WG consensus with/on.

>Again, the arguments may be there, but since they were never exposed to
>the mailing list, I cannot evaluate them.

"never" is, I think, not true.

I'll give you 'announced along with 50m other things in RTCweb 
(buried in the background noise) ...

> >
> > Color me confused...
> >
> > James
> >
> > BTW - Full disclosure, I'm an listed author of this draft, but had no
> > voice in it getting moved between the WGs.
>My biggest practical issue with this draft is that it's functionally

see above for the confusion

>I'm getting put in a place where I have to either delay shipping
>this feature in product or ship without even the guidance of a live draft.

I can certainly appreciate that

>I want this group to be done. As long as I can't even point to the
>document that describes how we do QoS, I have no chance of getting it to
>that stage.

again, I can certainly appreciate that


> >
> > 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
> >> process.
> >> 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
> >>
> >>
> >
>Surveillance is pervasive. Go Dark.