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

[Gonzalo Camarillo <[e-mail]>]

Hi,

Mary is right. People should avoid cross-posting to several mailing
lists because it increases the chances of people missing messages
because of their email filters.

Cheers,

Gonzalo

On 25/02/2014 11:28 PM, Mary Barnes wrote:
> 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]
> <mailto:[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:spencerdawkins.ietf@__gmail.com
>         <mailto:[e-mail]>>spencerdawkins.ietf@__gmail.com
>         <mailto:[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/>>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>>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] <mailto:[e-mail]>>tram@__ietf.org
>         <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
> 
> 
>