In message <f7960cd6-8c1d-44f9-a5ff-fb3fa9268...@hopcount.ca>, "Joe Abley" writ
es:
> Hi Tim,
>
> On 20 May 2015, at 22:13, Tim Wicinski wrote:
>
> > From the discussion on the mailing list, this draft appears to have
> > support in the working group. The authors have requested a Call for
> > Adoption. The chairs want to move forward with this draft if it has
> > consensus support.
> >
> > This starts a Call for Adoption for draft-wkumari-dnsop-alt-tld
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/
> >
> > Please review this draft to see if you think it is suitable for
> > adoption by DNSOP, and comments to the list, clearly stating your
> > view.
>
> I have read this draft. I support its adoption as a working group
> document. I am willing to review future revisions of this draft.
>
> I think reserving a DNS-like namespace anchor of ALT is unnecessary; as
> I mentioned in my comments about the ONION draft, you have a choice of
> anywhere in the namespace to place that anchor, and there are an
> enormous number existing places in the DNS where you can reserve a name
> without denting root zone maintenance processes or existing DNS
> namespace policy. Having said that, I don't think (if it turns out to be
> practical, see below) reserving the ALT label in the root will do any
> harm, and if people are willing to bang their heads against ICANN policy
> to make that happen, they should go right ahead.
>
> I like the quiet nod to the era of Usenet where people primarily
> exchanged text rather than 7-bit encoded MPEGs of mediocre network
> television. Those were the days.
>
> The "TLD" observation I made on the Onion draft seems not to apply here
> (except in the draft name, which will change anyway). The language used
> to describe the draft's goals seems clear and pleasantly unambiguous, at
> least following a quick re-skim.
>
> John expressed some mild reservations about the use of DNAME to sink
> accidental DNS queries with QNAMEs under the ALT domain; in fact the
> document does not specify that DNAME should be used, but rather that ALT
> be "delegated to 'new style' AS112 nameservers". I'll note that this
> would be a lame delegation, since those nameservers only serve the zone
> "EMPTY.AS112.ARPA".
>
> If DNAME *is* to be used, the authors might make quiet enquiries as to
> how much trouble this would cause the people involved in root zone
> maintenance, since to my knowledge there is nothing in the existing
> processes or RZM machinery to allow a DNAME to be added. The use of
> DNAME has the potential to expand an awkward political conversation
> between the IAB and ICANN about authority to reserve names in the root
> zone to one that includes the other two root zone partners as well.
The following will work fine and as one probably wants to break the
DNSSEC chain of trust for some of the experiments it would need to
be a insecure delegation.
ALT. SOA ...
ALT. NS ...
ALT. DNAME EMPTY.AS112.ARPA.
Just because you use a DNAME to get to EMPTY.AS112.ARPA doesn't
mean that there isn't going to be a traditional delegation as well.
> I could quite well be over-stating this; perhaps the IAB, ICANN, USG and
> VRSN are all tremendously best friends these days, brought together with
> one mind in glorious agreement over such trivial topics as the future of
> the IANA. But if there's an inkling of truth about my scaremongering,
> taking care to reduce the draft to the level where it can proceed to
> publication without everybody having to agree might be an idea.
>
>
> Joe
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
