[tsvwg] RFC 4594 bis

["Fred Baker (fred)" <[e-mail]>]

At IETF 93, there was ad hoc discussion of revising RFC 4594 and taking it to Proposed Standard. At minimum, such a project would include incorporating RFC 5865 and editing out statements that, in retrospect, may be ill-advised. Personally, I might want to collapse some of the video services into a single service. Most important, to me, would be incorporating operational experience. One of the key triggers for me to think about this has been statements made in draft-szigeti-tsvwg-ieee-802-11e that I wasn't sure were a good idea, and which Tim pointed out came directly from RFC 4594. Oops...

It will be a big job, I think.

Before I seriously consider it, I would like to know the opinion of the working group, and of the chairs. Is this something we want to accomplish? Who would be willing to report their experience and suggest text or review the outcome?

A little history: the process of writing RFC 4594 took at least three phases. I made an initial suggestion in ieprep at IETF 54, in Yokohama. This was met with significant resistance from at least one key participant in the Diffserv work, and I dropped it. My Nortel co-authors picked up the concept and the initial draft and took it to the ITU effort that was then developing what became (IIRC) G.1010, and then brought it back to the IETF and solicited my participation in the further development. We had differences of opinion, and we had a fair bit of operational input on certain services. However, much of it was a literature review - EF came from RFCs 3246 and 3247, CS* code points came from RFC 2474, AF from RFC 2597, Scavenger ("Low Priority") from Internet2's service and RFC 3662, and I suspect (but don't know) that the logic regarding service requirements came at least in part from the ITU discussions. Further subdivisions, especially in the video classes, came from several vendors' products at the time, which were using AF code points for video but complaining that the service as described had issues (they wanted to use the AFx2 and AFx3 code points to identify the more disposable bits in layered codecs, which doesn't work if an ISP uses AF as described).

More recently, James Polk sought to add services in draft-polk-tsvwg-rfc4594-update. It proposed four services for admitted traffic, building on RFC 5685, to whit:

> This document will import in four new '*-Admit' DSCPs from
> [ID-DSCP], 2 others that are new but not capacity-admitted, one from
> RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594.
> This is discussed throughout the rest of this document.

It also changed some DSCP numbers, which is not backward compatible. It was a significant revision. I did not support the effort, in large part because of lack of operational input to it.

So, *if* this is to be done, I want to be sure folks are interested in doing it, and that operational experience will be reflected, not just the opinions of armchair theorists.

Who's in?