Re: [tram] A note from your (so far) friendly AD ...

It would also be extremely helpful in cases where it's not entirely clear
whether the discussion belongs in TRAM, RTCWEB, etc. to please avoid
cross-posting.  Please check with the chairs about what list they think is
most appropriate and then just send a note to other lists that might care
that the discussion is happening on a specific mailing list.  It's
extremely confusing for those of us on multiple lists that try to sort and
follow threads by working groups.

On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins <
spencerdawkins.ietf@gmail.com> wrote:

> Dear TRAMsters,
>
> If I might offer a couple of suggestions to a new working group ...
>
> The TSV area diverts QoS discussions to the TSVWG working group, because
> that's where the QoS DSCP expertise lives.
>
> RTCWeb and TSVWG are having a robust and so-far productive discussion
> about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs for
> both working groups"). That discussion is more likely to be productive if
> RTCWeb QoS topics don't start popping up on other working group mailing
> lists, like this one.
>
> I'll let your working group chairs actually run the working group, but I
> note as more than an interested observer that the TRAM agenda at
> https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and
> I would really be happier if the working group focuses on the currently
> chartered milestones and demonstrates that you can deliver what you're
> already signed up to deliver, before adding more milestones. The rest of
> the IESG would be happier as well.
>
> Thanks, and see you in London.
>
> Spencer, as your responsible AD
>
> On 02/18/2014 03:33 PM, Simon Perreault wrote:
>
>> Le 2014-02-18 16:12, Oleg Moskalenko a écrit :
>>
>>> How to handle the DS and ECN fields is a part of TURN server RFC (see
>>> the section 12):
>>>
>>> http://tools.ietf.org/search/rfc5766#section-12
>>>
>>> And a good TURN server is supposed to implement that.
>>>
>> Well, the RFC just says that the TURN server should copy the DSCP from
>> one side to the other when doing en/de-capsulation. It doesn't say that
>> the server should actually do QoS based on the DSCP. My point is that
>> there's nothing preventing the server from actually doing it.
>>
>> Anyway, I was expecting responses along the lines of "DiffServ doesn't
>> work on the Internet in general." To which I would have replied: "then
>> couldn't we define a STUN attribute for transporting the DSCP in the
>> payload?" Instead of inventing a new taxonomy (audio, video, slides,
>> etc.), why not reuse DSCP?
>>
>> Simon
>>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>