Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc6598-rfc6303-00

From: Tim Wicinski <[email-masked]>
Date: Sat, 7 Dec 2013 08:59:32 -0500

Greetings,

We're kicking off the Working Group Last call on Adding 100.64.0.0/10 
prefixes to IPv4 Locally-Served DNS Zones Registry. The author believe 
that this document has addressed all the issues raised on the document.  
The latest version of the draft is available at:

http://www.ietf.org/id/draft-ietf-dnsop-rfc6598-rfc6303-00.txt
http://tools.ietf.org/html/draft-ietf-dnsop-rfc6598-rfc6303-00

Because of this last call is surrounded by the upcoming holiday season, 
we're making this a four (4) week last call cycle.

Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will
conclude on January 3rd, 2014.

thanks
tim

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Dec 2013 08:18:00 -0800

I have read this document a believe it is ready to move to IETF last call. If only all our operational documents were as uninteresting as this...

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Sat, 7 Dec 2013 16:55:14 -0500

Hi Tim,

On 2013-12-07, at 08:59, Tim Wicinski <[email-masked]> wrote:

> We're kicking off the Working Group Last call on Adding 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry. The author believe that this document has addressed all the issues raised on the document.  The latest version of the draft is available at:
> 
> Because of this last call is surrounded by the upcoming holiday season, we're making this a four (4) week last call cycle. 

I have read the document, I have no suggestions for changes, and I support its publication.

Joe

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Dec 2013 18:09:27 -0800

Hi,

> conclude on January 3rd, 2014.

I've read the document and I think there might be a bit of an issue:

It appears we now have multiple registries listing the same information.  Specifically:

http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml

seems to be a subset of

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Options to deal with this:
1. revise the IANA considerations section to indicate that both registries need to be updated
2. remove the locally served zones from the special-use-domain-names registry
3. merge the two registries into a single uber-wonky-name registry
4. give up on this DNS thing as it was clearly a mistake and go back to ip address literals

While the last option is looking more and more appealing, I'm personally leaning towards option 3, adding a column that says how the name should be dealt with (e.g., "locally served via DNS", "never touch the wire", "non-DNS", etc.).  

Regards,
-drc

P.S. There should probably be a better way to find these registries -- I had to resort to Google and clicking around to find both registries.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Dec 2013 08:59:22 +1100

In message <[email-masked]>, David Conrad
 writes:
> > Substantive comments and statements of support/opposition for advancing
> this document should be directed to the mailing list. Editorial
> > suggestions can be sent directly to the authors. The chairs will send
> in their comments as well during the last call period. This last call will

David you need to learn the definition of subset.  They are overlapping sets.

> While the last option is looking more and more appealing, I'm personally
> leaning towards option 3, adding a column that says how the name should
> be dealt with (e.g., "locally served via DNS", "never touch the wire",
> "non-DNS", etc.).
>
> Regards,
> -drc
>
> P.S. There should probably be a better way to find these registries -- I
> had to resort to Google and clicking around to find both registries.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Sun, 8 Dec 2013 14:18:21 -0800

Mark,

> David you need to learn the definition of subset. They are overlapping sets.

Sigh.
 
>> 4. give up on this DNS thing as it was clearly a mistake and go back to

And what's your choice?

Or do you not see it as an issue?

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Dec 2013 14:51:27 +0000

Tim Wicinski <[email-masked]> wrote:
>
> Substantive comments and statements of support/opposition for advancing this
> document should be directed to the mailing list.

I have read the document and I think it is ready to advance.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 9 Dec 2013 10:53:55 -0500

David,

I'm glad you spotted this. I think it is indeed a concern.

> While the last option is looking more and more appealing, I'm personally leaning towards option 3, adding a column that says how the name should be dealt with (e.g., "locally served via DNS", "neve…

Which answer makes the most sense depends a bit on whether there's any urgency to getting this draft published.

I suspect that merging the two registries, including agreement on a set of possible values for "what to do about it", is the right answer but also likely to take longer than having this draft update both existing registries (either of the remaining options you propose). 

I'd support your option 3 if there's no urgency here (and I'm aware of none). 

If people are in a hurry for some reason, option 1 seems marginally less likely to lead to confusion than option 2 (neither registry that people might be relying on today gets *less* useful), but it seems clear to me that somewhat idiosyncratic partial overlap between two registries is something we should avoid where possible.

Suzanne

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Dec 2013 13:43:36 -0500

> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Yes, I raised this when the second of the two registries you cited were created, but my concerns were apparently not universally-held as important.

> 4. give up on this DNS thing as it was clearly a mistake and go back to ip address literals

I would prefer the pragmatic option 5:

5. Leave both registries as-is, publish Mark's document as-is, and work on a separate registry clean-up draft later, since I am guessing that work will not be uncontentious and the guidance provided by the draft at hand is sufficiently useful not to stall.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Dec 2013 11:07:49 -0800

> 5. Leave both registries as-is, publish Mark's document as-is, and work on a separate registry clean-up draft later, since I am guessing that work will not be uncontentious and the guidance provide…

+1

There is no need to conflate the trivial addition of this for the benefit of the community with the mind-numbing process issues.

--Paul Hoffman

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 11 Dec 2013 06:28:36 -0700

jabley> I would prefer the pragmatic option 5:

jabley> 5. Leave both registries as-is, publish Mark's document as-is,
jabley>    and work on a separate registry clean-up draft later, since I
jabley>    am guessing that work will not be uncontentious and the
jabley>    guidance provided by the draft at hand is sufficiently useful
jabley>    not to stall.

+1 for pragmatic approach and moving forward.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 11 Dec 2013 10:14:12 -0500

Ummm....I'm not sure that adding "could be in neither registry, but reserved anyway" to the things people have to know to implement this properly is the most pragmatic approach, since we've already discovered that "could be in either, check both" is the advice we have to give if we're not integrating the registries.

Agreed on pragmatism, and I can therefore live with deferring the cleanup, but "update either or both" strikes me as moreso than "update neither".

However, I also agree this isn't worth a lot more haggling, and won't object to publication.

Suzanne 

On Dec 11, 2013, at 8:28, Paul Ebersman <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop