Subject: Re: [rtcweb] Protesting the QoS document decision

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Dec 2013 17:12:32 +0100

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Dave Crocker <[email-masked]>
Date: Thu, 19 Dec 2013 09:20:39 -0800

On 12/19/2013 8:12 AM, Magnus Westerlund wrote:
> This is clearly a failure by us chairs to ensure

A failure in transparency is actually the lesser offense, though lesser 
does not mean minor.

The deeper error is that the chairs felt they had authority to make a 
decision that really belonged to the working group.

This occurrence seems to be an exemplar of a pattern.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Dec 2013 09:20:57 +0100

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).

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Dec 2013 09:34:49 +0100

> references to -rtcweb-qos  with referenes to draft-dsheikan (or its

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

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Dec 2013 10:13:02 +0100

> This occurrence seems to be an exemplar of a pattern.

Dave,

I know we wrote decision in our response, and I would like to expand a
bit why. In this particular case the discussion between the TSV and RAI
ADs, the TSVWG and RTCWEB chairs as well as the draft-ietf-rtcweb-qos
authors resulted in an implicit decision. I stated that as being us
chairs taking a decision, that was due to our failure of properly anchor
this in the WG.

What in my mind should have occurred, but didn't in this case, would be
to do the following:

1. Send an email to the WG stating an intention to move the document.
Including the main motivations for the action. Provide a dead-line when
this will be done unless objections have been raised.

2. When the dead-line has been reached, assuming no objections document
it as the decided.

Do you think I as a chair is overstepping my authority if I follow the
above process in these cases where discussion is occurring in a smaller
group and some proposed direction is reached?

I note that in this particular case it could have been the ADs that
could have made the decision. However, as this wasn't communicated as an
AD decision, I will not attempt to hide my responsibility behind such a
line of argumentation.

Merry Christmas

Magnus Westerlund
(My view as an individual Chair)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Dec 2013 09:43:05 -0800

> AD decision, I will not attempt to hide my responsibility behind such a

Magnus,

(I note that Harald has indicated he's now satisfied with the current 
situation.  That moves this exchange farther into the realm of 
hypotheticals.  Still, it might be useful.)

Simple answer:  What you describe would have been 'legal', but I believe 
it also would not have been advisable.

Extended answer:

The IETF list today has a thread about the handling of chair and author 
assignments.  I posted a note into it that is relevant to rtcweb, given 
its history:

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=75013&tid=1387560859

That was about wg "structure".  The question here is about process for 
making a decision.

The basic model for IETF wg decision-making is "default no".  That is, a 
working group needs to amass rough consensus IN FAVOR, in order to 
approve a decision.

A common efficiency hack is to assert a default-yes model, for some 
decisions.  That's what you propose.

Default-yes works well in a healthy working group that is nicely making 
progress.  It relies in high trust of the working group chairs, 
participant comfort in being able to raise objections, and good working 
group support for discussing objections.

At the beginning of a working group, the primary goal needs to be to 
establish a pattern of affirmative consensus.  Folks need to get into 
the habit of finding things to actively agree on.  That requires an 
active process.  Passive "no one objected" agreement often isn't really 
agreement.  More importantly, it definitely isn't active support for the 
final output.

Active support for the final output is the single-most important goal 
for IETF work, since it creates a likelihood of adoption in the field.

That's not what you've got in rtcweb.  Quite the opposite.  Just look at 
the wg statistics.  Lots of documents.  1.5 years.  Nothing published. 
Blocked on a decision about a component.   I also hear continuing 
reports of mutual suspicion amongst participants.

So no, I don't think what you propose would have been a good choice, 
even though it might have been legal.

But your ending note about the possibility of an AD decision points to 
an even deeper problem:  ADs don't have that authority.

Working groups decide on what documents they adopt, within the 
constraints of their charters.  To move a document from one working 
group to another requires agreement of both working groups.  AD's do not 
have final authority on this.

If you disagree, please show me where that authority is assigned.

d/

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 20 Dec 2013 17:03:41 -0500

> have final authority on this.

The document is doing things that are in TSVWG's charter and not
in RTCWEB's charter.  It should not have been adopted in RTCWEB
in the first place.  Moving it out corrected that mistake.

-- 
Wes Eddy
MTI Systems

---

From: SM <[email-masked]>
Date: Fri, 20 Dec 2013 16:55:12 -0800

Hello,
At 09:43 20-12-2013, Dave Crocker wrote:
>That's not what you've got in rtcweb.  Quite the opposite.  Just 
>look at the wg statistics.  Lots of documents.  1.5 years.  Nothing 
>published. Blocked on a decision about a component.   I also hear 
>continuing reports of mutual suspicion amongst participants.

 From the RTCWEB minutes:

   The milestones were quickly reviewed, primarily noting that we are late with
   everything.  The WG was asked if they think it is a reasonable 
goal to finish
   all the core documents before the end of 2014.  This will be a challenge and
   people need to help by actually reviewing the documents and send comments.

   The dependencies was also reviewed.  Authors, consider if our normative
   references make sense. Are they really needed?  Waiting on references slows
   down publication.  WG please contribute to finish up these references also."

Currently, the goals and milestones are as follows:

   Oct 2012 - Send Security and Privacy Problem Statement
     (draft-ietf-rtcweb-security) to IESG for publication as Informational

   Oct 2012 - Complete Overview (and hold for dependency resolution)
     (draft-ietf-rtcweb-overview)

   Oct 2012 - Send Use Cases document 
(draft-ietf-rtcweb-use-cases-and-requirements)
    to IESG for publication as Informational

   Jan 2013 - Send Media Transport (draft-ietf-rtcweb-rtp-usage) to IESG for
     publication as Proposed Standard

   Jan 2013 - Send Security Solution (draft-ietf-rtcweb-security-arch) to IESG
    for publication as Proposed Standard

   Jan 2013 - Send Signalling Negotiation and NAT Traversal 
(draft-ietf-rtcweb-jsep)
     to IESG for publication as Proposed Standard

   Jan 2013 - Audio Processing and Audio Codecs 
(draft-ietf-rtcweb-audio) to IESG
     for publication as Proposed Standard

   Jan 2013 - Video Processing and Video Codecs 
(draft-ietf-rtcweb-video) to IESG
     for publication as Proposed StandardVideo Processing and Video Codecs
    (draft-ietf-rtcweb-video) to IESG for publication as Proposed Standard

   May 2013 - Send Quality of Service markings of RTCWeb packets
    (draft- ietf-rtcweb-qos) to IESG for publication as Proposed Standard

   Mar 2014 - Send STUN Usage for Consent Freshness to IESG for publication
     as proposed standard

   May 2103 - Send Data Stream Transport for non-media data
     (draft-ietf- rtcweb-data-channel) to IESG for publication as 
Proposed Standard

The "2103" could be a typo or RTCWEB could have been chartered for a 
100 years. :-)

Could the milestones be updated?  It might help to provide a sense of 
what the goals are and to assess whether the goals are being met.

Regards,
-sm

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Dec 2013 03:02:20 +0000

Agreed.

Aside from the issue of failure to publicise the chairs actions, which the RTCWEB chairs have acknowledged, I believe the only open issue is to identify whether the transfer of work within the scope of the TSVWG leaves any work that is outside the scope of the TSVWG.

Keith Drage

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Wesley Eddy
> Sent: 20 December 2013 22:04
> To: [email-masked]; Magnus Westerlund; Harald Alvestrand; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [rtcweb] Protesting the QoS document decision
> 
> > group to another requires agreement of both working groups. 
>  AD's do 
> > not have final authority on this.
> > 
> 
> 
> The document is doing things that are in TSVWG's charter and 
> not in RTCWEB's charter.  It should not have been adopted in 
> RTCWEB in the first place.  Moving it out corrected that mistake.
> 
> 
> --
> Wes Eddy
> MTI Systems
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>