<html>
<body>
Greg, there you go down the rabbit hole. <br><br>
Yes, I said the problems COULD arise regardless of the home of the server
the IANA.ORG domain points to. And yes, I have complete confidence that
there are technical solutions (even ones that *I* could develop, and that
is certainly not my field of expertise). BUT developing them is not
within our mandate nor on our critical path. <br><br>
THAT is why I suggested stopping at principles for the moment.<br><br>
Alan<br><br>
At 11/06/2015 12:25 AM, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">Alan,<br><br>
I was going to go into the technical issues regarding managing the domain
name issue, but I stopped myself, ssince as you say these issues will
exist regardless of who is the domain registrant.&nbsp; Indeed, if the
IETF Trust were to start operating the
<a href="http://iana.org">iana.org</a> website after the transition,
those issues would arise quickly. <br><br>
Since you've opened the door to the subject, I'll walk in. (FWIW, I
probably spend far more time these days dealing with tech issues than
pure trademark issues....)<br><br>
There are several alternatives.&nbsp; First, the page at
<a href="http://iana.org">iana.org</a> could be used as a disambiguation
page.&nbsp; An example of this can be found at
<a href="http://www.scrabble.com">www.scrabble.com</a>.<br><br>
<img src="cid:.0" width=472 height=265 alt="Inline image 1"><br><br>
Indeed, the current <a href="http://iana.org">iana.org</a> home page is
already very close to this, with separate sections for domain names,
number resources and protocol assignments.&nbsp; Clicking on these leads
to third level pages under domains, numbers and protocols.&nbsp; These
could easily be reworked into subdomains
<a href="http://domains.iana.org">domains.iana.org</a>,
<a href="http://numbers.iana.org">numbers.iana.org</a> and
<a href="http://protocols.iana.org">protocols.iana.org</a>, which could
then be hosted on servers managed by the community that has separated
from ICANN as the IFO.&nbsp; Alternatively, the link for domains, numbers
or protocols could go to an entirely different second level domain (e.g.,
iananumbers.web).<br><br>
Another alternative is for the separating customer to stop using the
<a href="http://iana.org">iana.org</a> domain entirely, but the first two
options are probably more palatable and less disruptive.&nbsp; If this is
approach is taken, you would probably want some form of notification (I
would say a pop-up, but pop-up blockers make that suboptimal) of the new
domain name, at least for a period of time.<br><br>
This could be dealt with by contract now or at the time of the split (or
some combination of the two).<br><br>
Greg<br><br>
On Wed, Jun 10, 2015 at 11:29 PM, Alan Greenberg
&lt;<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
&gt; wrote:<br>

<dl>
<dd>Greg, not quite. <br><br>

<dd>You are thinking about this as a TM attorney. There are also
technical issues. Currently <a href="http://iana.org">iana.org</a> has
uses within all three communities and it is simple to do since it ia all
run out of the current IANA. If there were to be a split at some point,
it is not just a matter of granting the right to use the TM, but creating
the mechanics to allow the domain name to be transparently used by all
three entities. And if one of the groups has left because they no longer
have faith in the ability of the then-current IANA to do things
correctly, that could be problematic. <br><br>

<dd>But the problems will be there regardless of where the
<a href="http://iana.org">iana.org</a> name resolves to if there is a
split. The best we can do is try to cover it with contractual
assurances.<br><br>

<dd>And as was pointed out ion the IETF list when this was first
discussed. Although no one wants to stop using
<a href="http://iana.org">iana.org</a>, and it would probably more
disruptive for the IETF than others (my recollection is that the name is
built into code), we would survive.<br><br>

<dd>Alan<br><br>
<br><br>

<dd>At 10/06/2015 11:15 PM, Greg Shatan wrote:<br>
<blockquote type=cite class=cite cite="">
<dd>Alan,<br><br>

<dd>You took the words out of my mouth.&nbsp; A clause in the agreements
between ICANN and the other two communities should require ICANN to grant
a worldwide royalty-free license to use the trademarks. This is a simple
fix. If we want to get fancy, there can be a contingent license that
automatically springs into place when the customer separates.<br><br>

<dd>I also agree with your point on defense/enforcement.<br><br>

<dd>Greg<br><br>

<dd>On Wed, Jun 10, 2015 at 11:03 PM, Alan Greenberg
&lt;<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
 &gt; wrote:
<dl>
<dd>I refrained from weighing in when this was first discussed and in
this iteration. But I will now. I think that whatever the solution, there
must be some principle adhered to:<br>

<dd>1. The TM must be owned by an entity that is prepared to defend it if
necessary.<br>

<dd>2. Whoever owns it must enter into an agreement with all three users
of it (or the other two if the owner is one of the users) so that if that
user chooses to move withdraw from the IFO used by the others, the TM
owner will grant it all necessary rights and privileges to continue using
the TM with no user disruption.<br>

<dd>In my opinion, it makes sense for the owner to be ICANN for the
immediate future, because it will, either directly or through PTI, have
agreements with the RIRs and the IETF and those agreements are reasonable
places in which to embody principle 2. And ICANN has the funding and
legal resources to defend the TM if necessary.<br>

<dd>But there are certainly other solutions that could also satisfy both
principles.<br>

<dd>Like Chuck, I may be naive (something I have rarely been accused of),
but I cannot see the details of the implementation being of concern to
the AC/SO (with the possible exception of the ASO and the
IPC).<font color="#888888"><br>

<dd>Alan</font><br>
<br>

<dd>At 10/06/2015 08:21 PM, Milton L Mueller wrote:<br><br>
<blockquote type=cite class=cite cite="">
<dd>Maarten,
<dd>The simple rationale for the numbers proposal, and the protocol
community’s acceptance of it, was that both of them em insist on
having the right to switch IANA functions operator at some time in the
future. If the IANA trademarks and domains are Ă˘€śownedââ˘â‚¬ by a
single IFO we cannot have that separability. If we want the IFO to be
able to change, then the trademarks and domains must not he owned by
either ICANN (which is the Ă˘€śowner’/controller of PTIof PTI) or any
subsequent IFO. It’s that t simple.
<dd>&nbsp;
<dd><a name="14de0aa62e1265f8_14de09298451ad06__MailEndCompose"></a>--MM
<dd>&nbsp;
<dd>From:
<a href="mailto:cwg-stewardship-bounces@icann.org">
cwg-stewardship-bounces@icann.org</a> [
<a href="mailto:cwg-stewardship-bounces@icann.org" eudora="autourl">
mailto:cwg-stewardship-bounces@icann.org</a>] On Behalf Of Maarten Simon
<dd>Sent: Wednesday, June 10, 2015 4:22 PM
<dd>To: Seun Ojedeji; Greg Shatan
<dd>Cc:
<a href="mailto:cwg-stewardship@icann.org">cwg-stewardship@icann.org</a>
IANA
<dd>Subject: Re: [CWG-Stewardship] drift in v5
<dd>&nbsp;
<dd>Next to Seun’s argument, I think the trademdemarks should remain
with ICANN as it is ICANN that will grant PTI the right to operate the
IANA functions through the contract. It seems logical to me that ICANN
only provides a license to PTI to use the trademarks through the same
contract and not transfer the trademarks themselves.
<dd>&nbsp;
<dd>The further question is if in the case of a separation the assets
will go from PTI to the new entity (probably in practise: yes) but in a
legal sense I would assume that PTI returns the assets to ICANN and that
ICANN provide these to the new operator.
<dd>&nbsp;
<dd>From: Seun Ojedeji
&lt;<a href="mailto:seun.ojedeji@gmail.com">seun.ojedeji@gmail.com</a>
&gt;
<dd>Date: Wednesday 10 June 2015 22:05
<dd>To: Greg Shatan
&lt;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
&gt;
<dd>Cc: SIDN SIDN
&lt;<a href="mailto:maarten.simon@sidn.nl">maarten.simon@sidn.nl</a>&gt;,
&quot;<a href="mailto:cwg-stewardship@icann.org">
cwg-stewardship@icann.org</a>&quot;
&lt;<a href="mailto:cwg-stewardship@icann.org">
cwg-stewardship@icann.org</a>&gt;
<dd>Subject: Re: [CWG-Stewardship] drift in v5
<dd>&nbsp;
<dd>Hi Greg,
<dd>Perhaps its worth noting that the other 2 operational communities are
still considering whether to contract directly with PTI as their
proposals currently indicates contracting with ICANN. So if for instance
there is a need for numbers community to move its functions, it would be
appropriate that the entity its contracting with provides access to the
IANA trademarks accordingly. 
<dd>As far as PTI is concerned at the moment, its separation mechanisms
as proposed by CWG is largely based on the names community (with the
other 2 communities having optional liaison roles). Based on that, i
don't see the other 2 communities agreeing to transfer the IANA
transdemarks (which is for all 3 operational communities) to PTI whose
accountability mechanism is largely names based.
<dd>Regards
<dd>&nbsp;
<dd>On Wed, Jun 10, 2015 at 8:52 PM, Greg Shatan
&lt;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
&gt; wrote: 
<dl>
<dd>Maarten, 
<dd>&nbsp; 
<dd>That is not my understanding of separation.&nbsp; If ICANN selects a
new provider, that provider would take all of the assets of PTI
(including the trademarks, under this scenario), so it could provide the
IANA services.&nbsp; PTI would then be wound down and ultimately
dissolved by ICANN.&nbsp; Recall that PTI is a controlled entity of ICANN
and would remain so throughout.&nbsp; In this case, the IANA operations
are separated from PTI. 
<dd>&nbsp; 
<dd>If PTI is actually separated (spun out) from ICANN so that it is no
longer under ICANN control, it would be done to further separate the IANA
Functions from ICANN and IANA would continue as a going concern (active
business). 
<dd>&nbsp; 
<dd>Under no circumstances does PTI become separated from ICANN without
continuing to serve as the IANA operator, yet continue to hold
IANA-related assets. 
<dd>&nbsp; 
<dd>Greg 
<dd>&nbsp; 
<dd>On Wed, Jun 10, 2015 at 3:44 PM, Maarten Simon
&lt;<a href="mailto:maarten.simon@sidn.nl">maarten.simon@sidn.nl</a>&gt;
wrote: 
<dl>
<dd>Hi Greg, 
<dd>&nbsp; 
<dd>I would like to respond to your suggestion: 
<dd>&nbsp; 
<dd>'An acceptable alternative may be to have PTI, rather than ICANN, own
the IANA trademarks.&nbsp; This is actually a simpler solution and is
consistent with trademark law and practice.&nbsp; This also contributes
to separability, since all of the IFO-related assets would be in a single
entity.’ ˘ 
<dd>&nbsp; 
<dd>If PTI is separated, ICANN will select a new IANA provider. Am I
correct that if the IANA trademarks rest with PTI, we will than have to
rename the services after the separation and they will not any longer be
named the IANA services ? 
<dd>&nbsp; 
<dd>If that is correct, I rather keep the rights in ICANN. 
<dd>&nbsp; 
<dd>Best, 
<dd>&nbsp; 
<dd>Maarten 
<dd>&nbsp; 
<dd>From: Greg Shatan
&lt;<a href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>
&gt; 
<dd>Date: Wednesday 10 June 2015 21:06 
<dd>To: manning
&lt;<a href="mailto:bmanning@karoshi.com">bmanning@karoshi.com</a>&gt; 
<dd>Cc: &quot;<a href="mailto:cwg-stewardship@icann.org">
cwg-stewardship@icann.org</a>&quot;
&lt;<a href="mailto:cwg-stewardship@icann.org">
cwg-stewardship@icann.org</a>&gt; 
<dd>Subject: Re: [CWG-Stewardship] drift in v5 
<dd>&nbsp; 
<dd>ICANN is an appropriate owner of the IANA trademarks.&nbsp; PTI is
also an appropriate owner of the IANA trademarks.&nbsp; The IETF Trust
does not appear to be an appropriate owner of the IANA trademarks. 
<dd>&nbsp; 
<dd>A trademark is an indicator of source or origin.&nbsp; The owner of a
trademark should be the ultimate source of the goods and services offered
under that trademark.&nbsp; In the most straightforward case, the
trademark owner offers those goods and services themselves or through a
subsidiary.&nbsp; The trademark owner can license the mark to third
parties to offer goods and services under the mark; but, consistent with
their status as the ultimate source, the trademark owner is required by
law to exercise continuing quality controls over the goods and services
offered by the licensee and the use of the trademark by the
licensee.&nbsp; A trademark owner cannot merely &quot;hold the
asset&quot; as CRISP proposed.&nbsp; Ownership of a trademark
fundamentally involves being the Ă˘€śsource or originĂn†of the goods
and services and fulfilling the Ă˘€śquality controlââ˘â‚¬ oversight
role, among other things.&nbsp; 
<dd>&nbsp; 
<dd>Quality control generally involves approvals by the licensor of any
potential new products or services, and approvals of any changes in
products or services (what they are, how they are offered, methods and
processes, etc.), as well as ongoing monitoring of quality.&nbsp; The
benchmark typically is that licensee's level of quality should be at
least as high as the goods and services offered by the licensor (i.e.,
the owner of the mark and the ultimate source/origin of the
goods/services).&nbsp; This is all set forth in a trademark license
between the licensee ans licensor. If a trademark license has no quality
control provisions, or the quality control provisions are not adequate or
not adequately exercised, the license may be deemed a Ă˘€śĹ“naked
license,†exposing the trademark to the risk of abandonment (loss of
validity as a trademark, and loss of the right to claim ownership and
usage rights of the mark).&nbsp; When a licensee uses a trademark, all
goodwill (brand reputation) goes to the owner, not the licensee.&nbsp;
The owner is the holder of that goodwill. 
<dd>&nbsp; 
<dd>I don't see how the IETF Trust makes legal sense as the owner of the
IANA Trademarks.&nbsp; The IETF Trust is not and does not intend to be
the ultimate source and origin of IANA services.&nbsp; Unlike copyrights
and patents, trademarks can't be owned by administrators; they need to be
owned by the source of the services.&nbsp; Further, the IETF Trust is
clearly not granting ICANN the right to provide the IANA Services, so it
is even more inappropriate for the IETF Trust to be the owner of the mark
associated with those services. 
<dd>&nbsp; 
<dd>An acceptable alternative may be to have PTI, rather than ICANN, own
the IANA trademarks.&nbsp; This is actually a simpler solution and is
consistent with trademark law and practice.&nbsp; This also contributes
to separability, since all of the IFO-related assets would be in a single
entity. 
<dd>&nbsp; 
<dd>If we assume for a moment that the IETF Trust were to own the IANA
trademarks, significant issues arise. 
<dd>&nbsp; 
<dd>In a trademark license, the IETF Trust, as licensor, would have the
power to terminate the license according to its terms (e.g., for material
breach of the agreement, misuse of the trademark, etc.) or to decide not
to renew the license, in which case ICANN would no longer have the right
to use the IANA trademark in the provision of services.&nbsp; It would be
inappropriate for the IETF Trust to have this power, without
accountability to and oversight by the names and numbers
communities.&nbsp; A mechanism would need to built for that.&nbsp; 
<dd>&nbsp; 
<dd>Quality control presents another challenge.&nbsp; In virtually all
circumstances, a licensor exercises these quality control obligations
through an employee or employees knowledgeable and capable of exercising
quality control over the licensee and its services.&nbsp; .It may also be
appropriate for the operational communities to be involved in quality
control and other aspects of the license as well, especially since
quality control and trademark usage guidelines can be changed from time
to time, typically at the licensor’s discretion, andand since the IETF
is not in a position to exercise quality control in the names and numbers
space.&nbsp; This may require amendment of the IETF Trust Agreement, as
well as the drafting of a somewhat unusual trademark license. 
<dd>&nbsp; 
<dd>Furthermore, the IETF Trust would also be responsible for policing
and enforcement of the trademark against third parties and for
maintenance of trademark registrations.&nbsp; 
<dd>&nbsp; 
<dd>It is not clear how the IETF Trust intends to carry out any of these
roles. 
<dd>&nbsp; 
<dd>Also, for the IETF Trust to become the owner of the IANA trademark,
ICANN would need to assign all of its right, title and interest in and to
the IANA trademark to the IETF Trust, along with all goodwill relating to
the mark (typically, in exchange for good and valuable
consideration).&nbsp; This may require a valuation of the IANA trademark
and its associated goodwill, which in turn may have tax or other
financial consequences for one or both parties. 
<dd>&nbsp; 
<dd>Finally, the IETF Trust, as such, may not&nbsp; be capable of owning
the IANA Trademark, since the IETF Trust does not appear to be a
“legal entity.â€&nbsp;&nbsp; If this is correct, the Trustees (in
their roole as Trustees) are the collective owners of the IANA Trademark
(in trust for the IETF, as Beneficiaries of the IETF Trust), and would
need to enter into the trademark license (again, in their role as
Trustees of the Trust).&nbsp; This appears to be consistent with Section
9.5 of the Amended and Restated Trust Agreement and the ownership of the
IETF trademarks (which are owned by Ă˘€śThe Trustees of the IETETF
Trust†) in the USPTO database.&nbsp; (Oddly, this is inconsistent with
the IETF General Trademark License (on the IETF Trust website) which
states that the IETF Trust is the licensor of the IETF marks, and which
also lacks appropriate quality control provisions.) 
<dd>&nbsp; 
<dd>Greg Shatan 
<dd>&nbsp; 
<dd>&nbsp; 
<dd>&nbsp; 
<dd>&nbsp; 
<dd>On Wed, Jun 10, 2015 at 3:18 AM, manning
&lt;<a href="mailto:bmanning@karoshi.com">bmanning@karoshi.com</a>&gt;
wrote: 
<dl>
<dd>Missed the attachment…&nbsp;&nbsp; which now iis attached!<br>

<dd>manning 
<dd><a href="mailto:bmanning@karoshi.com">bmanning@karoshi.com</a> 
<dd>PO Box 12317 
<dd>Marina del Rey, CA 90295 
<dd><a href="tel:310.322.8102">310.322.8102</a><br>

<dd>On 10June2015Wednesday, at 0:12, manning
&lt;<a href="mailto:bmanning@karoshi.com">bmanning@karoshi.com</a>&gt;
wrote:
<dd>&gt; 
<dd>&gt; On 19 May 2015, the number community provided specific feedback
regarding the need for alignment on the IETF trademark and domain (see
attached email from Izumi to the CWG call for comments). 
<dd>&gt; 
<dd>&gt; Did you notice that the most recent draft (v5) for discussion
that came out yesterday morning specifically moves farther away from this
direction, leaving these marks in ICANN rather than moving them to the
IETF Trust? 
<dd>&gt; 
<dd>&gt; CWG email re new draft - -&lt;
<a href="http://mm.icann.org/pipermail/cwg-stewardship/2015-June/003650.html">
http://mm.icann.org/pipermail/cwg-stewardship/2015-June/003650.html</a>
&gt; 
<dd>&gt; Draft Document - &lt;
<a href="http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150609/aea1179e/FinalTransitionProposal_v5-Redline-commentsandeditsfordiscussion-0001.docx">
http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150609/aea1179e/FinalTransitionProposal_v5-Redline-commentsandeditsfordiscussion-0001.docx</a>
 &gt; 
<dd>&gt; 
<dd>&gt; Proposed text in most recent document - 
<dd>&gt; 
<dd>&gt;&gt; &quot; ICANN grants to PTI an exclusive, royalty-free,
fully-paid, worldwide license to use the IANA trademark and all related
trademarks, and all applications and registrations therefor, for use in
connection with PTI’s activities under the ICANN-PTIPTI Contract. Ă˘€ś 
<dd>&gt; 
<dd>&gt; this moves the draft farther away from the received comments,
and would this make the ICG’s job of aligning the va various proposals
from the affected parties into a cohesive plan even more difficult? 
<dd>&gt; 
<dd>&gt; It might be premature to go to BA with this as an accepted
direction, without concurrence from the affected parties. 
<dd>&gt; 
<dd>&gt; 
<dd>&gt; manning 
<dd>&gt; <a href="mailto:bmanning@karoshi.com">bmanning@karoshi.com</a> 
<dd>&gt; PO Box 12317 
<dd>&gt; Marina del Rey, CA 90295 
<dd>&gt; <a href="tel:310.322.8102">310.322.8102</a> 
<dd>&gt; 
<dd>&gt; 
<dd>&gt; 
<dd>&gt; _______________________________________________ 
<dd>&gt; CWG-Stewardship mailing list 
<dd>&gt;
<a href="mailto:CWG-Stewardship@icann.org">CWG-Stewardship@icann.org</a> 
<dd>&gt;
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a>
<dd>_______________________________________________ 
<dd>CWG-Stewardship mailing list 
<dd><a href="mailto:CWG-Stewardship@icann.org">
CWG-Stewardship@icann.org</a> 
<dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br>
</blockquote></blockquote>
</dl>
</dl>
</dl>
</dl>
<dd>&nbsp;<br><br>

<dd>&nbsp;<br><br>

<dd>_______________________________________________<br>

<dd>CWG-Stewardship mailing list<br>

<dd><a href="mailto:CWG-Stewardship@icann.org">
CWG-Stewardship@icann.org</a><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br><br>
<br><br>
<br>

<dd>-- <br>

<dd>
------------------------------------------------------------------------ 
<dl>
<dd>Seun Ojedeji, 
<dd>Federal University Oye-Ekiti 
<dd>web:&nbsp;&nbsp;&nbsp;&nbsp;
<a href="http://www.fuoye.edu.ng">http://www.fuoye.edu.ng</a> 
<dd>Mobile: <a href="tel:%2B2348035233535">+2348035233535</a> 
<dd>alt email:<a href="mailto:seun.ojedeji@fuoye.edu.ng">
seun.ojedeji@fuoye.edu.ng</a> 
<dl>
<dd>The key to understanding is humility - my view !<br><br>
</dl>
</dl>
<dd>&nbsp;<br>

<dd>_______________________________________________<br>

<dd>CWG-Stewardship mailing list<br>

<dd><a href="mailto:CWG-Stewardship@icann.org">
CWG-Stewardship@icann.org</a><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/cwg-stewardship" eudora="autourl">
https://mm.icann.org/mailman/listinfo/cwg-stewardship</a><br><br>

</dl><br>
Content-Type: image/png; name=&quot;image.png&quot;<br>
Content-Disposition: inline; filename=&quot;image.png&quot;<br>
Content-ID: &lt;ii_14de0cbf61d40fdc&gt;<br>
X-Attachment-Id: ii_14de0cbf61d40fdc<br><br>
</blockquote></body>
</html>