Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 08 March 2018 13:21 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE95A126CE8; Thu, 8 Mar 2018 05:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ThYVxIHIJRnJ; Thu, 8 Mar 2018 05:21:07 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028EB126CD6; Thu, 8 Mar 2018 05:21:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8670; q=dns/txt; s=iport; t=1520515266; x=1521724866; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=yKGk850LNEjWwtLFxPVHj5CkMotYAe0VwfOYnwYJpR0=; b=aM4A5azD+nnP3jU5Djs4K2wGPlE737pHeNKNHetFvHYv6riI5OAxbGgr b5bqo8ywXi7h3aEUquvMcsc5WTUC62pA279o6Sr/68uCVCwMBuwp6Kwbr pz9AFb8boRbPoY1F/tvQt0mm0YyyCczjF0TvGzt36hffQt6p9aLITihYN s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAAAHOKFa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ2byiDUIoec5AcjwiFIRSCAQojhQICgys0GAECAQEBAQEBAms?= =?us-ascii?q?nhSQGI0sLEAtCAgJXBgEMCAEBF4R+D6sOgiYmhEuDeoIYBYU1hASBZimDBIMuA?= =?us-ascii?q?gECAYE6ARIBgyiCYgSIG5I0CYZJihgHgWOENIJzhVeHdIIFgUyGAoEsHjhhWBE?= =?us-ascii?q?IMxoIGxU6gkOCY4FmPzcBiR8NGAeCGgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,441,1515456000"; d="scan'208,217";a="2453093"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2018 13:21:02 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w28DL1sT028288; Thu, 8 Mar 2018 13:21:02 GMT
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
Cc: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, draft-ietf-netmod-rfc6087bis@ietf.org, Sandy Ginoza <sginoza@amsl.com>, Michelle Cotton <michelle.cotton@iana.org>
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <6ac9d4d5-d725-ad5a-d275-888afbc827cc@cisco.com>
Date: Thu, 8 Mar 2018 14:21:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------366B4F301A26E5F26D24D42C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/J_1DoSLjpcQeH5cih5fZy6N5AAc>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 13:21:14 -0000

Hi Adam,
> Adam Roach has entered the following ballot position for
> draft-ietf-netmod-rfc6087bis-18: 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-netmod-rfc6087bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. It is well-written and I believe it will be helpful.
> Comments follow.
>
> ---------------------------------------------------------------------------
>
> General:
>
> I've reviewed a couple of YANG modules where the indentation and/or wrapping was
> awkward and inconsistent. I would love to see guidance in this document that
> authors be careful to run their modules through pyang (or a similar tool) to
> ensure consistent formatting. It may be worthwhile to give an example of the
> exact commandline invocation of pyang to achieve a formatting that is consistent
> with existing published modules.
We've been in discussion with the RFC editor lately (Sandy, cc'ed) on 
this important topic.
And also with IANA, which should be keep the source of truth for IETF 
YANG modules (but this is not that easy. More on this later).

 From a YANG language point of view, as long as the module validates, 
we're good.
But OTOH, we do require some common style from the published modules, 
for example we want all lines to be properly indented and we require 
space characters between some tokens etc. Consistency is easier for readers

With the RFC editors, we agreed on this high level process:
     - extract the YANG file
     - run pyang -f yang --yang-canonical --keep-comments FILE
     - ask the authors if they are okay with the output file (before 
replacing it in the RFC (to be) for review)
     - assuming they agree, update the RFC
     - then transmit the module to IANA for publication.

During the discussion, Martin Bjorklund (THE pyang main developer), 
expressed:

      Such a tool will of course blindly produce consistent output, but
      sometimes a human needs to polish the result anyway.

      ...

    Unfortunately, I don't think the tool is quite ready to be used in an
    automated fashion.  It does produce consistent output wrt indentation
    and quotes etc, but it doesn't do a good job when it comes to handling
    long lines.  As an example, if the original module has:

           pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
                 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

    the tool will print:

           pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';


    I have just released a new version of pyang, 1.7.4, which fixes one
    issue with "-f yang" that has been discussed on the mailing list.

I see two solutions from here.
1. we mention "pyang -f yang --yang-canonical --keep-comments FILE" in 
RFC6087bis, with a warning such as: "As the tool matures, a human might 
need to polish the results"
2. we don't mention "pyang -f yang --yang-canonical --keep-comments 
FILE" in RFC6087bis, but we ask the YANG doctors to run the tests.

Considering that not many people know those specific pyang parameters, I 
would favor solution 1.

Feedback?

Regards, Benoit