Subject: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

From: Tim Wicinski <[email-masked]>
Date: Mon, 11 May 2020 13:41:19 -0400

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones

The draft is available here:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/

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.

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

This call for adoption ends: 25 May 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 May 2020 15:38:15 -0400

> This call for adoption ends: 25 May 2020
I support adoption and will review.

"3.  Description
An implementation of catalog zones MAY allow the catalog to contain
   other catalog zones as member zones."

It seems ok to me to allow catalog zones to include other catalog zones as
future feature, although I cannot figure out yet how that would work, but
it might conflict with:

"6.1.  Implementation Notes
   Catalog zones on secondary nameservers would have to be setup
   manually"

-- 
Bob Harold

---

From: George Michaelson <[email-masked]>
Date: Tue, 12 May 2020 08:48:48 +1000

I support adoption.

I wondered a little about "it is absolutely essential for these
transfers to be protected from unexpected modifications on the route.
So, catalog zone transfers SHOULD be authenticated using TSIG
[RFC2845]."

The use of a categorical *absolutely* and SHOULD is jarring. If this
is really categorical, the normative enforcement needs to be stronger
maybe?

I also wondered why the TTL of the RR is not held to be meaningful. It
felt like there is an opportunity to use this field but thats quibble,
the document as-is defines it as 0 and thats ok, if perhaps missing an
opportunity to use a field close to the zone being catalogued for some
purpose.

On Tue, May 12, 2020 at 3:42 AM Tim Wicinski <[email-masked]> wrote:
> The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 11 May 2020 21:24:29 -0400

>by DNSOP, and comments to the list, clearly stating your view.

It doesn't seem like a bad idea but I'm wondering who's likely to
implement it, since that makes it much more interesting.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 12 May 2020 10:23:14 +0200

> implement it, since that makes it much more interesting.

Knot DNS has an implementation already.  It's not merged and can't
create catalog zones yet, but we expect to support it in future.

I also see three other open-source server vendors among authors, so that
might give you an idea, but I can't speak for them :-)

--Vladimir

---

From: Willem Toorop <[email-masked]>
Date: Tue, 12 May 2020 14:50:23 +0200

Op 11-05-2020 om 21:38 schreef Bob Harold:
> On Mon, May 11, 2020 at 1:42 PM Tim Wicinski <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     All,
> 
> It seems ok to me to allow catalog zones to include other catalog zones
> as future feature, although I cannot figure out yet how that would work,
> but it might conflict with:
> 

Thanks Bob,

The secondary has to be "setup manually",
- to regard the zone to be a catalog zone
- but also, optionally, to associate a set of configuration which are
  applied to the zones generated from the catalog.

One of the things in the associated set of configuration could be that
zones from a certain catalog, are catalog zones themselves, however with
which set of configuration the zones added from those catalog are
associated, also needs to be configured manually on the secondaries.

-- Willem

---

From: Willem Toorop <[email-masked]>
Date: Tue, 12 May 2020 15:06:55 +0200

> is really categorical, the normative enforcement needs to be stronger

Agree, how about replacing "it is absolutely essential" with "it is key"?

> opportunity to use a field close to the zone being catalogued for some

We're staying away from actual configuration properties in this draft on
purpose.  TTL could be used to mean something in the dynamics of adding
& removing of zones itself, but it feels a bit fragile to do that to be
honest - we might exclude (or make more difficult) certain setups where
the catalog could not be used by or from the authoritative nameserver
directly.

-- Willem

---

From: George Michaelson <[email-masked]>
Date: Wed, 13 May 2020 00:31:54 +1000

yes. well finessed! keep the SHOULD relax the non-normative language is fine.

and I understand not wanting to work on this regarding TTL and meaning
against RR.

as I said, support adoption. this is good work. its implemented.

-G

---

From: Brian Dickson <[email-masked]>
Date: Tue, 12 May 2020 10:33:08 -0700

> We are looking for *explicit* support for adoption.
I support adoption of this as a WG draft. I believe it is suitable for
adoption by DNSOP. I am willing to review, and to contribute text.

Brian

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 May 2020 21:35:17 -0400

> On May 11, 2020, at 1:41 PM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All,
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ <https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/>
> 

Tim, 
a nit question: 
what is the intended publication status ? 
Experimental, Informational, Standard  

Thanks 
Olafur

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 12 May 2020 21:43:09 -0400

Olafur

Currently it's marked Standards Track, but I was working on the idea that
the working group would make
that decision as the document works toward Working Group Last Call.

I was reserving judgement until there was implementations,
interoperability, etc.

Please feel free to register any thoughts on publication status at this
time as well.

Hope that helps

tim

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 13 May 2020 11:44:15 +0400

> >     This call for adoption ends: 25 May 2020
I support Adoption of the document and I'm willing to review it.

---

From: Marc Groeneweg <[email-masked]>
Date: Wed, 13 May 2020 11:09:26 +0000

Hi,

I support adoption and will review it.

Regards,

Marc

From: DNSOP <[email-masked]> on behalf of Tim Wicinski <[email-masked]>
Date: Monday, 11 May 2020 at 19:43
To: dnsop <[email-masked]>
Cc: dnsop-chairs <[email-masked]>
Subject: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

All,

Thanks,
tim wicinski
DNSOP co-chair

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 13 May 2020 14:27:42 +0200

> implement it, since that makes it much more interesting.

co-author here :)

PowerDNS has a PoC, external, implementation of a previous incarnation of this draft. We will certainly implement (inside or outside PowerDNS) this draft when the shape of things is sufficiently agreed on.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 13 May 2020 16:31:27 -0400

> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
I support adoption, and will review the draft.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 May 2020 22:43:54 -0400

> On May 12, 2020, at 9:43 PM, Tim Wicinski <[email-masked]> wrote:
> 
> Olafur
> 
> Currently it's marked Standards Track, but I was working on the idea that the working group would make 
Tim 

Thanks for the clarification, 

> I was reserving judgement until there was implementations, interoperability, etc. 
> 
Fair point 

> Please feel free to register any thoughts on publication status at this time as well.
> 
> Hope that helps
> 

This draft is a result of a failure by the DNS community to create any kind of framework to manage distributed name server clusters. 
The draft is a “hack” of the best kind it is low impact but does the work for a sub-set of usage cases that a real control plane should have. 

I think making this document a standard would be a mistake.  
I think NOT publishing this document at all would be a  BAD thing. 

I support adoption and will review and continue to agrue against standards track. 

Olafur

> 
> On Tue, May 12, 2020 at 9:35 PM Olafur Gudmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On May 11, 2020, at 1:41 PM, Tim Wicinski <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> All,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>

---

From: Miek Gieben <[email-masked]>
Date: Thu, 14 May 2020 11:27:57 +0200

>I support adoption and will review and continue to agrue against standards

+1 on what's said here.

/Miek

--
Miek Gieben

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 24 May 2020 05:47:07 -0400

Hi

the Call for Adoption for this draft has completed, and there is strong
consensus for DNSOP to work on this.

Note:  During the Call, a very valid point was raised whether this document
should be Standards Track or not.
The chairs don't worry what are on the documents before adoption, as we
have faith that the working group
will help provide the correct guidance.  The authors are okay with
adjusting RFC status.

The chairs have been thinking about RFC status (real or imagined) of all
adopted work.  We do worry
about the effect all our work has on the Camel.

Thanks for your feedback.

tim