What would really help here would be standardize a way to measure toxicity. We
could then track a specific string toxicity over time, and maybe then define a
threshold where it is OK or not OK to delegate that particular string.
Yes, and that gets back to the question of whose job that is. As you
know, ICANN has done a lot of work on name collisions. Some of it is
pretty good like this report by JAS:
Some of it, like a wildcard that returns 127.0.53.53 for a few months, is
clever but strikes me as wishful thinking.
The IETF has technical expertise, but no way to do studies.
I would personally agree with your assessment that maintaining this list in
6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:
"f. [RFC6761] does not have provision for subsequent management of
the registry, such as updates, deletions of entries, etc…”
On Sep 16, 2016, at 8:10 PM, John Levine <jo...@taugh.com> wrote:
This is the toxic waste bit. The names don't make sense in the 6761
special use registry, since they're not being used in any way that is
or can be standardized, but they also aren't suitable for delegation
due to widespread de facto use. I also expect that if we redid last
year's debate in anything like the same way, we'd have the same
result, one or two highly motivated people who work for TLD applicants
would sabotage it.
As I hardly need tell you, it is utterly unclear whether it makes more
sense to have the IETF reserve them or, to switch hats and encourage
ICANN to put them on a list of names that aren't in use but can't be
delegated as SAC045 suggests.
One reason that the latter makes slightly more sense is that it's
likely that some of those names will eventually become less polluted,
so the list needs to be reconsidered every once in a while (years.)
For example, I gather that it's been a decade since Belkin stopped
making routers that leak .belkin traffic, and at some point most of
them will be gone.
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
DNSOP mailing list