Re: [rtcweb] Protesting the QoS document decision

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]>
> 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