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

[Spencer Dawkins at IETF <[e-mail]>]

And, just following up ...

On Wed, May 9, 2018 at 2:04 PM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Gorry,
>
> On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst <[e-mail]>
> wrote:
>
>> 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,
>>
>
> I don't object to the new text, but it looks like there's still some
> mailing list traffic on this draft - I'll go read that next.
>
> If you do the right thing, that will be fine with me, of course ...
>

Having caught up on the mailing list traffic, I still think you're doing
the right thing.

Thanks!

Spencer


> Spencer
>
>
>> 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.
>>>
>>> ?
>>>
>>
>>
>