Subject: Re: [EAI] Email and new RRTYPES (was: Re: Fw: I-D Action: draft-yao-eai-dns-00.txt)

From: John C Klensin <[email-masked]>
Date: Wed, 07 Mar 2012 14:59:04 -0500

Hi.
As Ned and others have suggested, let's move this discussion to
the IETF list, where the real action on the subject is occurring
(I know I haven't posted there yet, but that is temporary :-) ).

An observation or two inline below...

--On Wednesday, March 07, 2012 13:53 +0000 Tony Finch
<[email-masked]> wrote:

>...
> Sadly there are a few RR types which are a bit more
> complicated, and not all of them can be ignored. LOC, APL,
> IPSECKEY, HIP.

The model I had in mind was quite different from what John came
up with, largely because I was looking for an abstraction that
could accommodate any plausible future type while John based his
approach on examination of existing types and extrapolating.
Inserting one of the usual observations about the difference
between theory and practice here, John's approach is probably
better.

But I think we should recognize that such a description language
could also be immensely useful as a brake on complexity: if we
have a language that covers all of the reasonable cases, then,
if someone comes along with something so complex that it cannot
reasonably be described, then those who propose it have to
accept the costs of slow deployment.  I rather like that
tradeoff as an element of the design process.

> I would quite like to be able to use John's language to be
> able to translate back and forth between wire format and
> master file format for all RR types including the baroque
> DNSSEC ones - though that will need some type-specific code -
> as well as being able to auto-generate a user interface for
> the simple cases and future types.

Seems like a good idea in principle but the best may be the
enemy of the good.  Remember that, for any of this to be useful
in solving the "slow deployment" problem, people have to be
willing to install/ deploy a DNS software package version that
incorporates John's language and the needed interpreter.  The
experiences Ned and I have been talking about don't suggest that
will be easy.  For the subset of cases in which the question is
"what will this do for me and what might it do to me", I'd much
rather be able to explain it in terms of affecting new RRTYPEs
and only new RRTYPEs, rather than changing how existing types
are handled in the code.  In many cases, it will make no
difference and we will just need to wait.  However, in others,
contained risk is a fairly powerful argument that we should not
give up lightly.

>> Exactly the intent here. I suggested adding a type that would
>> allow either an IPv4 or an IPv6 address; John Levine pushed
>> back on it, saying that no existing type uses such a
>> mechanism and he wants to limit this to tried and true data
>> and presentation formats, in part to be able to make a
>> legitimate claim to minimal risk.
> 
> IPSECKEY RRs are a counterexample. Really it should have been
> three RR types, sigh.

And, while there are arguments against using multiple interlaced
RR types for the same general function (I'll leave explanations
to others, probably on the IETF list), that case may sort of
prove my argument for a slightly less rich description language
that makes it easier to identify and push back on complexity.

    john

---

From: SM <[email-masked]>
Date: Wed, 07 Mar 2012 12:20:33 -0800

Hi John,
>(I know I haven't posted there yet, but that is temporary :-) ).

I am not optimistic about whether there will be a meaningful 
conclusion to the real action.

>incorporates John's language and the needed interpreter.  The

There will be a "slow deployment" problem in deploying the solution 
to the "slow deployment" problem. :-)  BTW, there has been 
discussions about this topic on four IETF mailing lists.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Mar 2012 18:17:37 -0500

--On Wednesday, March 07, 2012 12:20 -0800 SM <[email-masked]>
wrote:

>> As Ned and others have suggested, let's move this discussion
>> to the IETF list, where the real action on the subject is
>> occurring (I know I haven't posted there yet, but that is
>> temporary :-) ).
> 

I'm not either.  If a meaningful conclusion required IETF
consensus, I would be even less optimistic.  However, getting
the contrast between strategies and a well-thought-out
alternative on the table has benefits in itself.  Perhaps
equally important, if one adopts a lightweight view of the
description language and interpreter issue (rather than the more
comprehensive approach that Tony suggested), no standardization
would be required because whether a new type is implemented by
table or code modification and recompilation or by putting a
rule into a configuration file is an implementation detail that
does not change the RRTYPE itself.  It would take changes to a
_very_ small number of implementations to make the
interpretation model available to a rather large fraction of the
servers on the Internet.  Now it wouldn't take many of the
people to whose attitude several of us have been objecting to
prevent those implementations from happening, but that is a
rather different problem.

>> enemy of the good.  Remember that, for any of this to be
>> useful in solving the "slow deployment" problem, people have
>> to be willing to install/ deploy a DNS software package
>> version that incorporates John's language and the needed
>> interpreter.  The
> 
> There will be a "slow deployment" problem in deploying the
> solution to the "slow deployment" problem. :-)

Sure.  But that solution needs to be deployed only once, rather
than once per time someone proposes a new RRTYPE.

>  BTW, there has
> been discussions about this topic on four IETF mailing lists.

Yes.  And so?

best,
   john

---

From: SM <[email-masked]>
Date: Wed, 07 Mar 2012 16:19:15 -0800

Hi John,
>alternative on the table has benefits in itself.  Perhaps

It might help if there was a draft discussing about the different strategies.

>rule into a configuration file is an implementation detail that

There is an argument for having it as a rule in a configuration file 
instead of hard coding.

>rather different problem.

It is going to take years for the changes to find its way into the 
servers out there.  However, if we do not start somewhere, it is 
improbable that things will change.  At the end of the day, it is 
about providing the incentive to make it happen.

>Yes.  And so?

It's unusual to see the same topic discussed on several mailing lists 
at the same time when it is not a cross-post.

Regards,
-sm

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Mar 2012 11:52:10 +0000

> tradeoff as an element of the design process.

I very much agree!

> contained risk is a fairly powerful argument that we should not

I think you are right.

> that makes it easier to identify and push back on complexity.

I'll just mention A and AAAA :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet, Irish Sea: West backing southwest 4 or 5, increasing 6
at times. Very rough or high in Sole and southwest Fastnet, otherwise moderate
or rough. Fair then occasional rain or drizzle. Moderate or good.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 07:03:22 -0500

> It might help if there was a draft discussing about the

Maybe.  I don't have time to do anything about that.  I believe
that substantially all of the issues and strategies have been
described in notes to this list in the last week or two.  If
someone wanted to draw those comments together into an I-D, I
think all of us who have contributed perspectives would be happy
with lavish acknowledgments :-)

I personally suspect that this problem is going to get solved,
if at all, by an implementation or two taking the initiative,
producing running code, and thereby putting competitive pressure
on the other implementations to do something.
 
>> description language and interpreter issue (rather than the
>> more comprehensive approach that Tony suggested), no
>> standardization would be required because whether a new type
>> is implemented by table or code modification and
>> recompilation or by putting a rule into a configuration file
>> is an implementation detail that

> There is an argument for having it as a rule in a
> configuration file instead of hard coding.

Yes.  And that argument has now been made several times on this
list alone.  See above.

>> interpretation model available to a rather large fraction of
>> the servers on the Internet.  Now it wouldn't take many of the
 
> It is going to take years for the changes to find its way into
> the servers out there.  However, if we do not start somewhere,
> it is improbable that things will change.  At the end of the
> day, it is about providing the incentive to make it happen.

Any decision to deploy a new version of DNS server software
(like just about anything else) is either made as a side-effect
of operating system software upgrades (i.e., without the DNS
changes being the major consideration) or is made by considering
the tradeoffs between incentive (benefits), disruption risk, and
costs and other priorities.  In that context, some of the
comments Ned and I have been making amount to organization
perceptions that the risks of disruption are a cost and the
costs and risk of cost are perceived as huge.   Thinking about
that as incentive alone is a sort of "if you build it, they will
come" argument, which rarely works in practice.  The balance is
especially relevant, and likely to be especially unfavorable, if
the driver is a handful of RRTYPEs that are relevant only to a
few sub-applications, especially if those sub-applications are
as disliked in some quarters as they are favored in others (SPF
is a perfect example of that part of the problem).

>> Yes.  And so?
> 
> It's unusual to see the same topic discussed on several
> mailing lists at the same time when it is not a cross-post.

Yes.  Under normal circumstances, it would be the job of some
responsible AD to notice that and try to draw things together,
perhaps by organizing the I-D that is hypothesized above.   I
haven't noticed that happening, but perhaps that identifies
where the point should be made.

    john

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Mar 2012 12:07:49 +0000

John C Klensin <[email-masked]> wrote:

> Perhaps equally important, if one adopts a lightweight view of the
> comprehensive approach that Tony suggested), no standardization would be
> required because whether a new type is implemented by table or code
> modification and recompilation or by putting a rule into a configuration
> file is an implementation detail that does not change the RRTYPE itself.
> It would take changes to a _very_ small number of implementations to
> make the interpretation model available to a rather large fraction of
> the servers on the Internet.

It's the user interfaces that need better support for new RR types much
more than the servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay: Easterly or northeasterly 3 or 4, increasing 5 or 6 in
southwest. Rough or very rough. Fair. Good.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 07:19:55 -0500

--On Thursday, March 08, 2012 12:07 +0000 Tony Finch
<[email-masked]> wrote:

>> Perhaps equally important, if one adopts a lightweight view
>> of the description language and interpreter issue (rather
>> than the more comprehensive approach that Tony suggested), no
>> is an implementation detail that does not change the RRTYPE
>> itself. It would take changes to a _very_ small number of
>> implementations to make the interpretation model available to
>> a rather large fraction of the servers on the Internet.
> 
> It's the user interfaces that need better support for new RR
> types much more than the servers.

Absolutely.  But it is hard to think about how to change the
user interfaces without the server support.  At the risk of
starting another subthread, note the difference between this and
ICANN's plans to deploy hundreds (or more) new TLDs in the
relatively near future.  Whatever the UIs decide to do about
them (checking, display, adjustment to DNS completion,...) there
is no evidence yet that any DNS server changes are needed.
However one intends to support new RRTYPEs, it is going to
require DNS server changes to either code those in, compile them
in, or interpret them from tables.  So, on a critical path
basis,...

    john

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Mar 2012 12:51:04 +0000

John C Klensin <[email-masked]> wrote:

> user interfaces without the server support.

If the user interface can translate a new RR into either wire format (if
it talks to the back end using DNS QUERY and UPDATE messages) or into
TYPEnnn format (for master files) or some proprietary RDATA blob format,
then no special server support is necessary, provided it conforms to RFC
3597 (handling of unknown RR types).

I don't mean to argue that server support for John's language is
unimportant, just that it isn't a prerequisite.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North FitzRoy: Variable 4 in east at first, otherwise southerly 4 or 5. Very
rough or high. Mainly fair. Moderate or good.