[DNSOP] FW: New Version Notification for draft-woodworth-bulk-rr-04.txt

"Woodworth, John R" <John.Woodworth@CenturyLink.com> Wed, 08 February 2017 10:37 UTC

Return-Path: <John.Woodworth@CenturyLink.com>
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 7EC771299E9 for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 02:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 ZQEMaQ_2e_nZ for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 02:37:18 -0800 (PST)
Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 43DFA1299E8 for <dnsop@ietf.org>; Wed, 8 Feb 2017 02:37:18 -0800 (PST)
Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id v18AbGCu023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 03:37:16 -0700
Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8DDAA1E0049; Wed, 8 Feb 2017 04:37:11 -0600 (CST)
Received: from lxdnp32k.corp.intranet (unknown [151.117.18.14]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 67BBC1E003F; Wed, 8 Feb 2017 04:37:11 -0600 (CST)
Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v18AbBHN032751; Wed, 8 Feb 2017 03:37:11 -0700
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 v18AbAUK032748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Feb 2017 03:37:10 -0700
Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.220]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0294.000; Wed, 8 Feb 2017 04:37:10 -0600
From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>
To: "'dnsop@ietf.org'" <dnsop@ietf.org>
Thread-Topic: New Version Notification for draft-woodworth-bulk-rr-04.txt
Thread-Index: AQHSgfW/v/1e+SB2+U+Wpl6/e37X2KFe6NAw
Date: Wed, 8 Feb 2017 10:37:09 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD06D322F@PODCWMBXEX501.ctl.intranet>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F8ej2kVT0OhGFxjuv0KLPvXrhc8>
Cc: 'JW' <jw@pcthink.com>, 'shash raghu' <shash.raghu@gmail.com>, "Woodworth, John R" <John.Woodworth@CenturyLink.com>, "Ballew, Dean" <Dean.Ballew@CenturyLink.com>
Subject: [DNSOP] FW: New Version Notification for draft-woodworth-bulk-rr-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 10:37:19 -0000

All,

I just submitted -04 in response to comments received.

As usual, all feedback is welcome.


Thanks again,
John
----------------------------------------------------------
**  I-D "BULK DNS Resource Records" Mini-FAQ   01-31-17 **
----------------------------------------------------------


Q) Why do we need BULK RRs?
A) BULK is a tool like many others.
   It was designed to help simplify the management of
   pattern based "generic" records and scale to fit the
   growing demand of IPv6 support. It builds on popular
   technology currently used today while providing a
   number of modern enhancements. The authors feel BULK
   is the next logical progression of what is already
   field-proven and accepted in the industry today.


Q) Does BULK cover all RR types?
A) No. The draft only covers A, AAAA, PTR and CNAME RR types.


Q) What happens if there are other RRs which fall inside
   a BULK pattern range?
A) BULK records can only exist where other records do not,
   a concept referred to as "Record Superimposition" [5.1]


Q) Can BULK generated RRs be DNSSEC validated.
A) The draft offers two DNSSEC solutions, on-the-fly
   generated signatures and a pattern based solution in
   the form of a support NPN RR type (included in the draft).


Q) Is BULK only for IPv6 namespace?
A) No, BULK is intended to simplify management of both IPv4
   and IPv6 "generic" records.


Q) Why not just script these ranges, use $GENERATE or
   simply forbid the larger ones?
A) Two fundamental goals behind BULK are to be able to
   provide the same capability behind scripting and
   $GENERATEs without the memory requirements and
   be able to transfer the zone maintainer's "intent".
   For example, when you transfer RRs managed by a script
   or $GENERATE the receiver gets "all" records and not
   the shorthand used to create them.  BULK transfers
   this intent so the copy looks just like the original.
   Several DNS Software Vendors are already providing
   this capability in a proprietary manner, BULK offers
   an open "standard" way to exchange these records
   which scales to fit any size.


Q) BULK syntax looks like regular expression, isn't that
   a bit too complicated?
A) BULK does offer advanced regular-expression-esque
   backreferences but in a simplified manner. In fact,
   the "star" backreference will work fine in most
   scenarios (e.g. "member-${*}.example.com."). NAPTR
   RRs currently provide client-assisted regular-
   expression pattern substitution so BULK leverages
   a familiar "feel" while also providing some of the
   heavy lifting.

--

-----Original Message-----
Subject: New Version Notification for draft-woodworth-bulk-rr-04.txt
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]


A new version of I-D, draft-woodworth-bulk-rr-04.txt has been successfully submitted by John Woodworth and posted to the IETF repository.

Name:           draft-woodworth-bulk-rr
Revision:       04
Title:          BULK DNS Resource Records
Document date:  2017-02-07
Group:          Individual Submission
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-04.txt
Status:         https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
Htmlized:       https://tools.ietf.org/html/draft-woodworth-bulk-rr-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-04

Abstract:
   The BULK DNS resource record type defines a method of pattern based
   creation of DNS resource records to be used in place of NXDOMAIN
   errors which would normally be returned.  These records are currently
   restricted to registered DNS resource record types A, AAAA, PTR and
   CNAME.  The key benefit of the BULK resource record type is the
   simplification of maintaining "generic" record assignments which
   would otherwise be too many to manage or require scripts or
   proprietary methods as bind's $GENERATE.

   This document updates RFCs 2308, 4033, 4034 and 4035.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


-- 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.