Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04

[Gorry Fairhurst <[e-mail]>]

These request are all OK with me, and I have made the changes.

The recent thread on the TSVWG list has made me wonder again whether it 
is possible for me to be slightly clearer about explaining the TOS 
precedence bleaching - without drilling into all the detail. This has 
always a nightmare to write concisely, but I think I may be able to do 
better, and if you agree, I would also incorporate the slightly longer 
replacement text below:

OLD:
An example is the need to assign a suitable recommended default 
codepoint for the Lower Effort (LE) per-hop behavior (PHB) 
[I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort 
(BE) traffic (packets forwarded with the default PHB) from LE traffic in 
congestion situations, i.e., when resources become scarce, best-effort 
traffic has precedence over LE traffic and may preempt it. The continued 
presence of bleaching of the IP precedence field, setting the first 
three bits of the former TOS byte to zero (i.e., zeroing the top three 
bits of the DSCP) in deployed networks motivates the desire for the LE 
PHB to use a DSCP with a zero value for the first three bits 
[I-D.ietf-tsvwg-le-phb].

NEW:
An example is the need to assign a suitable recommended default 
codepoint for the Lower Effort (LE) per-hop behavior (PHB) 
[I-D.ietf-tsvwg-le-phb]. The LE PHB is designed to protect best-effort 
(BE) traffic (packets forwarded with the default PHB) from LE traffic in 
congestion situations, i.e., when resources become scarce, best-effort 
traffic has precedence over LE traffic and is allowed to preempt it. 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 assiging a codepoint that 
has a zero value in the first three bits [I-D.ietf-tsvwg-le-phb]. 
Furthermore, if the LE PHB were to have been assigned one of the 
currently unused Pool 1 codepoints with a zero value in the first three 
bits, any bleaching of the IP precedence field would result in other 
(higher assurance) traffic being remapped to the assigned DSCP. This 
remapping could then cause diffserv-marked traffic to receive an 
unintentional LE treatment for the remainder of the Internet path. It is 
therefore important to avoid the resulting priority inversion. The 
absence of unassigned codepoints in Pool 1 that exhibit these important 
properties motivates assigning a Pool 3 codepoint as the default that is 
recommended for use with this PHB.
---

- Your thoughts please, I'll hold publishing the new revision until I 
hear from you,

Gorry

On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:
> On Tue, May 8, 2018 at 9:00 AM, David Black <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     David Black has requested publication of
>     draft-ietf-tsvwg-iana-dscp-registry-04 as Proposed Standard on
>     behalf of the TSVWG working group.
>
>     Please verify the document's state at
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/>
>
>
> I have a couple of comments, but this draft is ready for Last Call. 
> Could you take a look at my comments, and let me know what the right 
> thing to do is?
>
> Thanks!
>
> Spencer
>
>  There's a reference to 
> https://tools.ietf.org/html/rfc8126#section-4.9 in the Introduction, 
> but that text uses "Standards Action" with the reference but without 
> any expansion, while further down, the next occurrence of "Standards 
> Action" explains that this means "values are assigned by Standards 
> Track or Best Current Practice RFCs", without providing a reference. 
> Perhaps expanding
>    These are assigned by
>    Standards Action, as defined in [RFC8126].
>
> to read
>
>    These are assigned by
>    Standards Action, as defined in [RFC8126], i.e., values are assigned
>    by Standards Track or Best Current Practice RFCs
>
> and dropping the expansion from the second mention would be clearer?
>
> Independent of that question, I had to read through the text 
> containing the second mention a couple of times.
>
>   Although Pool 1 has not yet been completely exhausted, this document
>    changes the IANA registration policy of Pool 3 to assignment by
>    Standards Action, i.e., values are assigned by Standards Track or
>    Best Current Practice RFCs.  The rationale for this update is a need
>    to assign codepoints for particular PHBs that are unable to use any
>    of the unassigned values in Pool 1.
>
> Would it be correct to say
>
>   Although Pool 1 has not yet been completely exhausted, there is a need
>    to assign codepoints for particular PHBs that are unable to use any
>    of the unassigned values in Pool 1. This document
>    changes the IANA registration policy of Pool 3 to assignment by
>    Standards Action, i.e., values are assigned by Standards Track or
>    Best Current Practice RFCs, allowing these codepoints to be assigned.
>
> ?