Diffserv-Interconnection Classes and Practice
draft-ietf-tsvwg-diffserv-intercon-14
Yes
No Objection
(Alia Atlas)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 12 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(2016-12-01 for -12)
Unknown
Thanks for writing this document. One thing I didn't get is why not have a fifth aggregate that CS1 could be mapped into. Is it just because in other standards that have specified aggregates like this, they've gone with four and not specified one for less-than-best-effort? I'm also wondering about the choice to reserve AF42 and AF43. For WebRTC and real-time applications (see table at https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18#section-5) traffic marked as "Medium" in the table would be treated the same as "Low," which I fear would give incentives for applications to mark their traffic as "High" instead. Unless there is a strong need to reserve AF42 and AF43, it might be nice to just include them.
Mirja Kühlewind Former IESG member
Yes
Yes
(2016-11-30 for -12)
Unknown
PHB should probably be spelled out somewhere at the beginning of the doc; maybe even MPLS...?
Spencer Dawkins Former IESG member
Yes
Yes
(2016-11-29 for -12)
Unknown
I'm pleased with the changes that Last Call review, but I noticed a couple of nits that crept into new text.
In this sentence,
It is extensible and allows to
add a few more PHBs and DSCPs to the Diffserv-intercon scheme.
the text would be clearer if it said who was allowed to add PHBs and DSCPs, or what the process is to do that (which probably makes that clear) - I'm pretty sure I know that, but I'm not getting that from the text.
It looks like s/RFC5127s/RFC5127's/, to match other usages in the draft.
Alia Atlas Former IESG member
No Objection
No Objection
(for -12)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(2016-11-29 for -12)
Unknown
Lou Berger did the rtg-dir review of this document.
Ben Campbell Former IESG member
No Objection
No Objection
(for -12)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -12)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -12)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-11-30 for -12)
Unknown
Thanks for addressing the SecDir review and in particular, adding in the privacy consideration into the security considerations section. https://www.ietf.org/mail-archive/web/secdir/current/msg06802.html
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-12-01 for -12)
Unknown
- I'm puzzled by this being informational, it sure seems like something that could/should be a standard. (I'm not objecting, just puzzled.) - Section 2: For an IETF consensus document wouldn't it be good to have some references for claims like "has proven to be a poor operational practice"? Is that actually a statement where we're confident of IETF consensus? (I have no clue, I'm just checking based on the language and the Informational RFC status.)
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -12)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -12)
Unknown