Re: [rtcweb] Protesting the QoS document decision

[Magnus Westerlund <[e-mail]>]

On 2013-12-20 09:20, Harald Alvestrand wrote:
> Thank you, this resolves my practical issues, and the acknowledgement of
> the communication & transparency issues seems adequate to help prevent a
> repeat of this stall.
> 
> I'll also take this as instructions to the group to replace all
> references to -rtcweb-qos  with referenes to draft-dsheikan (or its
> successors).

Yes, as this is the document we currently have. If the WG sees a need
for a document that has another scope, then I believe each author and
the WG will need to consider which of the document is the appropriate
one to reference in their contexts.

Merry Christmas

Magnus Westerlund

> 
> On 12/19/2013 05:12 PM, Magnus Westerlund wrote:
>> Harald, WG,
>>
>> We apologize for the failure to inform and keep the WG aware of the
>> discussion and TSV ADs request to move draft-ietf-rtcweb-qos with it's
>> then content to TSVWG. A request chairs and authors accepted in the end
>> more than a year ago. This is clearly a failure by us chairs to ensure
>> sufficient transparency and a venue to timely protest that decision.
>>
>> After reviewing this with TSVWG chairs, the non-recused RTCWEB chairs
>> (Magnus and Ted) do believe that the DSCP aspects require TSVWG action,
>> and that draft-dhesikan belongs there as a result. If there are aspects
>> of the QoS approach that are outside draft-dsheikan's current remit,
>> those might still belong in RTCWEB. We might also be able to pull some
>> pieces out of draft-dhesikan for local progress, but we can't take the
>> full document as it stands. Thus nothing prevents the WG from creating a
>> new QoS related WG document assuming a different scope than the previous
>> document. If any WG participants see a need for such a document they are
>> welcome to submit an individual document as a proposal for such a WG
>> document.
>>
>> We note you protesting the lack of progress of draft-dhesikan in TSVWG,
>> and state that as one reason why this document should be in RTCWEB WG.
>> After reviewing mailing list discussion, meeting minutes and talking to
>> the TSVWG chairs, it appears that the main reason it hasn't been making
>> more progress have been the lack of an draft update to resolve the issue
>> raised in the Berlin TSVWG meeting. We have good hopes that the document
>> can make fair progress in TSVWG assuming author and RTCWEB participants
>> make timely contributions to the document.
>>
>> Harald, does this provide a clear enough way forward or, do you wish to
>> continue your appeal?
>>
>> Best Regards
>>
>> Magnus Westerlund
>> Ted Hardie
>>
>>
>>
>>
>>
>> On 2013-11-13 21:21, 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.
>>>
>>>
>>>
>>>
>>
> 
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------