On 14.7.2018 06:12, Shumon Huque wrote: >> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley <jab...@hopcount.ca > <mailto: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.
Nice summary. In short I support work on this and having it as WG documents makes sense to me. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
