Subject: draft-iab-dns-choices-02.txt comments

From: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 19:58:44 -0500

I believe that dns-choices is fundamentally flawed, it will be ignored
by developers that decide to use TXT and does not provide an useful
way forward.

I believe that that dns-choices flies in the face of decades of
successful Unix semantics about data storage in files.

I believe what needs to be done is to allocate say, 100 new DNS RRs as
clones of TXT records (say, TXT0-TXT99).  There are tens of thousands
of RR numbers sitting totally unused.

What the Unix philosophy about files is that there shouldn't be a
"file type" (RR number), most things should be put into flat text
files.  Files should be distinguished by "magic numbers", located
within the file.  These "magic numbers" do not need a central
authority to allocate them.

While text is often not as compact as binary formats and require
conversions/parsers, the advantages of being able to use standard
tools to edit and debug the files is huge.  Binary files are often not
significantly smaller, nor are the overhead of parsing is often
irrelevant.

Of course, the Unix philosophy of flat text files was developed back
in the 1970s when storage space and CPU cycles were far more expensive
than they are today, so these considerations are even less relevant 30
years later.

Reasonably long magic numbers are unlikely to collide, even globally.
When localized to particular application area, they are even less
likely to collide.  If one magic number is in widespread use, and
someone comes along and tries to re-use it, they will quickly discover
the collision and they, being the newer and less popular use, will
almost certainly back down.  Intelligent designers will do a survey of
the application area first to make sure there isn't a problem with
collisions.  Two unpopular systems that use the same magic number are
unlikely to collide because they are unpopular.

History has shown that collisions with Unix magic numbers is rare.  An
unofficial, first-come first-served registry of (TXTxx, magic number,
application area) tuples could make it even more rare.

By having, say, 100 TXT record clones to choose from, applications can
choose one that keeps the RR set small.  If there ever comes a day
when it looks like those 100 TXT RR clones are filling up, we can
allocate another 100, or even 1000 or 10,000 TXT RR clones.

The whole dns-choices I-D makes the assumption that TXT space is
limited, and instead of changing that assumption, it goes off claiming
that new, special purpose RRs should be used.

There are two conflicting problems with allocating new RRs.  First
off, the vast majority of ideas never take off, and if you allocate a
new RR type for every harebrained idea, we would run out of RR numbers
quickly and we would have a very long list of RRs that aren't used.
Secondly, if you try to do some sort of gate-keeping to make sure only 
"popular"/"useful" RRs get allocated, then that will be too much work
for people who want to just test an idea and they will go off and use
TXT RRs.  Of course, if that test proves successful, it will be too
late to change from a TXT.

Of course, right now we have a long list of RR numbers that have been
allocated, but hardly ever used, and the process of getting a new RR
number allocated is far too burdensome.

Let's take an example of Cisco's IIM email anti-forgery system.
Instead of using TXT, it is using a binary format called KR.  That's
what dns-choices says to do, right?  So this is good, right?  Well,
they have used used RR type number 1010 (decimal), which isn't in the
range that RFC2929 says to use.  Ooops.  So now there are people out
there deploying 1010 RR numbers and if IIM dies, that RR number will
be polluted for many years to come.  

And how am I supposed to look to see if these KR records exists with
dig?  Maybe there is a way, but I couldn't find it.  And how is this
stuff entered or displayed?  If you think that hex is as easy to read
as text, well, why aren't you reading this as hex now?  And since the
goal of IIM is to be used everywhere that email is used, every MTA,
every box that a mail admin uses, every DNS hosting service that lets
people create RRs will need to be updated with special code to deal
with KR records in a nice way.

Of course,Cisco's IIM system is defined by an I-D published on the
IETF website so it is easy to find.  How many other systems are there
that have gone and defined some other "easily typed" RR number that we
don't know about?

Dns-choices is doing nothing but tilting at windmills.  People will
continue to use TXT RRs because they are the best solution.  The only
problem with TXT is that their space is limited, but that can be fixed
as easily as it would take to create one single other new RR type.

-wayne

--
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: 9 Jun 2005 02:17:55 -0000

>by developers that decide to use TXT and does not provide an useful

I agree that the draft is fairly badly flawed, but I completely
disagree about what the problems are.

The first 2/3 is basically fine, the discussions about all of the ways
that one might add new data to the DNS and why most of them are bad
are fine.  But then section 5 waves its hands, and makes lame
arguments against the difficulty of adding new RR types.  The reality
is that adding new RR types is hard, and the honest thing to say is
yes, it's hard, there are barriers to doing so, but they're worth the
pain.  

The claim that most DNS servers and clients handle unknown RR types
is, unfortunately, just false.  One of the things we learned during
the MARID fiasco is that for some reason our pals in Redmond defined a
DNS API with a separate call for each RR type, and no escape for RR
types not in the API.  They then have built this API into a whole lot
of computers in use all over the world, and none of those computers
can handle new RR types at all, neither serve them nor look them up.
Yes, they should fix it, but getting them to do so and to get it
shipped to all the customers won't happen overnight.

It also understates the difficulty in assigning type numbers to RRs.
I am surely not the first person to note that the number of RR types
is the same as the number of TCP ports, and to wonder why assigning RR
numbers has been so much more of a problem than assigning TCP ports.

It also needs to address the issue of how front end and back end tools
will deal with hitherto unknown RR types beyond dumping them out in
hex.  It occurs to me that proposed RR types invariably consist of
sequences of a small set of basic data types, integers of various
lengths, IP addresses, strings, and names.  I would think it would be
easy to define a template language to describe new RRs, perhaps in
XML, so to upgrade our tools to handle new types we only need to
install an updated template, not a new version of the program.  (XML
bloat doesn't matter, this XML only goes into the DNS management
applications, not into the DNS itself.)

A more honest assessment of the current problems of new RR types and
some direction about solving those problems would make this document
a whole lot more persuasive.

R's,
John

---

From: John Levine <[email-masked]>
Date: 9 Jun 2005 02:17:55 -0000

R's,
John

---

From: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 21:40:07 -0500

> yes, it's hard, there are barriers to doing so, but they're worth the

Agreed.

> shipped to all the customers won't happen overnight.

Oh, but it is worse!

They have a firewall product that apparently many people use that
blocks all port 53 queries, so that you are *locked* into using this
braindead API and can't escape even if you roll your own resolver
code.

Mind you, the folks at the MARID interim meeting were not defending
these choices in any way, and the looked more than a little
embarrassed about the situation.  However, they weren't in any
position to change things, and it didn't sound like there were any
plans to change things.

> numbers has been so much more of a problem than assigning TCP ports.

Well, there are certainly similar problems with collisions in usage,
but DNS has the extra problem that name servers and resolvers have
done special process on certain records and have to know how to deal
with new record types.  There isn't an equivalent problem with TCP
ports. 

> a whole lot more persuasive.

Yep.

-wayne

---

From: wayne <[email-masked]>
Date: Wed, 08 Jun 2005 22:27:57 -0500

>> yes, it's hard, there are barriers to doing so, but they're worth the

Oops.  I misread the last sentence.

I agree with everything that John said, except that I *don't* think it
is worth the pain.  At least not in a many cases and a very large
percentage of the cases that this dns-choices document tries to
address.

-wayne

---

From: Dean Anderson <[email-masked]>
Date: Wed, 8 Jun 2005 23:38:26 -0400 (EDT)

> yes, it's hard, there are barriers to doing so, but they're worth the

I don't think adding new RR types is too hard.  Most implementations can
handle unknown RR types properly.  I think at this point, the ones that
don't are in the realm of "implementation problems" that aren't of concern
to a standards group.  But, I would agree that adding new RRs is not a
completely trivial exercise, and should not be undertaken frivolously. 
Frivolous RR types waste limited RR type space.

> the MARID fiasco is that for some reason our pals in Redmond defined a

I don't recall this being a problem with MARID, nor have I found anything
to date that this was ever raised as a MARID problem.  I'm presently
writing a paper on MARID problems, so if you have more specifics on this
problem WRT MARID, I would greatly appreciate it if you would forward that 
to me.

Thanks,

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 8 Jun 2005 21:11:26 -0700 (PDT)

> Frivolous RR types waste limited RR type space.

Tell me what percentage of RR type space is currently in use?
Would it be 1%? Perhaps less?

We have plenty of arguably "frivolous" tcp port assignments, yet we are
nowhere close to exhausting the number of available tcp ports. DNS people 
on this list really do guard assignments of new RR types too closely.

What should be done instead is separate registration into standard and 
provisional and allow easy registration of provisional RR type (with id 
assignment just for them, listing in IANA, etc) when just the internet 
draft is present.

Then DNS group would then watch their progress and if in say 2 years
they are able to get to standard level, provisional becomes standard
(keeping number) but if they fail, the provisional registration is
removed and in another 2 years the id is available for reuse by
somebody else. Obviously after 2 years pass/fail is not the only option 
they could apply for continuance of the provisional registration for
another 2 years, etc.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Thu, 9 Jun 2005 01:22:39 -0400 (EDT)

> Would it be 1%? Perhaps less?

Less at present.  But if we created new RR's for every anti-spam email
authentication proposal I've seen, we would quickly run out of 16 bits of
space.  And we expect that space to last for a long, long time.

> on this list really do guard assignments of new RR types too closely.

Getting harder to have rational allocaton of anonymous TCP ports. Can't 
just assume all services are less than 1024, now can you. 

> assignment just for them, listing in IANA, etc) when just the internet 

Reusing RR types is a bit harder than reusing IP address space.

> they could apply for continuance of the provisional registration for

Only problem is that this creates chaos for implementations to follow.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 13:38:53 +0200

> shipped to all the customers won't happen overnight.

But you can't be considerate eternally and halt all protocol
improvements because you think that a single vendor won't feel any
market pressure.

Section 3.5 in the draft misses the registration problem.  IANA is
probably unwilling to assign RR types to experimental protocols (in
the general sense of the word, not the IETF sense).  This is the main
reason why approaches solely based on RR types aren't generic enough
as an extension mechanism.

I see two solutions to the mess: Either fix wildcards to handle
prefixes gracefully, or dynamically assign RR types on a per-domain
basis (reserve a range of RR types, and use a two-stage query scheme,
to obtain the RR number first and the actual data in a second query).

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 13:53:24 +0100

> to obtain the RR number first and the actual data in a second query).

Dumb question time, based on two questionable assumptions.

IF   one is the opinion TXT records should not be used for this
AND  one is of the opinion "fixing" (breaking? :-) ) wildcards to do this
     is not desirable
THEN you are left with a new RR type as the only solution anyway.

So, if those assumptions hold true, why would you want to invent two-stage
queries, when you can just do

$ORIGIN example.com
foo	IN	TXT2	"SPFv71"	"Here's my SPF String"
foo	IN	TXT2	"killspam3"	"Here's my other string"

IE encapsulate the type in the record itself, but not as part of
the freeform text field.

Sure you can't query by it (today) by type, but you can get all the
information back anyway, and if we wanted at some stage to query
by 4-tuple rather than 3-tuple, it would be obvious how to do it.

Alex

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 15:05:56 +0200

> THEN you are left with a new RR type as the only solution anyway.

Seems reasonable, but as I wrote, I don't think the new RR type route
is a real solution, unless assignment is handled more liberally (which
is difficult because there are just 2**16 types).

> by 4-tuple rather than 3-tuple, it would be obvious how to do it.

I'm not sure how such a transition would interact with DNSSEC.

Just for clarity, I would propose something like this:

foo	IN	RTYPE		("SPFv71", 1025) ("killspam3", 1026)
foo     IN      TYPE1025	"Here's my SPF String"
foo     IN      TYPE1026	"Here's my other string"

(Everything is crammed into one RTYPE to cut down the protocol
overhead.  Another level of indirection (ahem) could be used to
increase caching.)

A client would request the RTYPE record, search for the corresponding
RR type, and request that RR type.  As a result, it wouldn't be bogged
down by large RRsets of a kind it's not interested in.  There's a
slight synchronization problem (you've to be careful when reusing
dynamic type numbers), but it doesn't look too bad.

IANA could liberally assign the indification strings because they
aren't a scarce resource.

---

From: wayne <[email-masked]>
Date: Thu, 09 Jun 2005 08:26:48 -0500

> I'm not sure how such a transition would interact with DNSSEC.

Yeah, I'm not sure how this would work either and I'm interested in
learning the answer.  At one time, I pondered the idea of using an
EDNS0-type extension system to allow for a *small* magic number
selector to be sent with the query in order to limit the number of TXT
records that are returned.  I think this would also cause problems
with conflicting TTLs.

> overhead.  Another level of indirection (ahem) could be used to

What happens if the list of mapped dynamic RR types exceeds the size
of a 512 byte UDP packet?

-wayne

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 15:42:31 +0200

> of a 512 byte UDP packet?

Fallback to TCP, as usual.  This doesn't seem to be too likely in
practice.  You can include more than ten identifiers before it
happens.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 09 Jun 2005 13:55:12 +0000

> foo     IN      TYPE1026	"Here's my other string"

yow!  lack of subclassing bites us again.  we need a new kind of
wildcard, for nonterminal matching.  but the above is a reasonable
pave-over for this pothole, until the protocol catches up someday.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 14:59:25 +0100

Florian,

> is difficult because there are just 2**16 types).

Indeed. So for clarification, my straw man proposal is, rather than to
invent 2 stage queries, or assign lots of new RR-Types, to assign a single
new RR-Type, the first field of which is (if you like) a sub-type.

>> So, if those assumptions hold true, why would you want to invent
>> two-stage queries, when you can just do
>>
>> $ORIGIN example.com

The 4-tuple query? Oh neither am I. No idea how it would interact
with anything. But it works on a 3-tuple query model too, which has
no adverse interactions.

> aren't a scarce resource.

Understand. Why (other than minimizing size of responses where
multiple things are present) do you need to have different RRTYPEs
for "SPF" and "other string" if this wasn't necessary with a
TXT-type solution (i.e. have 2 records of the same RRTYPE instead).

Again, possibly a dumb question.

> of a 512 byte UDP packet?

Wasn't this thrashed out in the more general case in EDNSO et al?
If you are saying "what about broken resolvers, broken firewalls,
broken servers etc. that don't support larger responses
(e.g. by falling back to TCP" then that type of broken stuff is
equally likely to be broken for any new RR type anyway, and encoding
in TXT records (all of which will be returned for one 3-tuple query)
is not going to be any more compact. IE it's no more broken either
in Florian's proposal or my straw man than any other way around it.

Alex

---

From: Florian Weimer <[email-masked]>
Date: Thu, 09 Jun 2005 16:08:13 +0200

> TXT-type solution (i.e. have 2 records of the same RRTYPE instead).

My two-stage proposal is entirely driven by a desire to minimize
response size.  In particular, it's possible to treat each record type
separately if your goal is the 512 byte packet size limit.

If TCP fallback isn't a practical problem, the simplicity of your
proposal clearly wins.  Unfortunately, I lack the kind of operational
experience necessary to make an informed judgment on the TCP fallback
question.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 09 Jun 2005 15:15:30 +0100

> experience necessary to make an informed judgment on the TCP fallback

So we would some real world data to tell us whether the set of resolvers
and middleboxen that break large answers is largely a subset of the
set of resolvers and middleboxen that choke on new RR-Types (because
if they choke on new RR-Types such as either yours or mine then whether
they choke on large queries is irrelevant).

My guess (uninformed by any actual data) is that the latter set (don't
support new RR-Types) is much larger, especially given the "helpful"
nature of many firewalls.

Research opportunity for someone.

Alex

---

From: "John L" <[email-masked]>
Date: 9 Jun 2005 10:47:38 -0400

> nature of many firewalls.

My understanding is that most Microsoft DNS software handles EDNS0, so big 
responses are less of a problem than new RR types.  The question about 
firewalls is a good one, both industrial sized ones and the little ones 
that every DSL customer has in their $30 router.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "John R Levine" <[email-masked]>
Date: 9 Jun 2005 10:53:46 -0400

>> is, unfortunately, just false. ...
> 

Quite true, but on the other hand, if you build software that half your 
users can't use, you're not going to get much traction.

> to obtain the RR number first and the actual data in a second query).

We don't need dynamic RR types, there's plenty of them.  We need to 
drastically lower the bar to assigning RR types.  It's a 16 bit field, if 
they handed out a thousand numbers of which only two turned out to be 
useful, it wouldn't be a big deal, it's less than 2% of the address space. 
It might also be good to designate some chunk of the RR space as the 
experimental range where numbers will never be assigned so people can 
safely fool around with private types there.

Well, except for the problem of getting DNS software to support new types. 
To date, there's been an unspoken assumption that new RR's will be rare 
enough that DNS software developers can just hand-code support for new 
types and ship updates, leading to another unfortunate circle of no new 
types. Something like my XML proposal to make new types a table update 
rather than a software upgrade oughta help there.

I also agree with Vix that embedded wildcards would be a way out of this 
mess, but I perceive a strong sentiment in the DNS community that the 
current wildcards are just fine and the only problem is that people don't 
understand them, so I'm not holding my breath.

Regards,

---

From: David MacQuigg <[email-masked]>
Date: Thu, 09 Jun 2005 09:03:24 -0700

At 07:58 PM 6/8/2005 -0500, wayne wrote:

<...>

>of RR numbers sitting totally unused.

This seems like a halfway step, like the old DOS database I used in the 
late 80's to run my business.  It had a scripting language, but no 
variables!!  After enough users screamed, they gave us a small number of 
variables with fixed names, like the above.  It seems very odd that the 
design of DNS allowed records to have a "class" attribute, but not a much 
more useful "name" attribute.  I don't like forcing the "type" attribute to 
serve as a "name".

My current plans are to prepend the necessary record names to the domain 
name, like CSV is doing with _client._smtp.<domain>.  TXT type is adequate 
for anything I will need.  As I understand it, the only problem is that I 
can't use wildcards at the same time.  So I can't have 
_client._smtp.*.<domain>.  That is a limitation I can live with, but 
something that might be nice for a future extension of DNS.

<...>

>The only

Sorry for a dumb question, but what will it take to raise the 512-byte 
limit, without a fallback to TCP, which would negate the UDP speed 
advantage, and make me want to use the more versatile HTTP for general 
queries?  Even if we had to wait 10 years for some old machines to die, it 
would be a nice improvement in DNS.  Meanwhile, we can continue to use 
multiple queries to linked records for anything over 512 bytes, and when 
the Internet is ready, make a smooth transition to a single, more 
streamlined record.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

---

From: Dean Anderson <[email-masked]>
Date: Fri, 10 Jun 2005 17:25:35 -0400 (EDT)

Umm. This seems like a lot of work for no good reason.  MARID failed for 
15 reasons, none of which was the problem with adding a new RR type.

SPF doesn't acheive its goals of stopping spam and creates more problems 
and more opportunities for abuse. I count so far 15 significant problems 
raised for SPF:

1.Abuser can still forge addresses at domain
2.Abuser can use stolen credential
3.DNS cache problems (more records per domain, same cache size)
4.DNS load (more records per domain)
5.Ongoing Maintenance issues
6.Migration issues
7.IP Renumbering issues
8.Lost non-spam emails
9.Lack of universal compliance.*
10.Not a basis for trust/reduced filtering
11.Makes forgery blowback problem much worse
12.Patent issues
13.spam-profiteering / charges for SPF services
14.Email Source Routing 
15.Outbound SMTP Relay Identification

I think if we have genuine need for a new RRtype, it can be accomodated.  
However, MARID wasn't a genuine need.

		--Dean

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 10 Jun 2005 15:13:33 -0700 (PDT)

> However, MARID wasn't a genuine need.

Dean,

I'm not going to go though your arguments, but from what I see the
issue is that DNSEXT is not assigning new RR types in without very very
substantial review and that creates other problems like that that 
proposals like SPF begin to use TXT as basis and then this may become 
widely used on the net.

It should not be for DNSEXT people to decide if concept itself is bad or 
good and argue about it here, you should focus on providing stability for 
dns system and let others run experiments that use dns for specific
applications and if experiment turns out to be usefull the requested RR 
assignment becomes permanent.

But trying to shut down (or not letting it start) the experiment by not 
getting it RR is just wrong and exactly why proposals like SPF or DK 
which attempt to use TXT RR instead of getting new one from the start.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Fri, 10 Jun 2005 17:33:42 -0500

> 2.Abuser can use stolen credential

These are out of scope for this list.

> 3.DNS cache problems (more records per domain, same cache size)

This is a choice that receivers can decide on.  If they don't think
the additional DNS cache is worth it, then don't use SPF checks.

> 4.DNS load (more records per domain)

This, indeed, is a problem that I wish didn't exist.  Domain owners
that don't want to deal with SPF will still receive DNS queries.  The
only thing I can suggest is to publish an SPF record that has a very
long TTL which says "v=spf1 ?all".

For domain owners that do want to publish SPF records, then that is
their choice to have more records.

> 5.Ongoing Maintenance issues

Again, this is up to the domain owners who choose to publish SPF
records.  SPF does have quite a few features that make these less of
an issue, at the expense of increased DNS loads.  The choice is up
tothe domain owner.

> 15.Outbound SMTP Relay Identification

These are out of scope for this list.

The things that are in scope for this list are reasons why I have
twice, without being asked, asked for reviews of the SPF I-D here.  If
it was up to the IESG, no review would have been done here.

-wayne

---

From: Dean Anderson <[email-masked]>
Date: Mon, 13 Jun 2005 15:40:33 -0400 (EDT)

> These are out of scope for this list.

No, actually, they aren't. A protocol that doesn't work isn't suitable for 
standardization.

But there is little point to arguing the details of why SPF doesn't work, 
now.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 13 Jun 2005 15:38:58 -0400 (EDT)

> but from what I see the issue is that DNSEXT is not assigning new RR
> types in without very very substantial review and that creates other
> problems like that that proposals like SPF begin to use TXT as basis and
> then this may become widely used on the net.

It is supposed to be IETF policy not to standardize hypothetical
protocols. That is, there should be working code. It should be tested and
proven to work as documented.

I think the problem here is methodology. The SPF folks came in and said,
essentially, "standardize and deploy this new protocol without any proof
that it works. Its too urgent to actually test before deployment."  But,
it didn't work, and they didn't get their standards, and they've been mad
ever since, claiming the IETF is irrelevant.

I don't see any problem with developing new RRtypes, showing that the
protocols work and perform some useful service, and then getting standard
RRtype codes. 

> assignment becomes permanent.

Experiments don't require standard codes.  The SPF folks didn't do any
real experiments. SPF was "too urgent" for such "nonsense".

> which attempt to use TXT RR instead of getting new one from the start.

No experiments were shutdown. Only production deployment was affected. 
Those are different matters, entirely.

Indeed, SPF supporters are currently asking sites to enter production SPF
TXT records, without telling those sites that they are participating in an
experiment. I've already suggested that this is misleading. The SPF
promoters are unconcerned and unfettered by ethical standards for
experimentation.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 10 Jun 2005 09:49:40 -0400

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

> be polluted for many years to come.

What is the difference between this and pullute by having used  
TXT4711 for the same thing?

    paf

---

From: wayne <[email-masked]>
Date: Wed, 15 Jun 2005 10:32:57 -0500

> TXT4711 for the same thing?

The TXT4711 would hopefully have a magic number to allow us to
distinguish the different uses of the same RR number.  Right now, if
we assign RR number 1010 to someone else, and you get a query, you
have a binary glob that may or may not be the IIM KR record.

Ok, we can probably tell KR records from the other records by looking
at the size of the record and the format of the data.  But, that is
just a "really bad magic number".

-wayne