Subject: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

From: Tim Wicinski <[email-masked]>
Date: Fri, 6 Jul 2018 20:26:59 -0400

We've had some interest in moving this document forward, and the chairs
wanted to kick off this Call for Adoption before Montreal so if there
are concerns there will be some meeting time to address.

This document is label as: Informational.  The document is attempting
to document operational deployment models on deploying DNSSEC signed
zones across multiple platforms.

This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec

The draft is available here:
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/

Please review this draft to see if you think it is suitable for
adoption by DNSOP, and comments to the list, clearly stating your view.
The authors will be at the next meeting to address questions or concerns.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 20 July 2018

Thanks,
Tim

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Jul 2018 11:09:19 -0400 (EDT)

On Fri, 6 Jul 2018, Tim Wicinski wrote:

> The draft is available here: https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/

I've reviewed the draft. It seems to me this is mostly a description of
novel uses of IETF protocols and possible business models. I don't see
a strong case for publishing this as an RFC and have a preference for
DNSOP to focus their time on working on protocol/operations matters and
our communal backlog of that.

So I am not in favour of adoption, but I would not object to adoption
either if that's how others want to spend the DNSOP time.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 10 Jul 2018 17:06:05 +0100

> our communal backlog of that.

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.

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 :-)

> either if that's how others want to spend the DNSOP time.

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.

Like Paul, my lack of enthusiasm for adoption shouldn't be interpreted as an objection.

Joe

---

From: Shumon Huque <[email-masked]>
Date: Sat, 14 Jul 2018 00:12:52 -0400

> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley <[email-masked]> 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

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

---

From: Petr Špaček <[email-masked]>
Date: Tue, 17 Jul 2018 13:18:30 +0200

On 14.7.2018 06:12, Shumon Huque wrote:
>> On Tue, Jul 10, 2018 at 12:06 PM Joe Abley <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> to be quite a bit of interest.. I went back and took a look at some of the
> previous discussion:
> 

Nice summary. In short I support work on this and having it as WG
documents makes sense to me.

-- 
Petr Špaček  @  CZ.NIC

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 17 Jul 2018 14:13:30 +0000

> -----Original Message-----
> From: DNSOP <[email-masked]> On Behalf Of Petr Špacek
> Sent: Tuesday, July 17, 2018 7:19 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [DNSOP] Call for Adoption: draft-huque-dnsop-
> multi-provider-dnssec
>
> >> 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.
> >

[snip]

> documents makes sense to me.

It makes sense to me, too. I support adoption.

Scott

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 17 Jul 2018 20:43:13 +0300

On Sat, Jul 14, 2018 at 7:13 AM Shumon Huque <[email-masked]> wrote:
> [..] The portion of the community that

Reflects my experience entirely.
Would be happy to see this adopted by the WG.

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: "Rose, Scott" <[email-masked]>
Date: Tue, 17 Jul 2018 14:18:08 -0400

> This call for adoption ends: 20 July 2018

I have read the draft and I think that it is something that should be 
documented.  I support it becoming a WG draft.

Scott

===================================
Scott Rose
NIST ITL
[email-masked]
+1-301-975-8439
GV: +1-571-249-3671
===================================

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 18 Jul 2018 09:43:50 -0400

Support adoption

this is actually a needed document, due to the fact that many "high value
zones" want to use multiple vendors.

   Olafur

On Fri, Jul 6, 2018 at 8:26 PM, Tim Wicinski <[email-masked]> wrote:

> The draft is available here: https://datatracker.ietf.org/
> doc/draft-huque-dnsop-multi-provider-dnssec/
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 19 Jul 2018 00:13:47 +0900

I support this draft to be WG I-D.

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 18 Jul 2018 12:25:05 -0300

> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec

I support the adoption of this document

Fred

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 18 Jul 2018 11:28:27 -0400

tjw> This starts a Call for Adoption for:
tjw> draft-huque-dnsop-multi-provider-dnssec

I support adoption of this document.

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Jul 2018 18:14:12 +0100

> Support adoption

+1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger, Southwest Fisher: Variable 3 or less,
increasing 4 at times. Smooth or slight. Fair. Good.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 19 Jul 2018 08:42:24 -0400

I also support adoption of this draft - it is attempting to address a genuine impediment to deploying DNSSEC and I think this group is the right place to work on it.

As mentioned at the mic in Montreal, I’d like to see it additionally reflect how the proposals here feed into the process for moving vendors after deployment. 

Sara.

> On 18 Jul 2018, at 11:13, Yoshiro YONEYA <[email-masked]> wrote:
>

---

From: Dan York <[email-masked]>
Date: Thu, 19 Jul 2018 13:20:10 +0000

+1. Support adoption.

> On Jul 19, 2018, at 8:42 AM, Sara Dickinson <[email-masked]> wrote:
>

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 20 Jul 2018 11:17:01 -0400

All

Thanks for all the comments on this draft.  The Call for Adoption is ending
today but it seems that there is consensus to adopt this work in DNSOP and
support this work.   The chairs thank everyone for the feedback.

Authors should upload a new version with the
draft-ietf-dnsop-multi-provider-dnssec  name.

Thanks!
Tim
for all the chairs