At the end of the meeting I was the last person at the microphone, and what I said was confusing. Let me explain...
First of all, I mentioned I was chair of SSAC. That was not the slightest a way of convincing you to listen more to me than others. It was a disclosure. My apologies if people did think the intention was different. I have been talking with the chair of the meeting (Suzanne) about the issue. Secondly, what I said was that we do not have any process to add anything to the root at the moment. This because the round of new gTLDs ICANN did run has closed and you simply can not apply for new TLDs. Questions have started to be asked to the various constituencies inside ICANN (including SSAC) what must be made, if anything, before a potential next round has started. Because of this, whatever IETF will say/do (even if the result is to in a conscious way be silent) is timely, and might be extremely important input to a potential PDP inside ICANN related to "more TLDs". And this includes of course that SSAC might come with more advice to ICANN "to work with IETF" than what we already have made, for example: > Resolved (2014.03.27.06), the Board adopts the SSAC advice in SAC062, and > directs ICANN's President and CEO, or his designee, to proceed with > implementing the recommendations in SAC062. > > > : > : > > The action being approved today is to accept the SSAC's recommendations > contained in SAC062 concerning name collisions. As noted in SAC062, the SSAC > in general supports the NGPC proposal. SAC062 focuses on three specific areas > of the NGPC proposal where SSAC has advice: the action on high-risk strings, > trial delegation, and the development of a monitoring framework for the root > zone. Specifically, the SSAC recommendations are as follows: > > Recommendation 1: ICANN should work with the wider Internet community, > including at least the IAB and the IETF, to identify (1) what strings are > appropriate to reserve for private namespace use and (2) what type of private > namespace use is appropriate (i.e., at the domain top-level only or at any > additional lower level). Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
