On 8.4.2014 18:02, Joe Abley wrote:
On 8 Apr 2014, at 11:01, Edward Lewis <[email protected]> wrote:
But isn’t that example (below) a new API? ;)
I wasn't reacting to the newness of the API, but rather the dual approaches of
(a) provide a new DNS API for applications, or (b) leave applications using the
existing/archaic API for name resolution, and introduce an additional API that
characterises the security characteristics of their use.
Amongst the problems with (b) is the lack of fine-grained (e.g.
DNSSEC-specific) message passing to the application, so that it can react to
the various failure modes in a manner that allows users to be informed and the
application generally to make good choices.
I should clarify that the proposal sent to dane-list is just a temporary
solution. *It doesn't prevent us from inventing a completely new shiny API.*
The purpose of the proposal is to ease transition from non-DNSSEC aware
applications/security models to DNSSEC-aware ones (without polluting every
application with validation logic and related configuration).
Sure, we can throw all existing APIs out of the window and wait few
years/decades until a new shiny API is available everywhere and upstream
developers decide to use it instead of old APIs...
Personally, I think it it is better to give application developers some really
easy way how to use data from DNS(SEC) tree today and let them gradually
migrate to new APIs later.
Once again: A new API definitely has value (e.g. better error handling etc.),
I'm not opposing it.
I just don't want to wait too long. From my perspective, it is much easier to
make/review/push patches which add one new flag to existing DNS library calls.
Compare it with replacing existing name resolution code with new shiny library.
I hope this clarifies my intent.
--
Petr Spacek @ Red Hat
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
