Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 13 Jun 2004 05:27:54 -0700

> The bottom line is that RFC 1464 was a syntax proposal design 
> to simplify
> information sharing. A registry was proposed to control name 
> collisions, but
> that never happened. It still seems to be a reasonable 
> approach and perhaps
> someone will put it back on the standards track someday if 
> appropriate.

I agree with most of the idea, but I don't agree with the 
registry part.

According to ICANN, IANA is costing $700,000 a year to 
maintain. I think it is time to either look at why it
costs so much and work to reduce it, or start looking for
engineering designs that do not depend on registry functions.

In the case of DNS RR prefixing there is no real problem
since the possible name space is essentially unlimited.
The chance of accidental collision is minimal.

The value that a registry would provide is as a concordance.

The engineering way to deal with this problem would be to move
to a competent document format such as XML, assign all 
code points automatically from a dictionary and build the
concodances and indexes automatically from the documents 
themselves.

This is somewhat over-engineered for our case since we 
already have a unique key, the group name is in theory
unique over time.

Using _MARID as the prefix is practically guaranteed to
be accidental collision free.

Adding the protocol identifier to the base prefix is
arguably an improvement, since we might use _SMPT._MARID.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 13 Jun 2004 14:14:38 -0700

On Sun, 2004-06-13 at 05:27, Hallam-Baker, Phillip wrote:
> > to simplify information sharing. A registry was proposed to
> > control name collisions, but that never happened. It still
> > seems to be a reasonable approach and perhaps someone will
> > put it back on the standards track someday if appropriate.
> 

Whether there are too many people maintaining the registry information
is separate concern from whether a registry is needed.  Moving Protocol
Number Assignment to a function of the IETF rather an IANA is a decision
well beyond the scope of this group.  A registry is a vital function
that must be employed to ensure the function of past and future
protocols.

> The value that a registry would provide is as a concordance.

As there are already protocols using text records to store random
strings, collision avoidance is depending upon labels.  The problem is
uses of a label as a sub-domain is prone to collision irrespective of
the differences of the labels as a result of wild cards, as there would
be motivation for using such a mechanism regardless of how it was
specified. 

> concodances and indexes automatically from the documents 

A concordance, (a registry) would need to encompass not just the
specification being developed, but other specifications either in
progress or already in use.  There would need to be agreement where this
information is to be centralized and arbitrated, and it would need to be
kept current and updated.  You imply such specification is free from
conflict but that is hand waving.  Just as using a domain name is not
free from conflict as it could have been owned by prior entities where 
previous history is unknown without a registry. 

> already have a unique key, the group name is in theory

Work group names were never ensured not to conflict with anything but
work groups.  In addition, these groups expire and are no longer a ready
reference.

> be accidental collision free.

As a label, it would not be free from conflict even if indeed no other
protocol used the label.  As a token, it is already in conflict with
random text strings.

> arguably an improvement, since we might use _SMPT._MARID. 

Again as a label, this offers little assurance.  Using more characters
for a token embedded in the text reduces chances of a collision, but so
would an embedded checksum of the entire record where such chances of
collision would billions of times less using just 8 characters.  It
would also ensure the TXT record would be generated as a result of a
script that would likely perform format checks in addition to
calculating the checksum.  A checksum can defend against random strings.
To allow future protocols the use of same mechanism, a registry is still
needed.  It has already been proposed the XML header is not included
within the TXT record, such that XML registries offer no benefit as this
information is virtual and too bulky for DNS.

-Doug