[dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

[Doug Barton <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As promised I've managed to squeak this draft in under the wire. As I
say in the Foreword I expect that it will need some polishing, and if
the group chooses to adopt the document I look forward to getting lots
of help with that. :)


Doug


http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit-00

- -------- Original Message --------
Subject: New Version Notification for
draft-barton-clone-dns-labels-fun-profit-00
Date: Mon,  7 Mar 2011 05:47:21 -0800 (PST)
From: IETF I-D Submission Tool <[e-mail]>
To: [e-mail]


A new version of I-D, draft-barton-clone-dns-labels-fun-profit-00.txt
has been successfully submitted by Douglas Barton and posted to the IETF
repository.

Filename:	 draft-barton-clone-dns-labels-fun-profit
Revision:	 00
Title:		 Cloning Domain Name System (DNS) Labels for Fun and Profit
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document describes a method for making one or more Domain Name
System (DNS) labels behave in the DNS "as if" they were actually an
entirely different label.  E.g., the delegee for the example.org zone
could define bar.example.org to be a CLONE of foo.example.org.  This
method is designed to meet the needs of those managing
Internationalized Domain Name (IDN) zones that have been determined
to be semantically similar, and therefore should be treated "as if"
they were identical.  This method can also be used more generally to
handle situations where currently either CNAME or DNAME Resource
Records are being used.

A key design goal for the CLONE method is that except for DNSSEC
support all of the semantic benefits are available by updating the
authoritative servers for the zone.  Therefore unless DNSSEC support
for the CLONEd zones is required there is no dependency on end users
being behind a CLONE-Aware resolving name server.

Foreword

[RFC Editor, please remove this Section at publication time.
Thanks.]

This is my first draft, please be gentle. :) I'm definitely open to
the possibility that there are better ways to accomplish the concepts
presented herein.  I'm sure that there are a non-zero number of
errors in the formatting, references, etc.  Also Sections 2 and 3 may
be under-specified, unclear, or unworkable.  So please don't be
afraid to offer (constructive) criticism.

TODO:


Update/add/improve references?


Add/improve examples?

Revision History:
1.  -00 Initial version




The IETF Secretariat.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBCAAGBQJNdOQJAAoJEFzGhvEaGryEBs0H/1OzHZvPwl0v7wDK2KQvNLwI
tt/UDJhVZD1TDOjVKXvoApp7sYFdOMgJQG0p0tDWETKs+RK5YYj/FP48G3UZrj6T
Ie47cVUwHDRxfJ+MT9So7YoCYFqAeN4/51PGWCFDkogNIcMBs+eMDKgC+95hO11S
Rit58laXgTUGJaJCpFIEstj2LS2Fm+uEXjmoOmzilvBj0WnbG80cRgxkXepZZilp
4dKsB2xSBReNODReTBn4GlFETnsquqdq1DRDQpSsOtA5EjoMYxfwPdmiVRJ+v2NT
pwWJT2igc4sSCcPlt8+VNQX4aUOT/6evo3U4USe+sgGOzdeZpUAY2w/pfHTTLKI=
=Ef+O
-----END PGP SIGNATURE-----