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 >
- [netmod] Potential additions to rfc6087bis: RegEx… Xufeng Liu
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Per Hedeland
- Re: [netmod] Potential additions to rfc6087bis: R… Ladislav Lhotka
- Re: [netmod] Potential additions to rfc6087bis: R… Per Hedeland
- Re: [netmod] Potential additions to rfc6087bis: R… Carsten Bormann
- Re: [netmod] Potential additions to rfc6087bis: R… Xufeng Liu
- Re: [netmod] Potential additions to rfc6087bis: R… Xufeng Liu
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Xufeng Liu
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Benoit Claise
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Kent Watsen
- Re: [netmod] Potential additions to rfc6087bis: R… Lou Berger
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Alex Campbell
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Acee Lindem (acee)
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Carsten Bormann
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Ladislav Lhotka
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Ladislav Lhotka
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Juergen Schoenwaelder
- Re: [netmod] Potential additions to rfc6087bis: R… Lou Berger
- Re: [netmod] Potential additions to rfc6087bis: R… Ladislav Lhotka
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Ladislav Lhotka
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Robert Wilton
- Re: [netmod] Potential additions to rfc6087bis: R… Lou Berger
- Re: [netmod] Potential additions to rfc6087bis: R… Andy Bierman
- Re: [netmod] Potential additions to rfc6087bis: R… Lou Berger