Re: [rtcweb] Protesting the QoS document decision

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 14 November 2013 05:21 UTC

Return-Path: <fluffy@cisco.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 47DCC21E81B2 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 21:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.583
X-Spam-Level:
X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 7OsAej+56RyP for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 21:21:15 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 38BAD21E81BB for <rtcweb@ietf.org>; Wed, 13 Nov 2013 21:21:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1384406475; x=1385616075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V6GRqgr2QJAlJHE64UHHAoiuWn6w7uq5vF/OpKAU0EM=; b=dNHqpdj/pOu7WCVw6LEqe6ZQx5cqqb09+QNPfuXq+DCLpsbqhiA2CbBP qib8bQAvo2CL6CjRFSegYaWz9KLRuJMUS1Zf/E8TCqa1yN+WRi9cDq4rm DsBrgfWCWYhmBVUrz1WWKDFHyamK/nBiBF24H11T1NAU9FXRfgr92aQLj c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FANpchFKtJV2a/2dsb2JhbABZgwc4U6xJkhdLgSkWdIIlAQEBAwEBAQEaHTQGBRACAQgYHhAnCyUCBAENBYdvAwkGDb9DBIxtgSkQgQYzB4MggREDliaBaoxUhTiDKIFxOQ
X-IronPort-AV: E=Sophos;i="4.93,697,1378857600"; d="scan'208";a="284579927"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 05:21:14 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAE5LEVP016192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 05:21:14 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 23:21:14 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, David Black <david.black@emc.com>
Thread-Topic: [rtcweb] Protesting the QoS document decision
Thread-Index: AQHO4PlVPlkJmTapqkioqraFxaneyw==
Date: Thu, 14 Nov 2013 05:21:13 +0000
Message-ID: <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>
In-Reply-To: <BLU403-EAS2689015F100872BC417EF2493F80@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C1E797C3726614DA9AA3857EAB14400@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rai-ads@tools.ietf.org Area" <rai-ads@tools.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 05:21:20 -0000

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. 

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 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
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> -- 
>> Surveillance is pervasive. Go Dark.
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb