On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear <l...@lear.ch> wrote: > Hiya! > > Thanks to Suzanne and the chairs for moving things forward. On this point: > On 16.10.22 17:22, Warren Kumari wrote: > > > >> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the >> basis that having the IETF “recognize” (if only by recording) such >> pseudo-delegations may serve to attract unwanted attention to the IETF’s >> supposed recognition of alternate (non-DNS) namespaces as reservations of >> the namespace from the shared, common DNS root. We’re still being denounced >> in certain corners for .onion. It might be good to have a paragraph calling >> out specifically why .alt is not a delegation of a TLD from the DNS root by >> the IETF, even though it looks like one. (We didn’t invent this problem, >> because we didn’t make the decision that top-level domain labels should be >> used by other protocols in a way that led to confusion. But let’s not >> propagate it.) >> > > > Yup. This is (IMO) the area of the draft where the consensus was the least > clear. I still think that it would be useful to have a *purely* > informational list saying "Group A says it is using string B and their > documentation is at https://foo.example.com"; and "Group X also says that > it is using string B and their documentation is at https://bar.example. > <https://foo.example.com/>net". Enough people have pushed back on asking > IANA to host this that I think that it should be removed (and I was the one > most strongly arguing for it). Obviously it's the DNSOP WGs decision, but I > won't argue for keeping it :-) > > > A few points: > > First, absent at least an FCFS registry there will be no ability to > programmatically switch against the label. If multiple entries exist this > is particularly painful. If no registry exists, then perhaps multiple > unofficial registries will pop up and we're in the same boat. Let's not > have that. That programmatic switch is important. It allows multiple > naming systems to co-exist all the way to the level of the application > (e.g., end-to-end) without any ambiguity being introduced. > > Second, people have been concerned about the possibility of vanity > registries. Requiring an RFC puts an end to that. I don't think we want > to *endorse* any particular approach, but IANA maintains many registries, > and nobody has ever taken any of their entries as endorsements. > > I suspect most of the burden here will fall on the Independent Submissions > Editor (currently me) with maybe a little falling on the IRTF, because I > doubt we will see a lot of consensus in the IETF for alternate naming > systems. I think some are worried that this will change the nature of the > IETF, but to me this confuses names with naming systems. Creating a naming > system is no mean fete. > > To address the possibility that we DO see a lot of requests, we can create > different types of failsafe mechanisms. They could be any or all of the > following: > > 1. If more than one assignment occurs within a year, no assignments > may occur in the following year. > 2. After N assignments, the IAB MAY suspend this procedure if they see > evidence of abuse, and refer the matter back to the IETF for further > consideration. > 3. This group can always amend the document based on whatever > experiences we see. > > I'm confident that there are other approaches as well. > The main problem that a registry is intended to solve, is the collisions among apex labels of various alternative naming systems.
This problem is rooted in the "naming system group chosen" aspect. I think there is a relatively simple technological solution to the naming system label collision problem. Consider what the registry would basically consist of: - semantic label (what would currently be used as the apex label, e.g. "foo.alt") - project URI Note the following characteristics of these elements: - The apex label is a "switch", but is otherwise not actually used (or meaningful) within the naming system (i.e. it is an arbitrary element, and usage is basically limited to a binary "compare" to any input to the non-DNS resolution system of the project) - The URIs of different systems will, by definition, be distinct (i.e. unique to the system) The obvious (to me at least) solution is to generate the apex label programmatically, e.g. encode the URI as the label to be used as the switch, rather than the name system's potentially ambiguous semantic name. For example, using a hash function, such as sha2-256, with output encoded as base32hex. (This is just an example; any suitable function that takes URI as input and produces an ASCII DNS-compatible label as output would suffice.) It would still be reasonable to have a registry somewhere of a table of "name, URI, hashed-URI-label". The difference is that it would no longer matter what order entries are added, and collisions cannot occur. Having two projects that want to call themselves "foo", the table entries would be: "foo","https://foo.example.com","deaddeaddeaddead"; // where hash_function(" https://foo.example.com";) == "deaddeaddeaddead" "foo","https://foo.example.net","beefbeefbeefbeef"; // where hash_function(" https://foo.example.net";) == "beefbeefbeefbeef" Having IANA or ISE validate the existence of individual URIs upon submission, and doing periodic garbage removal of no-longer-valid URIs, would address the vanity aspect, I suspect. Thoughts? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
