On Thu, May 21, 2015 at 7:56 AM, Joe Abley <jab...@hopcount.ca> wrote: > 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. > > 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.
Good point, thanks. I've removed the "delegate to new style AS112" text - this was originally form when we had 'Omniscient AS112', which could have been delegated to directly. Having .alt in the locally served zones registry will accomplish 99% of what AS112 would have anyway... Sorry it has taken so long to get to these comments.... W > > > Joe > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
