[tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13

Donald Eastlake <d3e3e3@gmail.com> Thu, 06 February 2020 23:03 UTC

Return-Path: <d3e3e3@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 0FDA3120853 for <tsvwg@ietfa.amsl.com>; Thu, 6 Feb 2020 15:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 bGb4hxvH7lMS for <tsvwg@ietfa.amsl.com>; Thu, 6 Feb 2020 15:03:24 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 BC660120829 for <tsvwg@ietf.org>; Thu, 6 Feb 2020 15:03:24 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id h8so39232iob.2 for <tsvwg@ietf.org>; Thu, 06 Feb 2020 15:03:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FRUq/AzIeYH/Zt6fDZkutd2fX+97U6cnCtCDyO+38VM=; b=UKzaFfSNRwsngRxzlhqsOkSlYqvZjuP0vuKiFXf5EdWfmJk1aK3PVlbUl+VwA2c27U hxA8S1SU8r+ClWnyHivtPU1/c2YuOUaYXmXOaZz/fcnPL51sPd01y0WfWv6mE4ygXxiH Bp35J50jbzJ9xS6EuS3jO1HMfplN3NnSluD1LwjpbXKYvKrXni6qMaQAis6oYBDxt5pr vnRjvAslK8Az3eLphwjO4B6tmqSavN7rf/8nKvyq0X9Jxl2bGoCW9pd1YIBXkJnNWx/B P+e36VN5EVYVkUaPa50gCmUo+1uQMs2SrHf9B4E43QHznyAjr4X0hpwrpyzl+X7ExF5M G1+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FRUq/AzIeYH/Zt6fDZkutd2fX+97U6cnCtCDyO+38VM=; b=V3MAFu9RGg1v/6FLpEdR4O9nwSKstvZjXzNXRAa5S++Ls2nsE59b0thx6CDrkfEDxI gGMknhtAozAWbY+dFFxCgT5cp7ETp1pjhO6DzOcEdVV0Yt+HcTOawUIn0RtInBK3eJTe rABow42qMEUMi+7s060PuKC1cVu3d2ZdPpkCGQ/GzRB/lyRDRNvuvsxhA1ELtNS/s7JB T8kqzkWq9XDKh2Z2A5MCpa5ntreRzcpuGPcyGjgRtpKViKNYV/T/Yw46/hmEdcXGkoCg NT7Ln9hgtfzbuy2bsuLKo55DLfp7qtb5p/HVAnpgwf7f/OFEIqmQzOBmYI0XvAgvYiyr RT0w==
X-Gm-Message-State: APjAAAUJHICY0KcyppJMOSjnyjrspTr5vW4ev6B4ILQafZY2SR7smLnj vbv0B+QgZNr+uFsjKTbA9EmTMu6B9k95IsRk4M7AOtX8nzg=
X-Google-Smtp-Source: APXvYqyoP7j6koWWc2VCiPV/EUbu9efrN0jG9m3gz+vdZ0qyn88E64jpmLC2/oesBPR5kepz4ms3o+fKsEn/Pzhsy3c=
X-Received: by 2002:a5d:9157:: with SMTP id y23mr516503ioq.199.1581030203647; Thu, 06 Feb 2020 15:03:23 -0800 (PST)
MIME-Version: 1.0
References: <CAF4+nEGu9XEiXypPw0NK+f2N9QbBwyTJKXbViKWVScJhOW=vUA@mail.gmail.com>
In-Reply-To: <CAF4+nEGu9XEiXypPw0NK+f2N9QbBwyTJKXbViKWVScJhOW=vUA@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 6 Feb 2020 18:03:12 -0500
Message-ID: <CAF4+nEEB2-pz4ugW-m1-3gq9KH-fyt93sLZ9WFh4BkJqQPX7PA@mail.gmail.com>
To: tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000aaee40059df047d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rRKJUKWl9V8mFH0opAHg--6qHy8>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-ecn-encap-guidelines-13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 06 Feb 2020 23:03:26 -0000

Hi,

I'm not subscribed to the tsvwg mailing list but I have reviewed
draft-ietf-tsvwg-ecn-encap-guidelines-13 and though you might be interested
in my comments.

Overall, this is a very clear and well-written draft. The comments below
are minor. Whether or not they are incorporated into the draft, I hope that
it can be advanced soon.

Section 1. I suggest just deleting the one occurrence in the draft of
"[RFC1323]" and the corresponding reference section entry. It seems
unnecessary and just leads to a nits checker warning which will have to be
explained, etc.

Section 1.1. Very minor but I believe the usual way, inside a draft, to
refer to the RFC which that draft might become is "[this document]"
(without the double quotes) rather than "[RFCXXXX]". Changing to the more
common notation would, I believe, enable the RFC Editor note to be removed
as "[this document]" is well understood by the RFC Editor.

Section 2. The initial paragraph on implementation keywords should be
updated to the following as per RFC 8174:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.


Section 2. Suggest putting the Terminology entries in alphabetic order.

Section 4.2, page 18. "802.1p" has been merged into 802.1Q ages ago. Values
of the priority field are commonly referred to in IEEE 802.1 as Priority
Code Points (PCPs) and in any case this seems a bit inconsistent to the way
that the merger of 802.1ah into 802.1Q is recognized in the draft. Perhaps
the last sentence of Section 4.2 could be: "An operator can define certain
[IEEE802.1Q] Priority Code Points to indicate non-QCN frames and an ingress
bridge is required to map arriving not-QCN-capable IP packets to one of
these code points."

Section 4.4, point 1, first starred subpoint, there is something odd about
"the packet MAY be forwarded, but it SHOULD be dropped".

Section 7. It doesn't matter much but IANA would prefer that sections
saying there are no IANA actions be left in the final RFC (see Section 9.1
of RFC 8126).

Section 9. Should "the document" in the first line of this section by "this
document"?

Appendix A. I did not review this update history.

Authors' Addresses: I don't think Pat Thaler can be listed as a front page
"author" in the RFC sense unless at least an email address is listed for
her. All authors should be pollable about IPR they know and when the draft
gets to the AUTH48 state before RFC publication, the RFC editor must be
able to contact all the authors. If no email address is known, she should
be moved to a "Contributors" section or the like.