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:32 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 409B11270AC; Wed, 9 May 2018 12:32:25 -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 DFN7knEuSf_8; Wed, 9 May 2018 12:32:22 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 6DF35126DD9; Wed, 9 May 2018 12:32:22 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id i13-v6so12729227ybl.4; Wed, 09 May 2018 12:32:22 -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=Hwyfltvap5FCmfrILRXOkfVjnfW5ZIbNdlgCBnD2tNo=; b=ea6onzRaWcq0QdWKPvFw7/RefJ8zKG0rw83SgiAndWQSQcm2yyMRP11+a1t6JkVu7b Ed/mQbM2Z1ZiPRuIwxRxXdCFAlfTcgc3qIJkUQR83ZcTbLbp4VjA3vi4PzyyM/6nzVhK RLMl0prrMSdJzK5D6gbQajM/S7+1XFM9RFBp7GPkKXicbLyUSwejFOakCT4StB6DeNN8 xWytQ2UchxVEqnsZh6hWayixuWac3X8VGxf2k+sPz5hyxXxrky8PBNo2wQJ+XQGEy3u0 GeNTW0QeQOr13JB/v7A7E6X7hq41xGfQ2M24s+892AtJLUrmRWzCEAyRqyybsd4S2zE+ kqnw==
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=Hwyfltvap5FCmfrILRXOkfVjnfW5ZIbNdlgCBnD2tNo=; b=n82n55ZUUVZnlz6fg+IrNDkbEc+SIqW8RHMmNyEzbUC4cPvPXpmUWnYLUYmaUG3+B6 qXs/zHXLr++Dj4mYi6tNVOieESvvNz7UTFlM+kKqZ9ow+xHRyMSMFdf5v0db0bQ+IZ6v M8crln5G9Vhcznc0zvsMmHOP1PnDr3d7b9a9t/COsmFefAIY5gHqAuQe+oMHeEsfwQpr ZZHmWt4ESSCqAgwtcpXiOjgAgZ0VljkVvF0xfjuxk7rFBiUBivMTgKE0+OirdYYr3Vri 383dzscSApFEihta/qPfU4ek4XE84NDWf65EjugtZ8uuuuzHdz1fZFy1OIpkQmzFpocf fw+g==
X-Gm-Message-State: ALQs6tB0n+gxbsda9PZy/io8BZYpf2047Ty40UzzbWuZnpFq0ckKixZf rzfvqj6rvWvj+kx2jMTrsWKyoZ5GmTL9PPBgi9E=
X-Google-Smtp-Source: AB8JxZqDFzTvbIfoRActcxvSlJbNmxICi5/0YNhOYXffyyJKuClL7pZi8UorjcSoEwSyI4mXrJzZ6OvBCw/IXPqG0/o=
X-Received: by 2002:a25:e08:: with SMTP id 8-v6mr21688188ybo.71.1525894341244; Wed, 09 May 2018 12:32:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Wed, 9 May 2018 12:32:20 -0700 (PDT)
In-Reply-To: <CAKKJt-d3bAkf=AWD024PuBniyecsmZmYE8wgnPLk4=kCr_pdug@mail.gmail.com>
References: <152578801020.16205.9788449750372171578.idtracker@ietfa.amsl.com> <CAKKJt-c8XHDr0EvSLX4edTt6tKzMNkEFp3Z-jW5w_cpeJh3GWg@mail.gmail.com> <5AF2ADBA.9060402@erg.abdn.ac.uk> <CAKKJt-d3bAkf=AWD024PuBniyecsmZmYE8wgnPLk4=kCr_pdug@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 9 May 2018 14:32:20 -0500
Message-ID: <CAKKJt-cbLD3pHs2-1_MdcUUaAsRKO8tGJ1zkdEciNT98RpntbQ@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="0000000000002cc2fc056bcaf643"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/aY2OfU7ol3Qipp1uIi6_6WfWJIo>
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:32:25 -0000

And, just following up ...

On Wed, May 9, 2018 at 2:04 PM, Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

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

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