On 16.10.22 12:03, Brian Dickson wrote: > 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 was my impression that the .alt draft is supposed to guide alternative name system developers and show how they can deploy their namespaces safely. A system that can resolve names (in the very generic sense) does not necessarily have a concept for such a "suffix" because it does not necessarily define the namespace so there is likely additional overhead in specification and development. Also, for users there is the additional cognitive overvead because of the longer names. IMO there are two "safety goals" that were discussed until now and one of them was explicity tossed by the original email: 1. "Protect the DNS namespace": If users/zone owners of alternative name systems want to safely deploy a namespace that "integrates"/does not collide with DNS they can(!) pick TLDs with the ".alt" suffix. ".alt" is good(TM) because DNS resolvers safely ignore such names because it is registered as a SUTLD. 2. "Prevent collisions of namspaces under .alt": Alternative namespaces currently already collide with DNS and other alternative namespaces. So, it makes sense to provide a mechanism to prevent this similarly to how ".alt" protects DNS. In order to "reel in" other name system developer groups that propose namespaces the registration of (sometimes reffered to here as "vanity") 2LDs level domains under ".alt". This "recognition of alternative name spaces"(sic) is IMO a very important factor to consider. Without such a measure, (1.) is likely to be very ineffective as there is little benefit to the groups in question. In other words: for (1.) to work you need to embrace alternative name systems more. Without this, you are building walls, not bridges. A final thought: If the registration issue cannot be solved and the document only focusses on (1.) then I would suggest not bikeshedding the 2LD because you will always be risking making it worse (e.g. hashes as names). Instead, just let alternative namespaces squat on .alt. This makes names potentially shorter, and DNS is still safe. Anything below .alt: "here be dragons". Maybe a registry will form itself, but I do not see why the draft would even have to mention that. It should explicitly state the chaotic and unsafe nature of .alt. This is similarly unattractive* as, for example, the hashing-idea, but will save you a significant amount of time. In our draft we can then add a configuration consideration for implementers that such a thing as ".alt" exists and can be used to prevent a variety of issues relating to DNS. BR Martin *well, maybe even a bit less unattractive. > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
