At-Large Beijing Meeting Reports Workspace

• Report on New gTLD SSR Update by SSAC Liaison
• The Audiocast of the Session can be found at http://beijing46.icann.org/node/37057

General Points

• IANA is ready to process delegations wef 1May.  
• Growth of traffic in the root zone is not really dependent on the no of TLDs. The change on the size of the root zone will not be as big as some previous changes (eg deployment of DNSSEC in 2010).
• L-root has been collecting some metrics (wef 3 Apr) so that long term trends can be observed i.e. they are establishing the baseline.

Discussion on SAC057 - Internal Name Certificates

Certificate Authorities (CAs)

• Not all CAs are members of the CA/Browser Forum and may not abide by Ballot 96. (See Supplementary Note)
• Even if they do, there will still exist a vulnerability window because of the 120 days (Ballot 96).
• We don't really know what certificates have been issued for these internal name servers.

Browser Vendors

• ICANN Security Team is working with Browser Vendors on this issue. Some browsers do not check for revocation of certificates.
• Part of Solution might be to use DANE and sign with DNSSEC.
• Options being considered by browser vendors to address this will only be applicable to latest versions and there will still be many older browser versions in use.

Other Applications

• Browsers are not the only applications used to connect to the internet. There are a number of other protocols that rely on Certificates. The traffic is not all web queries.
• Some applications don't support renovation checking at all, or a man-in-the-middle attack can stop the revocation from happening.
• One mitigation is to ask server manufacturers to turn on OCSP Stapling by default (On-Line Certificate Status Protocol).  This would ensure that revocation status would be checked.
• There may be other complex interactions between the DNS and other applications at the root level, cross application issues, which need to be explored.  SSAC has been asking for interdisciplinary studies on these issues and ICANN may need to act as coordinator/facilitator/collaborator on these.

Other Issues and Concerns

• Irrespective of the case where certificates already exist for yet to be released gTLDs, there is also a problem associated with internal network configurations which utilise these names with or without certificates at the second or third levels eg example.com where .example is an applied for new gTLD. Queries to these new gTLDs may be directed to these internal networks, causing problems for businesses, consumers and end users.  It was observed that ISPs will likely bear the brunt of complaints if this occurs and possibly  incur significants costs in customer support that is unrelated to their core services.

Letter from Paypal

• Letter identified their concern about 'significant security issues related to  delegating gTLDs that are currently in wide use as de facto private TLDs'. They state the top 10 of these represent 10% of the total query load at the root servers.  The top 13 invalid queries some of which are gTLD suffixes identified in RFC6762 are:
  
  • .invalid .wpad  .home  .belkin  .corp  .lan  .domain  .localdomain .localhost  .local  .intranet  .internal   .private
• This was highlighted in SAC045 - Invalid Top Level Domain Queries at the Root Level.  Recommendations were made in that report to mitigate this risk.

New Measurements

• SAC057 is based on data from August 2010. One member of the community has collected similar but not identical data since the release of SAC057. They examined only web queries in the .com and .net TLDs, looking for IPs that are pointed to by DNS names.  Although the results are not comparable, they found that there are some 25 million certificates associated with 51 applied for new gTLDs, the biggest being .corp with 102 unique sub-domains.
• The top 4 in order of size were:
  
  • .corp   .home   .offline   .inc
• Others that are also commonly found are:
  
  • .site   .mail   .bank  .ads  (active directory service)

Conclusion

There was a call to the community to identify any other issues and concerns which should be addressed in relation to new gTLDs.

Supplementary Note

Mozilla has a Network Security Services (NSS), a set of libraries designed to support cross-platform development of security-enabled client and server applications. This library provides a complete open-source implementation of the crypto libraries used by AOL, Red Hat, Sun, and other companies in a variety of products, including the following:

• The Mozilla client products, including Mozilla Suite, Firefox, and Thunderbird.
• The Netscape browsers
• AOL Communicator and AOL Instant Messenger (AIM)
• Open source client applications such as Evolution, Gaim, and OpenOffice.org 2.0.
• Server products from Red Hat: Red Hat Directory Server, Red Hat Certificate System, and the mod_nss SSL module for the Apache web server.
• Server products from the Sun Java Enterprise System, including Sun Java System Web Server, Sun Java System Directory Server, Sun Java System Portal Server, Sun Java System Messaging Server, and Sun Java System Application Server.

At the SSAC Public Meeting in Beijing (0800-0900 Thursday 11Apr12), it was revealed by a member of the CAB Forum that recently Mozilla started the process to adopt the gTLD requirements (ballot 96).  Once Mozilla adopts it, the requirement will be binding on all CAs (in NSS), regardless of whether they are CAB Forum members.

When typing a name in a browser for example, that name must be first translated into a number by a system before the connection can be established. That system is called the Domain Name System (DNS) and it translates names like www.icann.org into the numbers – called Internet Protocol (IP) addresses. ICANN coordinates the addressing system to ensure all the addresses are unique.

DNSSEC   (DNS Security Extension) is a technology to secure the Domain Name System.

During this session, the panelist presented through a sketch a scenario where user is redirected to another website pretending that it is the one he is looking for when there is a security problem.  DNNSEC can be implemented by any individual or organization who is handling a Domain name System server or simply a name server.

Another session for a half day workshop is scheduled for April 10, 2013.  

Thick Whois GNSO Working Group (providing the GNSO Council with a policy recommendation on universal ‘thick’ Whois) looking at the following elements: response consistency, stability, accessibility, impact on privacy and data protection, cost implications, synchronization and migration, authoritativeness, competition in Registry services, existing WHOIS applications, data escrow and Registrar Part 43 WHOIS requirements.

Began with a brief explanation of what ‘thick’ and ‘thin’ whois means. For thick, registrar collects data on the registrant, the domain and various contacts, and provides the information to the registry. For thin registries, only the domain data published – but all three data types retained. The WG has reached consensus on most issues – but not all. 

The issue for this session: privacy. Specifically, looking at the privacy implications for the Registrants who have registered their information in the thin model with the expectation that only domain data would be captured at the Registry during a transitional period where they’ve registered their name in a jurisdiction where there are strong privacy protections in local law? And now that data is going to be published in a Registry where the local law is different. The issue for registrants may arise if they deal with a registrar in a ‘privacy-friendly’ country with strong privacy laws, but the registry is in a jurisdiction with far less stringent privacy laws and registrant data is then made publicly available when all registries are ‘thick’.

Middle East Strategy : The meeting talked to strategies that are being worked on to improve achieve three goals:

• Foster two-way engagement between ICANN and the broader Internet community in the region;
• Build strong and competitive domain name industry in the region;
• Promote multistakeholder Internet governance mechanisms in the region.
• Strategic Focus areas are:
• DNS security and stability
• Domain name industry
• Internet governance ecosystem

In comments, the CEO of AusRegistry made suggestions including the need for metrics (such as number/percentage of registrations per population, registrations for businesses, number of gTLDs, ccTLDs, and talked of the need to promote local content as a driver.

Multi-Stakeholder Roundtable:

First session was on the new gTLDs. Speakers included Jeremy Malcolm, Consumers International, Peter Nettlefold, ViceChair, GAC, Zahid Jamil, Business Constituency, GNSO, Maguy Serad, ICANN Compliance.

Malcolm: Focus on end users- names they use, not have. Issues for consumers include the possibility of phishing, software incompatibilities, unclear expectations from the new names. Overall, the impact is likely to be relatively minor – a don’t know, don’t care attitude.

Nettlefold: Taken the view that they aren’t keen to object outright, but concerns include issues of defensive registrations, whether there is an implied level of trust with strings. On PICS, there was a need to identify the goal of commitments made in applications.

On compliance, there are issues of enforceability, who can raise concerns, who is notified, and what are the enforcement mechanisms.

Jamil: Are three stakeholders: the end user, the registrant and the trademark holder. All three should be protected. It is important that confusion is avoided, includingwhether there are IP risks attached to the name. What about scripts other than ASCII, and what about words that are similar? – is nothing in the Trade Mark clearing house to deal with those issues. On PICS, the current obligations are on registries – but what about registrars. Further, the RAA akkiws a oattern of abuse, with no mechanism to deal with it. Finally, developing countries do not have mechanisms to deal with the issues and maya become soft targets.

Serad: Compliance has been identifying the gaps in PICS and are building a readiness plan. There will be proactive monitoring for compliance. On enforceability, there is a lack of clarity on whether they are contractual obligations.

Rapport_Constituent Stakeholder Travel Guidelines

Whois Working Group

Review of documents published

Since then, have been additional negotiations, and has been agreement in principle to additional issues

Cautions:

• Has been a 4year process and there is a level of anxiety about the final text
• The specification on privacy/proxy has been condensed
• What about verification of the true registrant using a privacy/proxy service

Report_ICANN Finance Open Session.pdf

Engagement with RIRs – especially APNIC – be aware of events involving RIRs

• New groups, including new gTLD outreach
• Need for feedback on ATRT2
• Is survey on ICANN image
• Is a need for a youth session or youth forum as a bridge between users and ICANN
• Need for briefing sessions
• Issue of individual membership
• Elections: (for APRALO Chair – Holly’s term ends 30 June, for APRALO Vice Chair (YJ’s term ends 30 June) and for Secretariat – Edmon and Pavan – term ends 30 June)
  
  • Nominations are from 9 April to 3 May
  • 4 May – 10 May – acceptances by nominees
  • 17 May – 7 June: Elections
  • 1 July – Newly elected leaders’ terms begin

Report_Global Stakeholder Engagement.pdf

11 April 2013, 09:00-10:30

Members of the MSWG Group:

This was the first meeting of the Meeting Strategy Working Group (MSWG). It was mostly an introductory meeting. The agenda was as follows: 

1.Welcome

2.Composition

3.Goals

4.Deliverables

5.Organization

6.Schedule

7.AOB (any other business)

Please check here for more details: https://community.icann.org/download/attachments/40929548/ICANN_MSWG_Beijing_2013_04_11_fin+%283%29.pdf?version=1&modificationDate=1367251475241

The next meeting will be a telephone conference to be held May 2, 2013 @ 1400UTC. The group agreed to have these calls every two weeks going forward.

This was one of the final meetings of the WG.

The Study Group was established by a resolution of the ccNSO Council on 8 December 2010. The Study Group was tasked with developing an overview of:

• the way in which the names of countries and territories are currently used within ICANN, be it in the form of policies, guidelines and/or procedures;

• the types of strings, relating to the names of countries and territories that currently used, or proposed to be used, as TLDs; and

• the issues that arise (or may arise) when current policies, guidelines and procedures are applied to these representations of country and territory names. 

The Study Group is comprised of representatives from across the ICANN stakeholder community and has been conducting its work since May 2011.

A Final draft report was discussed and will be shortly presented to the public for comments.

Final draft recommendations from the group are:

• The ccNSO Council is recommended to request the Board to extend the current rule in the Applicant Guidebook to exclude all country and territory names in all languages, for consecutive rounds of new gTLD applications.
• It is further recommended that the ccNSO Council takes the initiative to establish a cross community working group to review the current definitions of country and territory names under current policies and propose a consistent and uniform definition that should be applicable across the respective SO’s and AC’s. The GNSO, ALAC and GAC should be invited to participate in such a WG.

Please check meeting transcript here: Transcript Country Names Beijing.pdf and final draft report here: 2012-03 ccNSO Study Group on Country and Territory Names -Final Report v02.docx

08 april

17:00-19:00

10 april

9:00 - 10:30

The rules for formal policy development are clear in the ICANN Bylaws, but the policy implementations are not so clear.  

Policy role whitin ICANN, 3 supporting organizations responsible for policy: Address Supporting Organization, Country Code Names Supporting Organization, Generic Names Supporting Organization. GNSO is responsible for developing and recommending substantive policy relative to top level domain. 

Multiple approaches to identify policy issues, reviewing, creating policy proposals, and providing policy advice, Advisory Committee: ALAC, RSSAC, SSAC, GAC. Policy Review Team: Whois. Experts Groups: Implementation & Recommendation Team.  

Implementation Process: reports, public comments, MS process.  

Implementations approaches: Identifying implementations issues, reviewing implementations, create policy implementation proposals and advice. 

We have Fast-track team (IDN), Stakeholder team (TMC), staff team (Applicant Guidebook), external consultants. It is getting more complex to move from policy to implementation.  

Who is responsible for making decisions relating to implementations?  

1. Faster process: is the staff look up the policy, produce implementation proposal, public comments, and Board approval. Ex. Red Cross Protection.  

2. Slower process: GNSO WG looks at an issue, present for GNSO Council approval, goes to the Board for approval, and goes back to staff to refine it. Ex. gTLD transfer.  

TENSIONS:  The GNSO wants to be consulted on implementations policies. Key issue: the perception is that if smth has to go to GNSO for policy works would take a lot of time (months, years) and creates tension. The reality is that the GNSO in many topics work quickly. Not a unanimous consent from various Stakeholders, come up into a vote. Tension as well. Use some other process.  

Provide more clarity. Not separate things. True MS input.  

Staff Paper: Objective is to be forward looking. Different variations in PDP. Not clearer or transparent for the community of what is to be expected and what the role are of different groups in the process. Impossible task to draw a line btw what is policy and what is implementation. Focus on how we can set clearer processes.  

Draft framework: outline a broad one, what need further discussions or clarifications. Identify criteria, principals. Suggestions for improvements. Short-term suggestions for improvements. Ex. SO/AC how they provide advice when they are being requested by the Board, also how the BOARD  request for advice and the timeframe.  

Real focus: clearer process, predictability and transparency, what happens when policy moves into implementation? What needs to happen in the policy development stage of discussions? Clarify the role of the different Stakeholders groups. Focus as well on the policy development aspects. How to facilitate implementations.  

The paper is for discussions: http://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf Encourage some feedback. 

Question 1 - What is from the perspective of your community the main priority with regard to the discussion on policy vs. Implementation?

   Priority to design a framework that works for the long term. Is not sensible to try to find a bright line btw policy and implementation. The value would be judge by whether it is elegant, its outcomes. As it is said, the proof on the pudding is on the eating.  

 Policy very often comes up in the act of interpreting the policy while doing the implementation. Ex. New gTLD. What is policy and what is implementation changes, policy is still involve in implementation issues. Constant awareness.  

Eliminate the issue that you don’t need to involve the supporting organization in the implementation. Has a responsibility to ensure that the policies are implemented according to the policy that has been approved.  

Main priorities are mechanisms to work together.  

 Not find ourselves in a position to draw the line. Policy is what you are going to do and implementation how you are going to do it. Good policy should anticipate implementation. Good implementation has to respect the intention of the policy makers.  

Look back to past for viable lessons, experiences.   

Policy is what you want, implementation is what I want. Establish some guidelines .  Beneficiary of those policies, be mindful of those folks who are going to implement them.

   Key concern is to have a sense of notice when our obligations are going to change. If there is a new rule, new obligations and parties, have to have a notice of that rule, to understand your new obligations, lenghty enough time to parties to comment, give modifications, explain their  concerns, suggestions. Decent Explanation of how the results are going to be. Strive for how the dispute are going to be solved.

Question 2 - Do you believe that an overall framework could be created for all policy implementation activities within ICANN or should specific models be created that would apply for ASO/ccNSO/GNSO policy implementation activities?

Don't need to be an overall framework, all policy and implementations activities are here to be principles regarding notices and due processes.

Do not need to be the sames across SO/AC. Balances. Making sure that we are consulting not only the ASOS but the community as well.

Not practical given the different reality, not a single framework for each SO/AC.

Might be a challenged.

Most definitely be set up, the nature of policy and implementation pretty much remain the sames, prefer an overall framework.

Could work for the definition. How is it put back to the ASO, no way we can do that with a single framework. Evolve in different SO/AC.

Cross Community engagement should be a natural. Culture of silos is smth that needs to be addressed. Fundamental part of the problem why it is so difficult to engage, how the GAC engage in early stage of the process, engage a broader level of the community. The concept of force engagement indicate the problem right in the question.

We can't force cross community activities. There has to be a mechanism for fostering it.

Is not necessarily natural if there is not a need or interest. Look alternatives. Never get over of silos, we have to learn how to work together inspite of our silos.

Mediate specific points of disagreements, find commonalities. Bridge silos through many mechanisms.

Should expect wide divergence. EU has a conciliation process. No solution if you guys can't come up with one.  Forcing does come from pression from government and law enforcement.

Practical solution. Delegating the issue to mediation. Use the tools that exists in the real world.

Consensus driven model, if there is conflicting policy advice, then is an acknowledgment that the status quo is not sufficient painful to make a policy change. Experts are here, no need for a third party to solve our problems. Can come to an agreement cannot force a cross community. Stay true to the principle that we have to agree in order to proceed.

Someone with better skills can help bring us to a higher place. Come to a better place with better tools.

Question 4 - What should be the next step in addressing this issue? Some have suggested the creation of a cross-community WG. What is your view on this approach? Are there certain elements that would need a cross-community approach while others should be addressed within respective SO/ACs? 

SO with the involvement of the AC should take the first steps on addressing this issue.  GNSO form a WG. Develope and the extend to other SO if relevant for them. Take to a cross community level.

Developing is a good idea.

Opportunity to implement. Tests cases with the Brand Registry Group, Close Generics, Singular and plural contentions sets.

Excellent idea to explore this issues. Try to identify challenges. Address them.

We already have some templates that has worked and has flaws and can be refined.

11 April 2013, 11:00-12:30

Grand Hall A