Hi, Having reflected on the proposed form for public comment for a few more minutes, I think that it should not be used. This is not to deny the probable utility it would bring. But I think it will itself be a distraction. The community was promised an open CCWG process with the normal ICANN procedures. As it is, the document is late, the document that gets posted will have significant gaps (this is a charitable way of saying "incomplete"), and the normal length of public comment is not going to be met. If we now add a completely new form that nobody has ever heard suggested before, people are going to wonder what's being hidden behind this innovation. (Indeed, several of us seemed to have exactly that reaction on the call.) It would be quite different if the plans to use this mechanism had been mooted before -- even weeks ago, but ideally in Singapore or earlier. Without having done that, this will look to those who mistrust ICANN as yet another way to filter input so that anything critical doesn't get heard. I'm moreover quite sceptical of the technical support behind this. The existing public comment mechanism uses SMTP (email) and a confirmation loop before taking that mail and putting it in a public archive. It's been working for years. On the call, I heard assurance that there's no database behind the proposed form (which, I note, was itself not actually complete in time for the call). In my day job for the past several years I have either designed, developed, or managed the developers of software. There needs to be some form handling that will take the input from the form and put it somewhere. This might not be a relational database, but there is _some_ software, however trivial, to develop here. This seems like work that would be valuable to do, but not work that is so valuable that we ought to drop other things to implement this new feature at the very last second before public comment should start. If one of my agile development squads came to me the day before the end of a sprint, and suggested designing and implementing a completely new mechanism the day before our demo to the product owner, I'd suggest -- very, very firmly -- that perhaps that idea belonged in the next sprint. If there is any software problem at all (I hesitate to use the word "glitch", but perhaps it will awaken memories for some of you), then it will raise all sorts of issues about preparation, execution of the task, and so on. Therefore, while I agree that this is an innovation that ought to be pursued, I suggest that it ought to be pursued in the context of a less fraught issue for a task that has been smoother than this one has been. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com