Hi Randy,

On 2013-08-22, at 16:58, Randy Bush <ra...@psg.com> wrote:

>> I think we need to acknowledge that there will always be signing
>> problems
> 
> < from a conversation with a friend wiser than i >
> 
> the problem is that we are going through a deployment phase where there
> is little penalty for sloppy server ops because so few are validating.
> 
> patching over this to be more tolerant of sloppy server ops is going in
> the wrong direction.  we need to think about how to make good server ops
> the easy path:
>  o less breakage prone protocols
>  o less breakage prone implementations
>  o easing fast repair if breakage is known
>  o detecting and reporting more aggressively
>  o blah blah blah
> 
> i.e. put that gun back in your hand

I like that line of thinking. Very nicely put, and it makes me reconsider my 
earlier thinking that NTAs will be useful to someone for ever.

However, I'm still not convinced that the right answer is not to standardise, 
or not to write up a BCP, for reasons of "if we write about this, people will 
do it for ever".

We can't predict how long this deployment phase will last, and it seems weird 
to assume that standardisation has no value over that unknown period. As a zone 
publisher, I would very much like to know how people are consuming my data. It 
seems more likely that I can have that insight if there is consistency in the 
way it is done.

When there is sufficient validation in the world that the support costs of 
signing errors shift from validator operators to zone publishers, it seems 
reasonable to predict that any words on NTAs will become useless naturally, on 
their own. That seems far more likely than the outcome where validator 
operators continue to deploy NTAs (at their own cost) for no reason.


Joe
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to