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

Andy Bierman <andy@yumaworks.com> Fri, 09 March 2018 16:06 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 585A012D7F9 for <netmod@ietfa.amsl.com>; Fri, 9 Mar 2018 08:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 YtzBDUPKGLf4 for <netmod@ietfa.amsl.com>; Fri, 9 Mar 2018 08:06:22 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 4791012D7F2 for <netmod@ietf.org>; Fri, 9 Mar 2018 08:06:22 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id l191-v6so13896526lfe.1 for <netmod@ietf.org>; Fri, 09 Mar 2018 08:06:22 -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; bh=prvGRv5ZstL2UEpEAtnNfg1ntxA0e++PY346ZlCAokk=; b=i5scMBHqPluhBQqXEHTzDIt2RJvR3myygXXOsXax7IzLOWKLF32/ylg/Z1HMWj5KU7 51t3XPvP54HW/g3yBhGo598hqb2Kl5F+8E2wiwfi2c6dEtnnctdOvltZSCDfSiSKV+/F TRs+Z/K+cKw+9OWPa0TWnAmk0OHeou/6waZGkTOEvlxcqGOdbbmiozyhEyrgKHdh2UP/ snsHavM1SsZWwBRHeM6JXuTB9jhteiXScFEpm+IUyQT8dJuEP3nkwDlGsg07vD1QFSIP ynx+cSpJD8rPD6tdaX2qPNQW01/uGncMhOrdRcySIzOsQNlSGqMLif1rpjOD4mBnM2Zx YuDw==
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; bh=prvGRv5ZstL2UEpEAtnNfg1ntxA0e++PY346ZlCAokk=; b=gDC704J7+MHFlh9qLUuTq0VrfrmGcfk47VGFHbt0/mqxJT+sWuQiuiy3Qua2iLVISb bQdDO2pu3xw33HKGKzDIEt4ByshYsO12e79sLTgJqpiw9TWde2iUr5d0ZMyXP6gBrb7s Qq6Q7zp3PKobHlqnV/999RIdMueGkq9ckgR6NdJFhpmhheWa0gdqAMh5QOyGRO2I83Kf 8DBljFqfb7JVLyCI6i70V8Vlt262t1WEC59HEohR8uYdiOZbwGbF8/TlDD9TjCFqZdBH PHpt8k++fk8M2QU5w3X9cXEWHlJWShIKLfOkRFYlM74DYzxlIl+UOovlqLrcaX+QN3Sa HGxw==
X-Gm-Message-State: APf1xPDetK4raZ5+gD/y+g97jCWxr2n9w3i/0AOtzNoAPvFBj8UWeHxu veS4NpXgONGf5ZAG/oKc2rUW3enZCbU+bP7Cq6BwTg==
X-Google-Smtp-Source: AG47ELvVhulfd0J1iPqsE011ttZHHwy/Wt4l/gOn7ZXGcJfRCX2rxtxz2G3lwj4iA18iKDuqmqXSulLPxSElU7ekuJA=
X-Received: by 10.46.82.16 with SMTP id g16mr20954108ljb.67.1520611580410; Fri, 09 Mar 2018 08:06:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.26.149 with HTTP; Fri, 9 Mar 2018 08:06:19 -0800 (PST)
In-Reply-To: <20180309155434.ufspajrfqskw77o4@elstar.local>
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com> <CABCOCHSmCioJPNM5b9J-5WCsXe_J2jMzKKCD8fw02uh-D5nNdA@mail.gmail.com> <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com> <CABCOCHSLAKZCyACHgQvdqU6TLLdLBtY9izh7+2Pi4Qc3Z2-Sjw@mail.gmail.com> <20180309062933.oeitoohvvowfjh2b@elstar.local> <1ca7deec-3dbd-cbed-d70b-ce043a1714ee@cisco.com> <20180309155434.ufspajrfqskw77o4@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 09 Mar 2018 08:06:19 -0800
Message-ID: <CABCOCHR41Lsg5=5oNeXhTT2N0kCU=k1nGeBk2VJaKaDxzTMp+g@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Benoit Claise <bclaise@cisco.com>, Andy Bierman <andy@yumaworks.com>, Adam Roach <adam@nostrum.com>, NetMod WG Chairs <netmod-chairs@ietf.org>, NetMod WG <netmod@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6087bis@ietf.org
Content-Type: multipart/alternative; boundary="001a113c366e179a230566fcf944"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GOEaeImufnxVswmK-2jxZjS_ZaY>
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 16:06:25 -0000

On Fri, Mar 9, 2018 at 7:54 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Mar 09, 2018 at 03:22:26PM +0100, Benoit Claise wrote:
> > Hi,
> > > On Thu, Mar 08, 2018 at 04:08:32PM -0800, Andy Bierman wrote:
> > > > I don't really know what a guideline should say about patterns.
> > > > I will try to add something that says to document the pattern
> limitations
> > > > and keep the pattern as simple as possible,
> > > >
> > > I object to a statement that "pattern should be as simple as
> > > possible".
> > The only guideline that makes sense is: "the pattern must be correct" or
> > "the pattern must be meaningful". Not even worth mentioning, as this is
> so
> > obvious!
> > Whether it's a simple or a complex regex is orthogonal here: the pattern
> > must fulfill its job.
>
> Properties such as 'correct' or 'meaningful' are not easy to define
> for pattern. Pattern can have different levels of strictness and often
> greater strictness comes at the price of increased complexity of a
> pattern.  There is no general advice that can be given how to trade
> strictness of a pattern against pattern complexity.
>
> That said, pattern can be incorrect (rejecting input that they are
> supposed to accept). If pattern become increasingly complex to
> increase their strictness, then it is important that they are
> sufficiently tested not to be incorrect.
>
>

I came up with 2 sentences to add to 6087bis:

#1)

If the patterns used in a type definition have known limitations
such as false positive matches, then these limitations
SHOULD be documented within the typedef or data definition.

#2)

Simpler patterns SHOULD be used instead of more complex variants,
if possible, because they are easier to read.


IMO #1 should be added, especially if YANG documents have patterns
that are known to be incorrect.  But I want to leave out #2.

YANG modules (including patterns) are source code for automation tools.
>From that perspective, the only thing that matters is the correctness of
the automation tool.  False positives and false negatives are both bad.
The readability of the source code is not that relevant here.

I would prefer to have the description-statement define the acceptable
values
than a pattern that is wrong.


/js
>
>
Andy


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