[rtcweb] Protesting the QoS document decision

[Harald Alvestrand <[e-mail]>]

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.