> -----Original Message-----
> From: Ted Hardie [mailto:hardie@qualcomm.com]
> Using a code from the "private use" range for SPF might have been
> a bit of stretch, but "specification required" would have
> been possible
> with far less of a barrier than a two-year consensus process.

If we are talking about anything less than a two year consensus
process then the text should not be talking about protecting the
DNS from maluse or baddly thought out proposals since that is
not going to be addressed by the process.

If that claim is going to be raised at all it should be
substantiated with empirical evidence rather than introduced
for the first time in one of the conclusions sections. We
already have an example of a record that has deliberately set
to evade the review process.

I beleive that if the data is fairly interpreted then the only
significant difference between prefixes and new RRs is the
extent of the review process. It is a logically consistent,
albeit naive, point of view that the review process might save
the DNS from a destructive record definition. But this point of
view is not consistent with RRs being readily available.


If the 'specification only' RRs are in fact issued then there
will be a new problem, nobody will ever want to use a standards
process RR again unless there is an inescapable loss of backwards
compatibililty anyway. Since the proposals will start with a
specification only number and have no incentive ever to change.


Rather than fixating on the MARID and MASS proposals as a means
of deploying DNSEXT there are far more effective means available.

For example, lets try to address the problem of DNS spoofing
without insisting on resort to crypto. All that is really needed
is a somewhat longer response cookie. So we create a DNS query
that is defined to result in the query data being returned.
Everyone who deploys MASS and MARID is going to want that capability
to talk to accreditation services.

The value of DNSSEC is going to come in authenticating policy
publication, in particular security policy such as MASS, MARID
and others to come in the future.


Phill

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: