ICANN ICANN Email List Archives

[comments-whois-accuracy-14may15-en]


<<< Chronological Index >>>    <<< Thread Index >>>

Comments on 2013 RAA Whois Accuracy Program Specification Review

  • To: "'comments-whois-accuracy-14may15-en@xxxxxxxxx'" <comments-whois-accuracy-14may15-en@xxxxxxxxx>
  • Subject: Comments on 2013 RAA Whois Accuracy Program Specification Review
  • From: Will Metters <Will.Metters@xxxxxxxxxxxxx>
  • Date: Fri, 3 Jul 2015 11:15:41 +0100

Dear Sir/Madam,

Below are some comments on the 2013 RAA Whois Accuracy Program Specification 
Review.  These are personal comments and are not those of the Metropolitan 
Police Service or the UK as a whole.

ICANN Staff Input
I fully support the comments made by the ICANN staff as it largely looks to 
define terminology and procedure to reduce any ambiguity that may currently 
exists.

Registry Stakeholder Group Input
Many of the suggestions of the Registry Stakeholder Group appear to make a lot 
of sense, however a few require a little bit of further clarification.  Where a 
particular comment made by the Registry Stakeholder Group is not listed below 
it can be assumed I have no objection to it.

Section 1 - 2) Removal of "Proper Format" requirement
Whilst I agree that this requirement is d duplication of that in Section 1(d), 
I do not agree that it should be removed as for clarity it is useful to state 
that the fields need to be in the proper format.  Rather than remove this 
reference it should be appended with "as defined in section 1(d)."

Section 1 - 3) Alternative to UPU formats
The goal is more important than the method, therefore if there are other 
formats that can be suggested by the Registry Stakeholder Group then these 
should also be listed.  That said, the wording of the current text already 
states "UPU Postal addressing format templates, the S42 address templates (as 
they may be updated) or other standard formats" which would appear to already 
allow the use of alternative formats.

Section 1 - 4) Cross Field Validation
I disagree with the removal of this requirement as it should remain an 
aspirational goal when "technically and commercially feasible".  This 
requirement already allows for this to only be complied with once it is 
technically and commercially feasible, therefore it should remain in the 
specifications as technology may emerge that makes this possible.  Removal now 
could make this harder to get reinstated at a future date when it may be is 
technically and commercially feasible.

Section 1 - 5) E-Mail Validation
I do not believe that this section needs to be amended as the process described 
is already prefixed with "such as" which to me suggests that registrars are 
free to use whatever method they like so long as it requires an affirmative 
response.  If anything needs amending it would perhaps be to move the "such as" 
statement to an earlier place in the sentence so that the section reads: "the 
email address of the Registered Name Holder (and, if different, the Account 
Holder) by sending an email requiring an affirmative response such as through a 
tool-based authentication method providing a unique code that must be returned 
in a manner designated by the Registrar".

Section 1 - 6) Telephone Validation
The telephone validation is more prescriptive than the email one.  I would 
suggests the wording be changed to be more similar to the email validation one, 
perhaps something like: "the telephone number of the Registered Name Holder 
(and, if different, the Account Holder) through the requirement to receive an 
affirmative response from the Registered Name Holder such as (A) calling or 
sending an SMS to the Registered Name Holder's telephone number providing a 
unique code that must be returned in a manner designated by the Registrar, or 
(B) calling the Registered Name Holder's telephone number and requiring the 
Registered Name Holder to provide a unique code that was sent to the Registered 
Name Holder via web, email or postal mail."  This would provide a minimum 
acceptable response, some suggested methods and leave the Registrars free to 
choose the method that best suits their operating model.

Section 1 - 7) 45 Day response window
The suggestion of allowing 45 days for a response is one of the most concerning 
recommendation.  To assist with clarity, perhaps section 1(f) should explicitly 
state "15 days", but not longer.

Section 1 - 9) Alternatives to Suspension
If the Registrar Stakeholder Group could come up with some alternatives to 
suspension then perhaps a menu of options could be built to provide 
alternatives to immediate suspension dependant on the circumstances.  In some 
scenarios suspension will be appropriate, however in lower risk cases then 
alternatives could be considered if acceptable alternatives can be suggested.

Section 2 - 1) Validation and Verification for substantial changes only
Provided an acceptable definition of "substantial" can be provided then I do 
not have a problem with this recommendation.  I would suggest that if any word 
or string is changed (e.g. full or partial name change, full or partial address 
change e.t.c.) then that must constitute substantial unless that change is the 
removal or spaces, punctuation or a change of case.  Defining substantial may 
be difficult, but perhaps defining those limited scenarios whereby 
validation/verification would not be required may be easier.

Section 2 - 2) 45 Day response window
As per Section 1-7) the suggestion of increasing the response window from 15 
days to 45 days is a very concerning recommendation.  15 days is already quite 
a generous amount of time for a registrant to verify their contact information. 
 Where the verification has been prompted by a request from law enforcement, 
any increase in the time window would have a potential knock on effect for 
investigation lengths and also potentially expose more members of the public to 
becoming victims of crime.  The increase in investigation time could mean that 
other data that might be subsequently requested may no longer be available due 
to short retention times for certain data and therefore could have a 
significantly negative impact on the ability to identify and prosecute 
offenders.  Before any extension of the 15 day window I would like to 
understand why 45 days is being suggested and why 15 days is not currently 
enough.  From a public safety perspective I would prefer to the see the window 
reduce rather than increase.

In relation to the comment regarding examples of "applicable contact 
information", I support any suggestion that can assist in providing clarity, 
and the inclusion of examples is a good way to do so provided that it is clear 
whether the examples are simply suggestions, or define exactly how it should be 
done.

Section 4 - 1) Substantiated information
If the word "substantiated" is to be added, some additional information would 
be required:

*         What would constitute substantiated information?

*         Who would decide if it had been substantiated?

*         What would the minimum standards be for substantiating the 
information?

*         What time window would be allowed for the substantiating to be done?

*         What recourse would there be for the complainant to escalate the 
matter if the Registrar decided the information was unsubstantiated?

Section 4 - 3) 45 Days
As per sections 1 - 7) and 2 - 2), 45 days seems excessively long.  15 days 
already seems generous and any extension of this should require strong evidence 
as to why this extension is required.

Section 5 - Substantiated concerns around WHOIS accuracy
This recommendation states that termination or suspension should only occur 
where the registrar inquiries concerning the accuracy of the contact details 
are substantiated.  Surely if the registrant has already failed to respond to 
email and/or telephone validation attempts after 15 days then the concerns have 
been substantiated?

Kind Regards

Will Metters
Member of the UK Public Safety Working Group

Total Policing is the Met's commitment to be on the streets and in your 
communities to catch offenders, prevent crime and support victims. We are here 
for London, working with you to make our capital safer.


Consider our environment - please do not print this email unless absolutely 
necessary.


NOTICE - This email and any attachments may be confidential, subject to 
copyright and/or legal privilege and are intended solely for the use of the 
intended recipient. If you have received this email in error, please notify the 
sender and delete it from your system.  To avoid incurring legal liabilities, 
you must not distribute or copy the information in this email without the 
permission of the sender. MPS communication systems are monitored to the extent 
permitted by law.  

Consequently, any email and/or attachments may be read by monitoring staff. 
Only specified personnel are authorised to conclude any binding agreement on 
behalf of the MPS by email. The MPS accepts no responsibility for unauthorised 
agreements reached with other employees or agents.  The security of this email 
and any attachments cannot be guaranteed. Email messages are routinely scanned 
but malicious software infection and corruption of content can still occur 
during transmission over the Internet. Any views or opinions expressed in this 
communication are solely those of the author and do not necessarily represent 
those of the Metropolitan Police Service (MPS).

Find us at:
Facebook: facebook/metpoliceuk
Twitter: @metpoliceuk


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy