[IRT.RegDataPolicy] Happy Lunar New Year

Fri Feb 12 20:03:39 UTC 2021

Thanks for the feedback Dennis. 

I still cannot understand why this matter is being overly complicated when it does not need to be. ICANN has utilized business days for over 20 years in the UDRP, over 5 years in the UDRP Rules, and the DNS continues to operate without problem. 

The pertinent sections are: 

UDRP 4(k): 
If an Administrative Panel decides that your domain name registration should be canceled or transferred, we will wait ten (10) business days (as observed in the location of our principal office) after we are informed by the applicable Provider of the Administrative Panel's decision before implementing that decision 

UDRP Rule 4(b):
Within two (2) business days of receiving the Provider's verification request, the Registrar shall provide the information requested in the verification request and confirm that a Lock of the domain name has been applied. The Registrar shall not notify the Respondent of the proceeding until the Lock status has been applied. The Lock shall remain in place through the remaining Pendency of the UDRP proceeding. Any updates to the Respondent's data, such as through the result of a request by a privacy or proxy provider to reveal the underlying customer data, must be made before the two (2) business day period concludes or before the Registrar verifies the information requested and confirms the Lock to the UDRP Provider, whichever occurs first. Any modification(s) of the Respondent's data following the two (2) business day period may be addressed by the Panel in its decision. 

Although I cannot speak to specific cases I processed and oversaw while at Compliance, I can assure that it was never a problem calculating business days for compliance purposes. When checking to determine compliance, we would ask the registrar to let us know what the business day count was and why there may have been delays. Because UDRP 4(k) clearly states it is the principal place of the registrar to determine, it was easy to confirm/validate. 

The 2009 RAA referenced both business and calendar days, and one of the often overlooked changes of the 2013 RAA was a move towards business days instead of calendar days. It is my recollection that this too never an issue during compliance reviews of registrar actions. 

I understand the desire of some parties to want to get things done ASAP due to a perceived urgency, but that is not the reality for many contracted parties. The vast majority are not staffed to a size that can allow for full operations during weekends and business holidays, and as they already operate under the business day requirement for ICANN for most other matters, it is simpler to adopt that to this process as well. 

Also, in the event that there is a significantly urgent matter, contracted parties already maintain separate abuse handling processes as required by ICANN that do accommodate shorter timelines. 

Let’s stick to a uniform approach (business days) and move ahead with the already significantly delayed implementation of this policy. 

Regards,

Owen

> On Feb 12, 2021, at 07:40, Dennis Chang <dennis.chang at icann.org> wrote:
> 
> Dear IRT,
>  
> Happy Lunar New Year! 
>  
> It’s an important holiday for many Asians.
> It’s actually a much bigger of a holiday than 1 January holiday.
> Many Asian businesses will close for the day and some for weeks to follow.
> Interestingly enough, some Asian businesses in the US may close till Monday next week due to US Holiday on Monday (President’s day).
>  
> So what this means is that if your requirement is defined in hours or calendar days, it’s universally understood.
> However, if your requirement is in terms of business days, one day could be understood as 24 hours, 4 days, or even 3 weeks for Asian businesses.
>  
> As I consider the language around response times, I struggle with how I should understand the intention of the recommendation.  I thought I’d share my personal experiences having spent many years in Asia and seek understanding from others.  One important reason is that we, the staff, are working on educational material where we will explain the requirement for implementation and enforcement.  We may explain that the requirement is made intentionally unclear as it was decided that way by the recommendation – it’s a feature that provides flexibility for example; requirement that is designed not to be applied equally i.e. 
>  
> As we open year of Ox (or Bull in my mind), RegDataPolicy and all of you are on my mind.
> I wish the health, fortune, and happiness for the IRT and forever grateful for your guidance in my ICANN work.
>  
> -- 
> Gratefully Yours,
> Dennis S. Chang
> GDD Programs Director
> Phone: +1 213 293 7889
> Sykpe: dennisSchang
> www.icann.org <http://www.icann.org/> One World – One Internet
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org <mailto:IRT.RegDataPolicy at icann.org>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://mm.icann.org/mailman/listinfo/irt.regdatapolicy>
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20210212/cd18dbf4/attachment-0001.html>