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

Ladislav Lhotka <lhotka@nic.cz> Wed, 23 August 2017 20:03 UTC

Return-Path: <lhotka@nic.cz>
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 9E21D132377 for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 13:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 BhIy76gFZGYN for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 13:03:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C62113209C for <netmod@ietf.org>; Wed, 23 Aug 2017 13:03:47 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 871BD622CE; Wed, 23 Aug 2017 22:03:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503518625; bh=lHEYhBmtMBaUtns/P3076omX7+5Vj59wjbMI02jJRec=; h=From:To:Date; b=kJL5NTj7jmiLzNGSv2oj+FejDlQXJJg5MnPcPk4GtjGVssITTEDbVs8pTW6/OoBV/ lEHvNAaODpqTcZjqwQp6RW8BiWpnK7ilVN/PBuwUmbpmLwyUrx5z5hJ9hB5hff/Deh Nb1VS3+pzGGm/HRhh5Gq6dnEoD4Gr7HtGjZn6g4c=
Message-ID: <1503518651.5001.27.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, netmod@ietf.org
Date: Wed, 23 Aug 2017 22:04:11 +0200
In-Reply-To: <c7190863-4cfb-9d97-79c2-589d75d17814@cisco.com>
References: <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> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <1503498125.32530.12.camel@nic.cz> <c7190863-4cfb-9d97-79c2-589d75d17814@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7aGtRCGuWBoWUy2rR_g0uVdf3j4>
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 20:03:53 -0000

Robert Wilton píše v St 23. 08. 2017 v 17:58 +0100:
> 
> On 23/08/2017 15:22, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200:
> > > On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
> > > > 1) Email address.  I understand that the full regex to validate all email
> > > > addresses is very complex, but checking that it at least contains an @
> > > > symbol still has benefit.  It would seem that a short imperfect regex is
> > > > better than a complete perfect regex.
> > > 
> > > What is your definition of 'better'? A stricter pattern catches more
> > > errors. An imperfect pattern is better than none.
> > > 
> > > > 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
> > > > "1-10,20-400,600,2000-3000", but only with non overlapping values in
> > > > ascending order.  It is easy to write a regex to check that the structure is
> > > > right, but AFAIK it is hard (impossible?) to write a regex that ensures that
> > > > the ranges don't overlap and are specified in ascending order.
> > > 
> > > So what. Does this provide a helpful argument whether patterns should
> > > be strict or imperfect?
> > > 
> > > > So, I propose that we use regexes for checking that the string is
> > > > structurally correct, but don't use regexes to perform numerical range
> > > > checks of string encoded numbers, since it makes the regexes hard to
> > > > read/verify, and doesn't improve the readability of the YANG file either.
> > > 
> > > So here is the point I think:
> > > 
> > >     It is desirable that regexes are as strict as they can be.
> > >     However, if regexes become so complicated that they become a
> > >     verification and maintenance problem by themself, then less strict
> > >     regexes may be a better choice.
> > 
> > Either way, the regex must not produce false negatives, i.e. reject valid
> > values. For some regexes this is what makes them complicated.
> 
> I agree.
> 
> > 
> > Also, I don't see any need for replacing existing patterns unless they are
> > wrong.
> 
> I also agree.  I'm not trying to retroactively change existing regexes, 
> just tweak the guidance when new regexes are being constructed so that 
> they end up being a bit simpler.

This is really subjective, and I am certainly on the side of making the regexes
as strict as possible because they guard not only against typos but also against
intentionally invalid values, i.e. attacks.

Lada

> 
> Thanks,
> Rob
> 
> 
> >   We have descriptions to tell human readers about the permitted value set.
> > 
> > Lada
> > 
> > > /js
> > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67