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

Adam Roach <adam@nostrum.com> Thu, 08 March 2018 09:33 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9E21205F0; Thu, 8 Mar 2018 01:33:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-netmod-rfc6087bis@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com>
Date: Thu, 08 Mar 2018 01:33:00 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Lwdy2XcjzOGeH0_oMAWspyBjRGE>
Subject: [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
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 09:33:00 -0000

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:


Thanks for this document. It is well-written and I believe it will be helpful.
Comments follow.



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.



>  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.



>  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.



>  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.



>  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.



>  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:

       +  '([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.



>              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.