Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Jouni Korhonen <jouni.nospam@gmail.com> Thu, 18 August 2016 15:34 UTC

Return-Path: <jouni.nospam@gmail.com>
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 5FC1A12D879; Thu, 18 Aug 2016 08:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 T4O3g2Rhqpwr; Thu, 18 Aug 2016 08:34:30 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 0969312D7F4; Thu, 18 Aug 2016 08:34:30 -0700 (PDT)
Received: by mail-pa0-x235.google.com with SMTP id pp5so7157998pac.3; Thu, 18 Aug 2016 08:34:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=S6zHqBmzxJmcQCWUavIdoRwjviIxmDSl4Im4ahtHroI=; b=DpCj9okV96T1gXhCHpwwhyTRCwBCGe75NSKI3XdQoy/vaI8dEexqrIbrYL1NlkxUYE FZ/732YFCrRYfq78oGgSb6583C1jSo4uMtpHkFjaPgyx9t4dgVJKTUvEHIC0JoN9lSC1 P59sJ/CFst2ic/UNqyLhss3Kv3tgGzDs16uhl26J1JGm0D3yle8Jpv3RUhrA9VpNnBH4 5yxEtLuqD081hY5iJix9IRg2avj/BldlBwy4dC2Y+O+cqZxhgdYzEMVS3D/JBGRzZXiH fH1d7P7x0EdmOKn0rqoRV7wmAWuHfaJm0q2IRBei7YCZ7K+Qj0/UWHdLg5J9Ivqq/s62 Vhvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=S6zHqBmzxJmcQCWUavIdoRwjviIxmDSl4Im4ahtHroI=; b=RnXd9p7mKwtYIn7rPx5/ZemmZpnJ0yP+B9d3nZIBfuvMwivdmu8Gf7Cd2HiiJVBF8b 4qLuYabhIkLQ4a3dBAgTpN/NaLqixQWP75q4d7Tji0PWxxEZD3Go7+aUxANhLJ4Jw0uJ sN+bop4ji0lIunEIZ0Y7gld4kSChjyDnopXY37u5VOas+Dkpqfc+zAe3uVhtfF43ZUUa K7+IXCWKiSMlSlEcwZTCtR2xA5f4mhBKEId47olnBVafQMJnmfLap66GleaNvnrwAKR6 gN7lrw+E9UqvcGdgOcwLxLz2pXDXA3QdZH3Z9RzQuLJztQ3R5GNiMnNrDET2CSu80+3B iZ3g==
X-Gm-Message-State: AEkoousZpJCzPaR0JLInfNxgV0WunsRDQzXe4JPvWud8p40DDXg256bc/vPLSj4DxVDnCA==
X-Received: by 10.66.14.161 with SMTP id q1mr5137160pac.103.1471534469256; Thu, 18 Aug 2016 08:34:29 -0700 (PDT)
Received: from [10.16.66.0] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id ao6sm4747539pac.8.2016.08.18.08.34.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 08:34:28 -0700 (PDT)
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D572BF115@dfweml501-mbb>
To: Lucy yong <lucy.yong@huawei.com>, "gen-art@ietf.org (gen-art@ietf.org)" <gen-art@ietf.org>, "draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org" <draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <7bf3aec9-1830-1ccd-ba07-2189db25979d@gmail.com>
Date: Thu, 18 Aug 2016 08:34:24 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572BF115@dfweml501-mbb>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/p6_q10vnlxSXfcV3xdEwUSur4Oc>
Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
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: Thu, 18 Aug 2016 15:34:32 -0000

Hi Lucy,

Thank you for the response. Sorry for my slow response. I tried to be on 
a vacation last week/weekend so my checking of emails was sparse at best 
;) See inline.

8/12/2016, 1:51 PM, Lucy yong kirjoitti:
> Hi Jouni,
>
> Thank you for the review and correction. Pls see inline below.
>
> -----Original Message-----
> From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Jouni
> Sent: Friday, August 12, 2016 1:51 AM
> To: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org
> Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
>
> 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-gre-in-udp-encap-16
> Reviewer: Jouni Korhonen
> Review Date: 8/11/2016
> IETF LC End Date: 2016-08-12
> IESG Telechat date: (if known)
>
> Summary:  Ready with minor nits.
>
> Major issues: None.
>
> Minor issues: Read on..
>
> Editorials/nits:
>  o My “complaint” of this document is basically on the following.. these are writing
>    style things so feel free to neglect:
>    - It repeats.. the same statements multiple times.
>    - When reading the document I get the feeling it is actually two documents. The
>      technical specification (which is very short) and the general deployment
>      considerations document. I would have split it to two but that is just me.
>
> The other nits.
>
>  o There are bunch of acronyms that are not expanded either never or on their first use.
>    Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to these.
> [Lucy] I will check.
>  o In the Introduction give a reference to EtherType e.g., the repository where they
>    are maintained or by whom they are maintained.
> [Lucy] I will put RFC7042 as the reference.

Or maybe  http://standards.ieee.org/regauth/ethertype/eth.txt
Either one works.

>  o On line 129 is says:
> 	   This document specifies GRE-in-UDP tunnel requirements for two
>    Based on the earlier text I would suggest saying “..document also specifies..”
> [Lucy] ack.
>  o On line 143 I would also (following the previous style in the paragraph) capitalize
>    “wide area networks” as well.
> [Lucy] ack.
>  o In multiple places (lines 236, 887) the reference is after the full stop. Place full
>    stop after the reference.
> [Lucy] My mistake. Will correct them.
>  o The document uses both tunnel ingress/egress and encapsulator/decapsulator. Is there a
>    specific reason to have this differentiation? If not use common terminology throughout
>    the document.
> [Lucy] I would prefer to use two teams in the document. Tunnel ingress and egress is the view from network perspective,
> And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is odd to say encapsulator IP address. I open to add a clarification if that causes a concern.

Maybe you should say this also in the draft?

>
>  o On line 654 is says:
>  	        MUST comply with requirement 1 and 8-10 in Section 5 of
>    How is this “MUST” enforced?
> [Lucy] Do you concern on the wording or the implementation?

See the discussion I had with David.

>
>  o In Section 7.1 I find it a bit odd discussing NATs in the specific context of IPv6. If
>    you have a specific IPv6 NAT scenario in mind either spell it out or give a reference
>    to a specification that describes the technology/use case.
> [Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP applications do not perform UDP checksum in IPv4 network; most UDP applications perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] [RFC6936] relax the need to perform UDP checksum in some special cases, which is applicable to this draft. But we need to state out the potential impact that is specific in IPv6.

Here as well, see the discussion I had with David.

>  o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not known to be
>    congestion-controlled.. I would be interested in knowing how to enforce this “MUST”
>    specifically in the Internet case.
> [Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not appropriate"? (match the wording in requirement 3 of Section 2.1.1)

Again, we did some more elaborations with David. Anyway, one concern I 
had was on having MUSTs on things that you cannot really guard or 
control using some protocol.. they are more like deployment 
recommendations or good wishes at best then.. which I think do not 
belong to a protocol spec.

- JOuni

>  o Line 909 typo “ether” -> “either”.
> [Lucy] ack. Thx.
>
> Regards,
> Lucy
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>