ICANN/GNSO GNSO Email List Archives

[council]


<<< 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 >>>