Re: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum"

["Black, David" <[e-mail]>]

Ok, this topic has had sufficient "soak time" - having seen no objections,
the Atlanta "hum" on Diffserv Classes is confirmed as the rough consensus
of the tsvwg WG:

> Restating - the sense of the room in Atlanta was that interactive
> media (e.g., multi-media conferencing) needs to be broken out of the
> existing diffserv media classes into at least one new class.

As promised, I will work with James on the next steps:

> If the sense of the room in Atlanta is confirmed, the next steps on
> Diffserv Classes are that I will work with James to come up with a list
> of all the things that he's proposing to change in
> draft-polk-tsvwg-rfc4594-update and ask the list whether each one
> of them needs attention (single subject/question emails).

My preference is to get the answers to those questions before asking
whether the tsvwg WG should adopt that draft as a WG draft.

Thanks,
--David (tsvwg WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, November 26, 2012 3:47 AM
> To: Black, David
> Cc: [e-mail]
> Subject: RE: Diffserv classes (rfc4594bis): Check on Atlanta "hum"
> 
> David,
> 
> again thanks for a well formulated proposal.
> 
> After a brief talk with my audio/video QoE experts I agree
> to differing telecoferencing (or whatever we call it) from
> streaming in DiffServ standards.
> 
> I see a need to clarify aggregation of DiffServ classes,
> if a revised RFC5127 or a revised RFC4594 are put on
> standards track. I'm having issues with RFC5127.
> 
> And a side one: terminology may be an issue - we all
> use "classes" in our exchanges and Brian correctly pointed
> out that it is not as well defined as major parts of the
> DiffServ terminology (which, I think, we however hardly use).
> 
> Regards,
> 
> Rüdiger
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Saturday, November 24, 2012 11:35 PM
> To: [e-mail]
> Subject: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum"
> 
> Hello - this is your new tsvwg co-chair, with <co-chair hat on>.
> 
> The Atlanta tsvwg minutes are at:
>         http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg
> 
> Many thanks to Ken and Mirja for being the note-takers.  I have two
> action items from the Thursday diffserv-oriented meeting - this
> message is about the first, the possible update to the Diffserv
> Classes RFC (RFC 4594).
> 
> Excerpt from the minutes (slightly edited/corrected):
> ---------------
> - (David Black) there is a suggestion that multi-media conferencing
> was not properly supported when Diffserv Classes were first defined.
> 
> So, what does the room think about this?  Audience "hum" thinks
> James Polk is correct and that a new more granular class is needed.
> Particularly, RFCs 4594 and 5127 need some work.
> 
> Black states that we need to put this on the list and discuss how
> many more things we need to fix.
> ---------------
> 
> Restating - the sense of the room in Atlanta was that interactive
> media (e.g., multi-media conferencing) needs to be broken out of the
> existing diffserv media classes into at least one new class.
> 
> If anyone disagrees with that sense of the room in Atlanta, please
> speak up now (please review the appropriate portion of the Atlanta
> minutes first).
> 
> Caveat: this topic and email are entirely about Diffserv Classes, i.e.,
> revising RFC 4594.  If RFC 4594 is revised, RFC 5127 on diffserv class
> aggregation will need a corresponding update to fit the new classes
> into its aggregates.  This email is *not* about the discussion
> of diffserv usage for interconnection (e.g., the ITU-T SG12 liaison).
> That interconnection topic may or may not involve a revision to RFC
> 5127 (e.g., it could be done in an entirely new document) and will
> be covered in a separate email thread; please wait for it.
> 
> If the sense of the room in Atlanta is confirmed, the next steps on
> Diffserv Classes are that I will work with James to come up with a list
> of all the things that he's proposing to change in
> draft-polk-tsvwg-rfc4594-update and ask the list whether each one
> of them needs attention (single subject/question emails).
> 
> In particular, this is *not* a call for whether tsvwg should adopt
> draft-polk-tsvwg-rfc4594-update - the initial steps are to figure
> out the scope of work that should be done.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
>