[Gnso-newgtld-wg-wt4] Work Track 4 agenda for 4 May 2017

Rubens Kuhl rubensk at nic.br
Mon May 15 10:39:35 UTC 2017

> On May 10, 2017, at 4:17 AM, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:
> Thanks Rubens.
> Not sure I get the logic of this in relation to applicants asking the Board to change the policy set up in the Framework.  Bears further discussion I think.

While I would say that fits more into implementation than policy, at that time that division was a hard line in the sand where the community only had a say in policy but not implementation. Since then, both staff and community recognised they are more intertwined, so we don't have that problem from now on. We can work more on principles for the road down the WG initial report, but whoever is interested still have a say when an IRT is convened. 

> https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf>     (See Paragraph 5)
> In connection with the next call (or rather the one after that given that Patrik will be presenting in our next call), I really think our WT needs to focus on the existing Name Collision Occurrence Framework paragraph by paragraph.
> The Framework was not developed within a GNSO policy process, but it IS the existing policy until it is replaced by something.

And since it focused on getting the 2012 round moving forward, they didn't focus on coming with more basal definitions. So let me suggest some of that considering what was observed in the 2012 round, even if not (yet) implemented no higher risk strings.

1) Some strings will have unbearable risks and should be kept off the root zone. We could call them "High Risk" as both Interisle and JAS advisors did. 
2) Some strings will have higher risks and require different mitigation frameworks. We could call them "Aggravated Risk". They could be delegated, but the contracts would require strict adherence to the specific framework. 
3) The other strings will have low risk and use the plain "vanilla" mitigation framework. We could call them "Low Risk" just as Interisle and JAS did. 

So if we would apply that to the 2012 round, one possible output would have been:
- .home and .corp classified as high risk. Applications are terminated. 
- .mail classified as aggravated risk. An specific framework is defined as forbidding dotless mail altogether, and instead of the internal collision response, an actual mail server responder is developed that gives error messages like "Please fix your mail infrastructure, it's trying to deliver mail to  an outside network", running for 6 months. 

Does the WT believe this classification (3 levels) and mitigations (block, custom, vanilla) would be enough for subsequent procedures ? 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170515/0d408524/attachment.html>

More information about the Gnso-newgtld-wg-wt4 mailing list