On Mon, Jan 15, 2018 at 01:19:09AM -0500, John Levine wrote: > I don't understand the objection. Anyone can put a DNAME at the apex > of a 2LD now, and if we invent ANAMEs, anyone will be able to put > ANAMEs there too.
Yes, obviously. > As far as I'm aware, almost no gTLDs or ccTLDs police the contents of > 2LDs now and when they do, it's for content rather than technical > reasons, e.g., to be sure that a sponsored or restricted domain has > the right kind of stuff. Are you anticipating TLDs that will allow > only approved DNAMEs? That seems implausible and unenforcable to me. No, I am anticipating that people want a technical solution to administrative controls that put names into some kind of administrative relationship with one another, such that there are rules about what one may do with one name on the basis of what is done with another name. The usual example of this is the CNNIC policy with respect to IDNs that use simplified or traditional Han characters, but there are other similar examples. Now, I happen to believe that DNAME and ANAME and the proposed-but-so-far-going-nowhere BNAME are all doomed for this purpose, but others don't think that and they want to try (again) to use them. A natural thing to do in that case is to put the relevant records on the parent side of the cut, in order to enforce the policy, instead of monitoring them on the child side. One might argue that what is needed in EPP for that purpose is just the request for the policy feature (the bundling extensions previously up for discussion here), but another way to achieve it is just to provision the relevant RRTYPEs on the parent side. I don't believe that this WG is the correct place to put a "don't do that" filter on these sorts of things. If there is something people want to be able to express in registries, then it's reasonsble to create a standard EPP way to do it. If this WG decides to say, "That's a dumb thing to want, so we won't publish the document," then people will create their own extensions to do those things anyway (since EPP is designed precisely to allow such extensions), and we'll be back to the same problem that brought EPP work back to the IETF: everyone conforms to the standard, and yet there are as many ways to do a thing in EPP as there are registries. That's not desirable. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
