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

Kaveh Ranjbar <kranjbar@ripe.net> Thu, 30 March 2017 16:27 UTC

Return-Path: <kranjbar@ripe.net>
X-Original-To: ccg@ietfa.amsl.com
Delivered-To: ccg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB69129841; Thu, 30 Mar 2017 09:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RW9Fvk3uu89; Thu, 30 Mar 2017 09:27:19 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [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 ietfa.amsl.com (Postfix) with ESMTPS id CC6C8129865; Thu, 30 Mar 2017 09:27:16 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <kranjbar@ripe.net>) id 1ctcuo-0003At-26; Thu, 30 Mar 2017 18:27:15 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::118]) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <kranjbar@ripe.net>) id 1ctcuj-0002Gr-LC; Thu, 30 Mar 2017 18:27:14 +0200
From: Kaveh Ranjbar <kranjbar@ripe.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_CEB311EF-0C17-4A73-8591-E662611749F1"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <6B862021-DEB0-4847-9474-DC093210C223@ripe.net>
Date: Thu, 30 Mar 2017 11:27:07 -0500
Cc: Trustees Trustees <trustees@ietf.org>
To: ccg@ietf.org
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 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5bac287aebf477a71df240e56892ddb9c0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccg/tnouTjfxUPxR_4HFvV-NLUiXx3s>
X-Mailman-Approved-At: Fri, 31 Mar 2017 08:04:44 -0700
Subject: [CCG] Responses to the questions raised re: Proposed Changes to License Agreements
X-BeenThere: ccg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IANA IPR Community Coordination Group <ccg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccg>, <mailto:ccg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccg/>
List-Post: <mailto:ccg@ietf.org>
List-Help: <mailto:ccg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccg>, <mailto:ccg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 16:27:22 -0000

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.