Re: [rtcweb] Protesting the QoS document decision

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 14 November 2013 06:33 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B9321E80C1 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 22:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFhm5dFWBgeF for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 22:33:01 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7393521E8087 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 22:33:01 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id hi5so267755wib.0 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 22:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5FmPx5Zjlc15Sz5uh8Bx2oQ6VlEJACdbGCg37///zTE=; b=Y0G7hOnKK9lEvpzt80Ce3qYTnzWYCMxHo4iUm/z6MTrCSHoNkF5Lo+ZrwXDMuHDaaN GFJ2tBPRIh2Su7c3k6opuv/bdn36zsTD88n/+qkwEw4FvoVe+TwmPDlSuHJDqYUcy6nr Wa6BXhI6ifXBcX9/Vb5ShVXZZ01XFFw5fwPtn4naH04ZlyfvNjEuVwPyGDozC9f1eDPM xek61mPVUafrnb0qHFADhQuFW2u9j3qQcZBw+A4+AO09EzchelM0nHvUGQ4nZR5y3nrH 9WAiUkgzsDPKn550PD2OeidB443XCsMrWB89Jb/GQNkHKm9tv8lLY55TKMVmOI/nulOo PueA==
MIME-Version: 1.0
X-Received: by 10.180.74.15 with SMTP id p15mr653635wiv.63.1384410780589; Wed, 13 Nov 2013 22:33:00 -0800 (PST)
Received: by 10.223.196.9 with HTTP; Wed, 13 Nov 2013 22:33:00 -0800 (PST)
In-Reply-To: <B80D5D7B-EDD6-4965-95C4-09A19E61E721@cisco.com>
References: <5283DF61.9060807@alvestrand.no> <201311132211.rADMBaBD011692@rcdn-core2-5.cisco.com> <52843288.5000507@alvestrand.no> <BLU403-EAS2689015F100872BC417EF2493F80@phx.gbl> <B80D5D7B-EDD6-4965-95C4-09A19E61E721@cisco.com>
Date: Thu, 14 Nov 2013 00:33:00 -0600
Message-ID: <CAKKJt-cPzKFXgb1-UYi5bWm+bVzDbqu1k9_OV7bKALnftewOkw@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary=f46d043be1b0cce6cc04eb1d4011
Cc: "rai-ads@tools.ietf.org Area" <rai-ads@tools.ietf.org>, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, David Black <david.black@emc.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Protesting the QoS document decision
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Thu, 14 Nov 2013 06:33:03 -0000

On Wednesday, November 13, 2013, Cullen Jennings (fluffy) wrote:

>
> I'm trying to not say much on this whole thread but I wonder if the tsv-ad
> could provide any more insight around why this was appropriate for TSV.


Probably so, but Martin is on his last week of parental leave - I'll check
with him when he surfaces.

Spencer


>
> It's not assigning any new DSCP, it's simply providing pointers to the
> existing codes defined in documents done by TSV that talk about the DSCP to
> use for audio, video, and such. I think if folks could help people
> understand what transport content was, that would help. (and added David as
> he has been involved with this draft )
>
> Cullen in my individual contributor role.
>
> On Nov 13, 2013, at 9:29 PM, Bernard Aboba <bernard_aboba@hotmail.com>;
> wrote:
>
> >> 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.
> >
> > [BA] The approach of dispersing work among half a dozen WGs isn't
> working in this case, and in fact hasn't worked particularly well in the
> past either, because it generates neither urgency nor focus.
> >
> > At this point, we are probably not much more than a year away from
> widespread deployment of  running code. So if a critical dependency is not
> making progress toward a WGLC it is time to hit reset. The reality is that
> there is no reservoir of undiscovered manpower to get this work done, just
> interested authors and reviewers who if fed a steady stream of documents
> without unnecessary distractions and bureaucratic impediments can help us
> rapidly get to closure.
> >
> > Our current process is akin to shuttling children from one neglectful
> foster home to another until we lose track of them and realize to our
> dismay that something bad has happened. This isn't a plan so much as an
> accident waiting to happen.
> >
> >
> >
> >
> >>
> >>
> >>>
> >>> 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 w