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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 09 May 2018 19:04 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25AF1274D2; Wed, 9 May 2018 12:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB9M-pwEIkIE; Wed, 9 May 2018 12:04:53 -0700 (PDT)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAC1127076; Wed, 9 May 2018 12:04:53 -0700 (PDT)
Received: by mail-yb0-x22d.google.com with SMTP id f3-v6so4301922ybg.13; Wed, 09 May 2018 12:04:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wocV9c45WMkpn0XVVuXOVQRc1ef81ldoDgt1qHb6ybM=; b=tvLQgP5tmEGId7Wgyxbn/j/qeIAqaD0zXW95r8G08MDqRbnE40Upowp5oM3R32BeDa X0zwcx7g2yJmgM+F/jEOYrM0B+zOzA8cDSx4dAkLmL2k//hz5Zql4NvbCQFC1i0nXsln e4kfgEouCTs6Dyutl0l3IbNh9tCE5c5xo2UpqiE6Y9DQxUwM6XKgin0vSJfDl787WX9y ZxnQ9MN9+DBbUwTww5Eh5AVnmiO43JVBUH0ai/lFUIfUm1ewlxErp32RoQcq4B6jHLiY WnaAR7pvMbh229pgS0zhmVbBOmHFJIUF6+FmsQsLez4i7A28Oo2q8AtPGwBHRcyqv2nt 9mWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wocV9c45WMkpn0XVVuXOVQRc1ef81ldoDgt1qHb6ybM=; b=f+h7luk0e3FgqiEuoIdrbWwo93WL8+6iIoFLBXehFPxynLAaZR+ZWoJW1dEBdRMSdl Z6FZ07nKoZHP3mUZSfSgBrT6UK5RyYljaXyGvifbmxURV+otgaoCXR8IISBY7IksyX97 NTZOF/AvhoyCquUSZn+SVwGatrKZVv580OWmg3JcgaFecYl5BrtOSmEyVQ2Bg//BSacW FOq4PlkhBIkvBbfqy9biO2SgO+yKbGNsASqkHluhl2W3eHrDNHy8QO7GkFqv5nEtsjfK b6io7ujLgI+dpMkiEQGViMjILWL+VumNcCeDYbepqRaWDc18gcEkWjWlg0bJAV73w1is he+A==
X-Gm-Message-State: ALQs6tChQLjH8CPQso+wRWP8ZFBCP4k2CgZyXKA0s8WNmZSunt9Z1H9q vJcNotF44Wn0Jmi7s9XrIPw9FylvGJ/OD7Csbf8=
X-Google-Smtp-Source: AB8JxZqtyoGI0oDknhEeWksx4rtiWv7dQkwhWJ/28jBeidcLWdJytUnvYL5n5tRV4z/F4RRCCTvoOxea1BkA7Bawp9M=
X-Received: by 2002:a25:6a55:: with SMTP id f82-v6mr12349105ybc.235.1525892692073; Wed, 09 May 2018 12:04:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Wed, 9 May 2018 12:04:51 -0700 (PDT)
In-Reply-To: <5AF2ADBA.9060402@erg.abdn.ac.uk>
References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> <CAKKJt-c8XHDr0EvSLX4edTt6tKzMNkEFp3Z-jW5w_cpeJh3GWg@mail.gmail.com> <5AF2ADBA.9060402@erg.abdn.ac.uk>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 9 May 2018 14:04:51 -0500
Message-ID: <CAKKJt-d3bAkf=AWD024PuBniyecsmZmYE8wgnPLk4=kCr_pdug@mail.gmail.com>
To: G Fairhurst <gorry@erg.abdn.ac.uk>
Cc: David Black <david.black@dell.com>, tsvwg-chairs <tsvwg-chairs@ietf.org>, tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e06947056bca930a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lYb619-4GnXKlh9Ebr6R4rElKuE>
Subject: Re: [tsvwg] Publication has been requested for draft-ietf-tsvwg-iana-dscp-registry-04
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 19:04:56 -0000

Hi, Gorry,

On Wed, May 9, 2018 at 3:13 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
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 ...

Spencer


> Gorry
>
> On 09/05/2018, 06:18, Spencer Dawkins at IETF wrote:
>
> On Tue, May 8, 2018 at 9:00 AM, David Black <david.black@dell.com <mailto:
>> david.black@dell.com>> 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.
>>
>> ?
>>
>
>