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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 22 August 2017 22:21 UTC

Return-Path: <acee@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8A132A97; Tue, 22 Aug 2017 15:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 UpwZ4U1b8CDQ; Tue, 22 Aug 2017 15:21:25 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87691132A95; Tue, 22 Aug 2017 15:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21053; q=dns/txt; s=iport; t=1503440485; x=1504650085; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B5RQz2xTxhz+jJPjWedenAksSga9bXzBFLgjK692vJQ=; b=Tpp0xqpEUu4u+DWrlTn9mdZYkEgfu0GPHDUpUp/V/rXAfiaySNi5EARj kZall1rCWdjDdtumMSxVkOjV/+pjrzzfAM2RhxRZQcdugSUHDk6ENhtZ3 qls2i16XbQYi58SsAFVc/PglyCE72dkJdoL2EJN8kBp7ujKhkzGwV7acT o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAAD4rZxZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFQeODZAbgW6QZoU5ghIhAQyESk8CGoQXPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQMBASFLBgUMBAIBCBEDAQEBKAMCAgIlCxQJCAIEAQ0FCYlEZ?= =?us-ascii?q?BCsXIImJ4tEAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMqggKDL4MngkZggSY+CR6?= =?us-ascii?q?CVYJhBZghiDQCh1OMboIQWYkFhnKJbYw7AR84gQp3FUmFTIFOdgEBiD6BMoEPA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.41,414,1498521600"; d="scan'208,217";a="446999873"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2017 22:21:24 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7MMLNuf029083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 22:21:24 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Aug 2017 18:21:23 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 22 Aug 2017 18:21:23 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, "'netmod@ietf.org'" <netmod@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Pattern statements [was Re: [netmod] Query about augmenting module from submodule in YANG 1.0]
Thread-Index: AQHTGpA9Gl54VvqvVk+CY8qb3KBKRqKQ9NGA
Date: Tue, 22 Aug 2017 22:21:23 +0000
Message-ID: <D5C2252F.C2E98%acee@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>
In-Reply-To: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: multipart/alternative; boundary="_000_D5C2252FC2E98aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/rY5r6iJ325ChnhnkPi9wzB4fq28>
Subject: Re: [bess] Pattern statements [was Re: [netmod] Query about augmenting module from submodule in YANG 1.0]
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Aug 2017 22:21:29 -0000

Hi Rob,
I’m fine with simplifying (even if the resultant pattern is much less impressive ;^). I’ve copied the BESS WG to see if there are any objections.
Thanks,
Acee

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Date: Monday, August 21, 2017 at 11:14 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "Ivory, William" <william.ivory@intl.att.com<mailto:william.ivory@intl.att.com>>, "'netmod@ietf.org<mailto:'netmod@ietf.org>'" <netmod@ietf.org<mailto:netmod@ietf.org>>, Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Subject: Pattern statements [was Re: [netmod] Query about augmenting module from submodule in YANG 1.0]


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?

Thanks,
Rob


On 21/08/2017 15:01, Acee Lindem (acee) wrote:

Hi William, Rob, Andy,

Given their limited usefulness and the detriments, perhaps we should
discourage the creation of new submodules in RFC6087Bis.

Thanks,
Acee

On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
<netmod-bounces@ietf.org on behalf of william.ivory@intl.att.com><mailto:netmod-bounces@ietf.orgonbehalfofwilliam.ivory@intl.att.com> wrote:



Hi Rob,

That would make it very hard to update existing 1.x YANG models to use
new features in YANG 2.x if they used submodules.  Maybe that's something
that no one would ever consider doing anyway, or maybe YANG 1.1 already
has similar differences to 1.0?  I had (perhaps naively) assumed that you
could migrate a namespace / model from YANG 1.0 to 2.0?

Regards,

William

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Query about augmenting module from submodule in
YANG 1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:


On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:


I remember that in early stages of YANG there was some irrational
fear of introducing too many namespaces, and submodules may be a
consequence of it. As you write, submodules provide no benefits
whatsoever in terms of modularity, but the overhead in terms of
metadata, IANA registration etc. is pretty much the same as for
modules.


In case YANG 2.0 is ever done, I suggest someone files a proposal to
remove submodules if the cost/benefit ratio is at odds. There is
nothing wrong with removing stuff that has been found problematic.


I agree.

I've added
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dw
g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7ow
I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=

Rob



The motivation for submodules was that organizations maintaining large
modules with multiple people can do so without having to mess around
with tools like m4 scripts to produce a single module from 'snippets'
and to avoid integration surprises. But perhaps using m4 scripts and
decent version control systems (that can integrate and compile on
checkin) is indeed cheaper than having submodules part of the YANG
language itself.

/js



_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwky
XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vG
IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>https://www.ietf.org/mailman/listinfo/netmod