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

Robert Wilton <rwilton@cisco.com> Mon, 21 August 2017 15:15 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 41C09132650 for <netmod@ietfa.amsl.com>; Mon, 21 Aug 2017 08:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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 k_gnAG6nSDO9 for <netmod@ietfa.amsl.com>; Mon, 21 Aug 2017 08:14:53 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7AE132A69 for <netmod@ietf.org>; Mon, 21 Aug 2017 08:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13183; q=dns/txt; s=iport; t=1503328492; x=1504538092; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=VHY6qykY5vo1CCWT4LP4RZKF8nRBg/bFdGDJ7ccuW/E=; b=Z6+3YbJ6ZexhskZxSOXZCC8nMjnombzqWfHVzliyyWeOV2250pE4vpjG ORc1eeYDGn5PShx30YK0M9EUbmxUL+6Y0CCClvFiCUGPG9dcoj8jcBGrk 9Pk91qCilAyVLWWi5sGOv5E0C8E8j/K9SThuFZ3B+7IoYBrBOm1NFAln7 g=;
X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208,217";a="654096013"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 15:14:50 +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 v7LFEokN004704; Mon, 21 Aug 2017 15:14:50 GMT
To: "Acee Lindem (acee)" <acee@cisco.com>, "Ivory, William" <william.ivory@intl.att.com>, "'netmod@ietf.org'" <netmod@ietf.org>, Andy Bierman <andy@yumaworks.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>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Date: Mon, 21 Aug 2017 16:14:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <D5C05EB3.C2681%acee@cisco.com>
Content-Type: multipart/alternative; boundary="------------825ED476C42CF7428E698B97"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_3d2niy3OxZh74-IVTNfTokC2fo>
Subject: [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: Mon, 21 Aug 2017 15:15:04 -0000

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> 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
>> 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
>> 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
>> https://www.ietf.org/mailman/listinfo/netmod