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 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.
here's where I think we are:
The document serves three purposes:
1) it establishes and/or encourages a practice to serve certain zones
locally an any recursive resolver (thus BCP)
2) to make the list non-static and maintainable, it establishes an IANA
registry with a policy and guidance (thus BCP)
3) from where it came from initially and to make (1) actually helpful,
it seeds this registry giving due space to explanations for choices
as well as considerations on thise prefixes/domains deliberately
not chosen.
(1) is basicly done and understood
(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 discussions like this:
"Additions to the registry will not have and instantly relieving
effect on those authoritative servers otherwise targetted with
the queries to locally served zones, it can be expected that
implementations will refresh the list of zones to serve occasionally
or based on their update cycles. For the same reason it can not
be expected that deletions from the registry will allow the
removed domain name to be resolved on the public Internet any time
after such removal."
Regarding (3), while it is useful to seed the registry as broad as
possible, it is safe to err on the side of refusal that to "poison"
a prefix by essentially making it non-reverse-mappable.
That said, there is consensus to drop section 4.7 and not to add
the ORCHID prefix (resp. its reverse mapping domain name) to the registry.
On a more editorial side, the document should state its threefold purpose
in the introduction.
The -14 version should then be ready to go to the AD together with the
two AS112 drafts as a bundle, meking the cross references resolvable.
-Peter (with hat and Stephen's advice)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
