In message <7ea38d42-3915-403e-afe3-c0a8e4a39...@hopcount.ca>, Joe Abley writes:
>
> On 14 Aug 2014, at 12:04, Mark Andrews wrote:
>
> > The assignements go:
> >
> > 0.0.0.0/0 IANA (IN-ADDR.ARPA)
> > 100.0.0.0/8 ARIN(100.IN-ADDR.ARPA)
> > 100.64.0.0/10 IANA (64.1
On 14 Aug 2014, at 12:04, Mark Andrews wrote:
> The assignements go:
>
> 0.0.0.0/0 IANA (IN-ADDR.ARPA)
> 100.0.0.0/8 ARIN(100.IN-ADDR.ARPA)
> 100.64.0.0/10 IANA (64.100.IN-ADDR.ARPA through
>127.100.IN-ADDR.ARPA)
>
> The 1
I followed previous discussions on this draft but don't remember all of
the details, so I may be rehashing some old discussions (in which case
that's not intentional...)
Overall: I think the idea is useful and it's eventually worth
publishing. But I've noticed a few non-trivial points that may ha
In message <86ac48c0-4dff-4286-a9b1-2a6be3d14...@hopcount.ca>, Joe Abley writes:
>
> On 13 Aug 2014, at 20:16, Mark Andrews wrote:
>
> > Can we please move on this.
> >
> > The reverse address are not yet insecurely delegated as
> > would be required for RFC 6598 compliance. This is
On 13 Aug 2014, at 20:16, Mark Andrews wrote:
> Can we please move on this.
>
> The reverse address are not yet insecurely delegated as
> would be required for RFC 6598 compliance. This is starting
> to cause operational problems for ISP's that validate DNS
> resp
Mark,
Surely, something stronger than a reminder is appropriate.
For a mission-critical requirement, this needs to be an explicit and
unambiguous request:
"This document directs IANA to create insecure delegations
for the listed zones."
Dick
On 14 August 20
