Subject: Little endians, big endians, and 16 bit eggs

From: "Christian Huitema" <[email-masked]>
Date: Fri, 21 Jan 2005 20:56:10 -0800

OK, the real title of the reference papers was "On Holy Wars and a Plea
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:

Name = example.net, Prefix = --myNewPseudoType, type = TXT, content =
string
And  
Name = example.net, Prefix = null, type = myNewType(1234), content =
string

Sure, there are differences, and it is worth noting them:

- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types

But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.

It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.

-- Christian Huitema

--
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: John Levine <[email-masked]>
Date: 22 Jan 2005 16:17:08 -0000

>> By my reading of RFC 2782, the prefixes on SRV names are supposed to
>> come out of the IANA services list
>
>I agree.  However, Christian Huitema was suggesting a TXT record in his
>example, not a SRV record.

True, but if you're using prefixes, regardless of what record types
you're (re)using, you need some sort of registry if you want to be
sure that nobody else will use your prefix to mean something else.  I
suppose you could use the URI trick to get uniqueness from domain
names, but I have my doubts about how 

The issue of how hard it is to get something into the registry is a
separate question from what it is you're registering.  I agree that in
retrospect it should have been easier to register new RR types so that
people wouldn't have written DNS software that assumes the set of RR
types is forever fixed.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Pekka Savola <[email-masked]>
Date: Sun, 23 Jan 2005 10:11:06 +0200 (EET)

On Sun, 23 Jan 2005, Mark Andrews wrote:
> 	The problems people are reporting today are non-compliance
> 	problems.  The way to fix non-compliance problems is to
> 	remove the offending software / hardware.

Hence, IMHO, it seems critical to have a concise document describing 
what MUST be implemented (and why), what is optional, etc.

If we would have a draft or RFC of 15-20 pages and could show it to 
the offenders, and people buying DNS equipment could request it in 
CFTs (see RFC3871).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alex Bligh <[email-masked]>
Date: Sun, 23 Jan 2005 19:51:51 +0000

--On 23 January 2005 16:33 +0000 Paul Vixie <[email-masked]> wrote:

> i agree, but you should all take a look at the following, just the same:
>
> <http://www.doxpara.com/dns_bh/Black_Ops_DNS_BH_files/v3_document.htm>

Indeed. But "can do" != "should do" :-)

Alex