ICANN ICANN Email List Archives

[gnso-sti]


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

RE: [gnso-sti] Review of draft recommendations - v2

  • To: "'Alan Greenberg'" <alan.greenberg@xxxxxxxxx>, GNSO STI <gnso-sti@xxxxxxxxx>
  • Subject: RE: [gnso-sti] Review of draft recommendations - v2
  • From: Konstantinos Komaitis <k.komaitis@xxxxxxxxxxxx>
  • Date: Tue, 8 Dec 2009 09:45:13 +0000

Alan,

Thank you very much for your detailed comments and your review of the final 
version of the document - they have been really helpful. NCSG generally agrees 
with your comments, with some exceptions. Where KK are my comments which have 
been discussed with the NCSG/STI group.

Best wishes

Konstantinos

-----Original Message-----
From: owner-gnso-sti@xxxxxxxxx [mailto:owner-gnso-sti@xxxxxxxxx] On Behalf Of 
Alan Greenberg
Sent: Monday, December 07, 2009 3:22 AM
To: GNSO STI
Subject: [gnso-sti] Review of draft recommendations - v2



 From Olivier and me (despite the comments starting with "I").

These comments are over and above those previously sent. Sorry about
the length. Although I do ask a number of questions here, In cases
where I suggest alternate wording, I do not *think* that I altered
the intent of the group. If I have erred, I trust someone will point it out.

A glossary of terms might be useful, but perhaps no time for that. If
not, do we need to define Registrant and Complainant?

Regarding minority opinions, I think that we should either delete
them from the last column of the document and have them in separate
minority statements, or leave them there but with the caveat at the
top that "Those minority opinions that were know at the time the
report was written were included. Others may be appended by
Stakeholder Groups."

KK: Agreed

Clearinghouse

We talk about provider(s) for the Clearinghouse, but do we need to
explicitly say that this should be an outsourced service and not
operated by ICANN?

KK: Generally, it might be a good idea to keep the original language. It 
appears that this language is also compatible with the IRT recommendation: " 
The IP Clearinghouse must be operated by a neutral service provider that is not 
currently in a direct contractual relationship with ICANN to provide domain 
name registration services including that of a gTLD registry, registrar or 
other technical provider of domain name services to a gTLD registry or 
registrar. The IP Clearinghouse must commit to a strict code of conduct that, 
among other things, requires it to provide equitable access to its services by 
all entities seeking to use the IP Clearinghouse".(page 14)

7.1 talks about post-launch claims, but the title "No required IP
Claims Notices" does not seem to be relevant. Perhaps "Post-Launch IP
Claims". Also, I would suggest the text of the recommendation be
"Provision of a post-launch IP Claims service is not mandatory". The
implication is that the TC could offer such a service (under the
terms already described in 6.1) but is not required.

KK: Agreed

URS

Intro paragraph: the last sentence ends with "provided that the
procedure includes appropriate safeguards to protect registrants who
may engage in legitimate uses of domain names." We suggest removing
the word "may" as the procedures protect people who ARE engaging in
legitimate use, not those who say that they will someday.

KK: Agreed

2.3 I suggest removal of the explicit to Nominet. For a number of
reasons, it may not help our case to explicitly reference them here.
removing "from Nominet" suffices. If we feel we need to justify the
concept of safe harbors, we can follow this sentence with "Such safe
harbors have been successfully used in similar processes in other
jurisdictions".

KK: Generally, it might be important to keep the original language as well here 
for two reasons: (i) providing the relevant background of these safe harbors is 
vital in order to gain the trust of the wider community. The STI did not come 
up with this language, rather there is precedent, based on the successful 
Nominet system;(ii) most of the language for the safe harbors has been copied 
verbatim from the language of Nominet's policy and due to copyright issues it 
might be necessary to keep reference to the Nominet system.

3.2 Instructing staff to implement language provisions in the most
"efficient" manner is not sufficient. At the very least, it must be
"in an efficient and effective manner". Preferably, though we should
be explicit as per the discussions we had and use "in an efficient
and effective manner; Specifically, the notice should be in the
language used by the registrant during the registration process."

KK: Agreed

4.1 This is a comment that will be repeated in a number of places. We
have the habit of assuming that a domain name is just used for the
web and we should ensure that our language does not do this. In this
section, we suggest replacing "but the domain name still resolves and
other features would function (e.g. e-mail). " by "but the domain
name still resolves to the original IP address and all features would
function (e.g. web, e-mail)."

KK: Agreed

4.2 This recommendation is incorrect as a domain does not get taken
down at Default, but rather after a Decision is rendered. The effect
of filing an answer after default is covered in section 5 so 4.2
should be deleted.

KK: We suggest we keep the original language for this section.

5.1 For clarity, at the end of the recommendation, add "prior to
being declared in default"

KK: We also suggest we keep the original language for this section.

5.2/3 Several problems: "timely" is not defined; the fee between 20
days and the decision being rendered is not defined; the title
Default Answer Fee does not quite address the issue.

I suggest changing "No answer fee will be charged if the Registrant
files its answer in a timely manner." to "No answer fee will be
charged if the Registrant files its answer prior to being declared in
default, or not more than thirty (30) days following a Decision. For
answers filed more than thirty days after a decision, the respondent
should pay a reasonable fee prior to re-examination."

KK: I see your point here Alan, but I believe that this becomes a problem only 
if these two subsections are read outside the context of section 5. We suggest 
keeping the original language here as well.

5.x The section currently numbered 8.1 includes text that should be
actually be here, as it is not part of the appeal practice (this
mis-placement probably happened due to a side-conversation between
Alan and Liz). My text is from the strawman.

Title: Filing Answer After Default
Recomendation: If respondent fails to file an answer within twenty
(20) days and the panelist rules in favor of complainant, respondent
could seek de novo review by filing an answer at any time.  Upon such
an answer being received, Domain Name to resolve immediately to
original IP address."

KK: Agreed

Comment: Do we want to comment on that case of a response being filed
after 20 days but before the examiner reviews the case?  We could
either incorporate the answer into the dossier, or let the judgement
be rendered and the re-do it. I suggest we leave this as an
implementation detail.

6.1 Replace "twenty (2)" by "twenty (20) days". In the next sentence,
we mix cases - "A decision ... they should be...". I suggest
replacing "they should be completed" with "a decision should be rendered".


KK: Agreed.

6.2 "with legal background" should be deleted as it is redundant and
included in 6.3.

KK: Here we suggest we keep the original language.

6.3 Do we need to be more specific about what the examiners should be
trained and certified in??  I guess that needs to be in the contract
but not here.

KK: NCSG has suggested we add 'trained and certified in URS proceedings'.

6.4 I suggest that at the start of the recommendation we replace
"ICANN" with "The URS implementation and contracts". On an ongoing
basis, ICANN should not be a party to the process.

KK: But isn't the case that ICANN will inevitably be part of this process, 
being in a contractual relationship with the URS service providers? We suggest 
we keep the original language.

6.5 I think that we decided that the grounds for not using a
particular Examiner should be wider than just language or
malfeasance, since for example, not delivering in a timely manner is
not really malfeasance. Mark had some good language at our last meeting.

Also in 6.5, I think that "ICANN Staff has the discretion to
determine whether this feature is implementable" is not what we said.
Avoiding gaming was a critical part of our unanimous consensus. ICANN
staff can determine if round-robin is feasible, or even working from
a overall common pool, but the principle of eliminating forum
shopping was not negotiable as I remember it.

7.1 The again uses "website" and does not include the concept of the
domain name pointing to a URS provider splash page saying that the
domain was suspended (and perhaps saying how to remedy this if the
registrant never answered). I suggest replacing "If the complainant
prevails, the domain name should be suspended for the balance of the
registration period and would not resolve to the original website."
with "If the complainant prevails, the domain name should be
suspended for the balance of the registration period and would not
resolve to the original IP address. Instead, it would point to the
URS provider which will provide an informative web page and no other services."

KK: Agreed

8.1 This section should be removed as the content has been moved
earlier in the document.

8.3 The parenthetical is incorrect and should be deleted (it applied
to the late answer and not the appeal). In the middle sentence,
"down" should be replaced by "suspended" (both occurrences). The last
sentence should be changed from "If the domain name resolves because
of a decision in favor of the Registrant, it continues to resolve."
to "If the domain name resolves to the registrant's IP address
because of a decision in favor of the Registrant, it continues to resolve."

KK: For issues of clarity we suggest we keep the original language.

NOTE: There are two sections numbered 8.3

8.4 I suggest that the first sentence about the ombudsman be deleted.
It's presence will only cause extraneous comments, and according to
Amy, it was just a suggestion that could be examined. We did not
specify what happens if the two parties cannot agree on which form of
panel to use.

KK: Agreed.

9.1 Do we need to specify who will be judging whether there was abuse
(will the Examiner be asked in each case if in his/her judgement t
here was abuse?). Regardless of who judges, do we need to specify who
will track this. Since there will likely be more than one URS
provider, who will track the union of all URS cases?

KK: My understanding and the practice of the UDRP has been that the examiner 
(or panelist for the purposes of the UDRP) examines abuse on a case-by-case 
basis. If during the examination process the examiner feels that abuse has 
taken place, s/he should mention it and take into consideration when rendering 
the decision.

9.1 (the second one!) If I understand the intent, the word "panelist"
should be replaced by "Examiner". And we have a similar problem
regarding who judges and who tracks.

KK: Agreed

10.1 I don't think the intent of our consensus was to just say there
will be no automatic termination after one year. I think that
replacing "one year" by "a set period of time" reflects what was said.

KK: We suggest we keep the original language. We have discussed the scenario of 
what will happen should the UDRP not work properly after a year - ICANN will 
either have to fix it or pull the plug.

Annex IX - Trademark Notice

The language in the square brackets is confusing. Certainly, local
language should not be used only in the case of IDN.

Annex X - Evaluation

The term "respondent" is used here and was never used in the original
document (we always used "registrant".

The first paragraph refers to "the following factors". I think that
these are later referred to (under Issuing a Decision) as the three
elements. We should be consistent.

Numbering the sections of this annex would be nice if time permits.













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

Privacy Policy | Terms of Service | Cookies Policy