Suzanne, On Oct 18, 2022, at 6:50 AM, Suzanne Woolf <swo...@pir.org> wrote: > We don't know what ICANN considers an attempt to "wade into ICANN territory," > and there's nothing the WG can do to resolve this question.
I’m unsure the protocols here, but the WG could request the IAB to have the IETF Liaison to the ICANN Board inquire as to whether the proposed reservation of .alt would be “an attempt to ‘wade into ICANN territory’”, no? Speaking personally, I think it’d be nice if there could be a definitive statement by ICANN on this question. > It would be helpful if we could focus on technical/operational impacts and on > whether .alt would in fact solve the problems that the draft claims to > address. OK. I’m assuming the "problems that the draft claims to address” (since there isn’t an explicit problem statement in alt-tld) are from the Introduction: "The techniques in this document are primarily intended to address the "Experimental Squatting Problem", the "Land Rush Problem", and “Name Collisions" issues discussed in [RFC8244]” Editorially, section 3 of RFC 8244 identifies 21 different problems and the terms “Experimental Squatting”, “Land Rush”, and “Name Collisions” are not explicitly referenced in that section (there is a reference to name collisions in section 4, but it talks about ICANN’s name collision study). This forces the reader to interpolate which RFC 8244 problems are being referenced. For clarity, it might be helpful to use the numbers in RFC 8244 (as I gather was the intent of numbering). Anyhow… On the “Experimental Squatting Problem”: Personally, I’m skeptical as I don’t see a lot of incentives to use .alt over some “interesting” string that has not yet been delegated, particularly given the low rate of change via ICANN’s gTLD processes. There might even be some perverse incentives unrelated to reserving .alt, e.g., squat now and get market share so ICANN can’t delegate due to name collision avoidance, and then petition for ICANN to delegate the name to you at a later date. However, empirically, since GNS appears to be willing to migrate over, perhaps I’m overly cynical. On the “Land Rush Problem”: As this isn’t referenced (AFICT) in RFC 8244, I’m guessing this is when lots of people rush in to obtain domains either for squatting purposes, to prevent squatting, or “investment”. I gather the intent of registry restrictions as specified is to limit who can use .alt names, but I’m not sure that’s going to work as intended. Specifically, section 3 of alt-tld states: 'Entry to the registry is a combination of "Specification Required” and either "Expert Review" or "IESG Approval". See [RFC8126] for the definition of these three terms,' (Nit: line ends with a comma.) If the goal is to encourage folks to move over to .alt from the root, I suspect the entry requirements are too much. I’d imagine any sort of requirement is going to create friction and reduce the likelihood folks will bother to move. As such, I might suggest a lighter weight registration process (maybe just “Expert Review”?). However, the draft states .alt is an unmanaged space, so I’m not sure I understand what the registry entry restrictions are going to look at (maybe just to avoid collision?). On the “Name Collisions Problem”: Section 2 of alt-tld states: "Alternative namespaces should differentiate themselves from other alternative namespaces by choosing a name and using it in the label position just before the .alt pseudo-TLD.” and later: “[Groups wishing to create new alternative namespaces] should attempt to choose a label that they expect to be unique among similar groups and, ideally, descriptive. Developers are wholly responsible for dealing with any collisions that may occur under .alt." The phrasing here is odd in that a namespace can’t differentiate itself from anything, rather applications need to be able to differentiate behaviors based on the (sub-)namespace created by .ALT. The implication of this statement is that some mechanism must exist that allows an application to make the distinction. What this mechanism is appears to be left to the reader as an exercise. As such, I’d say that the alt-tld draft doesn't address “Name Collisions”, rather it provides a way in which name collisions _at the root of the DNS_ can be avoided, but it explicitly moves that problem to a non-DNS context underneath .ALT. One other comment, as a nit, section 2 of alt-tld stats: "Because names beneath .alt are in an alternative namespace, they have no significance in the regular DNS context.” Presumably, the DNS significance of .alt is that it MUST NOT be looked up in the DNS and/or ICANN MUST NOT delegate .ALT in the DNS. The latter is probably implementable (assuming ICANN agrees, which I imagine they would). The former, pragmatically speaking, not. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
