On 19-Feb-25 22:16, Stephane Bortzmeyer wrote:
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).
I think that caricatures the text. See my comment a few minutes ago
about writing style.
It is
specially unacceptable in a standards track document. This opinion
about domain name registration has clearly no consensus in the IETF.
It's for the IESG to judge whether or not there is rough consensus.
Since this isn't a WG document, this thread is where the consensus may
or may not emerge.
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).
OK, so the draft lacks some linking text. Fair comment.
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,
I'm sure. Very annoying if I wanted to register putain.fr and somebody
wouldn't allow it. Today, all I have to do is send money to a domain
parking company and I can have it. You haven't persuaded me that this
is an improvement, but none of that is the IETF's business. However,
it *is* part of the environment our protocols live in.
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.
So email purporting to come from yapa70oyuckpqha.com isn't abuse?
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.
To be honest, writing text that distinguishes in objective terms
between well-managed CCTLDs and badly-managed CCTLDs isn't easy, and
the IETF isn't here to judge individual registries or registrars.
So, perhaps this particular text doesn't help much.
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.
Well, if an author doesn't find the term they need in RFC 9499, what are
they supposed to do?
Incidentally, RFC 9499 doesn't appear to define "Domain" at all, so
certainly doesn't define "Public Domain".
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.
I think the threat analysis for look-alikes is obvious, but your point
seemed to be lack of evidence for homographs in the wild. IMHO that's
beside the point; it's the *possibility* of homograph abuse that is
the threat, and limiting that possibility should a shared goal.
Brian
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
