>
> Hi Mark,
>
> > Thats why I said the DNS section was a "cop out". The DNS
> > information hadn't been collected, distilled and put on
> > paper. I attempted to do that.
> >
> > * Don't publish ambigious addresses global.
> > * It is unwise (but not wrong) to publish unreachable addresses.
> > * Don't let reverse queries for private address space leak.
> > That it is common to leak the private net next to you and
> > you should stop that as well as what you are using.
> > * That you can the apex of the reverse zone for private space
> > to create your own deleation tree (e.g. 10.in-addr.arpa,
> > 168.192.in-addr.arpa) and not have to slave all the reverse
> > zones everywhere.
>
> I agree that it would be good to document this information, but there
> are three reasons why I personally don't think that the ULA document
> is the right place to do this:
>
> (1) This is operational information, not part of the specification of
> these addresses, so it would be better published in a BCP.
Then remove all the other operational content. Saying
prefixes should be advertised / filtered is as much operational
content as saying what should and should not be advertised
in the DNS.
What I said was specific to ULAs with different constraints on
both types of ULA.
> (2) The IPv6 WG is not the best group to make broad statements about
> what should/should not be included in the global DNS. The dnsop WG
> would be a better place for this work.
Well run it past DNSOPS/DNSEXT. As far as I can see this
was never refered to either group. You have my options
from such a referral.
> (3) The ULA document has already passed IETF LC and is in the IESG.
> It should be re-opened for by the WG for critical technical flaws at
> this point, so I don't think it makes sense to use this document as a
> vehicle for publishing general information about how to handle local
> addresses in the DNS.
It is a critical flaw not to say how to prevent excessive load
on critical parts of the global DNS infrastucture.
> We need to come to some closure on how/if the DNS portions of this
> document need to change before publication, and we need to do it
> quickly because this document is already in IESG evaluation.
>
> Brian Haberman, I think you are serving as WG chair for this
> document, right? Could you possibly figure out if this conversation
> has raised any new issues that need to be considered after IETF LC?
> If so, can you figure out if there is any IPv6 consensus regarding
> what to do about them?
>
> I need to understand if it is necessary to delay this document for
> resolution of this issue.
>
> Thanks,
> Margaret
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
