Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Nov 2005 19:00:43 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Volz (volz)

> This technique has been in use for years by implementations 
> using TXT records because we've been unable to get the DHCID 
> RR approved.

OK so why are you proposing a new protocol rather than writing a
description of the protocols that are already in use?

Correctly prefixed TXT records work just as well as new RRs and are
completely compatible with the deployed infrastructure. If you attempt
to cut new DNS RRs you will hit the problem that your proposal is now
dependent on deployment of a new infrastructure which has no deployment
strategy.

Lets get back to the idea that a standard is a description of running
code. The DNS group has become a bottleneck for deployment of a lot of
technology. This should not be acceptable. There is a fundamental
extensibility flaw in DNS, new RRs must be understood by the sender,
receiver and intermediate infrastructure.

The DNSEXT group appears to believe that their objectives should be to
create as much of an incentive to upgrade to DNSSEC capable
infrastructure as possible and that the way to do this is to gate all
proposed uses of the DNS on cutting a new RR.

This is not a good strategy, DNSSEC is a double ended adoption problem,
the problem is not that the promise of DNSSEC is insufficient incentive
for deployment, the problem is that early adopter deployment of DNSSEC
has negligible incentive.

The Pareto optimal solution here is for the IAB to specify a method of
introducing new features that use the DNS that is entirely compatible
with deployed DNS infrastructure. These in turn create new dependencies
on the DNS that create a near term demand for DNSSEC and an early
adopter incentive. The DNSSEC people get an early adopter market for
their proposal, people looking to extend the DNS can do so without
committing error 33. 

For example one of the discussions in DKIM is on what to do with the
ESTG vehicle set up for early development. The idea that most people
seem to think is a good one is to turn it into a branding vehicle
similar to WiFi. So that just as people advertise that their product is
WiFi compatible to mean 'yes it really works' there would be an ESTG
brand that a registrar could use to say 'yes I do provide the services
necessary to support DKIM signed email'. This then leads naturally to
the question of levels of support, a level 1 registrar might do the bare
minimum necessary to support DKIM (allow the relevant records to be
defined), the requirements for level 2 might well include support for
DNSSEC (at least I would argue that they should require DNSSEC support).

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf