Subject: [regext] Fwd: New Version Notification for draft-mayrhofer-epp-domain-suggest-00.txt

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 1 Nov 2019 21:00:39 +0100

Hello everyone,

i've create a rough cut of a draft describing an EPP extension to
convey Domain Suggestions. I'm planning to do a small side meeting
with interested people outside to gauge interest, but i'm also happy
to grab 5 minutes off the regext session in Singapore to present the
idea.

As always - feedback highly appreciated!

best,
Alex

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Nov 1, 2019 at 8:57 PM
Subject: New Version Notification for draft-mayrhofer-epp-domain-suggest-00.txt
To: Alexander Mayrhofer <[email-masked]>

A new version of I-D, draft-mayrhofer-epp-domain-suggest-00.txt
has been successfully submitted by Alexander Mayrhofer and posted to the
IETF repository.

Name:           draft-mayrhofer-epp-domain-suggest
Revision:       00
Title:          Domain Suggestion Extension for the Extensible
Provisioning Protocol (EPP)
Document date:  2019-11-01
Group:          Individual Submission
Pages:          7
URL:
https://www.ietf.org/internet-drafts/draft-mayrhofer-epp-domain-suggest-00.txt
Status:
https://datatracker.ietf.org/doc/draft-mayrhofer-epp-domain-suggest/
Htmlized:
https://tools.ietf.org/html/draft-mayrhofer-epp-domain-suggest-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mayrhofer-epp-domain-suggest

Abstract:
   This document specifies an EPP Extension that allows servers to
   suggest available domain names to clients, for example in cases where
   the originally desired domain name is unavailable for registration.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 01 Nov 2019 15:15:07 -0500

Hello Alexander,

> As always - feedback highly appreciated!

3 quick ones more on the form than the substance:

- did you look at other extensions existing?
I know at least about one having namespace http://www.verisign-grs.com/epp/suggestion-1.1
(I do not know the status of it as it has been removed from latest Verisign SDK,
but it existed).
There may be others.

- whatever you choose, and even if not technically important, please do not
use "ds" as an XML alias. Too much confusing with DS from DNSSEC.

- please stick to RFC2606 when choosing names for examples (ie: do not use the TLD .tld)

-- 
  Patrick Mevzek
  [email-masked]

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 1 Nov 2019 21:40:34 +0100

Hello Patrick,

thanks for the very fast feedback. Responses inline:

> (I do not know the status of it as it has been removed from latest Verisign SDK,

Hmm, good point - i didn't check, didn't remember - and, indeed,
there's one registered at ..., here's the direct link to the spec:
https://www.verisign.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf?inc=www.verisigninc.com

It does indeed serve a very similar purpose, has more options, but is
also more complex. I guess i will have to talk to Scott to understand
why it was removed from the SDK..

> use "ds" as an XML alias. Too much confusing with DS from DNSSEC.

Right. Not a good idea, agreed.

> - please stick to RFC2606 when choosing names for examples (ie: do not use the TLD .tld)

I wanted to do that, but RFC2606 sadly provides only a very limited
choice. I wanted to include something else besides subdomains, that's
why i went off-path of the RFC. I know i would not get that past the
RFC editors, and will change this if the document progresses further.

best,
Alex

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 01 Nov 2019 15:49:16 -0500

> why it was removed from the SDK..

+1
 
> choice. I wanted to include something else besides subdomains, that's

You can use the .example TLD
So just s/\.tld/.example/g and everything is fine. But clearly bike shedding at this point.

Will try to read the draft more deeply later for substantive feedback, if any.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Sun, 03 Nov 2019 19:06:16 -0500

> As always - feedback highly appreciated!

Some others more substantive comments that I think have huge consequences:

- generating suggestions is surely costly for the registry, and hence should
not be done if not strictly necessary; hence said otherwise, besides
the negotiation at login, the registrar should or must have  a way to say, per command
"i want a domain:check with suggestions" or "i want a domain:check without  suggestions".
Like in the launchphase extension, where a single domain:check can return different
results depending on the phase.

Besides being costly to generate by the registry,
the registrar has no way in advance to know the size of
the response which can be a big problem for it.

This may show in fact that extending domain:check is maybe not the right way
to do and a specific separate command may be better

- multiple registries handle multiple TLDs: the registrar asking for suggestions
may wish to restrict the TLDs of suggestions, and hence need a way to convey that.
What if the registrar is not accredited for all TLDs in that registry?
Extending that, registrars may want to have more knobs to have the registry
returns results tailored to their needs:
* domain length
* using IDNs or not
* "language" or geographic target
* use of hyphens or not
etc.

I am sure everyone can see dozens of possible such settings.
Another way to not  explode in complexity but still enable various results,
the registrar could pass a "profile" name, which would be any opaque id
but the registry would announce, out of band, that profile named X means search
is done using such and such cases, etc.

It is not clear also if domain names returned are guaranteed (at that time)
to be available for registration or not.

At this stage, to be honest, I fear writing a specification is too early.
Various people have expressed interests, there seems to be already some
private/local implementations on various protocols,
and even a past EPP extension, so I think for now it is maybe better to be collecting
the use cases, the goals wanted, and looking at what exists,
to be able to first define what work needs to be done... before doing that work.

I guess I am looking more at past examples like
RFC 3375 "Generic Registry-Registrar Protocol Requirements"
or
RFC 7485 "Inventory and Analysis of WHOIS Registration Objects"
that were written before any work took place.

-- 
  Patrick Mevzek
  [email-masked]