- Bc-gnso - lists.icann.org

ICANN chair reins in new gTLD timeline hopes
by Steve DelBianco May 24, 2021

May 24, 2021

See this article today, regarding the next round ICANN chair reins in new gTLD timeline hopes<http://domainincite.com/26726-icann-chair-reins-in-new-gtld-timeline-hopes>

1 0

BC comment on GNSO Review of All RPMs in All gTLDs PDP Phase 1 Final Recommendations for Board Consideration
by Steve DelBianco May 21, 2021

May 21, 2021

Attached is the Business Constituency (BC) comment on GNSO Review of All Rights Protection Mechanisms in All gTLDs PDP Phase 1 Final Recommendations for ICANN Board Consideration This comment was drafted by Andy Abrams, with edits from Mason Cole, Zak Muscovitch, and David Snead. It was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

ICANN Business Constituency (BC) comment on .us TLD privacy plan
by Steve DelBianco April 6, 2021

April 6, 2021

Please accept this comment from the CANN Business Constituency (BC), regarding the comment opportunity on the .us TLD privacy plan<https://www.about.us/policies/ustld-stakeholder-council/ustld-privacy-recom…>. The BC appreciates the details shared by the Stakeholder Council on its plan to allow .US domain name registrants to use a registry-level privacy service. We believe the importance of this proposed policy and its potential impact on BC members and Internet users justifies calling out the following 3 high level concerns. First, As you know the ICANN community has been busy setting several policies related to WHOIS data, including the Privacy/Proxy Service Accreditation Issues (PPSAI) Policy and the various policies related to bringing the ICANN WHOIS system in line with the EU’s GDPR (a.k.a the Phase 1 and Phase 2 EPDP). As such we feel the .US Based Registry Privacy Service Plan<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.about.us_assets_us…>, which we note was drafted in September 2016, should be updated and be informed by both the PPSAI and EPDP policies. For example, we note that the proposed Whois output column in Appendix A goes far beyond what is even specified in the EPDP Phase 1 report. At a minimum the full contact details of the .US privacy service should be published / displayed. Second, given the importance the role contactability of the registrant behind the privacy services plays in mitigating abuse, we would like to see standardization of the email address published in the Whois response and suggest an email address similar to the following would be helpful: <.us domain name>@privateregistration.us<https://urldefense.proofpoint.com/v2/url?u=http-3A__privateregistration.us&…> (e.g. example.us(a)privateregistration.us<mailto:example.us@privateregistration.us>) Third, detail on how both private 3rd parties and law enforcement agencies request access to registrant data from the privacy service is inadequate. Any privacy service policy must detail, at a minimum, how requests can be made, what information is required and the timeline requestors should expect for a response. In addition, our initial read of the .US Registry Based Privacy Service Plan seemed to be focused solely on the release of information to Law Enforcement Agencies (LEA). Upon closer reading we do note that private parties and LEA are included, so we urge the council to update the language to ensure clarity in this regard. In conclusion, given the issues touched upon above, it is our view that more work is required before this policy is implemented for .US registrants. Sincerely, Steve DelBianco Vice chair for policy coordination ICANN Business Constituency (BC)

1 0

Business Constituency (BC) comment for Board consideration of EPDP Phase 2 Policy Recommendations
by Steve DelBianco March 30, 2021

March 30, 2021

Attached and below is the Business Constituency (BC) comment for Board consideration of EPDP Phase 2 Policy Recommendations. Members of the ICANN Board of Directors: The BC maintains its position that the EPDP Phase 2 Final Report fails to deliver a System for Standardized Access (SSAD) that meets the needs of its users. (see Minority Statement of the Business Constituency and the Intellectual Property Constituency on the EPDP Phase 2 Final Report<https://www.bizconst.org/assets/docs/positions-statements/2020/2020_07July_…>) On a substantive level, the SSAD proposed by the Final Report lacks a centralized disclosure mechanism and provides no meaningful framework regarding when disclosure should occur, leaving this determination up to the discretion of over two thousand separate contracted parties. It also fails to provide guidance to contracted parties as to how to address data accuracy and distinctions between legal and natural persons. The SSAD is also inflexible, lacking the ability to evolve with updates in data privacy laws, including pending legislation that may have a significant impact on obligations to disclose registrant data. On a procedural level, the SSAD proposed by the Final Report lacks the support of its intended users, lacks consensus among EPDP members and the ICANN community at large, and ultimately fails to serve the public interest by failing to support the security and stability of the Internet. Together with the views held by the Intellectual Property Constituency, Government Advisory Committee, the At-Large Advisory Committee, and the Security and Stability Advisory Committee, we have collectively noted that the EPDP work to date falls dramatically short of ICANN’s goal and that the Board must intervene in order realign the system for standardized access with the interests of the community and the public. To be clear, the Board must not hide behind majority approval within the GNSO Council as a proxy for community consensus given the strong opposition to the SSAD amongst its intended users within the EPDP. Nor should the Board use the GNSO Council’s vote as an excuse to move forward in dereliction of ICANN’s core value of protecting the global public interest. The inability of Internet users to identify with whom they are doing business with online, and the increasingly pervasive inability of law enforcement, cybersecurity, and legal professionals to identify criminal actors online through their domain name registration data, severely undermines the security and stability of the Internet. This comment is not made lightly and is not offered to the Board as hyperbole; if the Board approves the SSAD in its current form, then BC members will not use it and will recommend that other commercial entities also not use it. Furthermore, a decision by the Board to move forward in spite of all of the stated community opposition to the SSAD will serve as a strong signal to national regulators that more concerted intervention and direct regulation through administrative, legislative and judicial means are all necessary within the domain name industry. Put another way, the EPDP’s experimentation in providing legitimate access to non-public registration data will be viewed as a failure of the multistakeholder model, and it will be taken entirely out of the community’s hands. The Board has repeatedly insisted that it has done all it can to drive consensus and the law is the law. Indeed, it is. But rather than preventing ICANN from acting on a system of standardized access, the law as written presently in the GDPR and as contemplated in NIS2 do not require that data protection must conflict with public safety and cybersecurity needs. The European Commission has clearly provided ICANN with a roadmap for striking a balance between these interests, stating: “ICANN and the community can develop a unified access model that applies to all registries and registrars and provides a stable, predictable, and workable method for accessing non-public gTLD registration data for users with a legitimate interest or other legal basis as provided for in the General Data Protection Regulation.” This is precisely the Business Constituency’s aim - to support privacy protection for personal data, and to strike a balance between the individual right of privacy and other legitimate interests. Yet, instead of engaging in the work to outline the parameters of these interests, the Phase 2 Final Report merely provides for a central location to submit requests. It is a mere ticketing service that does not provide any meaningful access or disclosure function; as such, the SSAD will almost certainly become a black hole. Expensive window dressing that no one actually uses. We view the Board’s inaction to date as an abdication of leadership. This letter is a last attempt to urge the Board to correct this misstep, and to fulfill its obligations to the community and the public interest. This can only be done by remanding the SSAD recommendations back to the EPDP for further work to properly define a model for access to registration data that ensures that disclosure is proportionate and limited to the legitimate interest of the requesting party. Anything less is nothing at all. -- This comment was drafted by John Berard and Andy Abrams, and was approved in accord with our charter. Steve DelBianco Vice chair for policy coordination ICANN Business Constituency

1 0

Business Constituency (BC) support for proposed amendment to IANA Naming Function Contract
by Steve DelBianco March 23, 2021

March 23, 2021

The ICANN Business Constituency (BC) supports the proposed amendment to the IANA Naming Function Contract<https://pti.icann.org/iana-naming-function-services-service-level-agreements>: Article VII, Section 7.1 (a): This statement, "The relevant policies under which the changes are made shall be noted within each monthly report," be removed from the contract as it is a legacy statement from the NTIA contract that is no longer required. Implementation of this requirement has long been recognized as being operationally impracticable ever since the time of the NTIA contract, and the IFRT is satisfied that its continued inclusion in the contract adds no value to the reports. This comment was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

Business Constituency (BC) comment on ICANN Draft FY22-26 Op & Fin Plan and Draft FY22 Op Plan & Budget
by Steve DelBianco Feb. 16, 2021

Feb. 16, 2021

Attached is the Business Constituency (BC) comment on ICANN Draft FY22-26 Operating & Financial Plan and Draft FY22 Operating Plan & Budget. This comment was drafted by Tim Smith and Lawrence Olawale-Roberts, with edits by Jimson Olufuye, Tola Sogbesan, and Kileo Yusuph. It was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

ICANN Business Constituency comment on DoH and TRR
by Steve DelBianco Jan. 20, 2021

Jan. 20, 2021

Below and attached please find: ICANN Business Constituency response to Mozilla DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) Comment Period The Internet Corporation for Assigned Names and Numbers (ICANN) Business Constituency<http://bizconst.org/> (BC) is a chartered community in ICANN’s Generic Names Supporting Organization (GNSO), representing business of every size from all geographic regions. The BC’s mission is to advance policies for the DNS which develop an Internet that: * promotes end-user confidence because it is a safe place to conduct business * is competitive in the supply of registry and registrar and related services * is technically stable, secure and reliable. It is our pleasure to contribute to this public consultation being carried out by Mozilla<https://blog.mozilla.org/netpolicy/2020/11/18/doh-comment-period-2020/>, and we commend the organization’s efforts to advance conversations on this important subject. The ICANN community has for over two decades focused on developing policies for the DNS through a bottom-up, consensus-based processes, making use of the multistakeholder model to achieve balance between different points of view and arrive at satisfactory compromises. We recognize the value in innovation and developing new technologies such as DNS over HTTPS (DoH), which have the potential to increase the privacy of DNS queries. On the other hand, we also find some of its aspects concerning, particularly in relation to maintaining the legitimacy of the development of consensus-based policies within technical and multistakeholder bodies such as ICANN. It is possible that a lack of awareness of the consensus policies established within these bodies could result in them being overridden. We are in agreement with our colleagues from the ICANN At-Large Advisory Committee (ALAC), who wrote<https://www.icann.org/en/system/files/correspondence/hilyard-to-conrad-03de…>, “It is clear that DoH could have a direct impact on the DNS and Root Server System that ICANN is supporting”. In Mozilla’s “Security/DOH-resolver-policy<https://wiki.mozilla.org/Security/DOH-resolver-policy>”, under “Blocking & Modification Prohibitions”, we acknowledge that it is stated that “The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates.” However, this does not fully contemplate the scope of the decisions related to names and numbers that are painstakingly arrived at by the ICANN community. We also, for example, watch over the addition and removal of entries to the root zone, which should remain the forte of the global Internet community through ICANN’s consensus driven multi-stakeholder process. These cases also need to be considered in order for TRRs to be in alignment with the norms set by ICANN. It is our main intent with this comment to highlight the importance of compliance with the multistakeholder decisions arrived at by the ICANN community, so that we are able to maintain a single, interoperable Internet. We invite any interested representatives from Mozilla and the parties responsible for the Trusted Recursive Resolver (TRR) to engage with the ICANN Business Constituency to exchange ideas. An eventual implementation of DoH as an opt-out feature in all browser installations will clash with the corporate networks of a number of companies around the world, becoming a burden on enterprise users that operate using their own policies. Measures to facilitate the overriding of this setting at a large scale need to be put in place in order to avoid the generation of this problem. It is also of note to a number of our members that these technologies could significantly impact the ability of ISPs to comply with legal and regulatory obligations from their regional governments, be they related to activity logging, intellectual property protection, parental controls, cybersecurity, or any such purpose. This is a subject that needs to be clarified moving forward, to avoid unintended consequences such as the forcible circumvention or attempts at blocking DoH by State actors. Given all of the above, we invite Mozilla to consider the importance of creating mechanisms to ensure that trusted DoH (or similar) providers are not deviating from the consensus of the global community and preserve an obligation to adhere to these policies. Thank you for the opportunity to comment on this issue. Sincerely, The ICANN Business Constituency (BC) Mark Datysgeld, GNSO Councilor Alex Deacon, BC member Mark Svancarek, BC member Steve DelBianco, Vice Chair for BC Policy Coordination 18 January 2021

1 0

Business Constituency (BC) comment on Recommendations for ICANN’s Root Name Service Strategy and Implementation
by Steve DelBianco Dec. 8, 2020

Dec. 8, 2020

Below and attached is the comment of ICANN’s Business Constituency (BC) regarding Recommendations for ICANN’s Root Name Service Strategy and Implementation. The BC commends ICANN’s Office of the Chief Technology Officer (OCTO) on studies generated so far, and supports the continuation of these research projects, preferably published in all UN languages. The recommendations came at a time when more users and businesses are depending upon the Internet to conduct their activities, significantly increasing the load on the existing Root Server System (RSS) infrastructure. Placing Root Server Instances in diverse locations is a great strategy to handle increasing load and provide more resilience in areas where Internet adoption is growing – mostly via mobile. We recognize that the so-called Internet of Things (IoT) is still in its infancy, and we are yet to envision what the consequences of its deployment will truly look like once 5G networks and compatible devices are installed in a significant way. However, we observe their potential destructive power against the DNS in the hands of rogue actors, and this paints a troubling picture. ICANN Org should have presence in associations and groups related to IoT device manufacture to advance security by design, ensuring the DNS’ continued protection. To keep pace with the evolving threat landscape, we favor overprovisioning and erring on the side of caution, instead of potentially exposing businesses who are members of the BC to disruptions that could result in significant losses and security risks. The BC will publicly support expenditures made in this direction. ICANN Org should support with funds and capability the placement of ICANN Managed Root Server (IMRS) single instances in geographic areas where it is required but not feasible due to financial and/or knowledge restrictions. This will help build capability in these areas leading to innovation and more support for the RSS infrastructure. We support additional research into monitoring and how it would be performed, but request that a stream in the research should focus on the cost associated with the development, deployment and maintenance of these monitoring systems and the relative benefit to the operations of the RSS infrastructure in the long run. The BC agrees with the strategy of encouraging hyperlocal deployment, and recommends that ICANN Org makes full use of its community’s resources in sourcing local partners, such as ISPs, considering that they are working day-to-day with these actors. It would be a desirable gesture for ICANN Org to directly seek this kind of input, fostering stronger cooperation between both sides. The work of the regional managers should also be galvanized as the pandemic starts to wane. We further recommend a higher level of promotion, publicity and collaboration for the deployment of DNSSEC to tackle the integrity exposure of Root zone data. We would also like to see OCTO further pursue studies on the potential of IMRS Cloud, for us to fully grasp how implementation of these solutions could further ensure the Internet is technically stable, secure and reliable. We signal this a priority in terms of upcoming research. We would also like to better understand what are the opportunities to streamline the ICANN root zone encryption system with new technologies. -- This comment was drafted by Mark Datysgeld, Jimson Olufuye, and Vivek Goyal. It was approved in accord with our Charter. Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

Business Constituency (BC) comment on IANA Naming Function Review (IFR) Initial Report
by Steve DelBianco Dec. 2, 2020

Dec. 2, 2020

Attached is the comment of ICANN’s Business Constituency (BC) on the IANA Naming Function Review (IFR) Initial Report. This comment was authored by Jimson Olufuye. It was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0

BC Comment on DRAFT PTI and IANA FY22 Operating Plan and Budgets
by Steve DelBianco Nov. 30, 2020

Nov. 30, 2020

Attached is the comment of ICANN’s Business Constituency (BC) on the DRAFT PTI and IANA FY22 Operating Plan and Budgets. This comment was authored by Jimson Olufuye, with edits from Lawrence Olawale-Roberts and Tim Smith. It was approved in accord with our charter. -- Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency (BC)

1 0