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

[Mary Barnes <[e-mail]>]

James,

Correct. This current email thread was not cross posted but it was posted
to the TRAM mailing list and not just some WG chairs as you noted. My point
was that one of the threads of discussion which triggered this email
involved cross posting.   For some of us that are subscribed to all the
lists involved, it gets crazy trying to follow these threads.

Mary.


On Tue, Feb 25, 2014 at 2:44 PM, James Polk <[e-mail]> wrote:

> But that didn't happen here. Only Certain ADs and certain WG chairs were
> cc'd. You surely don't have a problem with that...?
>
> James
>
>
> At 11:59 AM 2/25/2014, Mary Barnes wrote:
>
>> 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 <<mailto:
>> [e-mail]>[e-mail]> 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/>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>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
>> <mailto:[e-mail]>[e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>