Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes

[Pieter Vandepitte <[e-mail]>]

Hi Roger,

Thanks for taking the time to answer my question.

I try to convince myself using client validation / UX argumentation. The most common user journey we experience – but maybe that’s not a typical user journey for all TLDs? – is:

  1.  A candidate Registrant visits the Registrar website
  2.  The candidate Registrant checks one or more domains
  3.  The candidate Registrant repeats step 1 and 2 on 1 or more other Registrar websites (this is typically what we see in the logs).
  4.  He selects a Registrar (most of the time, cost is the deciding factor)
  5.  The candidate Registrant “adds the domain to his cart” on the website of the selected Registrar
  6.  He fills in his contact details (Registrant details)
  7.  The candidate Registrant “buys” the domain (incl. some web hosting)

I understand that the current situation is really bad for Registrars: in step 6 the Registrant fills in his details, everything looks OK, but after selecting his web hosting etc. he clicks they “buy” button, but it seems his “contact details” are not valid.

I just don’t see yet why transactions would not be another valid approach to this problem. At step 6, the Registrar could perform the following actions:

  1.  Start transactions. Mode = auto-rollback
  2.  Create contact within transaction (transaction ID as extension)
  3.  Create domain within transaction (transaction ID as extension). Registrant id = contact id of previous command
  4.  Stop transaction. Create contact and Create domain are not persisted as transaction is auto-rollback.

(Step 1 and 2 and step 3 and 4 could be combined by allowing “start/stop transaction” as an extension of any command. But that’s just optimization. Principles are best explained by describing all steps.)

2 to 4 steps seem a lot for a client just to validate a contact, especially in terms of RTT, but:

  1.  It all depends on implementation. Using an asynchronous implementation, the negative effect of 2 commands is negligible.
  2.  As far as UX is concerned, the final delay is hardly noticed by the Registrant.

But far more important than this possible disadvantage are the advantages:

  1.  It’s a simple concept. Everybody knows transactions, rollback, etc.
  2.  I can imagine as a former developer that implementation is very straightforward for Registries with a transactional database as backend
  3.  The use of object extensions is straightforward: just apply them as you would do otherwise. No key/value concept needed.
  4.  Last but not least, it has a huge range of possibilities. Example situations which can be covered by transactions:
     *   A Registrant wants to either register 2 domains or none if one of the 2 domains can’t be registered for some reason.
     *   Various Registry policies can be detected early:

                                                               i.      Registrants can only register domains using the code points only known to their country code

                                                             ii.      A Registrant from a foreign country (ccTLDs) can only register domains for 1 year

                                                           iii.      More general:  a Registrant with extension X=Y is only allowed to register a domain if the domain extension A=B

     *   It could even be extended to other commands, e.g. testing transfer requests / domain deletes / … without actually executing them
     *   …

Not convinced? No hard feelings of course 😊

Kind regards

Pieter

--
Pieter Vandepitte
Product Expert
[phone]
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext <[e-mail]> on behalf of Roger D Carney <[e-mail]>
Date: Tuesday 17 July 2018 at 18:36
To: Registration Protocols Extensions <[e-mail]>
Subject: Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Good Morning,

Thanks Pieter. I think the real goal of Validate is improved customer experience.

I don’t think wrapping this in a transaction helps as the error identification is still occurring to late in the process.

There are quite a few steps in the registration process but today one of the main issues comes at domain create time (this is basically the last step in the process along with collecting fees).

Today, validating contacts in terms of their “roles”/contactType (Registrant/Admin/Tech/etc) occurs at Domain Create time, which is way too late for a good customer experience. A contact maybe a valid contact for the Registry but it may not be a valid contact for the “role” /contactType. So what we want to do is validate this data in as full of context as we can before the Domain Create / Collection of fees. Getting an error at this point (domain create) causes a painful customer experience and a lot of additional processing to occur.


Thanks
Roger


From: regext [mailto:[e-mail]] On Behalf Of Pieter Vandepitte
Sent: Friday, July 06, 2018 7:05 AM
To: Registration Protocols Extensions <[e-mail]<mailto:[e-mail]>>
Subject: Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Short question regarding the validate extension:

Isn’t the purpose of the validate extension to do what actually transactions are meant for? Ultimately the goal of the validate extension is to check whether a group of commands are possible: create some contacts, link the contacts to a domain with a specific role.
Why not trying to add a layer on top of EPP to enable transactions? Start a transaction, add commands to a transaction, execute a transaction with either commit or auto roll back?
I think that would lead to a much simpler model and could easily deal with other objects and other extensions.

Thoughts?

Pieter


--
Pieter Vandepitte
Product Expert
[phone]
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Roger D Carney <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions <[e-mail]<mailto:[e-mail]>>
Subject: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Sorry about the tardiness, please enjoy, see everyone in a couple weeks.

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.    Validate draft (comments, concerns, implementations)
2.    Registry Mapping
a.    Continue the lively discussion that was started in London
b.    Policy Extension Review: how a server implements an extension, the SHOULD(s), MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated charter with AD (Adam). Hopefully circulate new Charter to the group next week. Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James Gould posted to the list Monday June 4, 2018, copied below:

1.    I don’t see the purpose of the <validate:cd> element in the check command..  Initially, I thought the <validate:cd> may support a list within a list (e.g., <validate:contact>), but that is not the case.  There is also a little confusion with the use of <validate:cd> in both the check command and response.  My recommendation is to remove the <validate:cd> element from the check command and simply move all its sub-elements to sub-elements of the <validate:contact> element. [Interim] Interesting for removal, post to list.
2.    Is the extension meant to validate the contact details of existing contacts by contact id and also non-existent contacts based on the contact details, by contact type and by tld?  [Interim] Yes, both scenarios. For “new” contacts pass all data, don’t try to short cut it with only id, if only id is passed server will assume it is an existing contact. Change response validate:cd to include TLD and contact type attributes. Discussed the preferences of smaller payload versus complicated payload, went with simpler. Add a new section to 2.0 describing validate:id (Need to have response pass back contact type and tld).
a.    If both cases are true, then wouldn’t you have a choice of referencing the contact by identifier for an existing contact or defining the contact attributes for a non-existing contact?
b.    Also, what if you desire to use the same contact information for multiple contact types for a tld?

  1.  Do you need to replicate the same attributes for each contact type?  [Interim] Simple method would
  2.  It may be better to define a single contact (existing with contact identifier) or contact attributes for non-existing with the list of contact types.  I imagine that you always want to validate a contact within the scope of a tld.  [Interim] Interesting, thoughts?
3.    I view definition of only the check command and response with many contacts and with extensibility via the kv elements as somewhat non-optimal.  Other options include:
a.    Instead of supporting multiple contacts in an individual command, why not support the check or info of an individual contact with attribute extensibility via command / response extensions.  Yes, you can validate only a single contact with multiple target types and a tld at a time, but you get to use existing contact command / response extensions to define the additional contact attributes without having to use key / value pairs.  [Interim] One goal is to pass in multiple contacts and validate as a whole
b.    Create a validate command / response extension of the contact mapping that extends the contact create to function as a no-op with the additional attributes used to validate usage of the contact (e.g., object - domain, contact types, tld), which would define a validate contact validate create command.  The contact info could have been extended by the validate extension to function as a validate usage command with the usage attributes consistent with the contact validate create command (e.g., object – domain, contact types, tld).  In this case, the contact commands can be directly extended by the validate extension. [Interim] So does key/value make sense here. Can this validate extension be able to be extended with other extensions (e..g. registry has a VAT extension instead of this)?
4.    Each element needs to be fully described..  I include some examples below:
a.    <validate:contact> element does not define the required “contactType” or “tld” attributes.  [Interim] Add more descriptions
b.    There is no description of any of the <validate:cd> sub-elements in the check command or response. [Interim] Add more descriptions
5.    Wouldn’t be better to include a required “valid” attribute in the check response <validate:cd> element with an optional reason and reason language similar to the domain check response?  I’m not sure if there is a real need to define a whole list of validity errors using the list of <validate:kv> elements.  It may be good enough to short circuit the validation by simply saying yes or no and if no a human readable reason.  There would be no need for the <validate:response> element or the <validate:kv> elements.  [Interim] Should the response look more like a check response (result, and free form text response if invalid)? I like the draft format better but I understand the consistency part
6.    I don’t recommend directly referencing the urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct dependency to inclusion of the contact XML schema and namespace for a subset of the elements that are really specific to the validate mapping.  I would prefer for the validate XML schema to stand on its own by only referring to epp and eppcom, with no cross references to contact.  This would mean copying and pasting elements directly from the contact XML schema into the validate XML schema, which is an inconvenient, but makes it easier to implement.  [Interim] There has been discussion on list on this topic, continued discussion will be good.

We did not make it to the Registry Mapping discussions.