On 8/7/2022 5:39 PM, George Michaelson wrote:
In a similar spirit to avoiding "be damned" in a doc, I think
referring to choice 3 as "squatting" is probably both
truthful/accurate, and regrettable. We probably shouldn't formally
document (ab)use of a space this way without more considered language
and text around what it implies.

Yes, I might have said "creatively reuse" instead "squatting".

AFAIK, the consequences would be minimal, as there is approximately zero existing use of ".test" -- in constrast to say, ".local" or ".internal", which both have very significant usage. Plus, whatever user they are already warned.

In any case, it is probably fine to use ".test" for a test period, waiting for a definitive solution. That will have less side effects than just picking some name and learning later of a collision.

I thought your notes were helpful, a good write up of the "pick the
least worst" choices we've arrived at. I increasingly tend to think if
somebody in a public interest space had the $ and invested the cost of
delegating via ICANN process and handed it over for this purpose to a
registry, it would avoid all the pain of trying to document a
special-use: Simply get the delegation, burn the $200,000, meet the
ongoing opex, and turn it into the space through external process
compliance.

The cost itself is a hurdle, but fund raising could solve it. On the other hand, I am not aware of a simple ICANN process to reserve a name for this kind of purpose. Working through that could take a long time.


Basically, the IETF has two problems: it's trying to invoke its rights
to request a (non)delegation against its better wishes,  and it can't
entirely agree (achieve consensus?) inside itself on the wisdom of
doing it. Getting it through an external application outside of IETF
decision logic and then bringing it into the IETF might be easier, if
not cheaper.

Maybe. Or maybe not.

-- Christian Huitema


_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to