ICANN/DNSO
DNSO Mailling lists archives

[nc-impwhois]


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

Re: [nc-impwhois] Response from Louis Touton regarding the 15 dayperiod


this is my interpretation as well

ken stubbs
----- Original Message -----
From: "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au>
To: <nc-impwhois@dnso.org>
Sent: Friday, January 31, 2003 12:14 AM
Subject: [nc-impwhois] Response from Louis Touton regarding the 15 day
period


> It would appear from below that the 15 days is not a hard limit, and that
the implementation committee proposal with regard to 30 days does not
transgress the current contracts.
>
> Regards,
> Bruce Tonkin
>
>
> -----Original Message-----
> From: Louis Touton [mailto:touton@icann.org]
> Sent: Friday, January 31, 2003 4:02 PM
> To: nc-whois@dnso.org
> Cc: Dan Halloran; Bruce Tonkin; roessler@does-not-exist.org
> Subject: [RE: [nc-whois] FYI - ALAC discussions on 15 days issue]
>
>
> Marilyn,
>
> In our recent telephone conversation, we discussed that it might be
> useful to the Whois-policy-development process to summarize the
> currently effective requirements concerning what has been referred to as
> the "15-day period."  Some of the comments about the requirements
> indicate that the current requirements are misunderstood, even by
> sophisticated analysts.  (Compare, for example, Bret Fausett's 8 January
> 2002 comment on the Task Force's Whois report at
>
<http://dnso.dnso.org/dnso/dnsocomments/comments-whois/Arc02/msg00021.html>
> with his 11 January correction to that comment, noting that he had
> confused two different 15-day periods.  The correction is copied at the
> bottom of this message.)  Perhaps some level of confusion is inevitable
> concerning agreements that have many provisions with complex
> interworkings.  A clear understanding of the current requirements,
> however, should be helpful in assessing the merits of various suggested
> policy changes.
>
> Subsection 3.7.7.2 of the current (May 2001) registrar accreditation
> agreement requires that registrars include in the registration
> agreements they enter with their customers a provision that *permits*
> the registrar to cancel a domain-name registration in either of three
> circumstances:
>
>     1.  The customer's "willful provision of inaccurate or unreliable
>     information";
>
>     2.  The customer's "willful failure promptly to update information
>     provided to" the registrar; or
>
>     3.  The customer's "failure to respond for over fifteen calendar days
>     to inquiries by Registrar concerning the accuracy of contact
>     details".
>
> Condition (3) above, it should be noted, is only triggered when the
> customer fails to respond to an inquiry; it is not triggered when the
> customer responds to the inquiry but does not complete any corrections
> to inaccurate or out-of-date Whois data within 15 days.  Unlike
> conditions (1) and (2), which require willful transgressions on the part
> of the customer, condition (3) is triggered without a specific showing
> that the customer's failure to respond is willful, in recognition that
> the ability to prove willfulness tends to be frustrated by a customer's
> refusal to engage in dialog with the registrar.
>
> Subsection 3.7.7.2 of the registrar accreditation agreement does not
> *require* a registrar to cancel a registration in the event a customer
> fails to respond within 15 days.  The current contractual structure of
> requiring the registrar to retain the *right* to cancel if the customer
> fails to respond in 15 days, but not requiring the registrar to
> *exercise that right* is intended to give the registrar the flexibility
> to use good judgment to determine what action should be taken upon a
> customer's failure to respond to an inquiry about a Whois inaccuracy.
> According to the theory of the current registrar accreditation
> agreement, the appropriate course of conduct for a registrar varies
> depending on a variety of factors--including the materiality and
> severity of the inaccuracy, the customer's past conduct with respect to
> correcting inaccuracies, the extent of harm to third parties, etc.
> Where an inaccuracy is minor (e.g., an incorrect postal code), appears
> inadvertent (e.g., transposed digits), and harms no third party (e.g.,
> readily available means of contacting and locating the customer are
> provided by the data that is given), the case for immediate action is
> weak.  The contractual design is that in such cases the registrar, which
> after all is motivated to promote good relations with its customer, will
> not act precipitously. Where, on the other hand, it appears that a
> customer has deliberately provided severely false Whois data and third
> parties are being significantly harmed by the maintenance of the
> registration with the inaccurate data, prompt action by the registrar is
> appropriate.  Under the theory of the current registrar accreditation
> agreement, the registrar is given discretion to act as appropriate in
> the particular circumstance of the particular case.
>
> The provision of the registrar accreditation agreement limiting the
> registrar's discretion is subsection 3.7.8, which states in part:
>
>    Registrar shall, upon notification by any person of an inaccuracy in
>    the contact information associated with a Registered Name sponsored by
>    Registrar, take reasonable steps to investigate that claimed
>    inaccuracy. In the event Registrar learns of inaccurate contact
>    information associated with a Registered Name it sponsors, it shall
>    take reasonable steps to correct that inaccuracy.
>
> This requirement that registrars "take reasonable steps" is intended to
> reinforce the flexibility afforded to registrars that do not receive
> responses from their customers.  As noted above, the time that a
> registrar should wait for a response from its customer varies according
> to the nature of the inaccuracy and the circumstances from which it
> arose.  The current provision is based on the conclusion that a
> requirement of reasonable action by the registrar is better than a fixed
> timetable, while assuring that the registrar has the ability to cancel
> after 15 days of no response in very serious cases.
>
> These features of the registrar accreditation agreement are discussed in
> the 10 May 2002 "Registrar Advisory Concerning Whois Data Accuracy",
> posted at <http://www.icann.org/announcements/advisory-10may02.htm>,
> which states in part:
>
>    Once a registrar receives notification of an inaccuracy, Subsection
>    3.7.8 requires the registrar to take "reasonable steps" to investigate
>    and correct the reported inaccuracy. The term "reasonable steps" is
>    not defined within the agreement; precisely what constitutes
>    reasonable steps to investigate and correct a reported inaccuracy will
>    vary depending on the circumstances (e.g., accepting unverified
>    "corrected" data from a registrant that has already deliberately
>    provided incorrect data may not be appropriate). At a minimum,
>    "reasonable steps" to investigate a reported inaccuracy should include
>    promptly transmitting to the registrant the "inquiries" concerning the
>    accuracy of the data that are suggested by RAA Subsection 3.7.7.2. The
>    inquiries should be conducted by all commercially practicable means
>    available to the registrar: by telephone, e-mail, and postal mail.
>
> Under this guidance, ICANN reviews registrar compliance based on a
> standard of reasonable conduct by the registrar in the circumstances.
> Where, for example, a registrar appears to "to routinely ignore reports
> of inaccurate and incomplete contact data in its Whois database", ICANN
> has taken enforcement action by presenting the registrar a formal notice
> of breach.  See Letter from Louis Touton to Bruce Beckwith (3 september
> 2002)
>
<http://www.icann.org/correspondence/touton-letter-to-beckwith-03sep02.htm>.
> Where such a notice of breach is presented, subsection 5.3.4 of the
> Registrar Accreditation Agreement gives the registrar 15 working days to
> cure the breach before proceedings to terminate the accreditation can
> proceed.  This 15-working-day period, however, is a different one than
> the 15-calendar-day period after which cancellation of a registration
> becomes possible under a registration agreement due to a customer's
> failure to respond to the registrar's inquiry about Whois inaccuracies.
>
> I hope the above is helpful to the Task Force's review and development
> of recommendations for Whois policy improvements.
>
> Best regards,
>
> Louis Touton
> General Counsel
>
> -------- Original Message --------
> Subject: RE: [nc-whois] FYI - ALAC discussions on 15 days issue
> Date: Thu, 30 Jan 2003 22:16:27 -0500
> From: "Cade,Marilyn S - LGCRP" <mcade@att.com>
> To: "Thomas Roessler" <roessler@does-not-exist.org>, <nc-whois@dnso.org>
> CC: "Louis Touton (E-mail)" <touton@icann.org>,   "Bruce Tonkin
> (E-mail)" <bruce.tonkin@melbourneit.com.au>
>
> A new data point.
>
> I think that we may be misintrepreting wht the present requirement is.
>
> Let's get the ICANN staff to tell us what the present obligation is..
>
> I've cc'd Louie and if he can just online explain what the present
> obligation is, we can work from there.
>
> Thanks, all.
>
> -------- Original Message --------
> Subject: Re: Comment on 15 Day Response Requirement
> Date: Sat, 11 Jan 2003 07:42:46 -0800
> From: Bret Fausett <fausett@lextext.com>
> To: <comments-whois@dnso.org>
>
> I'd like to make a brief follow-up comment and clarification to the post
> I submitted earlier this week:
>
> http://www.dnso.org/dnso/dnsocomments/comments-whois/Arc02/msg00021.html
>
> First, I understand that there are two provisions of the Registrar
> Accreditation Agreement that provide fifteen (15) day response periods
> for different actions. Section 3.7.7.2 requires registrars to include in
> their registration agreements with registrants a response requirement
> for queries about data accuracy. Section 5.3.4 provides registrars
> fifteen (15) days to respond to notices of breach from ICANN. In my
> original comment, I implied that Section 5.3.4 (which ICANN invoked in
> September, 2002 to cure whois problems at Verisign Registrar) was what
> was driving short response deadlines from registrars to registrants.
>
> While I appreciate that the correct section for registrant response
> deadlines is Section 3.7.7.2, the interplay between the two sections may
> still be a cause of some registrars asking their registrants to respond
> to registrar queries in a shorter time frame. At least my registrar
> viewed the requirement of Section 3.7.7.2 as a maximum response time,
> leaving it free to set a short time for my response. Possible solutions
> might be (a) to provide registrar a longer response time under Section
> 5.3.4 (so they didn't feel required to make response time from their
> registrants even shorter) or (b) to set a minimum response time for
> registrants under Section 3.7.7.2, so registrars so longer have
> discretion to set a shorter time.
>
> Second, in my original post I wrote that it was my understanding that
> ICANN logged only the IP address of the complainant. I now understand
> that ICANN not only requires the name and e-mail address of the
> complainant but that it also already utilizes the kind of confirming
> methodology that I suggested. That's good news. At the same time,
> additional steps should be taken to discourage fraudulent complaints. On
> some level, fairness would indicate that some sort of symmetry should
> apply between the sort of data that a registrant must provide for the
> whois database and what a complainant must provide to make a complaint.
> Similarly, it wouldn't be unreasonable to require the complainant to
> provide as much authentication to the given registrar about his or her
> identity as the registrant would have to provide to confirm his or hers
> in responding to the complaint.
>
> I also encourage ICANN and members of the Whois task force to think
> further about ways to discourage fraud, not only in the whois database,
> but also in complaints about the whois database.
>
> Thank you.
>
> Bret Fausett
>
>
>
>
>



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