>> Twitter, Google+, Facebook, etc. could be the next steps. Let's embrace new >> tools to collaborate. > > Let's not. Collaboration based on software running on servers run by the IETF > or a contractor payed by the IETF is fine. Using collaboration tools owned by > the entities you listed, or similar entities, is not. I'm of two opinions here. One, I agree with Marc that the case has not been made for the use of proprietary technologies such as you mention; we actually do pretty well, and the ultimate issue is about effective communication with all of the relevant participants, not with those few that use a given social networking service (I, for example, use Facebook, but not twitter and not google+, and have specific reasons for my choices there). On the other hand, experiments involving other technologies (we have, for example, experimented with .ps, .pdf, .xml, jabber, and RFID badges) should not be out of bounds. Experiments should follow IETF experimental procedure. Arturo, my suggestion: in some context, after discussion with the working-group-or-whatever-in-question, use one of the tools you mention to accomplish IETF work. Take careful notes of what proportion of the indicated community (if the IPv6 Operations WG, for example, the participants in v6ops) join the discussions, and what contribution those discussions make. Think about archives, focused issue discussion (what SMTP readers call "threads"), and so on. Then write a draft documenting the outcome of that.