[Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 28 May 2016 18:23 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8B12B00F for <gen-art@ietfa.amsl.com>; Sat, 28 May 2016 11:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 x6_4Qox9Zwhi for <gen-art@ietfa.amsl.com>; Sat, 28 May 2016 11:23:08 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27BB12B071 for <gen-art@ietf.org>; Sat, 28 May 2016 11:23:08 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by comcast with SMTP id 6iswbaqJSLCmU6it9bzhe1; Sat, 28 May 2016 18:23:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464459787; bh=/xsVkuPHfzPd/oKPfu+waNLJTrtAgvLCLMNnD8h2qTo=; h=Received:Received:From:Subject:To:Message-ID:Date:MIME-Version: Content-Type; b=JSDJAeI1NEn2MsagvMqOlAIy1ltdZgKA4920VBVkPfJFdFoOA5eaLZvdAkvY6gxag IaIi2kkxb5eKR2Sk1aEzBWZNCL0hLzRq4GC/XrQuwyhEPESniflgRTGndb6dyULqAe S7Cj9rkV4v7fFV5CQuQnJf2jAnBwobvICplZVhxBTT4dSQ/ggr5m9oec7tZJ9ELMB4 i1mVL5PA7CZqFP2128oDXp4Z0H4K1jl2vzP574+D/pCcx5ojzBaGcjIxOg6fqwJr8f CB+vBPj3R4BqaUkYtqAsmUKpwNYaB47fFgDZx8geSXkZwUF96g+fwNRyyUcMyhRczx azQXbzO0bnbbA==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-11v.sys.comcast.net with comcast id zuP61s00Q3KdFy101uP7mP; Sat, 28 May 2016 18:23:07 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-tsvwg-rfc5405bis.all@ietf.org
Message-ID: <e75b3328-c782-ca66-6f3a-a0baf3e3c705@alum.mit.edu>
Date: Sat, 28 May 2016 14:23:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/kM_BoAynhqBB7EP9TOgGgWYAAPQ>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc5405bis
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 May 2016 18:23:10 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tsvwg-rfc5405bis Reviewer: Paul Kyzivat Review Date: 2016-04-27 IETF LC End Date: 2016-05-31 IESG Telechat date: Summary: This draft is on the right track but has open issues, described in the review. Issues: (Note: I am having difficulty assigning severity levels to these issues. So take the leveling with a grain of salt.) Major: 1? Minor: 1 Nits: 3 (1) Major? - Scope and Audience I had difficulty understanding the intended scope of this document, and the intended audience. It seems to want to be a variety of things. * It seems to be a fine reference about congestion control for applications of UDP. * It also seems to be pretty helpful in challenging developers about whether they should be using UDP or something else. Probably everyone contemplating using UDP ought to read this for that stuff. Those topics would be a good focus for the document. Beyond that it delves into a seeming random assortment of additional specialized uses of UDP. These may be of interest to some, but I suspect many won't find these things useful. And the topics covered seem to be simply what came to mind rather than being in some way exhaustive. Also, some applicability to congestion control for non-UDP protocols (those layered directly on IP) is claimed. This seems a bit of an afterthought, and incompletely covered. After diffing this document against RFC5405 I see that it really is an incremental change that leaves the scope largely unchanged except for the addition of multicast. So perhaps I am too late to question the scope of the document. But since this *is* a bis, it might be worth considering whether the scope could be focused by splitting some of the material off into a different document(s). (2) MINOR? - use of SHOULD I was struck by how much SHOULD is used in this document, and how infrequently MUST is used. And while possible justifications for violating SHOULD are sometimes provided, they often are not. In my experience there has been a growing awareness that such vagueness is problematic, because many implementers take it as free license to treat SHOULD as MAY, and just not do it. (IIUC, in a BCP the normative language is relative to best practice. So if MUST is written and you don't do it then you aren't following best practice. But if SHOULD is written without qualification, and you don't follow it then you can probably claim that you are still following the best practice as documented by the document.) I note that most of the SHOULD usage is inherited from RFC5405, so there is some justification for just leaving it be. But it could be a helpful exercise to review all this usage, and consider whether usages of SHOULD can be changed to MUST, or if valid justifications for violating the SHOULD can be stated. (3) NITs: Section 3.1.7 In the following: The set of mechanisms requires for an application to use ECN over UDP are: s/requires/required/ In the following: [RFC6679] provides guidance an example of this support, by describing s/guidance/guidance and/ In the following: In general, packets may be forwarded across multiple networks the between source and destination. s/ the// (4) NIT: Appendix A: I couldn't parse the following sentence as written: MPLS-in-UDP endpoints must check the source IPv6 address in addition to the destination IPv6 address, plus the strong recommendation against reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. I think it would better reflect the intent if it is changed as follows: s/MPLS-in-UDP endpoints must/The requirement for MPLS-in-UDP endpoints to/ (5) NITs - unlinked references I found a number of cases where, in the html format, references are not hyperlinked: [RFC5405] section 1 [RFC4342] section 3 [RFC6679] section 3.1.7 [RFC1981] section 3.2 [RFC6935] section 3.4.1
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Eggert, Lars
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Black, David
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Black, David
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Spencer Dawkins at IETF
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Jari Arkko
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Black, David
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Jari Arkko
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Black, David
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Spencer Dawkins at IETF