On Sat, Feb 15, 2025 at 09:26:27AM +1300, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote a message of 116 lines which said: > they certainly do not prevent discussion of business models as > such. Descriptions of use cases are extremely common in IETF > documents, and those often amount to descriptions of business > models. In the current draft, it is not a discussion or a description, but a strong opinion (automatic and cheap registration = bad, human-controlled, slow and "careful" registration = good). It is specially unacceptable in a standards track document. This opinion about domain name registration has clearly no consensus in the IETF. > I see analysis of the (presumably unintended) side effects of cheap > for-profit domain name registration, which is entirely appropriate > as background for the normative part of the draft. There is no relationship I see between this "analysis" and the normative part (which is just section 5). > The fact that many for-profit registrars allocate domain names > automatically, with purely mechanical checks, for a very small fee > that *by construction* excludes any possibility of human judgment is > a major enabler of confusing and deceptive domain names. Again, this opinion is not an IETF consensus. My employer had a policy of checking manually every registration, a long time ago, and everybody and his cat hated that, and it did not even prevent deception. > It could perhaps have been stated more explicitly that removing > human judgment from the registration process has exposed the DNS to > abuse Again, experience shows otherwise. We tried it. > > Another serious issue is that, while it refers to RFC 9499 on domain > > name and DNS terminology, it creates new definitions (section 4) which > > are quite vague and do not seem useful for IDNA. I've read the > > beginning of section 4 with the definitions of "zones operating > > primarily" and I still don't know where .fr would fit, for > > instance. > > I don't see any ambiguity in "Zones operating primarily or exclusively > within a organization, enterprise, or country ...". You do not mention the rest of the paragraph, which confuses me even more. > > The mention of "public domains" is specially confusing. (RFC > > 9499, section 9, has the proper definitions, which should be used.) > > Rather, I would say, the draft should explicitly use and if necessary > extend those definitions. Strong no. RFC 9499 was the result of a serious effort and I see no need to "extend" it outside of a 9499bis revision. > But I don't see that the present draft has any duty to provide a > full threat analysis; illustrative threats are enough to justify > preemptive counter-measures today. Strong no again. When you propose things that will limit the possibilities of the Internet users, you need to back that with a serious threat analysis. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
