Re: [CCG] Responses to the questions raised re: Proposed Changes to License Agreements

Kaveh Ranjbar <> Thu, 20 April 2017 05:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 596C3129450; Wed, 19 Apr 2017 22:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3BHqL8v9fwAP; Wed, 19 Apr 2017 22:49:21 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E03A12EAFE; Wed, 19 Apr 2017 22:49:21 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <>) id 1d14xy-0002jo-Fo; Thu, 20 Apr 2017 07:49:20 +0200
Received: from ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::22]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1d14xy-0006wa-0O; Thu, 20 Apr 2017 07:49:18 +0200
From: Kaveh Ranjbar <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_7A665F6E-A4FC-43FE-B94D-4D9CC20160FF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Apr 2017 09:49:14 +0400
In-Reply-To: <>
Cc: Trustees Trustees <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5b4f69f657f2d10f3e20164922d7b6efdb
Archived-At: <>
Subject: Re: [CCG] Responses to the questions raised re: Proposed Changes to License Agreements
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IANA IPR Community Coordination Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Apr 2017 05:49:24 -0000


Thank you for your comments.

The next step is that the Trust will publish the proposed
modifications to Exhibit E for a two-week community review. (Exhibit
E of the License Agreements: Domain Name Registrar Requirements)

Unless there are suggestions otherwise, that notice will be sent to <> and the IETF announce and ietf lists.

Please note the "Next Steps” section in my original announcement
sent out on 30th of March email (quoted below) and comment if you
have suggestions.

All the best,

Kaveh Ranjbar
Chair, IETF Trust

> On 30 Mar 2017, at 20:27, Kaveh Ranjbar <> wrote:
> All;
> On 1st March the Trust sent proposed changes to the License
> Agreements with ICANN to the CCG and requested feedback.
> Below are the Trust responses to the questions that were raised.
> We hope these satisfy the concerns of the CCG.
> In addition, we believe these are the Next Steps necessary to
> complete the transfer of the domains and we welcome your review
> and comments on these as well.
> Next Steps
> a.  Trust sends response to CCG questions
> b.  CCG reviews and comments
> c.  Upon acceptance, Trust publishes Exhibit E for community review
> [Exhibit E to License Agreement: Domain Name Registrar Requirements]
> d.  Community Review
> e.  With no substantive changes, Trust and ICANN execute
> 	amendments to the three License Agreements
> f.  Changes incorporated in the CSC Agreement Schedule A
>   [Schedule A is the same as Exhibit E of the License Agreements]
> g.  Trust publishes Schedule A of the CSC Agreement for Community Review
> h.  Community Review
> i.  With no substantive changes, Trust executes CSC Agreement
> j.  Test of CSC conformance to the requirements
> k.  Assuming successful test, all IANA domains transferred to Trust
> Again, we welcome your comments and suggestions.
> Kaveh Ranjbar
> Chair, IETF Trust
> ++++++++++++++++++++++
> Responses to Questions Raised by CCG:
> Q1:  Referencing Exhibit E Domain Name Registrar Requirements In
> items iii and iv, there is a change from "after the same period as
> above" to "after the same conditions as specified in item i. above".
> However, in item ii, the words "after the same period as above² have
> not been changed.
> Is the different approach in item ii deliberate?
> A1.  After review of ii in relation to i, iii, and iv, it is our
> opinion that the same conditions should apply and have been incorporated.
> The specific change would be as follow:
> ii. The name must be configured to renew automatically. Removal of
> this setting requires the approval of both administrative and
> technical contacts, with override only possible by the registrant
> after the same period as above.
> s/ after the same period as above./ after the same conditions as
> specified in item i. above.
> The Licensor shall arrange sufficient funds to ensure renewal is
> successful. Notices of pending, successful, and failed renewals must
> go to both technical and administrative contacts.
> See Exhibit E attached with the markup.
> Q2.  Referencing Exhibit E Domain Name Registrar Requirements
> section i, do we mean “no response” or “no objection” from the
> current contacts? It is possible that any response (even simply
> clarification) would inhibit update, and that may not be the desired
> outcome.  We would appreciate confirmation and are fine with either
> outcome.
> A2.  We mean “No Response.”  Section i provides for two scenarios.
> The first is the situation where the approval of both the technical
> contact and the administrative contact is needed to approve a change
> to the technical contact information, that is, there is “No
> Objection” to the change.
> The second is the situation where “No Response” was received from
> the administrative and technical contacts (or “No Objection” from
> one and “No Response” from the other).  In this situation the
> registrant (the Trust) can override the need for the parties to
> approve and approve the change to the technical contact information.
> There must be evidence that notice of change was provided to both
> parties and such action cannot be taken unless 10 business days have
> passed.
> Q3.   Can we also obtain confirmation that the agreement between the
> licensor and the registrar is only valid as long as the License
> agreement is in force?
> A3.  The contract with the Registrar will not terminate merely as a
> result of changing IANA service providers or the License Agreement
> The Trust is entering into a contract with CSC as Registrar for the
> purpose of it holding the IANA domains.
> Exhibit E of the License Agreements is Schedule A section 7 of the
> CSC Agreement.
> Neither Exhibit E nor Schedule A are ICANN specific.
> If ICANN is no longer the IANA Service Provider through PTI, License
> Agreements will then be negotiated between the Trust and the new
> provider(s).
> If Exhibit E of the License Agreement changes, then Schedule A of
> the Trust contract with the Registrar will be changed.
> Of course the License Agreements will be changed in accordance with
> the provisions of the Community Agreement.
> Applicable Community Agreement provisions include:
> Community Agreement Provisions
> 3.2       Licenses to IANA Operators.
> a.         The IETF Trust shall license the IANA Intellectual
> Property, including the use of associated domain names, to one or
> more third party operators selected as described below (“IANA
> Operators”) for use in connection with performing IANA Services
> under one or more written license agreements (“License Agreements”).
> e.         Operational Community IANA Operator Request.
> (i)  Upon the request of an Operational Community, the IETF Trust
> will attempt in good faith to negotiate a License Agreement with a
> prospective IANA Operator relating to the Operational Community’s
> designated IANA Service and based to the greatest extent possible on
> the Initial License Agreement(s) (or the License Agreement in use
> immediately prior to such negotiation, if different). (ii)  The IETF
> Trust and each Operational Community hereby acknowledge that the
> License Agreement that the IETF Trust has executed with the initial
> IANA Operator as of the Effective Date, attached hereto as Exhibit
> D-1, D-2 or D-3, respectively (the “Initial License Agreements”) is
> acceptable to it.
> <Exhibit E Domain Name Registrar Requirements Markup -01.pdf>