Re: [Lime] Adam Roach's No Objection on draft-ietf-lime-yang-connectionless-oam-14: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 26 October 2017 02:09 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4702913955B; Wed, 25 Oct 2017 19:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Cmjk61dE6yxU; Wed, 25 Oct 2017 19:09:55 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7521395F3; Wed, 25 Oct 2017 19:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10430; q=dns/txt; s=iport; t=1508983795; x=1510193395; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Gqk9QAqWlxlr24D8oTBr/Gc9YusaOs8x6/WlLyj8f6w=; b=R3Zd3pb46yIaeegX/KkQmXYfSBYSo37IpEIyV1pgwom5ZfAybLU2bvrk 9IAG29Zc2OPUchAmCkDrDY5RTXXg8ylZArlxaE0+FsJz5ag2jFXjSC33Z 0TB3XJFxZbHN6Jl9fuOyxzERT8IcK0ZGYg+d8d61PeG3wW44TmEWMndxd E=;
X-IronPort-AV: E=Sophos;i="5.43,433,1503360000"; d="scan'208,217";a="315400920"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 02:09:54 +0000
Received: from [10.24.95.171] ([10.24.95.171]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v9Q29rn5020537; Thu, 26 Oct 2017 02:09:53 GMT
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Cc: Ron Bonica <rbonica@juniper.net>, lime-chairs@ietf.org, lime@ietf.org, draft-ietf-lime-yang-connectionless-oam@ietf.org, cpignata@cisco.com
References: <150895915790.4735.12781687265993710022.idtracker@ietfa.amsl.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <f6d274a8-8eb6-87d4-1317-18a7ecefcd8a@cisco.com>
Date: Wed, 25 Oct 2017 19:09:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <150895915790.4735.12781687265993710022.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------95B9EE63E17DA3823E979A89"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/1N0mK_RcstRfvATc3ou0_9uHpcU>
Subject: Re: [Lime] Adam Roach's No Objection on draft-ietf-lime-yang-connectionless-oam-14: (with COMMENT)
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Oct 2017 02:09:57 -0000

Dear authors and document shepherd,

If you recall my AD review (on the LIME mailing list)

    My quick summary:
    Those two LIME drafts are hard to read. I've been spending hours to
    try to understand...
    I advice the authors, shepherd, chairs to review the two drafts with
    a fresh mind and improve readability.

Multiple IESG members had similar COMMENTS regarding readability.
These are not DISCUSSES, but you should anyway improve the document to 
address this point, starting with Adam's list.

Regards, Benoit
> Adam Roach has entered the following ballot position for
> draft-ietf-lime-yang-connectionless-oam-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'd like to update my comment with some fairly mechanical suggestions for
> improvement that I believe will increase readability of the document greatly.
> In evaluating this document, I found a number of minor formatting issues that
> made it somewhat difficult to read.
>
> 1. Please ensure that all opening parentheses have a space before them and no
> space after them.
>
> 2. Please ensure that all closing parentheses have a space after them and no
> space before after them.
>
> 3. Please ensure that all quoted terms include both an opening quotation mark
> and a closing quotation mark.
>
> 4. Please ensure that there are no spaces between a quotation mark and the term
> it is quoting.
>
> 5. Please ensure that there *is* a space before an opening quotation mark
>
> 6. Please ensure that there *is* a space after a closing quotation mark (unless
> followed by another punctuation mark)
>
> 7. Please ensure that periods at the end of a sentence have no space before
> them and a space after them.
>
> 8. Please break up long paragraphs into separate paragraphs or bullet lists.
> The third paragraph of section 3 and the paragraph that forms section 3.3 are
> prime candidates for such an improvement.
>
> 9. Please double-check the formatting of the YANG module. The indentation is
> inconsistent and, in some places, can easily mislead the reader about the level
> of nesting and association of elements with each other.
>
> My original comments follow.
>
> ------------------------------------------------------------
>
> Please expand "EXP", "VPLS", and "LAG" on first use.
>
> Section 3.2 refers to the "lime base model". Please define or expand "lime" or
> provide a citation that does so.
>
> The id-nits tool reports that there are 6 instances of overly-long lines in the
> document. Given that these exist in code elements, the authors can probably
> make better decisions about how to resolve these than the RFC editor can.
>
> Section 3.3 contains the following definition:
>
>                  list oam-neighboring-tps {
>                    key "index";
>                    leaf index {
>                       type uint16 {
>                          range "0..65536";
>                       }
>
> uint16 cannot represent 65536.
>
> ----------------------------------------
>
> Later in the model:
>
>   container timestamp-80bit {
>   when "derived-from-or-self(../timestamp-type, 'cl-oam:ptp80')"{
>           description
>            "Only applies when 80bit PTP Timestamp.";
>          }
>    if-feature ptp-long-format;
>        leaf timestamp-sec {
>        type uint64 {
>        range "0..281474976710656";
>        }
>        description
>          "48bit Timestamp in seconds as per IEEE1588v2.";
>         }
>        leaf timestamp-nanosec {
>        type uint32;
>        description
>          "Fractional part in nanoseconds as per IEEE1588v2
>           or Fractional part in 64-bit NTP timestamp.";
>        }
>        description
>        "Container for 64bit timestamp.";
>      }
>
> Issue 1: The 48-bit range should be 0..281474976710655, not 0..281474976710656
>
> Issue 2: The description for this 80-bit timestamp container contains a
> description of "Container for 64bit timestamp."
>
> ----------------------------------------
>
> Similar to issue 2 above, ntp-timestamp-32bit describes itself as a 64-bit
> timestamp.
>
>
> .
>