At 03:29 PM 12/6/2006, Olaf M. Kolkman wrote:
>Anyway, this all boils down to the blunt question: Should we flush
>all DNSSEC-bis work and put our bet on SO?

Um... no - and I hope no one thought I was recommending this.

(And isn't DNSSEC 4033-35 + NSEC3 DNSSECtris? :-) )

SO builds on PNE DNSSEC. The deployment model *is* different though
and may be more attractive to both some zones and some end-users. SO
can use PNE signed zones and trust anchors. In some ways SO could be
considered more as competition for NSEC3 than for PNE (as described
in 4033-4035).

PNE does provide specific functionality that SO does not - I don't
dispute that. If 4033-35 had been the end of it and fielding had
commenced, SO wouldn't have been written for years if ever. But we
have NSEC3, we have the issues for trust anchor rollover and we have
the general issues with how to deploy a given trust anchor in the
first place as still outstanding issues. I expect as PNE is fielded
more things will crop up - it's the nature of the beast. Some of
these may be show stoppers - I would hope not, but blind faith that
there will be only good outcomes is not really a good engineering principle.

In the meantime, SO may be a viable alternative for application
developers and service providers that don't at this time see a
requirement for PNE and do see a possible benefit from signed DNS
data. If PNE does end up getting deployed widely, an SO zone can
be converted into a PNE zone rather quickly - as can an SO-aware
application be converted into a PNE aware one. It's even possible
that SO-aware applications might encourage the deployment of PNE zones.

For PNE vs SO - most of the development work is at the application
rather than the server - and that work has generally been lacking
while the IETF tries to get the server side correct. Anybody who
wants to use SO is going to have to think about application use of
signed data. Once you do this, adapting an SO application to PNE
status is relatively simple.

In any event, I wouldn't at this time recommend stopping further
development on PNE related DNSSEC items - but ask me again in 2 years. :-)


to unsubscribe send a message to with
the word 'unsubscribe' in a single line as the message text body.