On Wed, Sep 06, 2006 at 03:55:22PM +0200, Olaf M. Kolkman wrote:
>
> On 8Aug 2006, at 3:05 PM, Peter Koch wrote:
>
> >Dear WG,
> >
> >this initiates a Working Group Last Call for
> >
> > draft-ietf-dnsop-default-local-zones-00.txt
> >
> >to end Thursday, 2006-08-24 23:59:59 UTC
> >
>
> The last call appeared during my vacation, apologies for the later
> reply.
>
> Bottom line: I think this is important work and support it to
> eventually be published as BCP. But....
>
>
> The text needs a bit more attention.
>
> I had the benefit of reading the thread so I was not so surprised
> that I had to read section 3 a couple of times and still didn't get
> it. So, I think that the suggestions by Peter are actually needed to
> improve readability and to make this document useful for the regular
> admin. I am not sure if that is sufficient.
>
>
> Wouldn't it be a sensible suggestion to enter the e-mail address of
> the 'local' adminsitrator for the MMAIL field?
>
>
> As for Ed's question:
> >Chapter 4 needs FQDN's in it. Also, why the IANA registry
> >reference? I don't see that IANA needs to have a list of these
> >"should be split-view'ed" zones.
>
> This is because you want to be able to point to a central place where
> the list of names is maintained for which queries SHOULD NOT get out
> on the internet. Besides you want to carefully control what gets on
> that list. Hence an IANA registry, including the highest possible
> review bar to get data in that registry. Or am I not listening
> carefully and missing Ed's point?
>
>
> Just a question. How is this going to be 'evenginerized'. Just
> creating a BCP is not sufficient. This is something that can be part
> of example configs in nameserver code but then the question is how to
> turn it on and get the appropriate parameters. In other words who is
> going to do the marketing after the IETF is done with it?
>
>
> --Olaf
>
>
>
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
hum... well, ISC has already coded this up in the current
BIND distributions, so for folks updating their code base,
its turned on by default. ... why the IETF needs to do
anything here to ratify an ISC action is mostly beyond me.
anyway. i think this is a huge mistake.
codifying "special" behaviour is a bear to clean up when
the "special" nature of the bahaviour changes.
granted, such behaviour may not change in the next few years,
but when it does change (and it will) - ripping all this cruft
out of deployed systems will take forever.
i'm increasingly dubious about the institutionalization of
one view of the "Internet". Yeah, Ed has had the fortune to
work for sites who have, by policy, had a walled garden approach
to connecting to any network (regardless of transport protocol)
and such techniques are common... but in such models break down
in the ad-hoc and truly mobil networking theaters.
so as a lone disenting voice in the wilderness, i think this is
a bad idea ... and i am a bit resentful that ISC implemented
such features before the IETF sactioned them. (yet another code
patch that I must make -every- time i update BIND code from ISC)
--bill
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
