Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-17 Thread Peter Koch
On Tue, Jun 15, 2010 at 02:32:54PM +1000, Mark Andrews wrote: Probably true, but not relevant to the discussion. The idea is to force imple menters to look at the registry so that they see *future* additions to it, ev en if they get there from reading this RFC-to-be. You can't

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-17 Thread bmanning
On Thu, Jun 17, 2010 at 01:15:06PM +0200, Peter Koch wrote: (2) is covered in the IANA considerations section but while that section refers to a formal policy it does not offer guidance for review. We should capture the considerations from the most recent as well as previous

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-17 Thread Peter Koch
On Thu, Jun 17, 2010 at 02:19:57PM +, bmann...@vacation.karoshi.com wrote: ANY TIME?? ever? how about ... deletions from the registry will allow the domain names to be resolved on the public Internet at some reasonable time after removal from the registry.

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-15 Thread Chris Thompson
On Jun 15 2010, Mark Andrews wrote: In message p0624080cc83c9ae05...@[10.20.30.158], Paul Hoffman writes: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-15 Thread Mark Andrews
A tentative suggestion: maybe lists of this sort ought to be distributed via the DNS itself, with nameserver software encouraged to fetch them dynamically and act accordingly. Something along the lines of local-zones.arpa. PTR 0.in-addr.arpa. PTR 127.in-addr.arpa.

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-14 Thread Mark Andrews
In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-14 Thread Paul Hoffman
At 12:12 PM +1000 6/15/10, Mark Andrews wrote: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-14 Thread bmanning
On Mon, Jun 14, 2010 at 07:51:14PM -0700, Paul Hoffman wrote: At 12:12 PM +1000 6/15/10, Mark Andrews wrote: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-14 Thread Mark Andrews
In message p0624080cc83c9ae05...@[10.20.30.158], Paul Hoffman writes: In message p06240867c8385b270...@[10.20.30.158], Paul Hoffman writes: At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-11 Thread Derek Diget
On Jun 10, 2010 at 17:38 +0200, Shane Kerr wrote: =On Mon, 2010-05-31 at 10:25 +0100, Stephen Morris wrote: = I think the local zones draft is just about there, but a couple more = questions: = = The last revision included the ORCHID addresses. They are not = routable but, unusually, they are

Re: [DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-06-11 Thread Paul Hoffman
At 4:23 PM -0400 6/11/10, Derek Diget wrote: Raising hand timidly In this group!? :-) Instead of listing the zones in section 4 (which then will get hard coded into implementations), follow section 6 and register the zones in the new/to-be-created IANA assignment registry. This will force

[DNSOP] draft-ietf-dnsop-default-local-zones-13

2010-05-31 Thread Stephen Morris
I think the local zones draft is just about there, but a couple more questions: The last revision included the ORCHID addresses. They are not routable but, unusually, they are time-limited - the assignment is set to be revoked in 2014. So there is the question as to whether the address range