<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [Fwd: RE: [gtld-council] modifications to new gTLD recommendations #3 and 6]
- To: robin@xxxxxxxxxxxxx, gtld-council@xxxxxxxxxxxxxx
- Subject: Re: [Fwd: RE: [gtld-council] modifications to new gTLD recommendations #3 and 6]
- From: Mawaki Chango <ki_chango@xxxxxxxxx>
- Date: Sun, 1 Jul 2007 16:45:10 -0700 (PDT)
I've been trying to help, but I wonder if anyone is really
interested :)
The classification that Ray points to -- "string" criteria,
"applicant" criteria, and "process" criteria -- is interesting
and tempting. I understand that might have been the committee
intention. I believe however that the logical fix proposed for
rec.#3 does not at all overide that categorization and the
nature of that rec., i.e. a string criterion.
Indeed the quintessence of this rec. is the string, and both its
_proposal_ and its _rejection_ must be subject to the existing
rights of the others, be it trademark or freedom of expression,
etc.
The confusion came from the fact that people initially talked
about process or string evaluation. We should strike out of our
mind those expressions; this is not at all a process, but
something very punctual, one clearly delineated element although
that element may be one inside the overall evaluation process.
_Proposal_ and _rejection_ are at same level of analysis, both
equally tied to the string itself.
That symetry is needed in rec.#3 because it expresses well the
balance that is sought here. Moving one part of that balance in
another rec. (e.g., rec.#1) makes it less meaningful while the
rec.#3 itself will lose its equilibrium.
Now, it's up to you virtuosos of the English language to draft
and wordsmith this rec.#3 as you see fit, but I just figure that
a phrase like "Proposal and rejection of a string, etc." may
clarify and feature there to address Ray's concern that this
rec. is really about the fate of the string, from both pro's and
con's perspectives.
My 2 cents,
Mawaki
--- Robin Gross <robin@xxxxxxxxxxxxx> wrote:
> Only a minor wording change is sought so Rec #3 makes sense.
>
> The current recommendation - which does attempt to protect
> free
> expression - should be logically worded.
>
> The way #3 is currently worded is to say that a string may not
> infringe
> existing legal rights.
>
> The problem is that a string cannot infringe free expression,
> but the
> rejection of a string could - and that is what the
> recommendation is
> trying to guard against.
>
> If Rec. #1 is the only place we can address process concerns,
> perhaps we
> should put our free expression concern there.
>
> Thanks,
> Robin
>
>
> Ray Fassett wrote:
>
> >Page 30 of the Final Report Part A:
> >
> >http://gnso.icann.org/drafts/pdp-dec05-fr-a-18jun07.pdf
> >
> >states that "Three main elements have emerged in relation to
> string criteria
> >- "string" criteria, "applicant" criteria, and "process"
> criteria.
> >
> >Recommendation 1 pertains to process criteria:
> >
> >"The evaluation and selection procedure for new gTLD
> registries should
> >respect the principles of fairness, transparency and
> non-discrimination."
> >This recommendation cites relevant sections of ICANN's
> mission and core
> >values in support of this committee recommendation.
> >
> >The work of the committee produced Recommendations 2, 3, 4, 5
> & 6 that
> >pertain to "string" criteria, not "process" criteria.
> >
> >I believe the NCUC is confusing Recommendation 3 to be about
> "process"
> >criteria when this was not the original intent or purpose for
> this committee
> >recommendation. While it is tempting to word smith and
> outright challenge
> >high level recommendations at this late stage dating back to
> December 2005,
> >I believe it is important for all participants to be very
> familiar with the
> >comprehensive documents produced by staff that underlie the
> current status
> >of the committee recommendations and implementation
> guidelines (notably
> >Final Reports A & B).
> >
> >Recommendation 1 pertains to "process" criteria. I do not
> believe we should
> >be debating at this stage that the origin of Recommendation 3
> pertains to
> >"string" criteria. While I do not want to speak for Liz, I
> can agree that
> >morphing Rec 3 into "process" criteria adds subjectivity that
> was not
> >originally intended by the committee from this
> recommendation. In this
> >light, I see Liz's comment as facilitating the discussion at
> this late stage
> >based upon comprehensive documentation produced by ICANN
> staff of the
> >committee's work.
> >
> >Ray Fassett
> >
> >
> >-----Original Message-----
> >From: owner-gtld-council@xxxxxxxxxxxxxx
> >[mailto:owner-gtld-council@xxxxxxxxxxxxxx] On Behalf Of Robin
> Gross
> >Sent: Sunday, July 01, 2007 12:05 AM
> >To: gtld-council@xxxxxxxxxxxxxx
> >Cc: Milton Mueller
> >Subject: [Fwd: RE: [gtld-council] modifications to new gTLD
> recommendations
> >#3 and 6]
> >
> >
> >
> >-------- Original Message --------
> >Subject: RE: [gtld-council] modifications to new gTLD
> recommendations
> >
> >#3 and 6
> >Date: Sat, 30 Jun 2007 23:16:04 -0400
> >From: Milton L Mueller <mueller@xxxxxxx>
> >To: <robin@xxxxxxxxxxxxx>, "Liz Williams"
> <liz.williams@xxxxxxxxx>
> >CC: Mawaki <kichango@xxxxxxxxx>, Norbert Klein
> <nhklein@xxxxxxx>
> >References:
>
><046F43A8D79C794FA4733814869CDF0701E637AF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> ><9C1CACD2-472C-4B62-837B-D87D5F1EFF33@xxxxxxxxx>
> ><4686D958.7050906@xxxxxxxxxxxxx>
> >
> >
> >
> >Can you forward to the Council list, please?
> >
> >I am not sure what Liz is driving at by saying that "ICANN
> itself would
> >become part of the objection process." Does she mean that
> ICANN would be
> >able to initiate objections to TLD proposals? If so, that is
> clearly not
> >what was intended nor is it implied by the phrase.
> >
> >Does she mean that people could object to the outcome of an
> ICANN gTLD
> >string selection process because it violated prior rights? If
> so, this can
> >and probably will happen regardless of whether Rec. 3
> includes the phrase
> >"string selection process" or not. There will always be
> debate about whether
> >the actual outcome of the process has met the requirements
> and constraints
> >of the policy. E.g., a trademark owner might complain that
> their prior
> >rights in a string were not respected by the process and take
> ICANN to
> >court.
> >
> >We need that amendment because, as we noted in San Juan, it
> is impossible
> >for a "string" by itself to violate free expression rights.
> It is only the
> >_rejection_ of a string that can do so. If an approval or
> evaluation process
> >rejects strings that people should have a right to use, it
> raises free
> >expression concerns. Therefore, to accommodate free
> expression guarantees,
> >one must refer to "string selection process" or something
> like that. There
> >was talk in San Juan of substituting the word "approval" for
> "selection."
> >That might make it clearer. We might also say "the rejection
> of a string".
> >
> >Liz is flat wrong that greater "subjectivity" is introduced.
> The level of
> >subjectivity is the same with or without the amendment. A
> "string" does not
> >jump out and say, "I violate trademark rights!" Whether it
> does or not must
> >be judged and interpreted. Likewise, whether or not a
> decision to reject a
> >string violates free expression rights requires the same
> kinds of judgments.
> >Inserting that term does not change the level of subjectivity
> in the
> >slightest.
> >
> >Finally, it is unfortunate that this needs to be said, but we
> do need to
> >insist that under the bylaws, policy in the GNSO is made by
> representatives
> >of constituencies, not by staff. Staff is a facilitator and
> administrator,
> >not a stakeholder. When constituencies agree--as they seem to
> have done on
> >this phrase -- it is highly inappropriate for staff to insert
> their own
> >personal opinion.
> >
> >
> >-----Original Message-----
> >From: Robin Gross [mailto:robin@xxxxxxxxxxxxx]
> >Sent: Saturday, June 30, 2007 6:30 PM
> >To: Milton L Mueller; Liz Williams
> >Cc: Mawaki; Norbert Klein
> >Subject: Re: [gtld-council] modifications to new gTLD
> recommendations #3 and
> >6
> >
> >Liz,
> >
> >ICANN staff should not be urging council members to reject
> NCUC
> >proposals - at least not if you want to claim "neutrality"
> with a
> >straight face.
> >
> >Robin
> >
> >
> >
> >Liz Williams wrote:
> >
> >
> >
> >>Colleagues
> >>
> >>I would urge you to reconsider carefully the second part of
> this
> >>recommendation. Including the second part means that ICANN
> itself
> >>would become part of the objection process. I am not sure
> that this
> >>is what you intend or how that would be measured. Revising
> the
> >>recommendation on the basis of the recommendation below
> would cause
> >>some significant subjectivity being introduced into the
> process about
> >>"infringement and unfairness". Of course ICANN must, in the
>
> >>selection process, operate in accordance with its bylaws and
> mission
> >>and core values.
> >>
> >>We have spent a great deal of time on ensuring that we have
> a pre-
> >>published, objective process that is about the applicant and
> the string.
> >>
> >>Kind regards.
> >>
> >>Liz
> >>.....................................................
> >>
> >>Liz Williams
> >>Senior Policy Counselor
> >>ICANN - Brussels
> >>+32 2 234 7874 tel
> >>+32 2 234 7848 fax
> >>+32 497 07 4243 mob
> >>
> >>
> >>
> >>
> >>On 29 Jun 2007, at 15:59, Gomes, Chuck wrote:
> >>
> >>
> >>
> >>>Regarding Recommendation 3, it seems to me that there are
> two key
> >>>elements: 1) strings that may infringe existing legal
> rights and 2) the
> >>>selection process that may infringe existing legal rights.
> If I am
> >>>correct, then we need to include both in this
> recommendation and I
> >>>think
> >>>we started working in that direction yesterday.
> >>>
> >>>Chuck Gomes
> >>>
> >>>"This message is intended for the use of the individual or
> entity to
> >>>which it is addressed, and may contain information that is
> privileged,
> >>>confidential and exempt from disclosure under applicable
> law. Any
> >>>unauthorized use, distribution, or disclosure is strictly
> >>>prohibited. If
> >>>you have received this message in error, please notify
> sender
> >>>immediately and destroy/delete the original transmission."
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: owner-gtld-council@xxxxxxxxxxxxxx
> >>>>[mailto:owner-gtld-council@xxxxxxxxxxxxxx] On Behalf Of
> Robin Gross
> >>>>Sent: Thursday, June 28, 2007 2:14 PM
> >>>>To: gtld-council@xxxxxxxxxxxxxx
> >>>>Subject: [gtld-council] modifications to new gTLD
> >>>>recommendations #3 and 6
> >>>>
> >>>>NCUC proposes the following modifications to new gTLD
> >>>>recommendations #3 and 6:
> >>>>
> >>>>Rec. 3:
> >>>>
> >>>>The process for selecting strings must not infringe
> existing
> >>>>legal rights that are enforceable under internationally
> >>>>recognized principles of law or the applicant's national
> law.
> >>>>
> >>>>Examples of these legal rights that are internationally
> >>>>recognized include, but are not limited to, rights defined
> in
> >>>>the Paris Convention for the Protection of Industrial
> >>>>Property (in particular trademark rights), the Universal
> >>>>Declaration of Human Rights and the International Covenant
> on
> >>>>Civil and Political Rights (in particular freedom of
> >>>>expression rights).
> >>>>
> >>>>
> >>>>Rec 6:
> >>>>
> >>>>Strings must not be contrary to legal norms that are
> >>>>enforceable under generally accepted and internationally
> >>>>recognized principles of law.
> >>>>Taking into account the aforementioned limitations, no
> >>>>application shall be rejected solely because the applicant
> or
> >>>>string is associated with an unpopular or controversial
> point of view.
> >>>>
> >>>>
> >>>>
> >
> >
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.5.476 / Virus Database: 269.9.14/882 - Release
> Date: 6/30/2007
> >3:10 PM
> >
> >
> >No virus found in this outgoing message.
> >Checked by AVG Free Edition.
> >Version: 7.5.476 / Virus Database: 269.9.14/882 - Release
> Date: 6/30/2007
> >3:10 PM
> >
> >
> >
> >
> >
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|