Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

Vladimir Vassilev <vladimir@transpacket.com> Wed, 23 August 2017 11:52 UTC

Return-Path: <vladimir@transpacket.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 745A81326EC for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 04:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 yyCEm3JheC18 for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 04:52:16 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1D01321DC for <netmod@ietf.org>; Wed, 23 Aug 2017 04:52:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A2FCD1403A44; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ik-B2HT2CyC4; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 764CC1403A43; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id edI57olMZPxQ; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 51CB41403A3D; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
To: Robert Wilton <rwilton@cisco.com>
References: <E3378E0605547F4E854DEE0CB1116AB020865B@gbcdcmbx03.intl.att.com> <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <E3378E0605547F4E854DEE0CB1116AB02102DC@gbcdcmbx03.intl.att.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <E3378E0605547F4E854DEE0CB1116AB0210631@gbcdcmbx03.intl.att.com> <defe35bb-bb8b-f1f0-d8c4-2d2d0f23731b@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> <E3378E0605547F4E854DEE0CB1116AB021CE2D@gbcdcmbx03.intl.att.com> <D5C05EB3.C2681%acee@cisco.com> <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com>
Date: Wed, 23 Aug 2017 13:52:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VFnd99TovknCrEna-Kh1B3AFTVk>
Subject: Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]
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: Wed, 23 Aug 2017 11:52:18 -0000

On 08/21/2017 05:14 PM, Robert Wilton wrote:

> Hi Acee,
>
> That makes sense.
>
> The other thing that I think that we have got wrong is modelling regex 
> pattern statements.  I think that it would be much better if these 
> were written to be less exhaustive and much simpler.
>
> E.g. the "route distinguisher" pattern in 
> draft-ietf-rtgwg-routing-types-09 is defined as this:
>
>           pattern
>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>           +     '42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>           +     '42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>           +     '655[0-2][0-9]|'
>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|'
>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|'
>           +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(6(:[a-fA-F0-9]{2}){6})|'
>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>           +     '[0-9a-fA-F]{1,12})';
>         }
>
> But I think that it would be much easier to read, and quite possibly 
> more performant to execute, if the pattern regex was written something 
> like the following:
>
>  pattern:
>     '(0:[0-9]{1,5}:[0-9]{1,10})|
>      (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>      (2:[0-9]{1,10}:0:[0-9]{1,5})|
>      (6(:[a-fA-F0-9]{2}){6})';
>
> Of course, this would allow more invalid values, but most servers 
> would be expected to reject those when it converts them into an 
> internal binary format any way.
>
> What do you, and others, think?
You still need the 
|(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):[0-9a-fA-F]{1,12}) in the 
end to not reject valid values though.

IMO a pattern statement has value if it absolutely defines the set of 
valid strings. In general I do not see the benefit of pattern statements 
that do not reject all invalid string instances. I prefer the original 
pattern or none at all.

Vladimir

> Thanks,
> Rob