Hi Warren,
I think that the root issue is that there is not a simple way to determine if a name is included in "that subset of the domain namespace that is used by IETF protocols like the DNS".
I think the IETF has done fine for years understanding what the DNS/zeroconf/dnssd/whatever namespaces looks like without needing a strict definition, with due deference to Robert Persig and apologies for the oblique suggestion of quality.
People have been intentionally causing name collisions with hosts.txt overrides, nsswitch.conf, locally-served zones, etc, etc for decades and it has not caused any great indigestion. Unintentional name collisions occur every millisecond. Domains exist in some networks that do not exist in any others. Domains are missing from the perspective of some clients that are very much alive and well to the majority. Zones do not propagate instantly. People mess things up.
Every single one of these things represents an opportunity to further bifurcate the domain namespace. The resulting uncertainty has caused no end of angst at ICANN when they have decisions to make about new TLDs but does it make the understanding of what the DNS namespace is in the IETF any more difficult in practical terms?
Are we in the business of asserting control over the whole domain namespace? Do we want to be the self-appointed, enforcement-free gatekeepers who decide who can use what for what?
Is it helpful for things to be included in the special names registry because the way they were assigned or registered is special, even though there is nothing special in how they are used?
If we had decided back before 6761/6762 that the gating function for new TLDs (or other reserved domains) for new name resolution protocols was the existence of a standards track specification with all the consensus that implies, would we have needed 6761?
If ONION was used in a name resolution protocol that had been developed within or brought to the IETF, and was carefully specified on the standards track, would it's namespace considerations be any different than LOCAL?
If we can agree that the IETF's policy perimeter is driven by IETF rather than external work, perhaps what we are actually looking for in a 6761bis is to fill the gaps in that policy.
Why is LOCAL better than LOCAL.ARPA?
We decided things about AS112.ARPA with little reference to any such policy. Was that ok?
How was it that homenet specified use of the HOME domain apparently without enough scrutiny and how do we prevent that from happening again?
I think these are all good questions well within the IETF's perimeter of responsibility which I think we have a good chance of forming consensus around and which will make a difference to future IETF work.
Worrying about what other, external name resolution protocols might do, in contrast, has sucked a lot of oxygen out of a lot of rooms without any apparent danger of a decision -- and even if a decision had been made, it's not clear who would care about it.
I don't claim to have all the answers about any of this. This is complicated stuff. But I sense that the discussion has been hard for a long time because the problem space has been over-broad. I think we will do a lot better with simpler questions, ideally of the kind that we know how to talk about.
Joe