> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley <jab...@hopcount.ca> wrote:
>
> I actually think the document is actually almost entirely operational;
> at least, it describes a set of operational and design considerations
> for deploying DNS services constrained by particular sets of
> requirements. I don't see it as describing business models, but rather
> how commonly-available commercial DNS services can be lego'd
> together. Having said that, see (further) below.
Yes, it is indeed almost entirely operational. If dnsop is now only about
protocol enhancements, maybe we need to change its name to dnsext! :-)
> I don't particularly know who the audience for this document is, but
> I'm pretty sure it's not me. So I'm not the right person to judge
> whether it solves a real problem or is pitched at the right level. I
> haven't reviewed the document in detail; I've just skimmed through
> it. I'm pretty confident that the authors know what they are talking
> about :-)
The audience in my opinion is the general DNS community, since I think
they should be aware of the issues. The portion of the community that
would benefit from actually using the new deployment models described
in the document is likely much smaller: a set of enterprises that
need to deploy DNSSEC in a multiple signing provider configuration,
and a set of managed DNS providers that are willing and capable of
supporting this. I expect this population will grow over time if/when
DNSSEC adoption grows. And yes, this does solve a real problem for
those enterprises.
> I don't know that the document would necessarily benefit from adoption
> by the working group. I also don't know that the working group ought
> to have the kind of concern about the topics that this document
> addresses that would cause it to seek editorial control. It seems
> entirely plausible that the document contains useful advice, however,
> and that the RFC series is a suitable place for its publication.
>
> I think this document is an ideal candidate for the independent
> stream. I don't see an obvious reason why it belongs in dnsop.
>From discussing this draft at the last IETF, it appeared to us that
there was interest from the working group in taking on this work. Doing
this as a working group document carries more weight than an independent
submission (of course, most people outside the IETF would not know the
difference).
On ceding editorial control to the working group, and whether or
not the group should even care about the issues raised in the
draft - that is a good question, and I had contemplated that prior
to the last IETF. If we sensed that this would lead to a protracted
fight between DNS protocol purists and the DNS traffic management/
tricks crowd about how to solve this problem in entirely different
ways, then I think we would probably have elected to go the
independent submission route. I did not get that impression.
In principle, I am open to tackling the larger question of should we
standardize the various traffic management tricks. But I suspect there
will be strong resistance from both camps, and even if it could be done
and implemented, it would not be possible to do so in a time frame
required by the folks interested in this draft.
> Like Paul, my lack of enthusiasm for adoption shouldn't be interpreted
> as an objection.
Ok. I waited a few days to see if other people will speak up in support
of this draft, but I guess we're in the pre-IETF lull period. Lest people
get the impression there is no enthusiasm for this draft, I want to remind
folks that I presented this draft at IETF101 in London, and there appeared
to be quite a bit of interest. I went back and took a look at some of the
previous discussion:
The original email thread for this draft from March starts here:
https://www.ietf.org/mail-archive/web/dnsop/current/msg22196.html
Here's video of my presentation at IETF101:
https://www.youtube.com/watch?v=MixId63DGP4&t=33m16s
And you can jump to the Q&A section here:
https://www.youtube.com/watch?v=MixId63DGP4&t=40m54s
As you can see, most people who expressed an opinion were supportive
of doing this work (as a working group document). The jabber session
shows more supportive comments. And I had largely positive discussions
with many other folks in the hallway track.
Jim Reid, notably, was quite vocally opposed. As far as I could tell,
on the basis that (1) this is another straw on the camel's back, and
(2) who is actually even asking for DNSSEC, is there any demand, and
will this move the needle.
Regarding (1), if this is straw, it seems to be rather light straw.
I don't think the DNS camel should be used as a bludgeon to beat back
all proposals to enhance the DNS. The incentives here appear to be in
the right place. There is increased complexity. But the folks that bear
the costs of this complexity are the enterprises and their DNS provider
partners that want to deploy this. It does not impose new operational
or complexity burdens on other folks.
Regarding (2), this actually has the potential to move the needle. If
there is no solution to this problem, organizations that use these traffic
management features with multiple providers will effectively be blocked
from deploying DNSSEC. If we are encouraging DNSSEC adoption, I
think this problem needs to be solved.
Lastly, I attended a meeting of several DNS companies on Thursday, and
the discussion on this topic that occured clearly indicated to me that
there is interest.
--
Shumon Huque
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
