Skip to main content

Diffserv-Interconnection Classes and Practice
RFC 8100

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.

Alvaro Retana No Objection

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

(Alissa Cooper; former steering group member) Yes

Yes (2016-12-01 for -12)
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 steering group member) Yes

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

(Spencer Dawkins; former steering group member) Yes

Yes (2016-11-29 for -12)
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 steering group member) No Objection

No Objection (for -12)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -12)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -12)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -12)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-11-30 for -12)
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 steering group member) No Objection

No Objection (2016-12-01 for -12)
- 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 steering group member) No Objection

No Objection (for -12)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -12)