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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 09 March 2018 06:28 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 948FF1242EA; Thu, 8 Mar 2018 22:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 e6bT-ASoLgok; Thu, 8 Mar 2018 22:28:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F206B126CC7; Thu, 8 Mar 2018 22:28:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BE522D03; Fri, 9 Mar 2018 07:28:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id mdD7eloFKAuX; Fri, 9 Mar 2018 07:28:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Mar 2018 07:28:04 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C6A820160; Fri, 9 Mar 2018 07:28:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yxRSMuZ_LCQL; Fri, 9 Mar 2018 07:28:04 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E3D92015B; Fri, 9 Mar 2018 07:28:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 4E8B84268EA3; Fri, 9 Mar 2018 07:28:03 +0100 (CET)
Date: Fri, 9 Mar 2018 07:28:03 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Adam Roach <adam@nostrum.com>
Cc: Andy Bierman <andy@yumaworks.com>, NetMod WG Chairs <netmod-chairs@ietf.org>, NetMod WG <netmod@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6087bis@ietf.org
Message-ID: <20180309062803.pwewp5s2unl34fsi@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Adam Roach <adam@nostrum.com>, Andy Bierman <andy@yumaworks.com>, NetMod WG Chairs <netmod-chairs@ietf.org>, NetMod WG <netmod@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6087bis@ietf.org
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com> <CABCOCHSmCioJPNM5b9J-5WCsXe_J2jMzKKCD8fw02uh-D5nNdA@mail.gmail.com> <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PkK1iaG2l-ILhwi1fhD_qVm4lE8>
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: Fri, 09 Mar 2018 06:28:09 -0000

On Thu, Mar 08, 2018 at 05:55:17PM -0600, Adam Roach wrote:
> >     §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.
> 
> It's a little more than that; it comes down to the purpose of the regex, and
> how much validation is expected to be provided. For example, ignoring the
> interface designation, the validation of IP addresses between the two
> productions above is radically different. The second one is set up so that
> anything it matches will be a syntactically correct IP address. The first
> one, by contrast, would accept any of the following as valid:
> 
>  * 999.999.999.999
>  * 1.3.6.1.2.1.2.2.1.3
>  * 17
>  * .......

This is a misunderstanding how YANG works. ipv4-address-no-zone is
derived from ipv4-address and hence all the ipv4-address rules apply
as well. Your examples will all be rejected.
 
> This seems a bit more than academic to me: given that modules are included
> into other modules, wild inconsistencies in validation philosophies can be
> surprising to users. For example, if an operator gets used to the syntax for
> IP addresses generating warnings or errors when they are out of range, then
> they may be frustrated to discover that IP addresses in other locations are
> not.
> 
> Clearly, the items that have already been published can't be changed, but it
> seems like there is room for guidance about whether to optimize for simple
> regexes, or for more rigorous ones.

In some cases, patterns are kept simpler but more specific text is in
the description statement. A pattern is one of several mechanisms to
constrain the value space.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>