Domain disputes: special reserved list (dispute domains)

[vohmar]

As of 1st of January 2017 the domains registrations that have been successfully disputed must be reserved for the contender for up to 3 years.

• new list (dispute domains) similar to reserved domains list (/admin/reserved_domains) - columns name, pw, created/updated at, valid to, actions. Filter fields - name, valid to from , valid to until, results per page
• domain form for adding domains to the list similar to reserved form (/admin/reserved_domains/new) with additions of mandatory 'valid to' and 'comment' (for url to dispute decision) fields
• registry must check that in case of epp domain update query with <domain:chg><domain:registrant> element (ie registrant change) the domain is not in the dispute domains list - if it is in the list the <eis:extdata><eis:reserved> element with correct password must be present in the extension block
• registry must check that in case of epp domain create query the domain name is not in the reserved nor dispute domains lists - if it is the <eis:extdata><eis:reserved> element with correct password must be present in the extension block
• if a domain name that is in the reserved domains list is added to the dispute domains list reserved list password is replaced with the new password from dispute domains list (if a domain in the dispute list is added to the reserved list the password in the reserved list is set from the dispute list - admin needs to be notified if the optional password field had a value in it - "proposed password rejected, dispute password used instead") - password for any domain in both reserved and dispute lists must be the same (shared)
• if the password for a domain in dispute list is used for domain create or domain update the domain is deleted from the dispute list (in case of reserved domain - the reserved password is reset like in regular reserved domain registration)
• The domains in dispute list will get a dynamic disputed status in WHOIS identically to current reserved and blocked statuses. Described in sub-issues Disputed status rest-whois#29 and Disputed status whois#15
• If the contender does not register the domain within the period of 3 years since the dispute decision (valid to of dispute list record) the domain will be removed from dispute list.

---

To test:

1. WHOIS regeneration: on domain update
2. WHOIS regeneration: on contact update
3. WHOIS regeneration: manually via rake whois:regenerate
4. /registrant/whois
5. WHOIS regeneration: on domain delete
6. Dispute/Blocked Domain/Reserved Domain management

[artur-intech]

№ 3, 4: What is the expected behaviour if validation fails?

[vohmar]

No3, 4: If reserved pw is missing for a domain in the dispute list an error must be returned
2003: Required parameter missing; reserved pw element required for dispute domains

[artur-intech]

created/updated at

I don't see update action listed above, so probably there is nothing to track?

If the contender does not register the domain within the period of 3 years since the dispute decision (valid to of dispute list record) the domain will be removed from dispute list.

automatically via CRON?

[artur-intech]

6 disputes per year

[artur-intech]

How about leaving our "Results per page" feature? I can't imagine usage case.

[artur-intech]

Does "password" field remain optional?

[artur-intech]

Can I implement domain selector as a drop-down, instead of a text field as it is in "reserved domains" section?

[vohmar]

1. the password should be editable (like in case of reserved list). Also the comment and valid to values should be editable - everything that is entered manually by admin.
2. cron is OK
3. results per can be left out from initial implementation (in case it is time consuming), but might be necessary for some other, bigger registry if one should be interested in using our registry software.
4. password field in optional in the sense that if left blank system will have to generate it (like in the case of reserved list)
5. yes, domain selector can be drop-down if it will not present performance issues with generating the values in the drop down

[artur-intech]

№ 1 OK, but only time of the last update will be tracked. Does it seem helpful?
№ 4 So it is either entered by a user or generated by the system automatically?
№ 6 Is "comment" field free-text?

[artur-intech]

№ 7: Is there a limitation of one dispute per domain?

[vohmar]

1. better if we could track the whole history with dates and updator info
2. yes, password is always set and necessary
3. yes, comment field is free-text
4. yes, there can be only one effective decision per domain

[artur-intech]

№ 6: Are you sure single comment field is enough? Perhaps it's worth implementing something more sophisticated, say like this: http://prntscr.com/e3kxkz?

The same could be applied to another entities as well (say, domain or contact)

[artur-intech]

№ 7: Do we need to validate that expiration date? For example to make impossible to use date in the past.

[artur-intech]

№ 8: Is pagination needed? I guess not given the amount of records?

[artur-intech]

№ 9: What is the default order on dispute list page?

[vohmar]

6. yes, I do not see the need for extra details. The comment field is for storing reference to the dispute case, there is no need for detailed description in registry system
7. this is nice to have feature - helps admin from making one type of mistake
8. pagination is not necessity, but in the context of having unified views and reusable code it might also be a good idea to have it. Your decision - what ever looks good and is simple to implement
9. default order should be latest/newest records first

[artur-intech]

№ 10: Do you want to be able to delete entries (manually)?

[vohmar]

10. yes, ie to remove records with typos. There must be a "are you sure" sanity check.

[artur-intech]

#355 is needed for this ticket, so I need to merge it.

[artur-intech]

№ 11: Is this the correct response if the password is invalid?

<result code="2202">
  <msg lang="en">Invalid authorization information; invalid reserved&gt;pw value</msg>
</result>

[artur-intech]

№ 12: How about introducing separate dispute view? Otherwise all fields do not fit well in the list http://prntscr.com/e51taj

[artur-intech]

№ 1: Is some UI needed to be able to browse deleted records?

[artur-intech]

Blocked by #536

[vohmar]

1. yes admin must have access to the "deleted" dispute records

[artur-intech]

domains.reserved?

[vohmar]

1. disputed status is missing - not present in registry/epp not whois
2. restwhois ei toimi - uurin martiniga mis seal viga võib olla
3. please use reserved element for disputed password - adding disputed element means development for registrars and that might be a problem
4. domain update / edit view needs an additional field to enter the reserved password - ideally this field should be dynamic, available only if the domain in question is disputed (consider effort - this is nice to have)
5. if verified yes element is missing from domain update the update request is put in bending but domain is already reamoved from the disputed list. If request is not confirmed wihting 48 hours the pending requet is canceled, previous owner remains as registrant but domain is free of disputed restrictions. Prefered solution here would be to autoconfirm reigstrant change id correct password is provided.
6. if admin deletes the disputed record it is not moved to expired / closed disputes list
7. there should not be a delete button for expired/closed disputes - as we do not have archive table for disputes (ie log_disputes) we need to save history. Instead we should show the date when the record was removed from active dipsutes list and if possible together with reason (registered/expired/deleted)
8. in the add to disputed view under start at cell there is a comment "Must be at least today / in future" that is not true. User can enter any date in the field. Actually the date should be today or in the past becuase domain should not be inserted to disputed list unless the dispute commitee's decision is in force. But this gives an alternative use case of not adding any manual statuses to prohibit unwanted updates to the registration. Will discuss this with registry admin.

[karlerikounapuu]

@vohmar

disputed status is missing - not present in registry/epp not whois

It's implemented just as reserved domain, eg. it's manipulated directly in WhoisRecord. Should it be viewable / editable as a status in registry as well? If it should, then registry admin must keep track of expiry dates herself because it's automated only in case Dispute model is created.

As per current implementation it should be present in whois/rest-whois. True, *-disputed-status branch (in rwhois/whois) should be applied at time.

restwhois ei toimi - uurin martiniga mis seal viga võib olla

This PR additionally required changes in rest-whois end. It should be tested in conjuction with rwhois/whois *-disputed-status branch. Otherwise it may trigger error about serializing.

[vohmar]

Comments:

1. We might indeed escape the need to add disputed status on registry level, whois could be enough just like in case of reserved and blocked domains. But there is a slight difference here - while in case of reserved domains the reserved status is there only in case the domain is not registered with disputed domains the status should possibly be always there even if the domain is registered to note that registrant change is restricted. Whois and rest-whois records' updating needs some mapping to understand why the statuses are not there in staging
2. is fixed now - rest-whois is working on staging

Additional issues:
9. removing a domain from disputed list while it is not registered should put the domain in auction list (if the listing expires or admin deletes it)

[vohmar]

State after new complete test run:
4. the password field was still missing from domain edit view (for domains in disputed list)
9. restwhois returns internal error for a domain in disputed list that was deleted, whois does not return anything
10. Its possible to add domains into disputed list that are not registered - lets add a warning to admin for this case to help in case of typos
11. the DisputeStatusUpdateJob does not log or return any results to stdout - it should at minimum declare how many domains were archived and preferably with domain names that were removed from active disputed list.

additional comments and ideas:

• please rename the menu option for domain disputes to disputed domains to mach the style of other lists ie reserved domains and blocked domains
  *expired/closed disputes list in admin - remove password column, replace expires at column with expired/closed at column, add updator column to mark who/what removed the record from diputes (expire job, admin, registrant change, registration)

[vohmar]

Latest rest results:
4. the password field did not show when error message was returned ie for not adding password for registrant change
11. job logs results but returns incorrect information. An example:

I, [2020-05-21T13:10:47.768349 #11673]  INFO -- : DisputeStatusUpdateJob - Found 2 closable disputes
DEPRECATION WARNING: PaperTrail.whodunnit is deprecated, use PaperTrail.request.whodunnit (called from add_updator at /home/registry/deploy/releases/20200520150349/app/models/concerns/versions.rb:26)
I, [2020-05-21T13:10:48.211055 #11673]  INFO -- : DisputeStatusUpdateJob - closed dispute  for 'timoajalugu10.ee'
I, [2020-05-21T13:10:48.276470 #11673]  INFO -- : DisputeStatusUpdateJob - Failed toclose dispute for 'timoajalugu9.ee'
I, [2020-05-21T13:10:48.277901 #11673]  INFO -- : DisputeStatusUpdateJob - Found 0 activatable disputes
I, [2020-05-21T13:10:48.279222 #11673]  INFO -- : DisputeStatusUpdateJob - All done. Closed 1 and activated 0 disputes.
I, [2020-05-21T13:10:48.279482 #11673]  INFO -- : DisputeStatusUpdateJob - Failed to close disputes with Ids:[20]

in reality both domains were successfully removed form dispute list. The supposedly failed timoajalugu9 was successfully sent to auction.

12. any domain update request (unless there is registrant element with current id present in the chg section) returns error requiring reservedpw. In reality only registrant change should be prohibited without correct password