Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78079128CFF for ; Tue, 28 Mar 2017 20:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gcu9Ur8IKUIp for ; Tue, 28 Mar 2017 20:19:13 -0700 (PDT) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9F71270A0 for ; Tue, 28 Mar 2017 20:19:13 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v2T3JCMO056162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 22:19:12 -0500 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0E0971E004E; Tue, 28 Mar 2017 21:19:07 -0600 (MDT) Received: from lxdnp32k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id DD7871E0035; Tue, 28 Mar 2017 21:19:06 -0600 (MDT) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T3J6Ro004963; Tue, 28 Mar 2017 21:19:06 -0600 Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2T3J6Rf004960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Mar 2017 21:19:06 -0600 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.58]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 22:19:06 -0500 From: "Woodworth, John R" To: "dnsop@ietf.org" CC: "'JW'" , "Woodworth, John R" Thread-Topic: BULK RR Myth[1] - BULK RRs use complicated regex for their syntax Thread-Index: AdKoOzwwaW0I649hTF6GY/u1rQi1JA== Date: Wed, 29 Mar 2017 03:19:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: multipart/alternative; boundary="_000_A05B583C828C614EBAD1DA920D92866BD0717ED4PODCWMBXEX501ct_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: [DNSOP] BULK RR Myth[1] - BULK RRs use complicated regex for their syntax X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 03:19:15 -0000 --_000_A05B583C828C614EBAD1DA920D92866BD0717ED4PODCWMBXEX501ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BULK actually does _not_ use regex for its syntax. It does, however, "borrow" from regex in the way it identifies backreferences. The similarities are intentional as to "feel" familiar and be simple to grasp. This familiarity is likely the cause of this misconception. Another is likely the use of regex in sections of example pcode. -- Q. Why not just use regex? A. Regex can be intimidating for some and it is downright painful for the narrow scope of the BULK RR draft. BULK RR patterns can only* contain literal character-strings and numeric ranges (including hex). Let's take a simple everyday example of matching the numeric range from 0 to 255. Matching this simple (and common) numeric range quickly becomes a bit confusing and complicated to just visualize. REGEX: (25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?) BULK Pattern: [0-255] In the BULK example, a simple glance and the intent is obvious. Just think what the range of 5 to 240 might look like as regex syntax (scary). NOTE: The regex pattern was borrowed from a quick web search (link below). I'm sure there are others but none with the same clarity as a simple range. https://chrisjwarwick.wordpress.com/2012/09/16/ more-regular-expressions-regex-for-ip-v4-addresses/ * A single-hyphen may be used to further simplify this under certain circumstances. -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. --_000_A05B583C828C614EBAD1DA920D92866BD0717ED4PODCWMBXEX501ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BULK actually does _not_ use regex for its syntax.

 

It does, however, "borrow" from regex in t= he way it identifies

backreferences.  The similarities are intention= al as to "feel"

familiar and be simple to grasp.  This familiar= ity is likely

the cause of this misconception.  Another is li= kely the use

of regex in sections of example pcode.

 

 

--

Q.  Why not just use regex?

 

A.  Regex can be intimidating for some and it i= s downright

    painful for the narrow scope of t= he BULK RR draft.

    BULK RR patterns can only* contai= n literal character-strings

    and numeric ranges (including hex= ).

 

 

Let's take a simple everyday example of matching the= numeric range

from 0 to 255.  Matching this simple (and commo= n) numeric range

quickly becomes a bit confusing and complicated to j= ust visualize.

 

 

REGEX:

 

(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)

 

 

BULK Pattern:

 

[0-255]

 

In the BULK example, a simple glance and the intent = is obvious.

 

 

Just think what the range of 5 to 240 might look lik= e as regex

syntax (scary).

 

 

 

NOTE: The regex pattern was borrowed from a quick we= b search

      (link below).  I= 'm sure there are others but none with

      the same clarity as a= simple range.

 

      https://chrisjwarwick= .wordpress.com/2012/09/16/

      more-regular-expressi= ons-regex-for-ip-v4-addresses/

 

*  A single-hyphen may be used to further simpl= ify this under

    certain circumstances.=

 

 

-- THESE ARE THE DROIDS TO WHOM I REFER:<= /p>

This communication is the property of CenturyLink and may contain c= onfidential or privileged information. Unauthorized use of this communicati= on is strictly prohibited and may be unlawful. If you have received this co= mmunication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communicat= ion and any attachments.
--_000_A05B583C828C614EBAD1DA920D92866BD0717ED4PODCWMBXEX501ct_--