Paul Hoffman <paul.hoff...@icann.org> writes:
> From the earlier list discussion and your presentation at DNS-OARC,
> processing dynamic zones is hard, and you might make different choices
> based on different amounts of dynamicness (dynamicity?). This should
> cause developers concern about implementing ZONEMD now because there
> will be an expectation that they will have to implement the changes in
> the future.
I also look at it in terms of implementation complexity and where in the
code base decisions are made. EG, if you have different RRTYPEs for
signaling things, then the logic is straight forward:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} else if (rrtype == ZONEMDMERKLE) {
do_fancy_new_hashtree_stuff();
} ...
On the other hand, with a reserved field we end up here:
if (rrtype == ZONEMD) {
do_ZONEMD_stuff();
} ...
do_ZONEMD_stuff() {
if (reserved_field != 0) {
do_fancy_new_hashtree_stuff();
} else {
do_ZONEMD_stuff();
}
}
Now, if do_ZONEMD_stuff() and do_fancy_new_hashtree_stuff() are likely
to be sufficiently different in implementation (and I suspect they will
be), then the first code above with two RRTYPEs is likely to be
cleaner. The only advantage gained in the second type is if you can put
the brunt of the code for both do_fancy_new_hashtree_stuff() and
do_ZONEMD_stuff() pretty much inline because there is sufficient
overlap.
It's hard to predict what the best route is advance without knowing now
how much the resulting double implementation will overlap.
Personally (authorship hat off and thus collector of consensus hat off),
I think we should use a second RRTYPE for the future as it's easier to
make implementations more module and remove earlier implementations when
that specification is no longer used because hashtrees are so cool that
nothing else is ever needed.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
