<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [council] A way forward on the Specification 13 question
- To: john@xxxxxxxxxxxxxxxxxxx, Bret Fausett <bret@xxxxxxxx>, "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
- Subject: Re: [council] A way forward on the Specification 13 question
- From: Volker Greimann <vgreimann@xxxxxxxxxxxxxxx>
- Date: Thu, 08 May 2014 16:14:32 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=key-systems.net; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1399558499; x=1400422499; bh=gwMTJbjVkeEP EJsFUZrZtUclX2bdGpLUI2f0bS8PlDY=; b=bRTgxNWryFludFSrin0QXD4DDXX+ xyRs5doXR7N0EpIyXW4bWmOjQgZ7SV1f0u265fKVPQ5pgeSM2+nJjQerNgBUXyFE fowovVSbTslOYfix29exadidwcMd5yghJnN/XDPiGCPzSdzxSdozQ3AzNGqvy71i vD1aHYejbOejVqs=
- In-reply-to: <20140508070809.a9a203d782c20324abd21efa41e2a5a6.b24ecea2e1.mailapi@email14.secureserver.net>
- List-id: council@xxxxxxxxxxxxxx
- References: <20140508070809.a9a203d782c20324abd21efa41e2a5a6.b24ecea2e1.mailapi@email14.secureserver.net>
- Sender: owner-council@xxxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
Hi John,
I fully agree that there may be real-world adjustments to the original
recommendation, provided proper process is followed. I do not feel
comfortable with setting aside a recommendation without such process
however.
Recommendation 19 as it reads today is perfectly clear with regard to
its language and intent. The proposed limitation to registrar access
currently left out of Spec 13 would be contrary to both, thus it is
inconsistent. While a solution may be found through proper process, it
is not our role to declare an inconsistency non-consequential. Therefore
the motion needs to be amended.
Best,
Volker
Am 08.05.2014 16:08, schrieb john@xxxxxxxxxxxxxxxxxxx:
Volker,
Your points are well-made, but the circumstances that led
Recommendation 19 to be modified/clarified/excepted by Specification
13 suggest broader implications for all future PDP work. Our
back-and-forth on the list shows that when the policies are
specifically prescriptive, it is easy to go astray once the real-world
elements of the marketplace then test them. But if we focus on
outcomes, there is more latitude to act in the face of circumstance --
as long as the result is in line with our intent.
In the current case, for example, it was understood though not
prescriptively stated that brand tlds were likely to be different
players than most gtlds. If the policy work acknowledged that and
made it clear that those differences were to be accommodated within
the framework of a set of rules governing registrar relationships,
then whether the names were open to all comers or to a short list of,
say, three, would not matter. Only the nature of the relationship
between the registry and registrars would.
This is where I am on the question of 19/13. Though I remain open to
whatever amendments may be offered today, even without change the
motion is a rational response that should be supported.
Cheers,
Berard
--------- Original Message ---------
Subject: Re: [council] A way forward on the Specification 13 question
From: "Volker Greimann" <vgreimann@xxxxxxxxxxxxxxx>
Date: 5/8/14 6:13 am
To: "Bret Fausett" <bret@xxxxxxxx>, "council@xxxxxxxxxxxxxx"
<council@xxxxxxxxxxxxxx>
Having reflected on the policy implications of the proposed
motion, I would like to propose to amend the resolved clauses of
the motion to read as follows:
-----
1. that the */proposed /*right to only use up to three exclusive
registrars, as contained in Specification 13 is inconsistent with
Recommendation 19 as (i) the language of this recommendation of
the final report of the GNSO does not stipulate any exceptions
from the requirements to treat registrars in a non-discriminatory
fashion and (ii) the GNSO new gTLDs Committee discussed potential
exceptions at the time, but did not include them in its
recommendations, which is why the lack of an exception cannot be
seen as an unintended omission, but a deliberate policy statement;
2. that the Council does not object to the implementation of
Specification 13 /*subject to the removal of the clause allowing a
Registry */*/Operator to designate up to three exclusive
Registrars. /*
3. that the Council requests the ICANN Board to implement
appropriate safeguards for /*this and */future new gTLD
application rounds to ensure that Recommendation 19 is not eroded
and that any rights granted to .BRAND TLDs cannot be used for
scenarios other than those specifically covered by Specification 13;
4. that the Council reserves the right to initiate a policy
development process, potentially resulting in Consensus Policy
affecting both existing and future TLDs, */to assess whether
/**/exceptions to Recommendation 19 /**/*/or any subsequent
provisions /*should be allowable in this circumstance, and under
what criteria future requests would be considered. /*
-----
Changed/added language is marked in bold-cursive for easier
reference.
The amendments take into consideration the various concerns voiced
by many individuals including myself on the council list in the
past weeks. The amended motion would clarify the policy position
of the council while at the same time creating a way forward for
the community to find a practical solution. It avoids the
hollowing-out of policy recommendations at the request of any one
interest but offers a constructive path to address any concerns
with the existing policy recommendation.
Best regards,
Volker Greimann
Am 07.05.2014 17:21, schrieb Bret Fausett:
I see that the motion does not yet have a second, so I would
like to second the motion for tomorrow’s meeting.
--
Bret Fausett, Esq. • General Counsel, Uniregistry, Inc.
12025 Waterfront Drive, Suite 200 • Playa Vista, CA 90094-2536
310-496-5755 (T) • 310-985-1351 (M) • bret@xxxxxxxxxxxxxxx
<mailto:bret@xxxxxxxxxxxxxxx>
— — — — —
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|