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

Andy Bierman <andy@yumaworks.com> Thu, 08 March 2018 20:00 UTC

Return-Path: <andy@yumaworks.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 496B512E036 for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 12:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=yumaworks-com.20150623.gappssmtp.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 ShnMZ5t5iy1L for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 12:00:42 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 A78F2129C5D for <netmod@ietf.org>; Thu, 8 Mar 2018 12:00:29 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id a196-v6so3748961lfa.13 for <netmod@ietf.org>; Thu, 08 Mar 2018 12:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KcrkqlA1lYNZdbX6rDDSioG3nlR+eBT+OWy4gUZcSuU=; b=lbjuQ6OWrZBaFPBDE+fPGp20AeijEed8t1HPhVPli64rjethhDEWMw4nnoR3sx36LM R8R4KZ7EOR19raoAO8fHFPljkXJmIesmvKCMYAUlNhfiBsusqStrPkTnPVvZmL6AI8+w 9n0AJxQuO1LdudRiMwbMRW5Miw2PYmchw2UJDHv6PT5KbCTzcpXguq872i9YsWNXMXGS cdMO+V1D7UPbgYykXKSfLjLa2taUv7/gGq/Qd/Og6SIH9VmhBllSHZfz828yR2o/QJRo aqOmf6ahqs7g8NvDXLSP0nklbra/ftX9k8imw/+kFohDqjQCD+2HgAfHHx/9O3d9NE+L c3qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KcrkqlA1lYNZdbX6rDDSioG3nlR+eBT+OWy4gUZcSuU=; b=MwIlZkI3vyK2roeKIVfoyw0VUbNQTzzWrKmDarqRT4oIJvZGej/bHOxc5mGlLHs1Z/ ZPMpgEq5oUFiP9Au3qT8ZdEgUJf3ilqf4JjwwAsqZ4UbB8jKv5vSIHv3aq+ZImu8VOn6 PqUsbBaWRuY4X/LsGSJCiR7eMio9gcsyuhYBMYGESYZ4yWayRjvsB5kg7sYQcC6EJyGn a1A3FtL1/YzWVw0ydtG8cFp4sEZ0lgAgWoYA65H8m+iXt9S8HyXW4L6j0eFbZ9Zh5/HX wbPQvje8lVqXogZTc7zJyrzfMGKQ5SUEB6XykWzf51KDrUHcurbkc57nwWhdX4VPxeMd fNPQ==
X-Gm-Message-State: APf1xPBaMpxNR9bgL64TUoCIaPtp5aNX2EOBViLCJj26atF4I8Dp3vvs NrDU9OAMJ71rJGICpyizBAPXa8ee8vHj2dznTI5qlg==
X-Google-Smtp-Source: AG47ELuJA5LIzxiAFqRHK9TwYrNwwnmkJbWTqe90lDeUKUD3GmYR2cnz2eMPhaTTEuDqxaOCo08NILHjVqMGNRcaYm0=
X-Received: by 10.46.82.16 with SMTP id g16mr18748750ljb.67.1520539227801; Thu, 08 Mar 2018 12:00:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Thu, 8 Mar 2018 12:00:27 -0800 (PST)
In-Reply-To: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 8 Mar 2018 12:00:27 -0800
Message-ID: <CABCOCHSmCioJPNM5b9J-5WCsXe_J2jMzKKCD8fw02uh-D5nNdA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6087bis@ietf.org, NetMod WG Chairs <netmod-chairs@ietf.org>, Kent Watsen <kwatsen@juniper.net>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a113c366e8a76e10566ec203c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rfEFPAZpjQQL6H8-RAdl3JjuzgY>
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 20:00:48 -0000

On Thu, Mar 8, 2018 at 1:33 AM, Adam Roach <adam@nostrum.com>; wrote:

> 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.
>
>
I added text that says consistent indentation and formatting SHOULD be used.



> ------------------------------------------------------------
> ---------------
>
> §3:
>
> >  YANG data model modules under review are likely to be contained in
> >  Internet-Drafts.  All guidelines for Internet-Draft authors MUST be
> >  followed.  The RFC Editor provides guidelines for authors of RFCs,
> >  which are first published as Internet-Drafts.  These guidelines
> >  should be followed and are defined in [RFC7322] and updated in
> >  [RFC7841] and "RFC Document Style" [RFC-STYLE].
>
> Maybe include a pointer to draft-flanagan-7322bis also, as this document
> is in
> the process of being revised.
>


This does not appear to be a WG document, so it seems premature to include
it



>
> ------------------------------------------------------------
> ---------------
>
> §3.6:
>
> >  Example YANG modules and example YANG fragments MUST NOT contain any
> >  normative text, including any reserved words from [RFC2119]
>
> Please clarify that this means only all-uppercase reserved words.
>
>
OK



> ------------------------------------------------------------
> ---------------
>
> §3.8:
>
> >  If there are no
> >  IANA considerations applicable to the document, then the IANA
> >  Considerations section stating that there are no actions is removed
> >  by the RFC Editor before publication.
>
> I believe that the current state of play is that removal is left to the
> authors'
> discretion, and that the IANA has a weak preference for leaving in
> sections that
> say "No actions are requested of IANA." This may change. Rather than try to
> capture the (potentially changing) state of play, my suggestion is to
> remove the text I quote above.
>
>
This was just changed to "might be removed"

Is that good enough?



> ------------------------------------------------------------
> ---------------
>
> §3.12:
>
> >  Each specification that defines one or more modules SHOULD contain
> >  usage examples, either throughout the document or in an appendix.
>
> Many of the YANG documents I've reviewed over the past year have contained
> examples that show only IPv4 addresses. The IAB has issued guidance that
> examples in standards track documents use either a mix of IPv4 and IPv6
> addresses or IPv6 addresses exclusively (see
> <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>). This section
> would do
> authors and reviewers a great favor by reiterating or pointing to this
> guidance.
>
>
OK



> ------------------------------------------------------------
> ---------------
>
> §4.11.2:
>
> >  The following typedef from [RFC6991] demonstrates the proper use of
> >  the "pattern" statement:
> >
> >      typedef ipv4-address-no-zone {
> >        type inet:ipv4-address {
> >          pattern '[0-9\.]*';
> >        }
> >        ...
> >      }
>
> By contrast, RFC 6021 has a somewhat more complex production:
>
>      pattern
>          '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>        +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
>        + '(%[\p{N}\p{L}]+)?';
>
> Is there any consensus on how complex the pattern validation should be?
> I've
> seen some YANG modules with patterns that occupied more than half a page.
> Is
> that encouraged, discouraged, or neither? It seems some guidance on this
> specific issue would be useful, as the currently published modules appear
> to be
> all over the map on this topic.
>
>
Not changing any text since the pattern complexity depends on the structure
of the text that is being modeled.



> ------------------------------------------------------------
> ---------------
>
> §10.2:
>
> >   [RFC-STYLE]
> >              Braden, R., Ginoza, S., and A. Hagens, "RFC Document
> >              Style", September 2009,
> >              <http://www.rfc-editor.org/rfc-style-guide/rfc-style>;.
>
> This URL returns a 404.
>
>

changed top http://www.rfc-editor.org/styleguide/



Andy


>