[Ietf-lac] Trump y el bloqueo a los Musulmanes

[Carlos M. Martinez]

El tema visas en Buenos Aires *no fue para nada fácil*, por ejemplo 
para los chinos. Se lo hicieron bastante difícil.

Lo comento no como crítica a Argentina sino para que lo tengamos en 
cuenta a la hora de evaluar la dificultad / facilidad de obtener visas 
para determinados grupos de personas en determinados países.

No hay un país que sea fácil para todo el mundo, lamentablemente, hay 
una matriz de dificultades.

s2

Carlos

On 3 Feb 2017, at 13:36, Alvaro Retana (aretana) wrote:

> On 2/1/17, 11:10 PM, "Fernando Gont" <fgont at si6networks.com> wrote:
>
>
>
> Fernando:
>
>
>
> Cómo vas?
>
>
>
>
>
> | Me pregunto cual sería la postura de I* si estuviera estipulada una
>
> | reunion en X pais, y el pais en cuestion dispusiera un "ban" contra
>
> | estadounidenses. Dudo que en tal caso hubiera chance alguna de que 
> la
>
> | reunion se realizara en el pais en cuestion.
>
>
>
> Supongo que tenés razón.
>
>
>
> Uno de los temas que hemos estado discutiendo esta semana 
> (IESG/IAB/IAOC) es si estamos dándole más importancia de la cuenta a 
> los EEUU.  Siempre han existido problemas de visas con las reuniones 
> en EEUU (casos individuales), pero hasta ahora es una acción mucho 
> más explícita.  Pero por otro lado no siempre reaccionamos igual, o 
> talvez no vemos el impacto directo (como comunidad) de lo que pasa en 
> otros lugares: acciones en Europa o en Asia (el GFW, etc.).  
> [relacionado con lo que escribiste abajo]
>
>
>
> Para bien o para mal, una gran parte de los participantes en el IETF 
> (todavía) vive en EEUU, entonces es algo que se tiene que considerar.
>
>
>
> Si, tenemos que tener mucha más diversidad, etc...
>
>
>
> Es muy difícil, tan cerca del IETF 98, decir que hubiera pasado si la 
> reunión hubiera estado programada para otro país con la situación 
> que planteas…  Yo tengo la fe de que algunas de las discusiones que 
> estamos viendo con respecto a hubs remotos en los países de los que 
> no pueden viajar a EEUU (por ejemplo – iniciadas por personas que 
> viven en EEUU) también estuvieran pasando.  En otras palabras, creo 
> que la comunidad está reaccionando como se esperaría que una 
> comunidad abierta reaccione…
>
>
>
>
>
> | Previo a la realización de la reunion en Buenos Aires, hubieron
>
> | numerosos argumentos ridiculos para no hacer una reunion en
>
> | latinoamerica. Creo que si la cuestion fuera minimamente pareja (que
>
> | personalmente no creo que lo sea), no deberia ni estar en discusión 
> que
>
> | al menos durante la administracion actual, no deberian realizarse
>
> | reuniones en USA (*).
>
>
>
> El I* (por lo menos el IESG/IAB/IAOC) no son entes políticos, y no 
> pensamos que sea prudente meternos en política ahora (o en ningún 
> otro momento).  Discusiones o pronunciamientos relacionadas con 
> administraciones específicas no son algo que el IESG/IAB/IAOC vayan a 
> hacer.   Esto a pesar de que una mayoría (todos!) creo que pensamos 
> lo mismo: la situación es difícil y cambiante – lo mejor que 
> podemos hacer es no planear reuniones en EEUU.
>
>
>
> Lo que si podemos (IESG/IAB/IAOC) hacer es guiar las consideraciones 
> sobre reuniones en el futuro para que se tome en cuenta la nueva 
> situación.  IETF 98 está demasiado cerca, pero IETF 102 (programada 
> para San Francisco) está siendo discutida: el IAOC debería tomar en 
> cuenta la situación actual, posibles cambios, sedes alternativas, 
> patrocinadores (ya confirmados) y contratos (ya firmados).  Claro, 
> todo dentro de los lineamientos que está fijando mtgvenue.  No creo 
> que esté garantizado que no nos reunamos en EEUU, pero si es un tema 
> que va a ser considerado seriamente.
>
>
>
> Aclaro arriba una parte del I* (IESG/IAB/IAOC) porque el ISOC *si* es 
> la parte política y la que podría no mediante comunicados, sino 
> mediante influencia tener un poco más de impacto político en lo que 
> está pasando…
>
>
>
>
>
> La reunión en Buenos Aires sirvió para demostrar que es posible 
> tener reuniones exitosas en América Latina.  Pero también nos 
> sirvió para empezar discusiones más serias con respecto a 
> participación remota, e incluso el tema de reuniones completamente 
> virtuales (a pesar de que todavía no tenemos una solución al 
> problema de la diferencia de hora).  El tema surgió por la amenaza 
> del Zika – consideramos cambiar la reunión (hasta teníamos una 
> sede alternativa “lista”) por el riesgo potencial, discutimos 
> reuniones virtuales, participación remota, etc.  Mucho del camino que 
> recorrimos ahí nos está ayudando ahora.
>
>
>
>
>
> | En tal sentido creo que este grupo deberia expresar opinión al 
> respecto.
>
>
>
> Con “este grupo” te referís al I* (o parte) o a ietf-lac?
>
>
>
> Como sabés, los Chairs del IESG/IAB/IAOC ya escribieron un blog.  Sin 
> entrar en temas políticos o en acciones específicas, no hay mucho 
> más que podamos decir.  De hecho, ya tenemos un texto corto que 
> básicamente dice lo mismo que el blog – algunos piensan que tenemos 
> que publicarlo (aunque no diga nada nuevo), otros pensamos que 
> debería decir más; por lo menos hablar de posibles acciones que el 
> IETF puede tomar…  Esperamos tener algo listo en los próximos 
> días.
>
>
>
> Saludos!
>
>
>
> Alvaro.
>
>
>
>
>
> | (*) Entiendo la problematica de que en algunos casos, si saliera de 
> US,
>
> | no podrían regresar. Mas alla de "solidarizarme" con los afectados 
> de
>
> | esa forma, entiendo que tal situación es mas bien un problema 
> doméstico
>
> | de USA. El "iluso" que hay en mi se pregunta porque no ubo 
> pronunciación
>
> | alguna (nunca) sobre otros "territorios" en los que, no por 
> decisión
>
> | propia sino por decisión ajena, no se puede entrar ni salir de los
>
> | mismos. (Tip: middle east)


> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20170203/14554f4f/attachment.html>