Pekka,
[FYI I've already indicated my support for this draft
in a message sent to the IESG.]
On 2007-10-03 03:11, Pekka Savola wrote:
On Mon, 1 Oct 2007, The IESG wrote:
The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Aggregation of DiffServ Service Classes '
<draft-ietf-tsvwg-diffserv-class-aggr-04.txt> as an Informational RFC
DiffServ Pool 1 codepoints require Standards Action [1]. While this
document doesn't define new ones (because there aren't any), it defines
how one should configure the treatment for each and every Pool 1
codepoint in the network. Therefore in spirit it specifies DSCP
codepoint behaviour and how those should be used.
I think this is really not a valid interpretation. It's very common in
the IETF to produce the first version of operational recommendations
as Informational, with the possibility of producing a later version
as BCP when there's successful operational experience. I believe
that this draft, and RFC 4594, are in that category. IMHO they do
not significantly change the implementation requirements for the
various Proposed Standard diffserv PHBs; they add configuration
recommendations for those PHBs, which is a perfectly legitimate
thing for an Informational RFC.
To be clear, the notion of reclassifying diffserv traffic at
a domain boundary is a fundamental part of the diffserv
architecture, and remapping diffserv classes into treatment
aggregates, as this draft describes, is just an example of
such reclassification. This draft does not change the diffserv
architecture and does not redefine any of the standards track
PHBs. To quote an example from the text:
Traffic in the Real Time treatment aggregate should be carried in a
common queue or class with a PHB as described in RFC 3246 [11] and
RFC 3247 [12].
As such I believe this document is inappropriate as an Informational RFC.
It is not clear that consensus in the IETF and deployments is strong
enough to approve/recommend any specific treatment for standards track
DSCP values.
If this work were to proceed, I suggest that first RFC 4594, which this
document builds on, would attain IETF consensus by following the
standards process for publication as a BCP.
Not until there is significant operational feedback, which is still
a year or three in the future. I don't see that this draft, or
RFC 4594, is significantly different in that respect from, say,
RFC 4472.
Brian
[1]
http://www.iana.org/assignments/dscp-registry
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf