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.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
