I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors.Document editors and WG chairs should treat these comments just like any other last-call comments. Thanks for writing this draft, this is a very interesting document. This document extends DSCP usage from the limited domain to end to end manner. One of interesting use case is to map 3GPP QCI/5QI to DSCP and support consistent end to end QoS. Here are a few comments I made for this latest version. 1.Section 1 My general question is support end to end QoS across multiple domains, why RSVP or Interserv is not sufficient? How does we use diffserv to provide consistent QoS requirements? 2.Section 3.1 DSCP Pool 3 description said: “ Pool 3 codepoints are now "utilized for standards assignments and are no longer available for assignment to experimental or local use" [RFC8436]. “ Really, this seems not what RFC8436 said, RFC8436 add one constraint which is only when Pool 1 is ever exhausted, do we intend to update RFC8436 to further relax constraint? If that is the case, how do we provide back compatibility to RFC what RFC8436 stipulated? 3.Section 3.1 said: “ Table showing the summary of the DSCP abbreviations used in published RFCs.“ Just want to confirm what table shows is DSCP abbreviations or PHB abbreviation? 4. Section 3.2 said: ” The traffic consists of the network control service class and the OAM service class. “ Is there any possibility DSCP CS2 used for OAM service class is overridden by some other data traffic? If that is the case, how do you detect some conflict? What is the impact on other data traffic? How such conflict can be resolved? 5. Section 4 said: “The DiffServ field can also be re-marked based on common semantics and agreements between providers at an exchange point. ” Common semantics and agreement usually is reached in the provider to provider interconnection domain or inter-domain or inter-provider use case? 6. Section 4 said: “If packets are received that are marked with an unknown or an unexpected DSCP by a DiffServ domain interior node, [RFC2474] recommends forwarding the packet using a default (best effort) treatment, but without changing the DSCP” Isn’t DSCP value unique and has ,consistent meaning in each domain?I want to see the text be specific about the reasons why DSCP is unknown or unexpected? E.g., some border router doesn’t support new DSCP value? Some of DSCP bits are set to zero? I see the big challenges when DSCP is remarked in each domain and match different local policy, in that sense, it seems hard to provide consistent end to end QoS? No? 7.Section 5.1.1 said: “ This aligned with the now deprecated use of CS1 as the codepoint for the lower effort service, as previously specified in [RFC4594]. ” This alignment is referred to PCP1 or PCP0? My impression is PCP1, no? 8.Section 5.1, table: The table provided here is not completely consistent with figure 7 in RFC7222, e.g., in figure 7 of RFC7222, PHB assigned to background is BE while in this draft, PHB assigned to background is CS0. Please make them consistent ”