Subject: Re: [[email-masked]: I-D ACTION:draft-hardie-out-rr-00.txt]

From: "Paul V. Mockapetris" <[email-masked]>
Date: Fri, 14 Jun 2002 11:35:42 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

At 10:28 AM 6/14/2002 -0700, Ted Hardie wrote:
>Howdy,
>         I would appreciate comments on the document referenced below,
>either to me or to the list.  As you'll note in the abstract, it
>describes a proposed RR that acts as a cross-class pointer, gives some
>use cases, and proposes some limitations to its use.
>                         best regards,
>                                 Ted Hardie

I talked to Ted after several drafts of this, but wanted to write down my 
thoughts on this.  I was so taken by Ted's precompensating spin and finesse 
(to avoid IDN and other current DNS debates), I decided to use a style that 
has all of the finesse of Roger Clemens.

---

I would rewrite the abstract/info/mission to say:

The CLASS mechanism in the DNS was created to be a mechanism that added an 
additional dimension to the DNS database.

In the original specification [RFC 1035] classes were parallel data 
structures with:
- identical name spaces
- potentially different delegations of authority
- TYPE formats which could either be identical across all classes (class 
invariant) or different

So that for example, we might have had the OSI class, and a host 
www.nominum.com might have a class IN format address of 10.0.0.1 in the IN 
class and its NSAP equivalent in the OSI class.  The IETF could continue 
control of the IN class for as long as it was necessary for backward 
compatibility and the ITU might regulate the OSI class.

BCP42 partially defines a different vision:

- different classes having fundamentally different name spaces
- the same view on delegation
- the same view on TYPES(?)

Given the need for new functions in the DNS, and given the fortunate 
absence of non-IN CLASS usage and hence the absence of compatibility 
issues, we propose a modest extension to the DNS called the cross-class 
pointer (CCPTR), and revisit once again the differences between classes of 
DNS data.

The new RR is

<name> <class> <TTL> CCPTR <other-class> <other-domain-name>

Basically this RR is typically used to point from a location in the DNS 
database to a different location, where the classes are typically 
different.  Multiple pointers may exist at the same name.

This RR is meant to facilitate early research in multiple classes.

But in reality, this is merely one small step toward defining a DNS class 
mechanism that could solve problems that are difficult to solve in the 
curent DNS.

A partial cut at the issues
===========================

We suggest the following:

Classes MAY have different name spaces.  This allows both the original type 
of usage envisioned in RFC 1035 and that seen in BCP42.

TYPES continue to be defined as either class-invariant or class-independent.

Delegations and control are class specific.

Case insensitive behaviour and matching rules be defined to be class-sensitive.

The IANA reserve CLASS.ARPA, where names such as 1.class.arpa and in.class.arpa
would hold TXT or other RRs that define the behaviour of classes.  (Note 
that there are some original requirements, such that TYPE and CLASS 
mnemonics be disjoint, which may need to be modified/restated).  [Note that 
this assumes DNSSec could be ready to go to securely distribute the 
data.  If this should not be the case a signed zone file would suffice]

A new DNS WG DCLASS, WG will define the rules for multiple class behaviour 
and for the data stored in CLASS.ARPA, with the objective that the classes 
may be delegated, and that cryptographically-signed data at CLASS.ARPA 
would be sufficient to configure DNS servers, resolvers, and support 
software to operate in a new class.  [Of course the correct steps for 
forming the WG would be a prelude]

DCLASS will attempt for provide the diversity that might be required by 
DNSEXT, IDNA, et al.  But the charter is to provide flexibility rather than 
a single set of rules compatible with the IN class.

We recognize that behavior other than those announced above may need to be 
codified.  For example - CNAMEs.

============================================================================ 
================

I have various presentation suggestions for Ted's examples, but nothing major.

---

From: Randy Bush <[email-masked]>
Date: Sun, 16 Jun 2002 05:45:09 -0700

while we're solving problems using this approach, is there a reason
that you did not mention that classes could be rooted differently?
e.g. the IN class could remain with the IANA roots, and the ITU
class could be controlled by the itu with its own set of root
servers.  let a thousand roots bloom.

randy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Paul V. Mockapetris" <[email-masked]>
Date: Sun, 16 Jun 2002 09:16:19 -0700

>Delegations and control are class specific.

so it was mentioned (different delegation at the root may mean different 
rooting/ownership).

Of course, this isn't anything like the proposals to have separate roots 
for class=IN, which generates so much fear of cataclysmic 
consequences.  There's no threat to the status quo here.