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 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 > >> >implementations to go look at the assignment registry and maybe more > >> >aware of the dynamic nature of some of these zones. As the draft is > >> >now, some implementors probably will stop reading after section 5. :( > >> > >> Good call. +1 > > > >The zone listed are intended to be stable enough in usage that they > >can be frozen in code. Zones added to the registry should be of a > >similar level of stability. It would be a very rare event for a > >zone to be removed from the registry and it would take decades, if > >ever, that the zone would be untainted. > > 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 force anyone to do anything. If this was split in two (one part saying look in registry and the other half saying this is the priming list) it still wouldn't help as developers may just read the second document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
