Re: [rtcweb] Protesting the QoS document decision

[Bernard Aboba <[e-mail]>]

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