Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-iana-dscp-registry-06: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 06 Jun 2018 12:39:16 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-iana-dscp-registry-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- The use of 2119/8174 keywords seem unneeded for this document. As far as I
can tell, there's just a MAY that talks about IANA behavior.

- Please define "bleaching".

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 07 Jun 2018 07:18:30 +0100

Thanks Ben,

see below

Gorry

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
Would this do:

OLD:
The continued presence of bleaching of the IP precedence field in 
deployed networks can result in setting the first three bits of the 
former TOS byte to zero (disabling any class-based flow management by 
routers configured with TOS-based packet processing). There is  a need 
to avoid this remapping of the DSCP for the LE PHB by assigning a 
codepoint that has a zero value in the first three bits

NEW:
In deployed networks, there is continued use of bleaching (i.e. 
intentionally setting to zero) of the IP precedence field. (Setting the 
IP Precedence field to zero disables any class-based flow management by 
routers configured with TOS-based packet processing). This causes the 
first three bits of the former TOS byte (now the upper part of the DSCP 
field) to become zero.There is therefore a need to avoid this remapping 
of the DSCP for the LE PHB by assigning a codepoint that already has a 
zero value in the first three bits...

Gorry

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jun 2018 10:34:45 -0500

That works for me.

Thanks!

Ben.

> On Jun 7, 2018, at 1:18 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> Thanks Ben,
> 
> see below
> 
> Gorry
> 
> The continued presence of bleaching of the IP precedence field in deployed networks can result in setting the first three bits of the former TOS byte to zero (disabling any class-based flow management by routers configured with TOS-based packet processing). There is  a need to avoid this remapping of the DSCP for the LE PHB by assigning a codepoint that has a zero value in the first three bits
> 
> NEW:
> In deployed networks, there is continued use of bleaching (i.e. intentionally setting to zero) of the IP precedence field. (Setting the IP Precedence field to zero disables any class-based flow management by routers configured with TOS-based packet processing). This causes the first three bits of the former TOS byte (now the upper part of the DSCP field) to become zero.There is therefore a need to avoid this remapping of the DSCP for the LE PHB by assigning a codepoint that already has a zero value in the first three bits...
> 
> Gorry