> On Tue, 8 Nov 2005, Olaf M. Kolkman wrote:
> > In the working group meeting I just mentioned that the IANA section of
> > draft-andrews-full-service-resolvers-01 should clearly mention who has chan
> ge
> > control of the registry.
> >
> > I'd suggest something along the lines "This registry can be amended through
>
> > IESG reviewed RFC publication" which is, as I've been informed, the highest
>
> > hurdle one can throw up in order to prevent unwanted modifications to the
> > 'blacklist'.
>
> I support the document.
>
> It depends on what category draft-andrews-full-service-resolvers-01 is
> aiming for. Given its nature, the target should maybe be BCP given
> that we need IETF-wide review of this. Then updating the list should
> require Standards Action. In any case, the IANA considerations need
> to be appropriately spelled out.
It was always intended to be BCP.
> Below are some editorial nits.
>
> editorial
> ---------
>
> Configuration Issues Facing Full Service DNS Resolvers In The Presence
> of Private Network Addressing
> draft-andrews-full-service-resolvers-01
>
> ==> the title etc. is not very intuitive compared to the abstract
>
> site-local addresses howsever, sacrificial servers for C.E.F.IP6.ARPA
>
> ==> typo
Thanks
> 255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */
>
> ==> should the whole 255.IN-ADDR.ARPA be covered? should 0.0.0.0 be
> covered ? what about site-local v4/v6 multicast addresses?
I was being conservative. I'll follow w.g. advice on this.
As for general multicast the reverse space for IPv4 multicast is
currently populated.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
