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:39 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 99E7112DDBE; Thu, 18 Aug 2016 08:39:52 -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 DBdpozT_tjBB; Thu, 18 Aug 2016 08:39:50 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 5F3F912DC97; Thu, 18 Aug 2016 08:39:50 -0700 (PDT)
Received: by mail-pa0-x22f.google.com with SMTP id i5so7203995pat.2; Thu, 18 Aug 2016 08:39:50 -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=SEBZ1FwJS4XUhoQJZvF7oBc5BzeqfoNlOivJu57tprw=; b=zDJO4s16LUdQ6cH0ktcXqtv+/CyEZ+P9mSZWf7jh0rWuhwziHhz91+H5R+933R23S+ O3T+bSx8stPbMd1d5qecd8EvvBoFPw4RJMtGHwwkTTPc4XGTqrsX88qpGJIP7tgHXruS g8jnHGQ5rIXFOX6bhcZVsEljXw64pdqxQmDgH+OZaUBVmp53h8PCb0scbKFtM1S6iHCY Jc/cZJX7CK6j07SzM8kZbJLnb1T32eKbWOVSzTT/uYSCDslh504ewa7M5eMnmqFP8Ivz foanl9m7w9ZR/lc5DwKNGmIQzrQl9XUuOmFf34dpUtZigrC+H2s8KTgMv9ny/UHCJyXi DkzQ==
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=SEBZ1FwJS4XUhoQJZvF7oBc5BzeqfoNlOivJu57tprw=; b=UeEFtqGdEuMUJXytVnR3xqV5B3poR+eYCskS0KFuMQBlwLg68SMKfBzhEDX7efOKm8 OvJYLyr3Djww4YorAS3y3fthJftTABb8Jf5P2deIoBgo+K5/Y6DmQc2ZHnVSO0lN4eNs 0Yo+v35WBR3xKchauTAWE9hE+EAXo8c8Qz1rR8iaiWWvH3BUMlUEkIni2vvM2b0/DZxo 4iQQV8C4e1r3VSN4GzI2a5rc14fVsG3FyVozK5xVK7OpR/P4qpqWC6I6elq6HWkifplv fd6Ns+AYScv7xUOnVcjYcQlBgHwsGEe7RumdvD2kstQTLecGNdVehMsBMGgQHgRsXDX2 dZew==
X-Gm-Message-State: AEkooutNkSEHSvTiYEfWqbKwf8O8CmiDNNsR/M7YkRFPHiMi982avTv1frsqcm7UhpCFiA==
X-Received: by 10.66.177.7 with SMTP id cm7mr5228515pac.132.1471534789522; Thu, 18 Aug 2016 08:39:49 -0700 (PDT)
Received: from [10.16.66.0] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id d72sm4756379pfj.15.2016.08.18.08.39.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 08:39:49 -0700 (PDT)
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D572BF140@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: <dcc7a6d6-688c-e561-3930-930ae936e154@gmail.com>
Date: Thu, 18 Aug 2016 08:39:45 -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: <2691CE0099834E4A9C5044EEC662BB9D572BF140@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/yG5cH-iOtFJ0NrDZgnSYyWQU184>
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:39:52 -0000

Hi Lucy,

See inline ;)

8/12/2016, 2:10 PM, Lucy yong kirjoitti:
> Hi Jouni,
>
> OOPS, forget this one, sorry.
>
> 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.
> Lucy: perhaps some can reference previous section.

See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.

>    - 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.
> Lucy: When we were developing this document, we kindly became clear ourselves, we need to address two parts and want to do in one document.

There's definitely wordsmithing to do here. Now the "guidelines" and 
protocol specification (the very short one) and kind of mixed, which to 
me makes reading a bit confusing experience. If you want to keep all in 
one document, it is fine by me. I was just expressing my personal 
opinion on structuring.

- JOuni

>
> Regards,
> Lucy
>
>
>
> -----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.
>  o In the Introduction give a reference to EtherType e.g., the repository where they
>    are maintained or by whom they are maintained.
>  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..”
>  o On line 143 I would also (following the previous style in the paragraph) capitalize
>    “wide area networks” as well.
>  o In multiple places (lines 236, 887) the reference is after the full stop. Place full
>    stop after the reference.
>  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.
>  o On line 654 is says:
>  	        MUST comply with requirement 1 and 8-10 in Section 5 of
>    How is this “MUST” enforced?
>  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.
>  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.
>  o Line 909 typo “ether” -> “either”.
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>