Diffserv-Interconnection Classes and Practice
RFC 8100

Note: This ballot was opened for revision 12 and is now closed.

Alissa Cooper Yes

Comment (2016-12-01 for -12)
No email
send info
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.

(Spencer Dawkins) Yes

Comment (2016-11-29 for -12)
No email
send info
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.

Mirja K├╝hlewind Yes

Comment (2016-11-30 for -12)
No email
send info
PHB should probably be spelled out somewhere at the beginning of the doc; maybe even MPLS...?

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Stephen Farrell) No Objection

Comment (2016-12-01 for -12)
No email
send info
- 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 No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-11-30 for -12)
No email
send info
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

Alvaro Retana No Objection

Comment (2016-11-29 for -12)
No email
send info
Lou Berger did the rtg-dir review of this document.