Re: [CWG-Stewardship] FW: [client com] IPR Memo
Thanks for the share Grace. Briefly looking through the document seem to indicate the only disadvantage of leaving the trademarks to ICANN is the unlikely case of bankruptcy. Will it not be be logical to count the disadvantages of each scenarios and be done with this trademark issues ;-) Regards On 5 Aug 2015 4:38 pm, "Grace Abuhamad" <grace.abuhamad@icann.org> wrote: Dear all, This legal input was sent to the Client Committee earlier today. Best, Grace From: <cwg-client-bounces@icann.org> on behalf of Sharon Flanagan < sflanagan@sidley.com> Date: Wednesday, August 5, 2015 at 12:05 AM To: Client Committee <cwg-client@icann.org> Subject: [client com] IPR Memo Dear All, Attached is a memo on the IPR issue under the three ownership structures. Please let us know if you have any questions or would like to discuss. Best regards, Holly, Josh and Sharon *SHARON* *FLANAGAN* Partner *Sidley Austin LLP* +1.415.772.1271 sflanagan@sidley.com **************************************************************************************************** This e-mail is sent by a law firm and may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. **************************************************************************************************** _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, On Wed, Aug 05, 2015 at 06:48:32PM +0100, Seun Ojedeji wrote:
Thanks for the share Grace. Briefly looking through the document seem to indicate the only disadvantage of leaving the trademarks to ICANN is the unlikely case of bankruptcy.
It seems to me that the memo is a little sanguine about the numbers community's possible reaction to the idea of leaving the trademarks and domain name with ICANN, and that it contains a misunderstanding. The CWG's IANA Stewardship Transition Proposal does have PTI as the IANA functions operator; but the numbers community proposal component of the Final Proposal does not talk about the IANA functions operator, but about the "IANA Numbering Services Operator". Moreover, that proposal says, "…the Internet Number Community believes that ICANN should remain in the role of the IANA Numbering Services Operator for at least the initial term of the new contract." (¶2076). This means that, from the numbers community point of view, the separation that the Sidley memo depends on will not exist. In such a case, leaving the trademarks and domain name with ICANN does not achieve the goal of moving the assets, because ICANN can then hold the assets up in an attempt to foil the ability of the numbers community to terminate the agreement. That was precisely the thing that moving the assets was supposed to prevent. This is made clear in the Transition Proposal, ¶2083: "Identifying an organization that is not the IANA Numbering Services Operator and which will permanently hold these assets will facilitate a smooth transition should another operator (or operators) be selected in the future. It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non- discriminatory manner for the benefit of the entire community. From the Internet Number Community’s perspective, the IETF Trust would be an acceptable candidate for this role." It seems to me it would be really wise to get the reaction from the numbers community to this idea before determining what the course of action is. They're the only community, after all, whose proposal contained a specific proposal about what to do here, and for the total proposal to work we need to be compatible with that (as noted in the ICG's assessment, ¶35). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
It seems to me that we are way past the time when all impacted parties should start talking with one another instead of at one another. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, August 05, 2015 2:14 PM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] FW: [client com] IPR Memo Hi, On Wed, Aug 05, 2015 at 06:48:32PM +0100, Seun Ojedeji wrote:
Thanks for the share Grace. Briefly looking through the document seem to indicate the only disadvantage of leaving the trademarks to ICANN is the unlikely case of bankruptcy.
It seems to me that the memo is a little sanguine about the numbers community's possible reaction to the idea of leaving the trademarks and domain name with ICANN, and that it contains a misunderstanding. The CWG's IANA Stewardship Transition Proposal does have PTI as the IANA functions operator; but the numbers community proposal component of the Final Proposal does not talk about the IANA functions operator, but about the "IANA Numbering Services Operator". Moreover, that proposal says, "…the Internet Number Community believes that ICANN should remain in the role of the IANA Numbering Services Operator for at least the initial term of the new contract." (¶2076). This means that, from the numbers community point of view, the separation that the Sidley memo depends on will not exist. In such a case, leaving the trademarks and domain name with ICANN does not achieve the goal of moving the assets, because ICANN can then hold the assets up in an attempt to foil the ability of the numbers community to terminate the agreement. That was precisely the thing that moving the assets was supposed to prevent. This is made clear in the Transition Proposal, ¶2083: "Identifying an organization that is not the IANA Numbering Services Operator and which will permanently hold these assets will facilitate a smooth transition should another operator (or operators) be selected in the future. It is the preference of the Internet Number Community that the IANA trademark and the IANA.ORG domain name be transferred to an entity independent of the IANA Numbering Services Operator, in order to ensure that these assets are used in a non- discriminatory manner for the benefit of the entire community. From the Internet Number Community’s perspective, the IETF Trust would be an acceptable candidate for this role." It seems to me it would be really wise to get the reaction from the numbers community to this idea before determining what the course of action is. They're the only community, after all, whose proposal contained a specific proposal about what to do here, and for the total proposal to work we need to be compatible with that (as noted in the ICG's assessment, ¶35). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi,
In such a case, leaving the trademarks and domain name with ICANN does not achieve the goal of moving the assets, because ICANN can then hold the assets up in an attempt to foil the ability of the numbers community to terminate the agreement.
I'm sorry, but I'm a bit confused. How exactly is this supposed to work again, particularly given as far as I can tell, "the numbers community" use of IANA.ORG is limited to (a) updating the delegations for the reverses for IPv4 and IPv6 blocks largely via an automated system; and (b) perhaps occasionally looking at the top-level IPv4, IPv6, and ASN registries (as far as I know, in a non-operational way -- I'm unaware of any software or system that depends on the contents of those registries)? If we assume "the numbers community" has decided to extract themselves from the use of the ICANN-operated IANA Numbering function, how exactly would ICANN refusing to give up IANA.ORG (which is FAR more operationally used by the IETF community and less so by the naming community) or the IANA trademarks have any impact on "the numbers community" at all? Presumably, they'd simply use the domain name supplied by the new operator (or perhaps the new operator would use a domain name supplied by "the numbers community"). What am I missing? Thanks, -drc (ICANN CTO, but speaking only for myself)
On Wed, Aug 05, 2015 at 09:41:58PM +0000, David Conrad wrote:
If we assume "the numbers community" has decided to extract themselves from the use of the ICANN-operated IANA Numbering function, how exactly would ICANN refusing to give up IANA.ORG (which is FAR more operationally used by the IETF community and less so by the naming community) or the IANA trademarks have any impact on "the numbers community" at all?
If you read the proposal, they seem to believe that this is an issue. I quoted the relevant text. I cannot pretend to be in the minds of others, so I can't tell you why people might feel this way. But that is the claim as far as I can tell. It seems to me that if one had wanted to dispute the claim, the time to have done that would have been when the proposal was being put together, rather than now when the other communities have been silent on the topic and the ICG has concluded that the whole proposal only hangs together if the other communities somehow agree to an arrangement that fits the names community's proposal requirements.
What am I missing?
You may not be missing anything now, but I think you may have missed your opportunity to talk the numbers community out of setting the requirement. It's now a part of the combined proposal from the ICG; if we don't find some way to accommodate it, then, according to the ICG's own discussion near the beginning of the document, the proposal will not hold together. If that happens, the process is that the ICG sends the whole thing back to the relevant communities and we don't get the proposal done in time for Dublin. And then we don't get a transition, because there won't be time. I hope it is evident to everyone that having this fall apart over a domain name would be something of a bitter irony. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
On Wed, Aug 05, 2015 at 07:54:08PM -0400, Andrew Sullivan wrote:
communities somehow agree to an arrangement that fits the names community's proposal requirements.
Um, "numbers community's", of course. Sorry. A -- Andrew Sullivan ajs@anvilwalrusden.com
I guess the numbers community indicated a few reasons why they "proposed" a transfer of the trademarks to IETF. It may be good to check if those concerns where addressed in the report sent by the CWG legal client. If they were, then it will be good that Chairs of both communities discuss those points together. If the CRISP chair is convinced, I am sure it will come back to the community for discussion. There is really no "cast in stone" content right now as the 3 communities has only proposed, so views can change, so long as there are compelling reasons. Regards On 6 Aug 2015 12:57 am, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
On Wed, Aug 05, 2015 at 07:54:08PM -0400, Andrew Sullivan wrote:
communities somehow agree to an arrangement that fits the names community's proposal requirements.
Um, "numbers community's", of course. Sorry.
A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
The only reasons expressed by the numbers community in their proposal regarding the IANA trademark/domain name are that transferring the trademarks to a third party "will facilitate a smooth transition should another operator (or operators) be selected in the future" and that it should be done "in order to ensure that these assets are used in a nondiscriminatory manner for the benefit of the entire community. Underlying the first reason is an apparent concern that that ICANN will be unwilling to allow use of the IANA trademarks and domain names in the event that the numbers community decided to give the Numbers Services Operator work to another (i.e, non-ICANN) entity. ICANN has stated that they will enter into an agreement to grant usage rights to a new operator, but this came after the numbers proposal was finalized so its unclear if that would have any effect on the numbers community's view. I don't recall reading anything that explained the apparent concern that ICANN would use the IPR assets in a "discriminatory manner," so I am at a loss to understand the genesis of this reason (and not surprisingly, there is nothing in the Sidley memo that deals with this mysterious concern). It seems that this choice of the numbers community is being imposed on the names community solely based on separability concerns. The Sidley memo addressed this to some extent, stating that ICANN could be obligated under its contracts to cooperate in any transition to a new operator, including by granting a trademark license to the new Numbers Services Operator for use of the IANA trademarks and to use some portion of the iana.org website for a subsite devoted to numbers matters (perhaps by creating a subdomain). I would hope that there is room for further dialogue with the other communities, and for the names community to actually make a choice in this matter. However, I'm concerned, based on some of the statements in this thread and some of the statements in the ICG proposal, that the CWG and the names community are being strong-armed to accept the numbers community proposal whether we like it or not. And that is deeply troubling. Greg On Wed, Aug 5, 2015 at 11:04 PM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
I guess the numbers community indicated a few reasons why they "proposed" a transfer of the trademarks to IETF.
It may be good to check if those concerns where addressed in the report sent by the CWG legal client. If they were, then it will be good that Chairs of both communities discuss those points together.
If the CRISP chair is convinced, I am sure it will come back to the community for discussion. There is really no "cast in stone" content right now as the 3 communities has only proposed, so views can change, so long as there are compelling reasons.
Regards On 6 Aug 2015 12:57 am, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
On Wed, Aug 05, 2015 at 07:54:08PM -0400, Andrew Sullivan wrote:
communities somehow agree to an arrangement that fits the names community's proposal requirements.
Um, "numbers community's", of course. Sorry.
A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, On Thu, Aug 06, 2015 at 01:37:45AM -0400, Greg Shatan wrote:
I don't recall reading anything that explained the apparent concern that ICANN would use the IPR assets in a "discriminatory manner," so I am at a loss to understand the genesis of this reason (and not surprisingly, there is nothing in the Sidley memo that deals with this mysterious concern).
If it is not obvious by now that some people in other operational communities do not trust ICANN to behave in a disinterested manner, then I'm not sure how to convince people. That is the explanation.
It seems that this choice of the numbers community is being imposed on the names community solely based on separability concerns.
The proposal was developed in public some time ago (and rather a long time, in this context). We all of us had ample time to raise objections to that and so on, and we knew that the ICG was going to take the different community positions and try to stitch them together. CWG (and IETF, for that matter) declined to state anything inconsistent with the numbes community proposal when delivering its proposal, so the numbers community proposal is what we have.
thread and some of the statements in the ICG proposal, that the CWG and the names community are being strong-armed to accept the numbers community proposal whether we like it or not. And that is deeply troubling.
I think that is an unfair interpretation of the state of affairs. We knew how the ICG was going to work, because it told us way in advance. By delivering a proposal that was not inconsistent with this provision of the numbers community proposal, the whole proposal automatically inherited the proposal from the numbers community. If we can't come up with an implementation of the unified proposal, the unified proposal falls apart. There's no strong-arming: this is the process we're working under, and by standing mute on this issue in its proposal CWG in effect accepted the proposal from the other community. It's not like there was a secret about it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew,
The proposal was developed in public some time ago (and rather a long time, in this context). We all of us had ample time to raise objections to that and so on, and we knew that the ICG was going to take the different community positions and try to stitch them together.
Well, yes. However, if the basis of an aspect of a proposal doesn't appear to make sense and that that problem isn't identified until after people have time to sit down and actually think about stuff, it seems a bit odd to me to say "oh well, you had your chance to fix it months ago." It's sort of like someone identifying a problem in an Internet Draft in IETF last call and the working group saying "sorry, you should've said something during the working group session a year ago."
CWG (and IETF, for that matter) declined to state anything inconsistent with the numbes community proposal when delivering its proposal, so the numbers community proposal is what we have.
This seems to be an interesting interpretation of "stitch together". An alternative interpretation would be that the ICG would actively work with the operational communities to modify the inconsistencies in order to reach a consensus opinion, not simply be passive and kick everything back to the operational communities to start over as you appear to be suggesting. Regards, -drc
On Thu, Aug 06, 2015 at 02:40:56PM +0000, David Conrad wrote:
Well, yes. However, if the basis of an aspect of a proposal doesn't appear to make sense and that that problem isn't identified until after people have time to sit down and actually think about stuff, it seems a bit odd to me to say "oh well, you had your chance to fix it months ago."
With respect, the idea that anyone didn't "have time" to think about this since the CRISP proposal was available ages ago is preposterous. Everyone knew that this was an issue, and people discussed it. We also knew what the process was going to be, and that there was going to be a conflict resolution problem if the communities had different views. Failing to have raised this during the many months that the CRISP proposal was on the table is and claiming now that this was something nobody'd really given proper thought to is, IMO, a pretty dangerous line to take.
It's sort of like someone identifying a problem in an Internet Draft in IETF last call and the working group saying "sorry, you should've said something during the working group session a year ago."
No, it's not, because the IETF almost never has a deadline imposed by US electoral politics.
This seems to be an interesting interpretation of "stitch together". An alternative interpretation would be that the ICG would actively work with the operational communities to modify the inconsistencies in order to reach a consensus opinion, not simply be passive and kick everything back to the operational communities to start over as you appear to be suggesting.
The ICG has been _crystal clear_ that they were going to kick any such problem back to the communities. They've said it over and over again. Anyone who thinks they were kidding is just engaging in wishful thinking. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Apologies: I left off the disclaimer that appears to be essential in discussions on this list. On Aug 6, 2015, at 7:40 AM, David Conrad <david.conrad@icann.org> wrote:
Andrew,
The proposal was developed in public some time ago (and rather a long time, in this context). We all of us had ample time to raise objections to that and so on, and we knew that the ICG was going to take the different community positions and try to stitch them together.
Well, yes. However, if the basis of an aspect of a proposal doesn't appear to make sense and that that problem isn't identified until after people have time to sit down and actually think about stuff, it seems a bit odd to me to say "oh well, you had your chance to fix it months ago." It's sort of like someone identifying a problem in an Internet Draft in IETF last call and the working group saying "sorry, you should've said something during the working group session a year ago."
CWG (and IETF, for that matter) declined to state anything inconsistent with the numbes community proposal when delivering its proposal, so the numbers community proposal is what we have.
This seems to be an interesting interpretation of "stitch together". An alternative interpretation would be that the ICG would actively work with the operational communities to modify the inconsistencies in order to reach a consensus opinion, not simply be passive and kick everything back to the operational communities to start over as you appear to be suggesting.
Regards, -drc
(ICANN CTO, but speaking only for myself)
Hi David, Perhaps I can provide some helpful context. From very early in the transition proposal development process, the ICG has been encouraging all interested parties to engage in the operational community discussions as early as possible. This is stated in the RFP we released nearly a year ago, in September 2014. [1] The numbers proposal was submitted to the ICG in January. It has not changed since then. The ICG analyzed it on its own as well as in conjunction with the other two operational community proposals. The ICG asked the numbers community some follow-up questions, including about IANA-related IPR, but none of those resulted in any changes to the numbers proposal. Based on the submissions the ICG received from the other two communities and a follow-up exchange the ICG had with the CWG, the ICG has concluded as follows (paragraph 34-35 in the transition proposal that is now out for public comment): " The ICG identified a potential compatibility issue regarding the IANA trademarks and the iana.org domain name. The numbers community proposed that the trademarks and domain name associated with the provision of the IANA services be held by an entity that is not the provider of the IANA numbering services, the IETF Trust being suggested as the repository. Although the protocol parameters proposal did not speak to this issue, in response to an ICG inquiry the protocol parameters community indicated that it had no objection to the IETF Trust serving as the repository for the trademarks and domain name associated with the provision of the IANA services. 35 The names proposal contains text that refers to the trademark in Annex S. In response to an ICG inquiry about the text, the CWG indicated that the text is clearly defined as placeholder text (in square brackets) within an initial draft proposed term sheet that does not have the consensus support of the CWG. In effect, the names proposal does not make a specific proposal with regard to the IANA trademarks (and it is completely silent as regards the domain name). Thus, the ICG considers the three proposals to be compatible in this regard, as the numbers proposal is the only one of the three proposals that includes requirements related to IANA intellectual property. As long as the other two communities can accommodate the specified requirements as part of their implementation, then the implementation of the proposals will be compatible. The ICG expects the operational communities to continue to coordinate on this topic during the implementation phase to ensure that the requirements are met. In short, the proposals are compatible because only one of them states a position on the issue at hand. At present, the transition proposal is out for public comment. While the ICG has requested that commenters focus on specific questions about the proposal as a whole [2], some commenters may choose to comment on details of the individual operational community proposals. Although the numbers proposal has been stable for many months, if you believe any aspect of any of the proposals is unworkable, submitting a public comment would be one option for you to express your concerns. However, as noted in the text quoted above and as is my understanding of what happened on the CWG call today, it might be preferable to see what the outcome of the ongoing coordination between the communities is first. And if you or anyone requires clarification about the rationales behind or anticipated implementation of the numbers portion of the proposal, I would encourage you to send mail to ianaxfer@nro.net. Best, Alissa [1] https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.... [2] https://www.ianacg.org/calls-for-input/combined-proposal-public-comment-peri... On Aug 6, 2015, at 8:04 AM, David Conrad <david.conrad@icann.org> wrote:
Apologies: I left off the disclaimer that appears to be essential in discussions on this list.
On Aug 6, 2015, at 7:40 AM, David Conrad <david.conrad@icann.org> wrote:
Andrew,
The proposal was developed in public some time ago (and rather a long time, in this context). We all of us had ample time to raise objections to that and so on, and we knew that the ICG was going to take the different community positions and try to stitch them together.
Well, yes. However, if the basis of an aspect of a proposal doesn't appear to make sense and that that problem isn't identified until after people have time to sit down and actually think about stuff, it seems a bit odd to me to say "oh well, you had your chance to fix it months ago." It's sort of like someone identifying a problem in an Internet Draft in IETF last call and the working group saying "sorry, you should've said something during the working group session a year ago."
CWG (and IETF, for that matter) declined to state anything inconsistent with the numbes community proposal when delivering its proposal, so the numbers community proposal is what we have.
This seems to be an interesting interpretation of "stitch together". An alternative interpretation would be that the ICG would actively work with the operational communities to modify the inconsistencies in order to reach a consensus opinion, not simply be passive and kick everything back to the operational communities to start over as you appear to be suggesting.
Regards, -drc
(ICANN CTO, but speaking only for myself)
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, Given that Numbers does not want ICANN to have it, and given that the IETF trust is bound to IETF concerns, I personally find it difficult to understand how we will come to any solution other than the creation of a trust specifically for the IANA names and marks. If Names agrees to this, then we and Numbers will be on the same page. Of course while Protocols seems willing to have it in a trust, there is no indication of their willingness for it to be in a trust other than the one they control. So that may be a hangup. If a trust can be written to make it accountable to each of the 3 communities with a commitment to do the right thing if one of them breaks away from the common IANA, and with 1 rep from each of the operational communities designated as the owner of the trust, woud it be possible to cut this knot? avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hi, I don't think it's about numbers not wanting ICANN to have it(because they currently have it anyway) but about number's concern on whether ICANN would refuse to provide access. So the question will be, Whether ICANN can assure numbers of access to the trademark to clear their concern comfortably. The numbers currently recognise that ICANN is doing fine, u don't think she will not be willing to read an assurance from ICANN that the trademark access will be possible. That said, if setting up an independent trust will be the acceptable solution fine let's go ahead. Nevertheless, I think it's just an overkill IMO. Regards On 6 Aug 2015 6:42 pm, "Avri Doria" <avri@acm.org> wrote:
Hi,
Given that Numbers does not want ICANN to have it, and given that the IETF trust is bound to IETF concerns, I personally find it difficult to understand how we will come to any solution other than the creation of a trust specifically for the IANA names and marks.
If Names agrees to this, then we and Numbers will be on the same page. Of course while Protocols seems willing to have it in a trust, there is no indication of their willingness for it to be in a trust other than the one they control. So that may be a hangup.
If a trust can be written to make it accountable to each of the 3 communities with a commitment to do the right thing if one of them breaks away from the common IANA, and with 1 rep from each of the operational communities designated as the owner of the trust, woud it be possible to cut this knot?
avri
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, On Thu, Aug 06, 2015 at 01:41:48PM -0400, Avri Doria wrote:
Of course while Protocols seems willing to have it in a trust, there is no indication of their willingness for it to be in a trust other than the one they control. So that may be a hangup.
Emphasising that I speak only for myself, I can't see why the IETF would be any more resistant to some additional trust than it would be to the idea of ICANN continuing to hold the assets (which, after all, was the state of affairs about which IANAPLAN declined to comment last year). I worry (again because of availability of people) about the possibility of adding more institutional commitments to the IETF's ledger, but it may just be a cost of doing business.
If a trust can be written to make it accountable to each of the 3 communities with a commitment to do the right thing if one of them breaks away from the common IANA, and with 1 rep from each of the operational communities designated as the owner of the trust, woud it be possible to cut this knot?
There is the issue Greg seems to be worried about, which is the relationship between the TM holder and the activity so covered. I have had different opinions from different lawyers about that view, so I'm not entirely sure I understand it. But there might be another way here that would leave things in the hands of ICANN and still be acceptable to the numbers community. Suppose we created a three-person panel with appointees by each of the three operational communities. Suppose it had the ability to direct the ICANN board in how to license the various assets. Suppose that this were written into one of the fundamental bylaws. I wonder whether that would be adequate to address RIRs' concerns. It's still not perfect. The CCWG proposals about the fundamental bylaws give the ICANN community (or actually, certain participating constituencies) control over those bylaws, so in the event of a serious dispute ICANN (the community) could change the ICANN (the corporation) bylaws in a way that delivers all the problems the numbers community is worried about. But it would take time and the numbers community therefore might have time to react, try to stop it, and develop (and warn everyone about) an alternative plan. I have no idea whether this would be any good or fly with anyone, and this is the first I've even thought of it (so please feel free to rip it apart). But in the spirit of trying to see a way out of this unpleasant conversation, I thought I'd offer it and see what people think. A -- Andrew Sullivan ajs@anvilwalrusden.com
I don't recall reading anything that explained the apparent concern that ICANN would use the IPR assets in a "discriminatory manner," so I am at a loss to understand the genesis of this reason (and not surprisingly, there is nothing in the Sidley memo that deals with this mysterious concern). First, your assertion is factually untrue. There has been extensive discussion of the switching costs associated with allowing an incumbent operator to control the IPR associated with the service. Second, you have now admitted that the Sidley memo fails to deal with the transferability concern. Since this concern is, and has been, the key consideration behind the call for a transfer of the IPR, its omission indicates that the memo has little value in these discussions.
On 6 Aug 2015 3:49 pm, "Mueller, Milton L" < milton.mueller@pubpolicy.gatech.edu> wrote:
I don't recall reading anything that explained the apparent concern that
ICANN would use the IPR assets in a "discriminatory manner," so I am at a loss to understand the genesis of this reason (and not surprisingly, there is nothing in the Sidley memo that deals with this mysterious concern).
First, your assertion is factually untrue. There has been extensive
discussion of the switching costs associated with allowing an incumbent operator to control the IPR associated with the service.
Just to clarify, I presume the cost referred is on whether ICANN will be willing to allow access to the trademark in a manner currently experienced if an operational community decides to move it's function to another operator? If I am write, I think ICANN board confirmed such will be possible and I think the legal memo also proposed how to ensure such possibility. Other than that, is there any other specific cost you refer? If yes, would that cost have been likely as well if NTIA had decided to transition IANA to another operator today?
Second, you have now admitted that the Sidley memo fails to deal with the
transferability concern. Since this concern is, and has been, the key consideration behind the call for a transfer of the IPR, its omission indicates that the memo has little value in these discussions.
While I am not Greg, I believe the memo suggested ways to ensure ICANN complies with the IANA trademarks usage/access requirements. There is also an indication from the memo that the community would have the accountability mechanism/powers to fix things if need be. Overall I think the fact that the CWG-Stewardship is not owning up to have it's view on this issue is of great concern. Initially it was said that the memo is what will help, we now have the memo and now we are saying it's a cross-operational community group that will help. Would it not be better for the CWG-Stewardship to just go neutral on this matter (like the IETF) and let the CRISP team's view prevail because I don't understand the essence of a cross-operational community group when one of the group currently have no specific direction/view on the subject of discussion. Hopefully we will recognise that time is ticking and an issue as small as this could indeed affect the overall transition from proceeding. Regards
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Would it not be better for the CWG-Stewardship to just go neutral on this matter (like the IETF) and let the CRISP team's view prevail because I don't understand the essence of a cross-operational community group when one of the group currently have no specific direction/view on the subject of discussion. MM: This is where Seun and I agree. The simplest way to avoid continued problems is to implement the specific proposal that the CRISP team has proposed. The only critique I have heard of that proposal is the ‘accountability’ issue regarding the IETF Trust, and that is not something I take seriously. The issue seems to be who can be trusted to keep the IANA mark and domain accessible, and the IETF has from its origins treated the Internet protocols and standards it produces nonproprietary. Indeed, global compatibility and nonproprietary standards are deeply ingrained in the IETF culture, so I can’t think of a better trustee for the IANA domain and mark. Hopefully we will recognise that time is ticking and an issue as small as this could indeed affect the overall transition from proceeding. MM: Indeed.
Would it not be better for the CWG-Stewardship to just go neutral on this matter (like the IETF) and let the CRISP team's view prevail because I don't understand the essence of a cross-operational community group when one of the group currently have no specific direction/view on the subject of discussion.
For what it is worth, I agree with Milton *. We’ve been in neutral mode at the IETF since last year, for various reasons. As noted, we’ve expressed our willingness to step up and have the IETF Trust provide a home if needed. Would be happy to do so **. Or we could participate in other solutions. But lets avoid any of our three community proposals having to go back to the community process and seek for re-approval. I think that would be silly. Jari *) And didn’t that already happen? It was clearly stated at ICANN53 that the CWG proposal was silent on this topic. I think the rest is implementation, and we should accommodate the whole proposal as specified. **) Also, I can say from the IETF perspective that we are working on providing some suggested implementation approach(es) that satisfies the numbers community’s requirements and will communicate to CWG and CRISP when we have something written up. The details matter and it will take time, but we are considering this as an implementation issue, not something that should fundamentally change the transition proposal.
There's really no such thing as being neutral at this point, since the effect would be the same as affirmatively accepting the CRISP proposal. Any position we take will be a decision. any of our three community proposals having to go back to the community process and seek for re-approvalI think the IETF decision not to object (which was still a decision) is difficult to compare, because that decision would put the trademarks and domain names into the IETF Trust, a trust set up by the IETF with the IETF as its beneficiary. It's not surprising that the IETF would feel comfortable with that decision (subject to possible concerns about how that might change the IETF Trust). I also don't think it's accurate to state that failing to embrace the CRISP proposal will result in "any of our three community proposals having to go back to the community process and seek for re-approval." There's no indication that needs to happen, and stating that it will tends to look like an attempt to shove the CWG into accepting the CRISP proposal by proposing that some awful thing will happen if we don't. That may not have been the intent, but it certainly could be the effect. As to Jari's first footnote, deciding to be neutral did not happen. Would we be doing what we're doing right now if it did? While I don't think there's any benefit to rehashing things, the CWG's decision and statement regarding the "silent" nature of the proposal was more nuanced than that, and it was clear that the effect was to reserve the CWG's ability to face this issue head-on, which we are doing now. Backing into a decision was never the intent, and it should not be the effect or the interpretation. We need to do what we are doing, which is to subject the options to scrutiny, and come to an affirmative decision on the merits and substance of these options, based on both legal and policy considerations. We need to decide which option is the most appropriate option without being pressured into accepting any particular option (since I've been told that we are not being "strongarmed" into a particular outcome, and that it would be "unfair" for us to feel that we were). As to Jari's second footnote, it's good to hear that the IETF is considering the consequences of the CRISP proposal. I think it behooves the CWG to determine what our "requirements" would be if the CRISP proposal came to pass, both generally and specifically as to the IETF Trust (as opposed to some other existing or yet-to-be-created third party). We may need to do this even before we decide whether the CRISP proposal is one that we will adopt (indeed, it's really part of the same analysis). We will then need to communicate that promptly to the ICG and to the other communities. If we don't do that, this is going to become yet another decision delivered to us, instead of made by us. Greg On Sun, Aug 9, 2015 at 11:27 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
Would it not be better for the CWG-Stewardship to just go neutral on this matter (like the IETF) and let the CRISP team's view prevail because I don't understand the essence of a cross-operational community group when one of the group currently have no specific direction/view on the subject of discussion.
For what it is worth, I agree with Milton *.
We’ve been in neutral mode at the IETF since last year, for various reasons. As noted, we’ve expressed our willingness to step up and have the IETF Trust provide a home if needed. Would be happy to do so **. Or we could participate in other solutions. But lets avoid any of our three community proposals having to go back to the community process and seek for re-approval. I think that would be silly.
Jari
*) And didn’t that already happen? It was clearly stated at ICANN53 that the CWG proposal was silent on this topic. I think the rest is implementation, and we should accommodate the whole proposal as specified.
**) Also, I can say from the IETF perspective that we are working on providing some suggested implementation approach(es) that satisfies the numbers community’s requirements and will communicate to CWG and CRISP when we have something written up. The details matter and it will take time, but we are considering this as an implementation issue, not something that should fundamentally change the transition proposal.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 10 August 2015 at 09:46, Greg Shatan <gregshatanipc@gmail.com> wrote:
I also don't think it's accurate to state that failing to embrace the CRISP proposal will result in "any of our three community proposals having to go back to the community process and seek for re-approval." There's no indication that needs to happen, and stating that it will tends to look like an attempt to shove the CWG into accepting the CRISP proposal by proposing that some awful thing will happen if we don't. That may not have been the intent, but it certainly could be the effect.
Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part of the principles NTIA expects us to follow: Support and enhance the multistakeholder model; and Meet the needs and expectations of the global customers and partners of the IANA services. My views alone. Regards ______________________ Mwendwa Kivuva, Nairobi, Kenya "There are some men who lift the age they inhabit, till all men walk on higher ground in that lifetime." - Maxwell Anderson
And shouldn't the names community have that opportunity now? In any event, that doesn't mean an entire proposal would be sent back for re-approval. On Monday, August 10, 2015, Mwendwa Kivuva <Kivuva@transworldafrica.com> wrote:
On 10 August 2015 at 09:46, Greg Shatan <gregshatanipc@gmail.com <javascript:_e(%7B%7D,'cvml','gregshatanipc@gmail.com');>> wrote:
I also don't think it's accurate to state that failing to embrace the CRISP proposal will result in "any of our three community proposals having to go back to the community process and seek for re-approval." There's no indication that needs to happen, and stating that it will tends to look like an attempt to shove the CWG into accepting the CRISP proposal by proposing that some awful thing will happen if we don't. That may not have been the intent, but it certainly could be the effect.
Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part of the principles NTIA expects us to follow: Support and enhance the multistakeholder model; and Meet the needs and expectations of the global customers and partners of the IANA services.
My views alone.
Regards ______________________ Mwendwa Kivuva, Nairobi, Kenya
"There are some men who lift the age they inhabit, till all men walk on higher ground in that lifetime." - Maxwell Anderson
From: Greg Shatan [mailto:gregshatanipc@gmail.com] On Monday, August 10, 2015, Mwendwa Kivuva <Kivuva@transworldafrica.com<mailto:Kivuva@transworldafrica.com>> wrote: Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part
And shouldn't the names community have that opportunity now?
MM: The names community has had that opportunity for about six months. And it still does have that opportunity. The problem is that you have failed to convince even the names community that ICANN should hold the trademarks – there is clearly no consensus on this – and most of us here have expressed a willingness to accept the CRISP proposal. So what Seun called “neutral” simply meant that there is no consensus here to overcome or substitute for the CRISP proposal, and in the absence of such a consensus proposal it is ok to accede to what the others have already accepted.
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
MM: No, but a refusal to accept the CRISP proposal and development of another alternative does mean an important part of the proposal would have to be re-approved by two other communities. And it’s not like we have a consensus alternative for the other communities to consider. So it also means spending another month or two developing an alternative. All this, for a position that seem to be supported by only you.
Hi, My guess is that the Co-Chairs at the moment prefer suggestions that further postpone the CWG's need to make decision on the TM issue. Otherwise i fail to understand what other convincing is required to have a consensus view of the CWG on this matter (which i will again say is supposed to be minor) While my preference has always been leaving the TM with ICANN, i have no issue with it going to the IETF trust because i think that would be the least complicated and "trusted" external entity that can house the TM. Any other external setup would be complicated, unpredictable and not in anyway justify the "perceived" fear of leaving it with ICANN It is my hope that the co-chairs will rethink the need for a cross-operational community group as it will still bring us back to status-quo considering that we have no CWG's view at the moment. Regards On Mon, Aug 10, 2015 at 1:54 PM, Mueller, Milton L < milton.mueller@pubpolicy.gatech.edu> wrote:
*From:* Greg Shatan [mailto:gregshatanipc@gmail.com]
On Monday, August 10, 2015, Mwendwa Kivuva <Kivuva@transworldafrica.com> wrote:
Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part
And shouldn't the names community have that opportunity now?
MM: The names community has had that opportunity for about six months. And it still does have that opportunity. The problem is that you have failed to convince even the names community that ICANN should hold the trademarks – there is clearly no consensus on this – and most of us here have expressed a willingness to accept the CRISP proposal. So what Seun called “neutral” simply meant that there is no consensus here to overcome or substitute for the CRISP proposal, and in the absence of such a consensus proposal it is ok to accede to what the others have already accepted.
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
MM: No, but a refusal to accept the CRISP proposal and development of another alternative does mean an important part of the proposal would have to be re-approved by two other communities. And it’s not like we have a consensus alternative for the other communities to consider. So it also means spending another month or two developing an alternative. All this, for a position that seem to be supported by only you.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
On Mon, Aug 10, 2015 at 8:54 AM, Mueller, Milton L < milton.mueller@pubpolicy.gatech.edu> wrote:
*From:* Greg Shatan [mailto:gregshatanipc@gmail.com]
On Monday, August 10, 2015, Mwendwa Kivuva <Kivuva@transworldafrica.com> wrote:
Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part
And shouldn't the names community have that opportunity now?
MM: The names community has had that opportunity for about six months. And it still does have that opportunity. The problem is that you have failed to convince even the names community that ICANN should hold the trademarks – there is clearly no consensus on this – and most of us here have expressed a willingness to accept the CRISP proposal.
GS: I don't think anybody has been convinced of anything, yet -- including a willingness to accept (or to give in to) the CRISP proposal.
So what Seun called “neutral” simply meant that there is no consensus here to overcome or substitute for the CRISP proposal, and in the absence of such a consensus proposal it is ok to accede to what the others have already accepted.
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
MM: No, but a refusal to accept the CRISP proposal and development of another alternative does mean an important part of the proposal would have to be re-approved by two other communities. And it’s not like we have a consensus alternative for the other communities to consider. So it also means spending another month or two developing an alternative. All this, for a position that seem to be supported by only you.
GS: Just the emails that have come up in the last few hours have proven your last statement wrong. I suggest that your other "nose-counting" exercises are o ff-target as well .
GS: Just the emails that have come up in the last few hours have proven your last statement wrong. I suggest that your other "nose-counting" exercises are off-target as well Not counting noses, Greg, just counting the number of people who have said they can’t live with IETF Trust holding the trademarks. I stand by my assessment. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology
Hi Greg, On Mon, Aug 10, 2015 at 04:04:31AM -0400, Greg Shatan wrote:
And shouldn't the names community have that opportunity now?
There are lots of things that, in an ideal world, we might like to have happen. Unfortunately, we're constrained by the calendar in this world. I suggest that even if the names community wants to discuss this with all logically possible options open to it, the only live options now are "somehow consistent with what the numbers community published in January" or "no transition". See below for why I think this.
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
No, but that doesn't help. Suppose that we wanted the numbers community to agree that ICANN itself meets the criteria in the portion of the ICG proposal that came from the numbers community. I suggest that this flies in the face of the plain meaning of the text at ¶ 2076 and ¶ 2083. So we'd need to find some way to get the numbers community to agree with this novel reading. Now, the way the "numbers community" is structured, this would involve coming to agreement with the CRISP team. They would then have to evaluate consensus among the RIRs. To do that, each RIR would need to go back to its community and run its consensus process. Each RIR does this differently, but it takes time in every case. I'd be astonished if a change like this could be decided in under a month. If there are adjustments that have to happen in order to get the relevant support, then that too has to go through the relevant paths and back to all the various RIRs. And of course, all of this assumes that names and numbers don't come up with something inconsistent with the text that came from the IETF. If so, then you have that community to involve, too; and changes to the IANAPLAN WG's product cannot possibly happen in less than a month, assuming everyone was already on board (because of the length of time last call would take. If we tried to run it short, we'd create an avenue for appeal). Once all of that is done, then the ICG would have to knit the new state of affairs into its proposal and await public comment on that. I don't see how all of this happens in time for the proposal to be demonstrably supported by everyone in time for the Dublin ICANN meeting. I do not believe there is any remaining slack in the timeline. And we cannot fail to do this in the completely above-board way I just outlined, because if we did we would not be acting consistently with the NTIA criteria, and the NTIA would not then be able to certify the transition plan, so the transition wouldn't go ahead anyway. Therefore, I believe that the CWG needs to come up with a resolution that is consistent with the proposal the ICG has put out, or else accept that the CWG's position will derail the transition. This is not any other community attempting to force anything down CWG's throat. This is just the fact of the calendar and the fact that the CWG was dealing with other things since January. Having stood mute on the principles underlying this topic when the proposals were going to the ICG, we now need to undertake implementation consistent with what the ICG published. That includes the proposal from the numbers community, so that's the principle we need to work with. If any of this is unclear or you want further elaboration, I'd be happy to discuss either on list or on the phone or however you like. The above is, of course, just my own analysis; and I have no special knowledge or power in this, but I'm reasonably confident in my sense of how long this could take in those other communities. Best regards, A (only for myself, as ever) -- Andrew Sullivan ajs@anvilwalrusden.com
I have a strong preference that the TM and domain name remain with ICANN. The CWG chose not to delve further in this matter prior to issuing its final proposal. Regardless of why that happened, that is a fact. When the report was issued and the issue was raised as to the meaning of the "placeholder" words in Annex S, the reply included the words "Therefore it is our firm view that it is specifically not in conflict with either of the CRISP & IANAPLAN proposals on this subject. To reaffirm this, and to discuss a potential consolidated position, we have extended an offer to the leadership of the other two operational communities for a call on Tuesday, 7 July." (Message from Jonathan Robinson, 02 July 2015). That, I presume, was the basis for the ICG issuing its consolidated proposal. I do not recall what was reported out of that meeting, if indeed it happened. Based on all of that, I still PREFER an option where ICANN holds the assets. However, I can live with them being transferred to the IETF Trust with appropriate contractual language to give the names community security that the assets will be available for them regardless of the paths taken to provide IANA service for the Numbers and Protocol communities. Establishing an understanding with the IETF Trust so that the details can be completed as part of the implementation schedule is, in my mind, the number one priority. Alan At 10/08/2015 11:34 AM, Andrew Sullivan wrote:
Hi Greg,
On Mon, Aug 10, 2015 at 04:04:31AM -0400, Greg Shatan wrote:
And shouldn't the names community have that opportunity now?
There are lots of things that, in an ideal world, we might like to have happen. Unfortunately, we're constrained by the calendar in this world. I suggest that even if the names community wants to discuss this with all logically possible options open to it, the only live options now are "somehow consistent with what the numbers community published in January" or "no transition". See below for why I think this.
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
No, but that doesn't help.
Suppose that we wanted the numbers community to agree that ICANN itself meets the criteria in the portion of the ICG proposal that came from the numbers community. I suggest that this flies in the face of the plain meaning of the text at ¶ 2076 and ¶ 2083. So we'd need to find some way to get the numbers community to agree with this novel reading.
Now, the way the "numbers community" is structured, this would involve coming to agreement with the CRISP team. They would then have to evaluate consensus among the RIRs. To do that, each RIR would need to go back to its community and run its consensus process. Each RIR does this differently, but it takes time in every case. I'd be astonished if a change like this could be decided in under a month. If there are adjustments that have to happen in order to get the relevant support, then that too has to go through the relevant paths and back to all the various RIRs.
And of course, all of this assumes that names and numbers don't come up with something inconsistent with the text that came from the IETF. If so, then you have that community to involve, too; and changes to the IANAPLAN WG's product cannot possibly happen in less than a month, assuming everyone was already on board (because of the length of time last call would take. If we tried to run it short, we'd create an avenue for appeal).
Once all of that is done, then the ICG would have to knit the new state of affairs into its proposal and await public comment on that.
I don't see how all of this happens in time for the proposal to be demonstrably supported by everyone in time for the Dublin ICANN meeting. I do not believe there is any remaining slack in the timeline. And we cannot fail to do this in the completely above-board way I just outlined, because if we did we would not be acting consistently with the NTIA criteria, and the NTIA would not then be able to certify the transition plan, so the transition wouldn't go ahead anyway.
Therefore, I believe that the CWG needs to come up with a resolution that is consistent with the proposal the ICG has put out, or else accept that the CWG's position will derail the transition. This is not any other community attempting to force anything down CWG's throat. This is just the fact of the calendar and the fact that the CWG was dealing with other things since January. Having stood mute on the principles underlying this topic when the proposals were going to the ICG, we now need to undertake implementation consistent with what the ICG published. That includes the proposal from the numbers community, so that's the principle we need to work with.
If any of this is unclear or you want further elaboration, I'd be happy to discuss either on list or on the phone or however you like. The above is, of course, just my own analysis; and I have no special knowledge or power in this, but I'm reasonably confident in my sense of how long this could take in those other communities.
Best regards,
A (only for myself, as ever)
-- Andrew Sullivan ajs at anvilwalrusden.com
On Mon, Aug 10, 2015 at 12:17:13PM -0400, Alan Greenberg wrote:
IANAPLAN proposals on this subject. To reaffirm this, and to discuss a potential consolidated position, we have extended an offer to the leadership of the other two operational communities for a call on Tuesday, 7 July." (Message from Jonathan Robinson, 02 July 2015). That, I presume, was the basis for the ICG issuing its consolidated proposal.
As I understand it, there was such a meeting and there will be more. But as I tried to say in Buenos Aires and again in my last message, meeting with "the leadership" of the numbers or protocol parameters community(ies) on this does not help at all if the plan is to do anything inconsistent with the proposal as published. For (as I think you know) "the leadership" of those communities can only act as a conduit for taking things back to their respective communities. The IETF in particular simply does not delegate people to speak for the IETF, except in extremely constrained ways (such as the IAOC for negotiating contracts).
Establishing an understanding with the IETF Trust so that the details can be completed as part of the implementation schedule is, in my mind, the number one priority.
I agree; though I would make a friendly amendment that, if the CWG thinks the IETF Trust is somehow unsuited (as for instance Avri has suggested) then with even greater urgency we need to get to work on the new trust organization or else figure out what minimal changes to the Trust agreement would put the names community at ease. My view is that we need to pick the path of least resistance consistent with the ICG proposal. Best regards, A (for myself) -- Andrew Sullivan ajs@anvilwalrusden.com
I accept that friendly amendment and should have had a reference to it in my original note. I agree on taking the path of least resistance which meets all of out mandatory goals. Alan At 10/08/2015 01:04 PM, Andrew Sullivan wrote:
On Mon, Aug 10, 2015 at 12:17:13PM -0400, Alan Greenberg wrote:
IANAPLAN proposals on this subject. To reaffirm this, and to discuss a potential consolidated position, we have extended an offer to the leadership of the other two operational communities for a call on Tuesday, 7 July." (Message from Jonathan Robinson, 02 July 2015). That, I presume, was the basis for the ICG issuing its consolidated proposal.
As I understand it, there was such a meeting and there will be more. But as I tried to say in Buenos Aires and again in my last message, meeting with "the leadership" of the numbers or protocol parameters community(ies) on this does not help at all if the plan is to do anything inconsistent with the proposal as published. For (as I think you know) "the leadership" of those communities can only act as a conduit for taking things back to their respective communities. The IETF in particular simply does not delegate people to speak for the IETF, except in extremely constrained ways (such as the IAOC for negotiating contracts).
Establishing an understanding with the IETF Trust so that the details can be completed as part of the implementation schedule is, in my mind, the number one priority.
I agree; though I would make a friendly amendment that, if the CWG thinks the IETF Trust is somehow unsuited (as for instance Avri has suggested) then with even greater urgency we need to get to work on the new trust organization or else figure out what minimal changes to the Trust agreement would put the names community at ease. My view is that we need to pick the path of least resistance consistent with the ICG proposal.
Best regards,
A (for myself)
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, Oh well, I guess that we better do what Milton and the Numbers community are telling us to do. We are forced and have no choice. Did I understand correctly? Personally until such time as we see the changes offered by the IETF Trust that addresses Names concerns (e.g. that their IETF focus of fiduciary responsibility would not necessarily serve Names well in a crisis) I think since letting ICANN hold the property just won't do, we need to plan on a separate trust. S Should we be asking the lawyer to define it for us? Or is that just an implementation detail. avri On 10-Aug-15 11:34, Andrew Sullivan wrote:
Hi Greg,
On Mon, Aug 10, 2015 at 04:04:31AM -0400, Greg Shatan wrote:
And shouldn't the names community have that opportunity now? There are lots of things that, in an ideal world, we might like to have happen. Unfortunately, we're constrained by the calendar in this world. I suggest that even if the names community wants to discuss this with all logically possible options open to it, the only live options now are "somehow consistent with what the numbers community published in January" or "no transition". See below for why I think this.
In any event, that doesn't mean an entire proposal would be sent back for re-approval. No, but that doesn't help.
Suppose that we wanted the numbers community to agree that ICANN itself meets the criteria in the portion of the ICG proposal that came from the numbers community. I suggest that this flies in the face of the plain meaning of the text at ¶ 2076 and ¶ 2083. So we'd need to find some way to get the numbers community to agree with this novel reading.
Now, the way the "numbers community" is structured, this would involve coming to agreement with the CRISP team. They would then have to evaluate consensus among the RIRs. To do that, each RIR would need to go back to its community and run its consensus process. Each RIR does this differently, but it takes time in every case. I'd be astonished if a change like this could be decided in under a month. If there are adjustments that have to happen in order to get the relevant support, then that too has to go through the relevant paths and back to all the various RIRs.
And of course, all of this assumes that names and numbers don't come up with something inconsistent with the text that came from the IETF. If so, then you have that community to involve, too; and changes to the IANAPLAN WG's product cannot possibly happen in less than a month, assuming everyone was already on board (because of the length of time last call would take. If we tried to run it short, we'd create an avenue for appeal).
Once all of that is done, then the ICG would have to knit the new state of affairs into its proposal and await public comment on that.
I don't see how all of this happens in time for the proposal to be demonstrably supported by everyone in time for the Dublin ICANN meeting. I do not believe there is any remaining slack in the timeline. And we cannot fail to do this in the completely above-board way I just outlined, because if we did we would not be acting consistently with the NTIA criteria, and the NTIA would not then be able to certify the transition plan, so the transition wouldn't go ahead anyway.
Therefore, I believe that the CWG needs to come up with a resolution that is consistent with the proposal the ICG has put out, or else accept that the CWG's position will derail the transition. This is not any other community attempting to force anything down CWG's throat. This is just the fact of the calendar and the fact that the CWG was dealing with other things since January. Having stood mute on the principles underlying this topic when the proposals were going to the ICG, we now need to undertake implementation consistent with what the ICG published. That includes the proposal from the numbers community, so that's the principle we need to work with.
If any of this is unclear or you want further elaboration, I'd be happy to discuss either on list or on the phone or however you like. The above is, of course, just my own analysis; and I have no special knowledge or power in this, but I'm reasonably confident in my sense of how long this could take in those other communities.
Best regards,
A (only for myself, as ever)
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Hi, On Mon, Aug 10, 2015 at 01:10:52PM -0400, Avri Doria wrote:
Oh well, I guess that we better do what Milton and the Numbers community are telling us to do.
For what it's worth, I think that needlessly personalizes this issue. Milton is arguing strongly, but the numbers proposal has been around for months and the names community elected not to put forth a position inconsistent with it. If CWG now wants to ask that something inconsistent with what ICG has published be the path we follow, nobody should be surprised that it would create some trouble.
We are forced and have no choice.
Did I understand correctly?
If what you mean by that is, "The march of time and CWG's low engagement with the numbers community proposal between January and June (because of other higher priorities) means that certain options are now foreclosed, and we might not like the remaining ones," then I think you did understand.
crisis) I think since letting ICANN hold the property just won't do, we need to plan on a separate trust. S
Should we be asking the lawyer to define it for us? Or is that just an implementation detail.
It seems to me that, before asking for legal advice on how to do something, one ought to be clear about what one wants. I agree with you, however, that a separate trust appears to me (and I speak only for myself) would satisfy the requirements in the ICG proposal out now, and might be a way forward. Perhaps we should spend some time kicking around what a good trust arrangement would look like to the CWG. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
-----Original Message----- If what you mean by that is, "The march of time and CWG's low engagement with the numbers community proposal between January and June (because of other higher priorities) means that certain options are now foreclosed, and we might not like the remaining ones," then I think you did understand.
Exactly.
It seems to me that, before asking for legal advice on how to do something, one ought to be clear about what one wants. I agree with you, however, that a separate trust appears to me (and I speak only for myself) would satisfy the requirements in the ICG proposal out now, and might be a way forward. Perhaps we should spend some time kicking around what a good trust arrangement would look like to the CWG.
I do think that that option has been foreclosed too, unless you delight in the prospect of adding 2-3 months to the process for a very marginal possible gain (or risk of loss) in the proposal. I agree with your earlier comment about following the path of least resistance and would not encourage anyone to start down this road.
Hi Avri, On Mon, Aug 10, 2015 at 6:10 PM, Avri Doria <avri@acm.org> wrote:
Personally until such time as we see the changes offered by the IETF Trust that addresses Names concerns (e.g. that their IETF focus of fiduciary responsibility would not necessarily serve Names well in a crisis) I think since letting ICANN hold the property just won't do, we need to plan on a separate trust. S
I really don't understand what we are looking to achieve with the new trust that IETF cannot ensure. Do you care to elaborate on why you think IETF is not sufficient as i havn't heard much of the whys and i believe you have more IETF history than myself so maybe there is more devil the details of IETF than i thought.
Should we be asking the lawyer to define it for us? Or is that just an implementation detail.
Wow! well its been said that the money is there so why not....lets keep on spending it FWIW. Lets just remember a few USD digits has just been spent on the TM and we have not made any good use of the output that came out of that effort. Regards
avri
On 10-Aug-15 11:34, Andrew Sullivan wrote:
Hi Greg,
On Mon, Aug 10, 2015 at 04:04:31AM -0400, Greg Shatan wrote:
And shouldn't the names community have that opportunity now? There are lots of things that, in an ideal world, we might like to have happen. Unfortunately, we're constrained by the calendar in this world. I suggest that even if the names community wants to discuss this with all logically possible options open to it, the only live options now are "somehow consistent with what the numbers community published in January" or "no transition". See below for why I think this.
In any event, that doesn't mean an entire proposal would be sent back for re-approval. No, but that doesn't help.
Suppose that we wanted the numbers community to agree that ICANN itself meets the criteria in the portion of the ICG proposal that came from the numbers community. I suggest that this flies in the face of the plain meaning of the text at ¶ 2076 and ¶ 2083. So we'd need to find some way to get the numbers community to agree with this novel reading.
Now, the way the "numbers community" is structured, this would involve coming to agreement with the CRISP team. They would then have to evaluate consensus among the RIRs. To do that, each RIR would need to go back to its community and run its consensus process. Each RIR does this differently, but it takes time in every case. I'd be astonished if a change like this could be decided in under a month. If there are adjustments that have to happen in order to get the relevant support, then that too has to go through the relevant paths and back to all the various RIRs.
And of course, all of this assumes that names and numbers don't come up with something inconsistent with the text that came from the IETF. If so, then you have that community to involve, too; and changes to the IANAPLAN WG's product cannot possibly happen in less than a month, assuming everyone was already on board (because of the length of time last call would take. If we tried to run it short, we'd create an avenue for appeal).
Once all of that is done, then the ICG would have to knit the new state of affairs into its proposal and await public comment on that.
I don't see how all of this happens in time for the proposal to be demonstrably supported by everyone in time for the Dublin ICANN meeting. I do not believe there is any remaining slack in the timeline. And we cannot fail to do this in the completely above-board way I just outlined, because if we did we would not be acting consistently with the NTIA criteria, and the NTIA would not then be able to certify the transition plan, so the transition wouldn't go ahead anyway.
Therefore, I believe that the CWG needs to come up with a resolution that is consistent with the proposal the ICG has put out, or else accept that the CWG's position will derail the transition. This is not any other community attempting to force anything down CWG's throat. This is just the fact of the calendar and the fact that the CWG was dealing with other things since January. Having stood mute on the principles underlying this topic when the proposals were going to the ICG, we now need to undertake implementation consistent with what the ICG published. That includes the proposal from the numbers community, so that's the principle we need to work with.
If any of this is unclear or you want further elaboration, I'd be happy to discuss either on list or on the phone or however you like. The above is, of course, just my own analysis; and I have no special knowledge or power in this, but I'm reasonably confident in my sense of how long this could take in those other communities.
Best regards,
A (only for myself, as ever)
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
On 10-Aug-15 14:46, Seun Ojedeji wrote:
I really don't understand what we are looking to achieve with the new trust that IETF cannot ensure. Do you care to elaborate on why you think IETF is not sufficient as i havn't heard much of the whys and i believe you have more IETF history than myself so maybe there is more devil the details of IETF than i thought.
I have said it a few times. In various ways, but I guess not clearly. The IETF Trust is excellent and full of trustworthy people. I trust them completely to protect IETF interests. Their fiduciary responsibility is, in fact, to the IETF interests. In a crisis that could be problematic for the Names interests. (I equate it to my mother having trusted my father's lawyer in their divorce) Names should not accept such a situation. The lawyers have indicated that there is legal manipulation that could be done to protect Names' interest. Jari has indicated that they are looking at language. I assume it is that kind of language. So we can wait to see that language and get our lawyer's opinion on it. Or we start working on separate language. Or we go down both paths in parallel so as not to interfere with the schedule. I see no other alternative. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
At 10/08/2015 03:06 PM, Avri Doria wrote:
On 10-Aug-15 14:46, Seun Ojedeji wrote:
I really don't understand what we are looking to achieve with the new trust that IETF cannot ensure. Do you care to elaborate on why you think IETF is not sufficient as i havn't heard much of the whys and i believe you have more IETF history than myself so maybe there is more devil the details of IETF than i thought.
I have said it a few times. In various ways, but I guess not clearly.
The IETF Trust is excellent and full of trustworthy people. I trust them completely to protect IETF interests. Their fiduciary responsibility is, in fact, to the IETF interests. In a crisis that could be problematic for the Names interests. (I equate it to my mother having trusted my father's lawyer in their divorce) Names should not accept such a situation.
The lawyers have indicated that there is legal manipulation that could be done to protect Names' interest. Jari has indicated that they are looking at language. I assume it is that kind of language.
So we can wait to see that language and get our lawyer's opinion on it. Or we start working on separate language. Or we go down both paths in parallel so as not to interfere with the schedule. I see no other alternative.
avri
I don't care much which way we go, but we need an overall direction and game plan. Perhaps it can be done with legal language (ICANN transfers the assets to the IETF Trust on the condition that ICANN will continue to have uninterupted access to and use of the assets in relation to the Stewardship of the IANA Names function). Or perhaps we need a new trust. Either way I think we need to get past theoretical options and move to the implementation of a real one. Alan (with more than a little frustration)
I think Martin points out a significant concern with the IETF Trust plan: accountability (or rather the lack of it). Between the CWG and the CCWG, we have spent many months and thousands of collective hours working on methods for ICANN to be held accountable to the community and for the names community to provide oversight on ICANN's carrying out the IANA Functions. I don't think we have spent more than a few minutes considering how we would exercise oversight over the IETF Trust or how we would hold the IETF Trust accountable to this community. We need to contemplate how this fits into our proposal. Can any of our suggested oversight and accountability mechanisms be used for oversight and accountability of the IETF Trust? How would they change? What new mechanisms might need to be created? If ICANN is the steward of the IANA functions, as we propose, how will it exercise that stewardship over IPR it no longer owns? We have not yet begun to answer those questions. It's entirely possible that being unable to say how we will exercise oversight and control over the IETF Trust could derail our proposal, given the significance of the IETF Trust becoming the IANA brand owner. As for the IETF Trust itself, this will require more fundamental changes than smoothing over some language. As it stands, the IETF Trust is an extension of the IETF. That's fine when the Trust's job is to hold IETF IP assets, but transferring ownership of the IANA trademarks/domain names would be a transformational change -- it would no longer be internal to the IETF. In essence, *if the IETF Trust becomes the owner of the IANA trademarks, the IETF Trust essentially becomes IANA*. The INTERNET ASSIGNED NUMBERS AUTHORITY would no longer be the IANA group at ICANN -- it would be the IETF Trust, licensing ICANN to carry out services under the IETF Trust's brand. As such, the source and origin of the services offered by IANA will be the IETF Trust. The licensee is just an instrumentality of the licensor -- just as if ICANN was making Mickey Mouse bath towels under a license from Disney. The IETF may be the source of protocols and standards that guide IANA's work and which are entered into a database maintained by IANA, but the IETF is not now the source or origin of the services themselves. That would all change as the IETF Trust becomes IANA. With that change, the IETF Trust would need to change considerably. Is this an insurmountable issue? No, but it will take serious changes in the IETF Trust to resolve. If the IETF Trust is going to become the owner of non-IETF assets, and particularly the IANA brand owner, that needs to be reflected in the structure and functioning of the Trust itself. It shouldn't solely be an "IETF trust" anymore. At a minimum, I believe the Trust would need to make changes to: - the Beneficiary of the Trust - the Purpose of the Trust - the Trustees of the Trust, including the eligibility - how the Trustees carry out their duties relating to the IPR held by the Trust (or at least, the IANA trademarks/domain names) - the ability of the Trustees to license, transfer and dispose of Trust Assets - the Trustees obligations and fiduciary duties - the use of Trust income and financial assets *Beneficiary: *Now, the sole beneficiary of the Trust is the IETF. That's appropriate now, while holding IETF IPR is the Trust's job. If it becomes the owner and proprietor of the IANA trademarks/domain names, the beneficiary would need to be changed or added to to reflect this broader scope. Perhaps the "Community Mechanism" contemplated by the CCWG would become a beneficiary; perhaps the NRO as well. Perhaps ICANN. *Trustees: *The Trustees run the the Trust. Right now, to be a trustee, one must be a member of the IETF Administrative Oversight Committee (IAOC). Indeed, it appears that most (if not all) members of the IAOC serve as Trustees (and vice versa). This further emphasizes how intertwined the IETF Trust is with the IETF. Again, perfectly acceptable when it's a trust for IETF assets being held in trust for the IETF. but not afterwards. The Trustees would need to be accountable beyond the IETF and the make-up and eligibility criteria would need to change to reflect the makeup of the broader community. We need control over the Trustees and Trust. *Actions of the Trustees: *The Trustees/IAOC have broad discretion to run the Trust (within certain parameters). They decide whether to grant licenses for the Trust Assets. They decide to take or not to take action with regard to unauthorized use, infringement or dilution of the Trust Assets. They decide how to protect the Trust Assets -- what registrations to file, what registrations to keep or let go. All things a trademark owner must do, and all sensible when the IPR is all core IETF IPR. For the IANA IPR, all of this is currently in the hands of ICANN with regard to the IANA trademarks/domain names. The names community would need to have various controls, oversight and accountability measures in place so that the Trustees acted in ways that the names community thought were necessary. Practically speaking, ICANN would need to have significant rights wi8th regard to to protecting and enforcing the IANA IPR. *Quality Control: T*he Trustees/IAOC would be in charge of exercising quality control over the services provided under the IANA marks. The Trustees would need to set quality standards for all IANA services and then exercise regular efforts to determine if those standards are met, including (typically) pre-approving any new service or substantial difference in the service or how it is conducted. If the Trustees thought that IANA wasn't meeting their standards or meeting other terms of their license agreement, the Trustees could decide that ICANN was in breach of its license agreement and demand that the breach be cured in a timely fashion. As for the remedy if the breach is not cured -- typically, the remedy is termination of the license agreement. *In other words, ICANN would be answerable to the IETF Trustees for all of its IANA services, not merely those relating to protocol parameters. and could lose the right to use the IANA trademarks and domain names for all services if the IETF Trustees decided that there was an uncured breach*. It should be noted that quality control can be delegated (but not to the licensee). In my experience, such delegation rarely if ever happens -- quality control is too important an obligation for a brand owner to delegate, since it goes to the heart of the licensor/licensee relationship. The delegation does not relieve the brand owner of the ultimate responsibility for quality control -- only the job of carrying out the inspections, approvals, sample review, etc., against the licensor's standards. It's unlikely that ICANN would be the appropriate "delegee" for such quality control, given the unity of interest between ICANN and PTI. I don't believe these are merely implementation details. If we have no oversight and control over the owner of the IANA brand, if we can't hold that brand owner accountable, we will have a serious problem. If the IETF Trust is not an appropriate IANA brand owner and steward of the IANA trademarks and domain names, we will have a serious problem. Greg On Mon, Aug 10, 2015 at 3:06 PM, Avri Doria <avri@acm.org> wrote:
On 10-Aug-15 14:46, Seun Ojedeji wrote:
I really don't understand what we are looking to achieve with the new trust that IETF cannot ensure. Do you care to elaborate on why you think IETF is not sufficient as i havn't heard much of the whys and i believe you have more IETF history than myself so maybe there is more devil the details of IETF than i thought.
I have said it a few times. In various ways, but I guess not clearly.
The IETF Trust is excellent and full of trustworthy people. I trust them completely to protect IETF interests. Their fiduciary responsibility is, in fact, to the IETF interests. In a crisis that could be problematic for the Names interests. (I equate it to my mother having trusted my father's lawyer in their divorce) Names should not accept such a situation.
The lawyers have indicated that there is legal manipulation that could be done to protect Names' interest. Jari has indicated that they are looking at language. I assume it is that kind of language.
So we can wait to see that language and get our lawyer's opinion on it. Or we start working on separate language. Or we go down both paths in parallel so as not to interfere with the schedule. I see no other alternative.
avri
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi Greg, In case it isn't clear below, I really don't know the answer to what I'm asking and I'm not trying to advance an argument by pretending to ask a question. I'm not a lawyer, as I've noted, but I've heard an interesting argument (hinted at by Milton more than once) and I'd like to understand your view of it. On Mon, Aug 10, 2015 at 07:45:52PM -0400, Greg Shatan wrote:
assets, but transferring ownership of the IANA trademarks/domain names would be a transformational change -- it would no longer be internal to the IETF. In essence, *if the IETF Trust becomes the owner of the IANA trademarks, the IETF Trust essentially becomes IANA*.
[…]
As such, the source and origin of the services offered by IANA will be the IETF Trust.
At the foundation of an IANA registry[1] is an RFC that either was subject to IETF consensus, or for which the IETF now has change control, or for which the IAB (now a committee of the IETF) is the source of authority. This includes the very idea of the DNS root zone and the very idea of the root of an IP allocation tree. Some of the RFCs in question predate the IETF, in some cases by many years. But I've never seen an argument that they're not now subject to IETF change control. This is different to the individual entries in any given registry. If that is true, then is it or is it not the case that the IETF is the "source and origin of the services" offered by IANA, and IANA is merely executing the function created by the IETF in the first place? If so, does that mean that the IETF Trust turns out to be an appropriate place for these marks and the associated iana.org domain name? If not, why not? To be clear, I don't think the argument I sketch above depends on the idea that the IETF maintains policy authority over all these areas. It clearly does not, and I'm confident in believing that it does not want such policy authority. I'm rather asking about the "source and origin of the services" claim, which I understand to be critical to the point you're making. Thanks and best regards, A (asking as usual only for myself) [1] all IANA registries? I'm unable to come up with a clear counter-example at the moment, but I won't swear there are none; the IDN practices registry might be a counter-example, but I'm not sure. It's in any case an awkward case. RFC 1591 is another difficult case; it's never been updated, and it was in my opinion an IANA statement of policy outside IETF control, so the int. registry might be another case. -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, The meaning of "source or origin" in trademark law is considerably different than the meaning used in your email below. In the trademark context, the "source or origin" referred to is the source of the goods or services currently being offered to a customer, not the source of the idea for that service. It is a "present day" analysis: if I am buying these goods or services today, the trademark identifies a single source that is providing me the service or manufactured the product that I am now buying. Originally, this was construed so narrowly that trademark licensing was prohibited. Over time, by obligating a trademark owner to actively engage in quality control over the goods and services (and to reflect that in a contract), trademark licensing was allowed. The trademark licensee is not viewed as the "source or origin" of the product or service -- the trademark owner (i.e., the licensor) continues to be the "source or origin," even though they are not physically manufacturing the product or providing the service. The "goodwill" (or reputation) that comes from making a good product or offering a good service accrues to the benefit of the trademark owner, not the licensee. "Source or origin" has nothing to do with "genesis" or historical foundation; for trademark "source" purposes, it doesn't matte where the idea for something comes from or where the function was first created, or even where "standards" (in the sense of parameters set by a standards-setting organization) are set. All kinds of goods and services must conform to external standards, whether set by governments or by non-governmental standards-setting bodies (e.g., the ISO). And of course, those standards-setting bodies do amend standards from time to time. So, when looking at the question of "source," the questions to be asked in the IANA context by someone receiving a service from the IANA group at ICANN are the following: "Do I believe that the responsibility for the execution of the service I am receiving today lies with ICANN or with some other source? Do I believe that how well (or how poorly) that service is being provided (e.g., how timely, how accurate, how professionally) is the responsibility of ICANN or of some other entity?" I believe that the answer in both cases is "ICANN." That does not denigrate the role of the IETF in any way. Nor does it mean that ICANN cannot move from being the "source" of the services to being a licensee, by transferring the IANA marks to a third party and entering into a trademark license. However, that would mean that this third party would need to exercise active and ongoing "quality control" over the services being delivered by ICANN (and potentially, some other IANA service provider); that is not something that the IETF (or the IETF Trust) does today. Another important point: It's not necessary to argue that the IETF was always somehow the "source and origin" for IANA services in order to propose the IETF Trust as a potential home for the IANA brand. That would also be a "present day" analysis. However, the argument that the IETF has always been and continues to be the "source" of IANA services for trademark purposes does have several unintended consequences. First, the IETF has never entered into a license for ICANN (or its predecessor as the IANA service provider) to use IANA or Internet Assigned Numbers Authority as a trademark. The IETF has never exercised "quality control" in the trademark sense over ICANN or its predecessor (or if it did, it stopped a very long time ago). The IETF has never challenged the trademark registrations owned by ICANN or its predecessor. All of these things would lead to a finding that the IETF had abandoned the trademark and that whatever claim it once had to the trademark is extinguished. Conversely, if the IETF was the rightful owner of the IANA trademarks at the time that the current registrations (or the earlier registrations assigned to ICANN by its predecessor) were applied for, then ICANN and its predecessor committed "fraud on the trademark office," since the applicants claimed (as required by law) that they were the rightful owners of the marks and that they know of no other party that could make a claim to own the marks in connection with the relevant services. The end result of "fraud on the trademark office" is that the current registrations would be void and subject to cancellation by the trademark office. Ironically, ICANN could then reapply to register the marks now without "fraud on the trademark office" so long as it established that the IETF had abandoned the mark. (Alternatively, if ICANN established that the IETF was never the rightful owner of the marks, the current registrations would not be void.) There's no reason to subject the IANA trademarks to these risks -- and frankly, there's no basis to do so either. Hope that helps. Greg On Mon, Aug 10, 2015 at 11:51 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi Greg,
In case it isn't clear below, I really don't know the answer to what I'm asking and I'm not trying to advance an argument by pretending to ask a question. I'm not a lawyer, as I've noted, but I've heard an interesting argument (hinted at by Milton more than once) and I'd like to understand your view of it.
On Mon, Aug 10, 2015 at 07:45:52PM -0400, Greg Shatan wrote:
assets, but transferring ownership of the IANA trademarks/domain names would be a transformational change -- it would no longer be internal to the IETF. In essence, *if the IETF Trust becomes the owner of the IANA trademarks, the IETF Trust essentially becomes IANA*.
[…]
As such, the source and origin of the services offered by IANA will be the IETF Trust.
At the foundation of an IANA registry[1] is an RFC that either was subject to IETF consensus, or for which the IETF now has change control, or for which the IAB (now a committee of the IETF) is the source of authority. This includes the very idea of the DNS root zone and the very idea of the root of an IP allocation tree. Some of the RFCs in question predate the IETF, in some cases by many years. But I've never seen an argument that they're not now subject to IETF change control. This is different to the individual entries in any given registry.
If that is true, then is it or is it not the case that the IETF is the "source and origin of the services" offered by IANA, and IANA is merely executing the function created by the IETF in the first place? If so, does that mean that the IETF Trust turns out to be an appropriate place for these marks and the associated iana.org domain name? If not, why not?
To be clear, I don't think the argument I sketch above depends on the idea that the IETF maintains policy authority over all these areas. It clearly does not, and I'm confident in believing that it does not want such policy authority. I'm rather asking about the "source and origin of the services" claim, which I understand to be critical to the point you're making.
Thanks and best regards,
A (asking as usual only for myself)
[1] all IANA registries? I'm unable to come up with a clear counter-example at the moment, but I won't swear there are none; the IDN practices registry might be a counter-example, but I'm not sure. It's in any case an awkward case. RFC 1591 is another difficult case; it's never been updated, and it was in my opinion an IANA statement of policy outside IETF control, so the int. registry might be another case.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-----Original Message-----
The IETF Trust is excellent and full of trustworthy people. I trust them completely to protect IETF interests. Their fiduciary responsibility is, in fact, to the IETF interests. In a crisis that could be problematic for the Names interests.
IANA is a resource that pertains to all IETF protocols, not just domain names (DNS). Thus it is appropriate for a trust rooted in the IETF to control its identity. I would like to know more from Avri about how "names interests" (as if the names community had a unified set of 'interests' rather than being a collection of warring interests) might conflict with IETF interests. The worst scenario one can imagine is that for some unknown reason IETF would refuse to allow the names community's desired IFO to use the trademarks. This seems easily remedied. Put into the transition plan a simple commitment that IETF Trust would recognize the recommendations of an IANA Functions Review. After all, AT BEST those who favor ICANN as the TM holder can propose that ICANN should make the same kind of commitment. The difference, of course, is that ICANN has a huge conflict of interest in any attempt to transfer the domain and marks, and the IETF doesn't. I find the accountability concerns expressed here about IETF to be odd, kind of like the psychological malady known as projection, where one attributes one's own flaws and problems onto some innocent victim and blames them for it. I am pretty familiar with the quirks and clubbiness that sometimes characterizes IETF hierarchy, but the IETF isn't in the business of making money off IANA or DNS, unlike certain other participants in this process, and it doesn't have a long history of accountability problems and abuses, as ICANN does. It can't compel anyone to use its standards, it doesn't issue contracts of adhesion as ICANN does, it doesn't tax its users and generate tens of millions of dollars or dabble in geopolitics. It main interest seems to be in making things work. The choice between the two seems pretty straightforward to me, especially given ICANN's rooting in the names community only.
On 11 Aug 2015 02:06, "Mueller, Milton L" < milton.mueller@pubpolicy.gatech.edu> wrote:
-----Original Message-----
The IETF Trust is excellent and full of trustworthy people. I trust them completely to protect IETF interests. Their fiduciary responsibility is, in fact, to the IETF interests. In a crisis that could be problematic for the Names interests.
IANA is a resource that pertains to all IETF protocols, not just domain
names (DNS). Thus it is appropriate for a trust rooted in the IETF to control its identity.
I would like to know more from Avri about how "names interests" (as if
the names community had a unified set of 'interests' rather than being a collection of warring interests) might conflict with IETF interests. The worst scenario one can imagine is that for some unknown reason IETF would refuse to allow the names community's desired IFO to use the trademarks. This seems easily remedied. Put into the transition plan a simple commitment that IETF Trust would recognize the recommendations of an IANA Functions Review. After all, AT BEST those who favor ICANN as the TM holder can propose that ICANN should make the same kind of commitment. The difference, of course, is that ICANN has a huge conflict of interest in any attempt to transfer the domain and marks, and the IETF doesn't.
SO: While I agree this is indeed all it will require to ensure IETF complies, I don't necessarily agree that such compliance responsibility would be different if it were with ICANN. Otherwise I would have said ICANN will have even been a better option considering that it will become a member organization and the collective operational community can ensure it complies with its TM obligations. Nevertheless I guess it doesn't really matter convincing that ICANN should retain the TM as it seem those who don't want IETF seem not to want ICANN as well. So it seem i am alone on this one, which is fine. That said, I think it will be quite disappointing if IETF agrees to setting up an independent trust based on reasons shared by Avri as I think it undermines the role of the IETF. I think because we have made this a 3 operational community thing makes us see IETF as just one of those communities, IMO they are more than that. I would even think they should have been the custodian of the TM long time ago (even before ICANN) but I guess their approach of "if it ain't broke don't fix it may have gotten us to this state" Maybe we need to remind ourselves about the basic fact that the IETF defined the number identifier (IP and AS) and also the names identifier. How then can we expect the creator not to allow access to the TM for use by its creation. Seem to me we may be looking for something more than just access to the TM. If there is really a part of this transition that the doesn't need any politicizing, I think the TM should such item. Come to think of it, IETF even uses the TM far more than the other 2 operational communities, so they seem to even have more stake in this.
I find the accountability concerns expressed here about IETF to be odd, kind of like the psychological malady known as projection, where one attributes one's own flaws and problems onto some innocent victim and blames them for it. I am pretty familiar with the quirks and clubbiness that sometimes characterizes IETF hierarchy, but the IETF isn't in the business of making money off IANA or DNS, unlike certain other participants in this process, and it doesn't have a long history of accountability problems and abuses, as ICANN does. It can't compel anyone to use its standards, it doesn't issue contracts of adhesion as ICANN does, it doesn't tax its users and generate tens of millions of dollars or dabble in geopolitics. It main interest seems to be in making things work.
SO: +1 on this
The choice between the two seems pretty straightforward to me, especially given ICANN's rooting in the names community only.
We can argue about this but I guess it doesn't matter at this time ;) Regards _______________________________________________
CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 11 August 2015 at 09:29, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Maybe we need to remind ourselves about the basic fact that the IETF defined the number identifier (IP and AS) and also the names identifier. How then can we expect the creator not to allow access to the TM for use by its creation.
Seem to me we may be looking for something more than just access to the TM. If there is really a part of this transition that the doesn't need any politicizing, I think the TM should such item. Come to think of it, IETF even uses the TM far more than the other 2 operational communities, so they seem to even have more stake in this.
Thank you Seun, That has been my thinking all alone. Nearly all identifiers and protocols enjoyed by the names and numbering community originated from IETF. Including the IANA name, domains, Internet Protocol addresses, e.t.c. On the other hand, the business community was able to monetize the said identifiers. I don't see why there should a mistrust on the IETF whatsoever. Actually, if IETF decided to change the said identifiers and rename all their use of the IPRs to something else, they would do it. And the names and numbers may need to follow through for compatibility purposes in-case new innovations come through. And new innovations is actually the domain of the IETF. My views alone. Regards ______________________ Mwendwa Kivuva, Nairobi, Kenya "There are some men who lift the age they inhabit, till all men walk on higher ground in that lifetime." - Maxwell Anderson
Sure Greg, I have not seen any objection from any community should they be required to modify any section of their proposal. But on the contrary, there is no operational community that has seen the need to modify its proposals so far On Aug 10, 2015 11:04 AM, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
And shouldn't the names community have that opportunity now?
In any event, that doesn't mean an entire proposal would be sent back for re-approval.
On Monday, August 10, 2015, Mwendwa Kivuva <Kivuva@transworldafrica.com> wrote:
On 10 August 2015 at 09:46, Greg Shatan <gregshatanipc@gmail.com> wrote:
I also don't think it's accurate to state that failing to embrace the CRISP proposal will result in "any of our three community proposals having to go back to the community process and seek for re-approval." There's no indication that needs to happen, and stating that it will tends to look like an attempt to shove the CWG into accepting the CRISP proposal by proposing that some awful thing will happen if we don't. That may not have been the intent, but it certainly could be the effect.
Certainly, if the numbering community are asked to adopt another stance than that in their proposal, the community has to be given a chance to debate and ratify. That is part of the principles NTIA expects us to follow: Support and enhance the multistakeholder model; and Meet the needs and expectations of the global customers and partners of the IANA services.
My views alone.
Regards ______________________ Mwendwa Kivuva, Nairobi, Kenya
"There are some men who lift the age they inhabit, till all men walk on higher ground in that lifetime." - Maxwell Anderson
For what it's worth, I can live with either ICANN holding the rights in its role of steward for the names community - but can see why that might not be appropriate for numbers and protocols - or for a separate trust to take on this role for all communities. It should *not* be with the operator (PTI or successor) except on a right to use. Like others I think setting up a new trust to manage this role sounds like yet another layer of bureaucracy and I fail to see how it would add any value - it certainly could add risk (the creation of a new entity and new layers always does). I realise that it is implementation, but whoever carries out the role there needs to be a clear accountability of that organisation to names, numbering and protocol-parameter communities that the use of these resources will be granted to the organisation(s) carrying out the role of the IANA functions operator(s). ICANN does this currently: would it need some form of bylaw change to ensure that it does have to grant rights to the operator(s) or its successor(s), if it were to continue in this role? IETF could do this in the future, but again needs to show some framework for accountability to the operational communities. As Jari says, this is an implementation issue, but one which we need to nail down in time for the proposal to go forward. Martin -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jari Arkko Sent: 10 August 2015 04:27 To: Mueller, Milton L Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] [client com] IPR Memo
Would it not be better for the CWG-Stewardship to just go neutral on this matter (like the IETF) and let the CRISP team's view prevail because I don't understand the essence of a cross-operational community group when one of the group currently have no specific direction/view on the subject of discussion.
For what it is worth, I agree with Milton *. We've been in neutral mode at the IETF since last year, for various reasons. As noted, we've expressed our willingness to step up and have the IETF Trust provide a home if needed. Would be happy to do so **. Or we could participate in other solutions. But lets avoid any of our three community proposals having to go back to the community process and seek for re-approval. I think that would be silly. Jari *) And didn't that already happen? It was clearly stated at ICANN53 that the CWG proposal was silent on this topic. I think the rest is implementation, and we should accommodate the whole proposal as specified. **) Also, I can say from the IETF perspective that we are working on providing some suggested implementation approach(es) that satisfies the numbers community's requirements and will communicate to CWG and CRISP when we have something written up. The details matter and it will take time, but we are considering this as an implementation issue, not something that should fundamentally change the transition proposal.
participants (12)
-
Alan Greenberg -
Alissa Cooper -
Andrew Sullivan -
Avri Doria -
David Conrad -
Gomes, Chuck -
Greg Shatan -
Jari Arkko -
Martin Boyle -
Mueller, Milton L -
Mwendwa Kivuva -
Seun Ojedeji