Subject: [regext] Registrar service discovery for 3rd party access

From: Pascal Bouchareine <[email-masked]>
Date: Fri, 03 Jun 2016 14:31:07 -0700

Greetings from Gandi,

Inspired by the current ietf-draft on 3rd party operator to
registrar/registry, for which we're hoping to publish an experimental
service soon, we've been digging into RDAP-based discovery of registrar
or dns operator services (or documentation) - and how end user
experience can be improved.

I've contacted Gavin Brown about his rdap.org experiment - and he kindly
gave me a lot of interesting pointers, including this list.

We've pushed a draft here:
https://github.com/Gandi/dnsknife/blob/master/docs/extending_registrar_functions.txt

We also setup a few experimental services to test the idea:
- rdap.gandi.net
- partners.gandi.net has a rough welcome process and implements NS
changes
- ten.pm is basically faking a 3rd party operator
- rdap.io is a temporary glue, to make the documentation part work with
more registrars

We would love to hear feedback and maybe find other interested parties
wanting to work on this with us.

Regards,
Pascal

---

From: Andrew Newton <[email-masked]>
Date: Mon, 6 Jun 2016 21:16:12 +0200

Hi Pascal,

This is an interesting idea.

As for the RDAP portion, there is an existing 'links' JSON structure
which you may also leverage instead of creating a new structure. If
you are just providing links, that may be easier. If you need
additional data, then a separate structure is probably appropriate.

I hope this helps.

-andy

On Fri, Jun 3, 2016 at 11:31 PM, Pascal Bouchareine <[email-masked]> wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Pascal Bouchareine <[email-masked]>
Date: Mon, 06 Jun 2016 15:26:45 -0700

Thanks Andrew,

This seems more appropriate indeed - For now the only additional
data/property we were thinking of, was to maybe identify "embeddable"
documentation as opposed to service URIs.

After reading a bit more of RFC5988 I think we can try using an
extension relation type URI, if that makes sense.

---

From: Pascal Bouchareine <[email-masked]>
Date: Tue, 07 Jun 2016 19:01:51 -0700

> additional data, then a separate structure is probably appropriate.

I tried that in a newer version - all experimental services/components
have been updated to work with links instead.

We're using rel extension URLs to look for services. That simplifies
enumeration of services from the client point of view.