Subject: RE: DNSEXT WGLC: RFC2929bis

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 28 Oct 2006 17:09:01 -0400

Hi Ed,

The consensus of the CLASS-dependent versus cross CLASS RR distinction,
although based on a small number of responses, seems to be clearly on
your side. Also, the rate of RR and CLASS allocations are such that it
probably does not cause any significant harm to just treat all RR
allocations as if they were cross CLASS.

So I withdraw my suggestion to make this additional distinction.

Donald

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 8:18 AM
To: Eastlake III Donald-LDE008
Cc: Edward Lewis; [email-masked]
Subject: RE: DNSEXT WGLC: RFC2929bis

At 16:27 -0400 8/18/06, Eastlake III Donald-LDE008 wrote:

>### If you are asking about interest in general, the only recent spurt 
>I can think of off hand related to internationalization.

To those who followed that effort - using a separate class for non-ASCII
names is pretty much dead, right?

>### I never claimed this proposed change was terribly important but 
>unless we are going to rewrite the fundamentals of DNS, why not take 
>them into account? The provisions I'm talking about affect allocation

Why not - because taking time to define rules and solutions to problems
that don't exist is a waste of time.

>### (continued from above)
>which is exactly the topic of 2929bis. If they were adopted, things 
>would be fine if someone did get a CLASS allocation and wanted to use 
>it for their own thing. If we don't adopt this simple change and 
>someone gets a CLASS allocation, you would probably end up having to 
>update 2929bis.

There's a point when you begin throwing good money after bad.  I think
the CLASS concept has proven to be bad money.  Perhaps it had a good
intent, but a pragmatic look says it has failed.

>several ways you can have your own root servers." But CLASS is the 
>intended way to have your own tree completely under the control of your

>own root while still having access to the generally accepted IN tree.

It's not that you can't do this, it's that no one does it.  If the IETF
is to avoid becoming "irrelevant" then we need to keep in mind how the
protocols are being used vs. what they were designed to do in the 80's
and 90's.

My point being, backing up to 2929bis, is that we are over-engineering a
task we  wish to make a simple bureaucratic step. 
This is a case of trying to solve a problem that just doesn't exist in
nature.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-
Edward Lewis
+1-571-434-5468
NeuStar

--
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: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 28 Oct 2006 18:41:04 -0400

Hi Ed, 

See below at %%%

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 8:45 AM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: RE: DNSEXT WGLC: RFC2929bis

At 17:35 -0400 8/18/06, Eastlake III Donald-LDE008 wrote:

>### I don't think there is much similarity. Although there are (nice) 
>people involved, so a finite error rate is only to be expected, the 
>whole idea of IANA Considerations is to make the decisions required of 
>IANA to be mechanistic, objective choices. That is certainly amenable 
>to engineering and has nothing to do with legal issues which changes 
>with the constantly shifting human judgment of judges.

My point is not that there's a legal element to this.  My point is that
engineers are as bad at bureaucracy as they are bad at legal matters.

%%% My point wasn't exactly intended to be that you said there was a
legal element, it's that you are insisting it is a "bureaucracy" that is
supposed to make human judgments. But it is not. IANA allocations are
supposed to be mechanistic, not judgmental. Hopefully the IETF is
reasonably good at unambiguously specifying mechanistic processes such
as protocols. IANA shouldn't ever have to do anything worthy of the name
analysis, that's for the IETF via working groups, the IESG, and
Designated Experts. IANA should be able to mechanically and
unambiguously follow the allocation process given in IANA Considerations
sections requests.

>### If things are set up properly (properly "engineered") it should 
>make little different to IANA how many categories of RRTYPEs there are 
>unless IANA has to do some analysis, ...

Cross-my-eyes and furrowing-my-brow...if there was just one bin for all
requests, there isn't room for analysis.  If we create bins to take away
the need for analysis, then the bureaucracy has to analyze the request
to know where to bin it.

%%% Aren't you exaggerating a bit? I didn't claim that the situation was
identical no matter how many categories there are. I said that if you
make the IANA process as mechanical as possible, so that it doesn't make
any sense to call it "analysis", then the number of categories makes
"little difference" not zero difference. Surely you admit that IANA has
to at least read and understand the text in an ID enough to determine,
say, that it is an RR Type Code you are seeking to allocate, rather than
an RCODE or something else? Well, if, for example, we write the
allocation rules such that for all future RR Type Code allocations the
IANA Considerations section in the ID must say either "data-RR Type
code" or "meta-RR Type Code" and that anything else that looks like it
might be an RR Type Code but is not clear on this point is to be bounced
back as an error by IANA with no allocation made, I just don't see why
there should be any particular difficulty on this point.

When you go to an old time DVD store, do you look for "The Blues
Brothers" in the musical or comedy section?  It's easier if the store
just lines the titles up alphabetically.

%%% The situation isn't the same. It's more like going to a store and
wanting to buy a either an audio CD or a 33 rpm vinyl LP. You won't
expect them to be mixed.

>### I do not see how that follows. So there was one case where giving a

>meta-RR a number from the data-RR range did not cause a problem. Why

I see a score of "The type value doesn't matter" of 1, "the type value
is does matter" of 0.  Is the stratification of type codes a solution to
an artificial problem?

%%% A sample size of 1 seems pretty small to me. I have described how it
is a real problem.

>does this imply that it is just fine to make it inherently impossible 
>for future DNS software to tell whether an unknown RR is a data RR 
>which should be cached or a non-data RR which shouldn't?  Among other 
>things, OPT overloads the CLASS field with the sender's UDP payload 
>size limit and is supposed to always have root as the owner name, so 
>even if it were cached, it seems very unlikely to cause problems. Who 
>knows what owner name or other characteristic future unknown meta-RRs
will have?

Why tie the RR type code to caching?  If you want a record to not be
cached, use the TTL field (set it to 0,1,5, whatever).  That's another
matter, but this same question came to me in another media too.  Even in
this case, there are a bunch of other ways to stop this record from
being cached.  (For instance, its RFC2181 trustworthiness is low.)

%%% There are at least three problems with "just use TTL":
%%% (1) OPT overloads TTL. Who knows how future meta-RRs will overload
TTL?
%%% (2) I was using "caching" as a simplification. Setting TTL to zero
(which it is not clear to me how you would guarantee) would stop
"caching" but the RR can still be used to answer a recursive question.
Thus the meta-RR would, depending on various factors, be blindly copied
by a recursive server that didn't understand it into an answer sent to a
resolver which did understand it, which could have very bad effects.
%%% (3) The interval of RR numbers from 128 to 255 is already assumed by
some resolvers to be reserved for non-data RRs. Thus it is already
implemented and deployed, to some extent, to tie RR type code to whether
an RR is data or meta.

%%% Thanks,
%%% Donald

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 28 Oct 2006 19:15:43 -0400

See below at @@@ 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Weiler
Sent: Saturday, August 26, 2006 12:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: DNSEXT WGLC: RFC2929bis

Summary: I do NOT support the publication of this document in its
present form.

...

It's probably unwise to specify the namedroppers list in Sections
3.1.1 and 3.1.3, since lists occasionally change.  Instead say: "The
DNSSEXT WG mailing list, or another mailing list designated by the IESG.
Currently, this list is ..."

@@@ I believe it is flat out prohibited to specify a working group, as
they are deemed inherently temporary. I really don't see what's wrong
with specifying the [email-masked] mailing list. It is hosted
under ietf.org. If DNSEXT is terminated, it does not seem like there
would be any problem in namedroppers continuing. If some new DNSEXT2 WG
were formed and, for some reason, decided to use a new mailing list, the
RR Type allocation mailing list could still remain namedroppers. I
suppose it might be reasonable to make up a brand new permanent
DNS-RR-Types@???.ietf.org mailing list if someone wanted but I don't
think it makes much sense to be vague about it in 2929bis and throw the
burden on the applicant.

Seceral sections (3.1.5, 3.2) use "IETF Consensus" as an allocation
metric.  That term is deprecated in 2434bis and should be replaced.

@@@ Good idea. Should be replaced with "IETF Review" as suggested in
2434bis.

As Thierry Moreau noted: In section 3.1, sentence starting with "Thus
far ...", is missing reference to DLV and TA assignments.  Similarly,
those codepoints need to be excluded from the meta range (and it should
be explicitly called out in the breakdown of the space that these are
normal data types, not "meta types...which it is safe to simply
discard").

@@@ Yes, this should be fixed re the recent excepts in this range.
(However, 2929bis does not require all meta-types in the relevant range
to be "safe to simply discard". If they are not so safe, they just have
to be allocated by a Standard Action instead of by approval of the
Designated Expert.)

Section 3.1.1 item 2: "(b) a Meta TYPE who processing is optional, i.e.,
which it is safe to simply discard.".  First, there's the odd 'who'.
Second, is 'discarding' really the right answer when a recursive
resolver gets a meta type query?

@@@ "who" -> "whose".
@@@ If you are asking about what to do when you get an unknown non-data
type as the type being queried for, then I guess you are right.
Returning an error seems like the right thing to do. What I was
referring to is what to do when you get an RR with an unknown but
known-to-be-non-data type. The allocation rules in the current 2929bis
draft say that for such a non-data type to be sufficiently innocuous to
be allocated based on Designated Expert approval, it must be safe to
drop such RRs, whether they occur in queries or responses. 

-- Sam

@@@ Thanks,
@@@ Donald