Subject: [DNSOP] Microphone question on back-references - BULK RR

From: Brian Dickson <[email-masked]>
Date: Thu, 30 Mar 2017 19:07:28 -0500

>
> Apologies but I did not hear the full question regarding BULK RR’s and the
> perl like back-references.  If you could please repeat the question we
> would be happy to comment.
>
>
>
>
>
> Thanks,
>
> John
>

Sorry for the delayed response.

The question was:

Given the use of perl-style back-references ( like "${1}" ) - would it not
make sense to use the same perl syntax to provide well-defined targets for
those back-references?

E.g. "my-special-(<regex-thing>)-(<regex-thing>)-with-suffix" and then
there is no ambiguity as to what ${1} and ${2} point at?

Perl regex rules are IMHO very clean and clever, and avoid ambiguity very
nicely.
(Also historical shout-out to Henry Spencer, whose regex mods served as the
source for perl's.)

Things inside parentheses are the target of back-refs.
In Perl, there is no need to escape the parentheses within regexes.

Brian

---

From: "Woodworth, John R" <[email-masked]>
Date: Fri, 31 Mar 2017 07:20:39 +0000

> From: DNSOP [mailto:[email-masked]] On Behalf Of Brian Dickson
>
> > Apologies but I did not hear the full question regarding BULK RR’s
> > and the perl like back-references.  If you could please repeat
> > the question we would be happy to comment.
> >
> >
> > Thanks,
> > John
> >
>

Hi Brian,

Thank you so much for following up!

>
> The question was:
>
> Given the use of perl-style back-references ( like "${1}" ) - would
> it not make sense to use the same perl syntax to provide
> well-defined targets for those back-references?
>
>
> E.g. "my-special-(<regex-thing>)-(<regex-thing>)-with-suffix" and
> then there is no ambiguity as to what ${1} and ${2} point at?
>
> Perl regex rules are IMHO very clean and clever, and avoid ambiguity
> very nicely.
> (Also historical shout-out to Henry Spencer, whose regex mods served
> as the source for perl's.)
>

Full disclosure:

   I especially love the perl-regex rule engine and can't imagine doing
   even half the things I have to do every day without it.

   I echo your thanks to Mr. Spencer and include the authors of libpcre
   who's dedication has allowed me to easily use the perl-regex ruleset
   for my every whim.

In fact, when we first set out to solve our problem, regex was our
instinctual go-to.  Unfortunately, it soon became clear regex is
simply _too_ complicated for the task at hand.

First, in our case the patterns will _always_ be numeric ranges
(or sets of ranges) and regex, no matter the flavor, simply brings
too much baggage (i.e. overhead) to the party.

Second, regex was designed for string/ substring pattern matching
and is simply horrible at multi-digit numeric ranges
(the one thing we need it for).

Try out this example:

We want to match a numeric range from 0-255.

With PCRE, this becomes:

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

With BULK-RR, this becomes:

[0-255]

Now, lets take a slightly more complicated example.  Say we have
an IPv4 /16 broken into 4 /18's.

Depending on which /18 is being targeted, the third octet can be
within the ranges: 0-63, 64-127, 128-191 or 192-255.

[0-63]    vs. (0|[1-5][0-9]|6[0-3])
[64-127]  vs. (6[4-9]|[789][0-9]|1[01][0-9]|12[0-7])
[128-191] vs. ???
[192-255] vs. ???

Even if you are an absolute regex genius and this poses zero
challenge, in situation like this I often ask myself:

  -  Which would you rather figure out in the middle of the night?
  Or
  -  Would I like to be woken up for this or should it be easier
     for 'someone else'?

> In Perl, there is no need to escape the parentheses within regexes.

The square brackets can only contain numeric ranges (or sets of ranges)
so no need to escape within them either.

Thanks again,
John

NOTE: The regex pattern for 0-255 was borrowed from a quick web
      search (link below).

      https://chrisjwarwick.wordpress.com/2012/09/16/
      more-regular-expressions-regex-for-ip-v4-addresses/

> Brian
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.