The IRT has reached closure and consensus on the wording for Urgent Requests.  Here are the concerns I continue to have.

1.     How to reach the registrar

So far as I can tell, the proposed procedures and policies do not include a well specified means for reaching a registrar urgently.  This seems to me a gap, i.e., an incomplete solution.  A gap of this sort means the proposed system is not fit for purpose (NFfP).  NFfP is a showstopper.  No amount of process or consensus or reference to the policy development process manual overcomes NFfP.

Current registrar contact info is idiosyncratic, i.e. not organized in any uniform way.  Some of the registrar representatives (Sarah, Owen) claim law enforcement personnel know how to reach them.  Some law enforcement personnel (Gabe) say that when law enforcement specific contacts exist, they are not universally known to all law enforcement entities for all registrars.

Whois queries now include contact info for reporting Abuses.  However, when I suggested LEA could use the Abuse contact, a registrar representative said fielding Abuse reports and fielding Urgent Requests requires different skill sets, and the people on duty to handle Abuse reports cannot be used to field Urgent Requests.

This begs further discussion.  What will the person fielding Abuse complaints do if the input is from a law enforcement agent presenting an Urgent Request?  Further, law enforcement personnel, when asked “What do you actually do in practice?” respond, “We use all available means.”

I suggested registrars supply a contact for Urgent Requests, and that it be available only to trusted requesters, principally known law enforcement personnel.  Further, ICANN could maintain such a list and act as an intermediary.  The financial impact on registrars should be negligible because this only requires reaching a responsible party within the registrar.  It does not impose any specific requirement on what the registrar does with the call.  Making the contact data available only to trusted personnel and/or having ICANN field the requests would essentially eliminate the registrars’ concerns about being inundated with false requests.

 If I recall correctly, this was rejected for two distinct reasons.  One was an insistence that such calls would necessarily require bringing an attorney into the conversation to determine whether the request is genuinely Urgent and that it is permissible to provide the requested data.  The other response was this constituted a new proposal and thus is outside the scope of the Implementation Review Team.

2.     Actual data

There does not seem to be any data on situations that have arisen in the past that resulted in Urgent Requests.  Or, even if the criteria is loosened to include other requests that do not fit the narrowly defined definition of an Urgent Request but nonetheless were urgent (lowercase) and high priority, there doesn’t seem to be any concrete data.

This makes it hard to know whether there really needs to be a defined procedure for handling Urgent Requests.  I assume the group has nonetheless agreed to this.  Going forward, Urgent Requests should be reported and the data reported on a regular basis.

As far as I can tell, nothing along this line is included in the current proposal.  This is not a showstopper, but it’s a lack and should be addressed.

3.     Confusion; Optics

The wording embodies two kinds of confusion.  First, by emphasizing the maximum response time, it creates the impression that ICANN is officially specifying the response time for Urgent Requests to be measured in days.  This is both confusing and a bad look.  At the very least, the description of the rule should make it clear that registrars are expected to respond quickly.  The specification of a maximum response time is intended to deal with worst case situations, not normal emergencies.

Second, the registrars are really looking for protection against harassment or penalty if they haven’t responded quickly.  Whether the response time is 24 hours or several days due to vacations is probably not relevant for Urgent Requests.  It will be too late.  Instead, the purpose of this specification is to protect registrars from having to maintain a standing army of lawyers and to protect themselves from a flood of bogus requests.

Much clearer wording would help.