Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
Hi All. For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to. Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise. The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “ Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.” Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices. What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of. Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion. Best, Rubens
Rubens, If we had a Registry Services Provider pre-approval process, how would that process interact with the policy you have stated below? Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com or jeff.neuman@comlaude.com T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw -----Original Message----- From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2016 8:32 PM To: gnso-newgtld-wg-wt4@icann.org Subject: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing Hi All. For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to. Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise. The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “ Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.” Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices. What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of. Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion. Best, Rubens _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4
Jeff, It would speed-up the process to reach both milestones of contract signing and TLD delegation, since the technical infrastructure won't have to be evaluated and delegation readiness will already be known. It will also allow applicants to choose a Registry Services Provider when they see fit; if they prefer selecting it before applying it would be their choice, if they prefer shopping for a provider after securing the TLD, they could too. It still keeps the freedom to use a completely new infrastructure and have it evaluated, a liberty that can be useful now that there is one open-source gTLD registry system available: http://domainincite.com/21147-google-could-shake-up-the-registry-market-with... <http://domainincite.com/21147-google-could-shake-up-the-registry-market-with...> . (Previously, CoCCA had sources available but was not license-free to gTLD registries, only to ccTLD registries). But anticipating something from the implementation phase, I think it will make sense to have technical evaluation charged as a separate cost item for applicants, in order to benefit most of the applicants with the cost reduction potential of the RSP program. But that's a definition not in the table for now, just a side note for us to get back within the IRT for this policy. Rubens
On Dec 16, 2016, at 7:25 AM, Jeff Neuman <jeff.neuman@comlaude.com> wrote:
Rubens,
If we had a Registry Services Provider pre-approval process, how would that process interact with the policy you have stated below?
Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com or jeff.neuman@comlaude.com T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw
-----Original Message----- From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2016 8:32 PM To: gnso-newgtld-wg-wt4@icann.org Subject: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
Hi All.
For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to.
Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise.
The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “
Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.”
Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices.
What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of.
Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle
For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion.
Best, Rubens
_______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4
The other question I have on the language is on the interaction with contention resolution (assuming there is one or more application windows or rounds). With your change, in theory we could have a situation where a prevailing registry in contention resolution may not pass a technical evaluation. Should there be a time limit on demonstrating its capabilities? If it is unable to demonstrate that, what do you do? Can get kind of messy? Should we state that in the case of contention resolution it needs to be prior to the completion of such contention resolution? Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Friday, December 16, 2016 10:47 AM To: Jeff Neuman <jeff.neuman@comlaude.com> Cc: gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing Jeff, It would speed-up the process to reach both milestones of contract signing and TLD delegation, since the technical infrastructure won't have to be evaluated and delegation readiness will already be known. It will also allow applicants to choose a Registry Services Provider when they see fit; if they prefer selecting it before applying it would be their choice, if they prefer shopping for a provider after securing the TLD, they could too. It still keeps the freedom to use a completely new infrastructure and have it evaluated, a liberty that can be useful now that there is one open-source gTLD registry system available: http://domainincite.com/21147-google-could-shake-up-the-registry-market-with... . (Previously, CoCCA had sources available but was not license-free to gTLD registries, only to ccTLD registries). But anticipating something from the implementation phase, I think it will make sense to have technical evaluation charged as a separate cost item for applicants, in order to benefit most of the applicants with the cost reduction potential of the RSP program. But that's a definition not in the table for now, just a side note for us to get back within the IRT for this policy. Rubens On Dec 16, 2016, at 7:25 AM, Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: Rubens, If we had a Registry Services Provider pre-approval process, how would that process interact with the policy you have stated below? Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw -----Original Message----- From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2016 8:32 PM To: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing Hi All. For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to. Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise. The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “ Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.” Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices. What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of. Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion. Best, Rubens _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org<mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4
On Dec 16, 2016, at 9:23 AM, Jeff Neuman <jeff.neuman@comlaude.com> wrote:
The other question I have on the language is on the interaction with contention resolution (assuming there is one or more application windows or rounds). With your change, in theory we could have a situation where a prevailing registry in contention resolution may not pass a technical evaluation. Should there be a time limit on demonstrating its capabilities? <> It's already specified by ICANN that there is a time limit between being approved and signing a contract. It would fall within that time limit to either secure an approved RSP or get technical evaluation approval, or request an extension to ICANN to get such approval.
If it is unable to demonstrate that, what do you do? Can get kind of messy? <> That's why there was also a question in Hyderabad, reflected in the slides, of what should happen in the case, but people seemed not interested in discussing it. We also have some similar situations right now like applicants not passing background screening, failing to pay the auction bid or simply failing to send the signed agreement to ICANN.
I prefer thinking what happens even in corner cases such as this, but in this case the existing mechanism of allowing some time to sign and possibly grant an extension to that seems enough to handle it.
Should we state that in the case of contention resolution it needs to be prior to the completion of such contention resolution? <>
. The feedback in Hyderabad was the opposite of that: that only after contention resolution should the quest for technical capability begin, because it was only at that point that the applicant would be sure of having secured the TLD. Otherwise, many applicants have to secure contracts while only one will become a registry. That's exactly the issue this is trying to address. Rubens
Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com <mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw
From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Friday, December 16, 2016 10:47 AM To: Jeff Neuman <jeff.neuman@comlaude.com> Cc: gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
Jeff,
It would speed-up the process to reach both milestones of contract signing and TLD delegation, since the technical infrastructure won't have to be evaluated and delegation readiness will already be known. It will also allow applicants to choose a Registry Services Provider when they see fit; if they prefer selecting it before applying it would be their choice, if they prefer shopping for a provider after securing the TLD, they could too. It still keeps the freedom to use a completely new infrastructure and have it evaluated, a liberty that can be useful now that there is one open-source gTLD registry system available: http://domainincite.com/21147-google-could-shake-up-the-registry-market-with... <http://domainincite.com/21147-google-could-shake-up-the-registry-market-with...> .
(Previously, CoCCA had sources available but was not license-free to gTLD registries, only to ccTLD registries).
But anticipating something from the implementation phase, I think it will make sense to have technical evaluation charged as a separate cost item for applicants, in order to benefit most of the applicants with the cost reduction potential of the RSP program. But that's a definition not in the table for now, just a side note for us to get back within the IRT for this policy.
Rubens
On Dec 16, 2016, at 7:25 AM, Jeff Neuman <jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com>> wrote:
Rubens,
If we had a Registry Services Provider pre-approval process, how would that process interact with the policy you have stated below?
Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com <mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw
-----Original Message----- From: gnso-newgtld-wg-wt4-bounces@icann.org <mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org <mailto:gnso-newgtld-wg-wt4-bounces@icann.org>] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2016 8:32 PM To: gnso-newgtld-wg-wt4@icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> Subject: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
Hi All.
For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to.
Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise.
The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “
Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.”
Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices.
What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of.
Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle
For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion.
Best, Rubens
_______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org <mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4>
participants (2)
-
Jeff Neuman -
Rubens Kuhl