Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

Robert Wilton <rwilton@cisco.com> Mon, 04 September 2017 11:04 UTC

Return-Path: <rwilton@cisco.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 585C5126DD9 for <netmod@ietfa.amsl.com>; Mon, 4 Sep 2017 04:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sy4VdrRj0n0V for <netmod@ietfa.amsl.com>; Mon, 4 Sep 2017 04:04:46 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8439E1241FC for <netmod@ietf.org>; Mon, 4 Sep 2017 04:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2393; q=dns/txt; s=iport; t=1504523085; x=1505732685; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=u4OgE9vP5KFT4aBhPUMtyrFvxpfuCdF6zp8MUyV+Usc=; b=elGEeMp6DLJjaOuj+3l4BpOTBbkVSk2+vUcrT9MGy1FvEhaRJlAU+OIj fJbeV+jdxQIPKMn57XgCZGdu13REQhJ1Q6Ucy/UEnG3IwRB4ezsj6iKoo 11kkpLZ8I696E1ITUMbcCHQhVFHMQGyxtGmhZoEd390DtCRQ/Ybmz0o2I 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuAgCzMK1Z/xbLJq1dGgEBAQECAQEBAQgBAQEBiUqLFJEbmDoKhT4ChF4UAQIBAQEBAQEBayiFGAEBAQECASMPAQVRCxgCAiYCAlcGAQwIAQGKJQi1aIIni08BAQEBAQEBAQIBAQEBAQEBIYENgh2DUIIOgn2ICIJhBaB0lFGLVIcdjVeHKQMGBQIZgTk2IYENMiEIHBWHZT+LVQEBAQ
X-IronPort-AV: E=Sophos;i="5.41,474,1498521600"; d="scan'208";a="696957031"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 11:04:43 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v84B4hnp003070; Mon, 4 Sep 2017 11:04:43 GMT
To: Alex Campbell <Alex.Campbell@Aviatnet.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <c8de6140-af50-0a4b-a479-b011a8dfbbe7@cisco.com> <CABCOCHRNt3Tkxy8Ffz3JGgPe-rQYwZ3MTLmD43OQi4P6tZQJmg@mail.gmail.com> <f7151a6b-9deb-52ad-62a9-78b29a552540@cisco.com> <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <e8482a9c-cba3-28e2-9ffa-ec5eb5c1c0a4@cisco.com> <20170830123156.cssrg5kklpo67fie@elstar.local> <CABCOCHTtN611FO2ov2kTLtZx-Q3=tzgH7Xk9uGvFUD1WuyMZyw@mail.gmail.com> <b13c5e9a-e9f9-96e9-8823-0402fb74af09@cisco.com> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <e92d63dc-012c-c37f-e94e-8013def8c736@cisco.com>
Date: Mon, 04 Sep 2017 12:04:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170902073342.xoziwor4tdr5bipw@elstar.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FQL34d7AikUHZtlecLVWUJg2Nxs>
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
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: Mon, 04 Sep 2017 11:04:47 -0000

Hi Juergen,


On 02/09/2017 08:33, Juergen Schoenwaelder wrote:
> On Fri, Sep 01, 2017 at 10:45:51AM +0100, Robert Wilton wrote:
>> Hi Alex,
>>
>>
>> On 01/09/2017 00:57, Alex Campbell wrote:
>>> Hi,
>>>
>>>
>>> I'd be very wary of adding guidelines that restrict the regex syntax.
>>>
>>>
>>> A tool that supports YANG must implement the full regex language anyway
>>> (or ignore regexes altogether if they are not relevant to the tool's
>>> function).
>>>
>> This is true if the tool is designed to work with any arbitrary YANG
>> module.  But if a tool only needs to work with a subset of YANG modules
>> (e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need
>> to support the subset of the XML RE language that is used by the YANG
>> modules that they load.
>>
> Rob,
>
> you are on the path to create multiple flavours of YANG, an IETF
> flavour, an OC flavour, a Vendor XYZ flavour - in my view this can't
> be the goal of a standard.
This is the actually the polar opposite of my aim.  My aim is to try and 
stop the fragmentation that is already happening in the industry, via 
what I perceive is a pragmatic compromise.  I appreciate others
feel differently.

I.e. make XML RE easy enough to use that others in the industry don't 
feel that they need to fork YANG for this reason.  My understanding is 
that for the OpenConfig YANG models authors, the "must use an XML RE 
implementation argument" doesn't seem to be working, in that their 
models are currently defined using POSIX regex pattern statements that 
are certainly incompatible with XML RE (they have anchors).  Although my 
understanding is that they may move to define a separate "posix pattern" 
statement instead, I would guess that they will probably only use the 
"posix pattern" statement in their models and not define both the POSIX 
and XML RE expressions.

So, as it stands today, I think that we will either already end up with 
effective multiple flavours of YANG, or that YANG implementations will 
need to support both XML RE and POSIX RE implementations.  I think that 
is a worse outcome for the wider industry than just encouraging people 
to only use a pragmatic subset of XML RE for network management YANG models.

Rob

>
> A compliant implementation of YANG 1.0 and YANG 1.1 must handle XSD
> pattern.
>
> /js
>