[LAC-TF] FAQ: Grupo2 - Pregunta "a"
Mariela Rocha
marielac.rocha at gmail.com
Tue Mar 10 15:49:26 BRT 2009
Estimados:
Dado que la elaboración de esta respuesta ha llevado mucho mas tiempo
del estimado y que hay cierto acuerdo en que la que redactó Guillermo
engloba tanto la de Nicolás como la de Jorge, creo que sería bueno ir
finalizando con ella para dar lugar a una nueva pregunta en la FAQ.
Si les parece bien, mañana estaríamos lanzando la pregunta 2 "b".
Saludos a todos!
Mariela.-
Jorge Villa wrote:
> Hola Alvaro, como estas?
>
> Reitero la pregunta a responder: ¿Es posible estimar la inversión de dinero
> requerida para actualizar aplicaciones, de manera que funcionen
> correctamente sobre IPv6?
>
> Segun el diccionario de la Real Academia de la Lengua Española, estas son
> las acepciones de Estimar:
>
> estimar.
> (Del lat. aestimare).
>
>
> 1. tr. Apreciar, poner precio, evaluar algo.
>
> 2. tr. Juzgar, creer.
>
> 3. tr. Hacer aprecio y estimación de alguien o de algo. U. t. c. prnl
>
>
> Segun las posibles acepciones y la manera en que esta redactada la pregunta
> (donde se hace explicito el factor monetario), creo que la pregunta va
> orientada hacia tener un costo aproximado (en dinero) para realizar el
> proceso de actualizacion de aplicaciones.
>
> Uno podra conocer cuales son los factores a tomar en cuenta para desarrollar
> el proceso, pero no es posible cuantificar a grosso modo, porque depende de
> la situacion particular de cada aplicacion y como se desarrolle el proceso.
> Sigo pensando que NO es posible hacer una estimacion economica del asunto.
>
> Esta pregunta a quienes interesa principalmente? Pienso que en general a dos
> tipos de personas: A los ejecutivos y a los que buscan hacer negocio. Los
> ejecutivos requieren presupuestar y concebir el proceso y por tanto les
> interesan las cifras monetarias y los tiempos en que pueden lograrlo. Los
> que buscan hacer negocios portando aplicaciones de IPv4 a IPv6 (tal como los
> que hicieron negocio en este campo cuando el error del milenio) necesitan
> tener una idea del dinero, para tratar de ofrecer la realizacion del proceso
> a un costo menor.
>
> No hay forma de decir a priori, aunque sepas los factores a tomer en cuenta,
> que actualizar un software debe costar (por ejemplo, alrededor de 10 mil
> dolares). Las compañias productoras de software normalmente pueden hacer sus
> estimados, a partir de los costos de los productos que ya han hecho y
> analizando la complejidad del problema a resolver, las tecnologias a usar,
> etc; pero todo difiere de una empresa a otra. Por eso ayer hice la
> comparacion de la estimacion de este proceso con la estimacion de una camara
> fotografica, aunque podia haberla hecho con un router o cualquier
> dispositivo. Para todo dispositivo hay un rango de precios mas o menos
> conocido, por tanto si uno esta proyectando una inversion puede estimar
> cuanto dinero debiera tener uno para comprar el equipo requerido. O lo
> puedes hacer al reves, si sabes cuanto dinero tienes, puedes hacer un
> estimado de los equipos que puedes comprar con esa cantidad.
>
> Saludos,
> Jorge
>
> ----- Original Message -----
> From: "Alvaro Vives Martinez" <alvaro.vives at consulintel.es>
> To: <lactf at lac.ipv6tf.org>
> Sent: Tuesday, March 10, 2009 5:08 AM
> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
>
>
>
>> Hola a todos,
>>
>> La respuesta de Nicolas me parece correcta para la FAQ ya que permite
>> situar
>> a la persona que se haga esa pregunta.
>>
>> En otro orden de cosas, repondiendo a Jorge, yo diría que tal vez haya que
>> jugar con la semántica aquí. Yo diría que SI es posible ESTIMAR el coste,
>> pero que NO es posible CALCULARLO con seguridad. En general siempre se
>> puede
>> estimar, la cosa es que luego se acierte :-)
>>
>> Por eso la respuesta debe ir en la línea informativa de Nicolas, diciendo
>> que se puede estimar de manera aproximada en cada caso concreto y
>> basándose
>> en el conocimiento de diversos factores (apuntados por Jorge).
>>
>> La cuestión es identificar ahora mismo cuáles son esos factores que
>> deberán
>> tenerse en cuenta. Eso lo veo de mucha utilidad para el lector de la FAQ
>> que
>> se haga esa pregunta.
>>
>> Un saludo,
>> Alvaro
>>
>>
>>> -----Mensaje original-----
>>> De: lactf-bounces at lacnic.net [mailto:lactf-bounces at lacnic.net] En
>>> nombre de Jorge Villa
>>> Enviado el: lunes, 09 de marzo de 2009 21:19
>>> Para: lactf at lac.ipv6tf.org
>>> Asunto: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
>>>
>>> Nicolas, como estas?
>>>
>>> Pues bueno, la pregunta esta formulada de la manera mas generica
>>> posible, y
>>> pienso que NO es posible estimar "de forma general" la cantidad de
>>> dinero
>>> requerida para actualizar aplicaciones, porque los procesos son
>>> diferentes
>>> por completo (segun la complejidad de cada aplicacion) y las
>>> condiciones en
>>> las que se hace el proceso para cada aplicacion tambien es diferente, y
>>> todo
>>> ello influye. En mi respuesta anterior me habia referido a 5 topicos,
>>> que
>>> por lo general de una manera u otra influyen en el proceso, y ya eso te
>>> genera una buena aleatoriedad en los costos asociados. Por tanto la
>>> estimacion tendra que hacerla cada quien para su situacion particular.
>>>
>>> En este caso, no es como estimar el costo de una camara fotografica,
>>> digamos
>>> de 8 megapixels de una marca conocida (Sony, Canon, Fuji, Panasonic,
>>> Kodak,
>>> etc). Es cierto que los precios pueden variar, pero una camara de una
>>> marca
>>> conocida, de las normalitas (para uso domestico) de esa resolucion
>>> puede
>>> andar entre los 150 y 400 dolares, segun donde se compre y segun la
>>> marca y
>>> modelo. A lo mejor en Estados Unidos la consigues en 150 dolares
>>> minimo, y
>>> en otros paises la misma camara sale en el doble, pero mas o menos
>>> puedes
>>> dar una idea a grosso modo de cuanto se requiere para tener una camara
>>> asi.
>>>
>>> En el caso de lograr que aplicaciones actualmente IPv4 funcionen
>>> correctamente en IPv6, por lo menos yo, no me atreveria a dar una cifra
>>> y
>>> que fuera algo real. No se si Fernando, Alvaro o alguno de los que han
>>> estado participando en el FAQ, o de los que no lo han hecho pero si lo
>>> van
>>> siguiendo, pueden dar otra luz al respecto.
>>>
>>> Por lo demas, me siento satisfecho por la respuesta que ha ido
>>> estructurando
>>> Guillermo, porque aporta elementos a quien esta buscando "la respuesta
>>> magica" a esta pregunta. O sea, uno puede decirle a cualquiera: No te
>>> puedo
>>> decir cuanto te cuesta llevar tu aplicacion a IPv6 (haria falta una
>>> bola de
>>> cristal); pero si puedes sacar tus propias cuentas teniendo en cuenta
>>> estos
>>> factores, y ademas, te sugiero que la valoracion la pueda hacer un
>>> equipo
>>> multidisciplinario, pues aunque se hable de aplicaciones no solo los
>>> desarrolladores de software estan involucrados"; asi que aqui copio la
>>> respuesta de Guillermo.
>>>
>>> "No es posible estimar la inversion desde un punto de vista generico,
>>> ya que dependera de varios factores, tales como
>>>
>>> - arquitectura de la aplicacion
>>> - tecnologias empleadas
>>> - calidad del codigo fuente
>>> - capacitación del personal
>>> - sistemas operativos
>>> - arquitectura de red
>>>
>>> Sin embargo, en cada caso particular se podra hacer una estimacion de
>>> la inversion necesaria, de acuerdo a los factores que correspondan.
>>> Como recomendacion general, es conveniente pensar en que intervenga un
>>> equipo multidisciplinario ya que no esta involucrado solo un
>>> conocimiento de programacion, sino tambien cuestiones referentes a la
>>> tecnología IP, sistemas operativos, etc."
>>>
>>>
>>> Saludos,
>>> Jorge
>>> ----- Original Message -----
>>> From: "Nicolas Antoniello" <nantoniello at gmail.com>
>>> To: <lactf at lac.ipv6tf.org>
>>> Sent: Monday, March 09, 2009 3:04 PM
>>> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
>>>
>>>
>>>
>>>> Hola Jorge,
>>>>
>>>> Justamente yo decia que para mi SI se puede estimar, siempre que se
>>>> tengan en cuenta los factores correspondientes a cada caso en
>>>> particular.
>>>> Ahora me pregunto si la pregunta (aunque suene redundante) ¿apunta a
>>>> estimarlos en un caso genérico o en cada caso?
>>>>
>>>> Saludos,
>>>> Nicolas.
>>>>
>>>>
>>>> 2009/3/6 Jorge Villa <villa at reduniv.edu.cu>:
>>>>
>>>>> Hola a tod at s, como estan?
>>>>>
>>>>> Pues como que se quedo en el aire la respuesta de la nueva pregunta
>>>>>
>>> del
>>>
>>>>> FAQ,
>>>>> luego de la ultima respuesta de Fernando haciendo referencia a la
>>>>> RFC5461.
>>>>>
>>>>> La pregunta a responder es la siguiente:
>>>>>
>>>>> ¿Es posible estimar la inversión de dinero requerida para actualizar
>>>>> aplicaciones, de manera que funcionen correctamente sobre IPv6?
>>>>>
>>>>> Pienso que se han aportado muchos elementos acerca de que seria
>>>>>
>>> necesario
>>>
>>>>> modificar o de aspectos tecnicos de implementacion, pero seguimos
>>>>>
>>> sin
>>>
>>>>> responder exactamente la pregunta.
>>>>>
>>>>> Yo creo que NO es posible estimar la inversion de dinero que se
>>>>>
>>> requiere
>>>
>>>>> para actualizar aplicaciones IPv4, de manera que funcionen
>>>>>
>>> correctamente
>>>
>>>>> sobre IPv6, producto que ello dependera de varios factores. Entre
>>>>>
>>> ellos,
>>>
>>>>> creo fundamentales los siguientes:
>>>>>
>>>>> - arquitectura de la aplicacion
>>>>> - tecnologias empleadas
>>>>> - calidad del codigo fuente
>>>>> - capacitación del personal
>>>>> - sistemas operativos
>>>>> - arquitectura de red
>>>>>
>>>>> La arquitectura de la aplicacion se relaciona con si la aplicacion
>>>>>
>>> es
>>>
>>>>> monolitica, o es una aplicacion cliente-servidor (basadas o no en
>>>>>
>>> web), y
>>>
>>>>> por supuesto de la modularidad con que haya sido diseñada la
>>>>>
>>> aplicacion.
>>>
>>>>> En
>>>>> algunos casos puede necesitarse rehacer un modulo, pero en otros
>>>>>
>>> casos
>>>
>>>>> puede
>>>>> necesitar rehacerse un porciento significativo del producto. Si la
>>>>> aplicacion tiene clientes Web, entonces sera necesario rehacer solo
>>>>>
>>> el
>>>
>>>>> servidor, pero si tiene un cliente personalizado, con seguridad
>>>>>
>>> habra que
>>>
>>>>> trabajar tanto en el cliente como en el servidor.
>>>>>
>>>>> Tambien existen multiples tecnologias con las que puede construirse
>>>>>
>>> una
>>>
>>>>> aplicacion. Algunas son mas simples y otras mas complejas. En muchos
>>>>> casos
>>>>> se emplean bibliotecas estandares y en otras bibliotecas diseñadas a
>>>>>
>>> la
>>>
>>>>> medida. Puede suceder que tambien alguna de las tecnologias con que
>>>>>
>>> se ha
>>>
>>>>> construido una aplicacion se haya descontinuado por sus fabricantes,
>>>>>
>>> y
>>>
>>>>> por
>>>>> tanto haya que rehacer el producto con base en una nueva plataforma.
>>>>>
>>>>> Los codigos fuentes son otro dolor de cabeza para muchas
>>>>>
>>> aplicaciones, ya
>>>
>>>>> que en algunos casos estos no estan disponibles, otras veces estan
>>>>> disponibles pero no estan hechos con calidad o no estan comentados
>>>>> adecuadamente, y eso complica la legibilidad del codigo, sobre todo
>>>>> cuando
>>>>> quien tiene que actualizar la aplicacion no fue su diseñador
>>>>>
>>> original.
>>>
>>>>> El personal que participa en el proceso tiene que estar bien
>>>>>
>>> capacitado.
>>>
>>>>> Hay
>>>>> programadores que no dominan ni siquiera aceptablemente la
>>>>>
>>> tecnologia IP,
>>>
>>>>> y
>>>>> logran hacer aplicaciones que funcionen en red adecuadamente
>>>>>
>>> confiando en
>>>
>>>>> las librerias de comunicacion de los paquetes de desarrollo de
>>>>> aplicaciones.
>>>>> Para entender correctamente la RFC5461 y algunos de los otros draft
>>>>>
>>> al
>>>
>>>>> respecto, hay que saber de tecnologia IP. Por lo general, en este
>>>>>
>>> proceso
>>>
>>>>> de
>>>>> actualizacion debe intervenir un equipo multidisciplinario.
>>>>>
>>>>> Los sistemas operativos tambien influyen, segun la calidad de la
>>>>> implementacion del stack IPv6 en los mismos. Tambien puede existir
>>>>>
>>> un
>>>
>>>>> costo
>>>>> asociado a sistemas operativos, ya que si la aplicacion actual se
>>>>>
>>> ejecuta
>>>
>>>>> en
>>>>> Windows 98 o 2000, en W98 no hay soporte IPv6 y en W2K hay soporte
>>>>> limitado,
>>>>> por tanto habra que crear al menos a nivel experimental, una
>>>>> infraestructura
>>>>> basada en XP o Vista.
>>>>>
>>>>> La arquitecturas de red puede complicar en mayor o menor medida el
>>>>> proceso
>>>>> de desarrollo de aplicaciones. Es mucho mas facil crear un entorno
>>>>>
>>> de
>>>
>>>>> desarrollo y/o actualizacion a nivel local (para aplicacion para
>>>>>
>>> Internet
>>>
>>>>> desde PCs) que cuando hablamos de aplicaciones para dispositivos
>>>>>
>>> moviles,
>>>
>>>>> donde hay otros aspectos a tener en cuenta.
>>>>>
>>>>> Como quiera que tras cada aplicacion hay un cerebro diferente, las
>>>>>
>>> formas
>>>
>>>>> de
>>>>> pensar y de llegar a las soluciones difieren y por esto es muy
>>>>>
>>> dificil
>>>
>>>>> cuantificar el proceso (a grosso modo). Tambien las condiciones
>>>>>
>>> tecnicas
>>>
>>>>> en
>>>>> que se desarrolle el proceso influyen, y por supuesto que la
>>>>>
>>> inversion en
>>>
>>>>> capacitacion es fundamental.
>>>>>
>>>>> Bueno, hasta aqui mi respuesta a la pregunta A del grupo 2 del FAQ.
>>>>>
>>> Que
>>>
>>>>> siga
>>>>> la ronda.
>>>>>
>>>>> Saludos,
>>>>> Jorge
>>>>> ----- Original Message -----
>>>>> From: "Fernando Gont" <fernando at gont.com.ar>
>>>>> To: <lactf at lac.ipv6tf.org>
>>>>> Sent: Monday, March 02, 2009 1:34 PM
>>>>> Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"
>>>>>
>>>>>
>>>>>
>>>>>> Hola, Nicolás,
>>>>>>
>>>>>> Comentarios entre lineas....
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Le había echado un vistazo hace un tiempo a la RFC que tu
>>>>>>>
>>> propusiste.
>>>
>>>>>>> La consulta que te hago es sobre que es lo que te parece que
>>>>>>> tendríamos que agregar o tener en cuenta, en particular para las
>>>>>>> aplicaciones.
>>>>>>> ¿Te referís en estos casos a entornos mixtos IPv4-IPv6, donde por
>>>>>>> ejemplo, una aplicación debe "lidiar" con los errores derivados de
>>>>>>> time-outs,
>>>>>>>
>>>>>> En aquellos casos en que una se publican RRs (resource records)
>>>>>>
>>> AAAA
>>>
>>>>>> apra un determinado nombre de dominio, y la conectividad IPv6 es
>>>>>> limitada, se corre el peligro de caer en el escenario de "grandes
>>>>>> esperas antes de poder establecer una conexion" que se describe en
>>>>>>
>>> el
>>>
>>>>>> RFC mencionado. Para el caso de aplicaciones interactivas, esto es
>>>>>> directamente intolerable (ver referencias en el RFC.. aunque
>>>>>>
>>> tambien
>>>
>>>>>> puedo aportar otras).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> que no sean manejados directamente por los módulos que
>>>>>>> manejan las conexiones correspondientes o por ejemplo para
>>>>>>> aplicaciones de tiempo real o similares?
>>>>>>>
>>>>>> Esta cuestion es muy dificil de manejar. En primer lugar, porque
>>>>>> tradicionalmente NO se maneja a nivel TCP, entonces termina siendo
>>>>>> responsabilidad de la aplicación. EN segundo lugar, porque la
>>>>>>
>>> mayoria de
>>>
>>>>>> las aplicaciones no imponen timeouts apra el establecimiento de
>>>>>> conexión.
>>>>>>
>>>>>> Ajeno al workaround explicado en RFC 5461 (que puede NO funcionar,
>>>>>>
>>> en
>>>
>>>>>> caso que no se generen mensajes ICMP), hay algunas otras
>>>>>>
>>> alternativas,
>>>
>>>>>> como las descriptas en este I-D:
>>>>>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt
>>>>>> Si bien recuerdo, la gente de Mac hace algo de esto.
>>>>>>
>>>>>> En cualquiera de los casos, todavia no existe una solucion completa
>>>>>>
>>> a
>>>
>>>>>> esta cuestion, y conozco de proveedores de Internet que han
>>>>>>
>>> encontrado
>>>
>>>>>> grandes problemas debido a esta cuestión. Por ej., la gente de NTT
>>>>>>
>>> Japón
>>>
>>>>>> incluso ha hecho presentaciones sobre esta cuestión en algunas
>>>>>> conferencias (si alguien las desea, puedo buscar las diapositivas
>>>>>> correspondientes).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Creo que tu aporte y tus conocimientos al respecto aportarán mucho
>>>>>>>
>>> en
>>>
>>>>>>> esta fase de las FAQ.
>>>>>>>
>>>>>> En "alto nivel", la cuestion es que publicar registros AAAA apra
>>>>>>
>>> nombres
>>>
>>>>>> de dominio que tambien son accesibles mediante IPv4 puede llevar a
>>>>>> grandes demoras en el establecimiento de conexion, que apra
>>>>>>
>>> aplicaciones
>>>
>>>>>> interactivas resultaria directamente inaceptable.
>>>>>>
>>>>>> En lo que se refiere al workaround propuesto/descripto en RFC 5461,
>>>>>>
>>> apra
>>>
>>>>>> que funcione se necesitan dos cosas:
>>>>>>
>>>>>> * Que las implementaciones de TCP funcionen como lo describe el
>>>>>> documento (Windows *no* lo ahce asi, por ejemplo... aunque LInux y
>>>>>>
>>> e.g.
>>>
>>>>>> NetBSD *si* lo hacen)
>>>>>>
>>>>>> * Que en aquellos puntos de la red donde se limita la conectividad
>>>>>>
>>> IPv6,
>>>
>>>>>> se generen errores ICMPv6 cuando se tenga queo que rutear algun
>>>>>>
>>> paquete
>>>
>>>>>> IPv6, pero no se pueda hacerlo por falta de conectividad, etc.
>>>>>>
>>>>>>
>>>>>> En lo que hace a las "conexiones paralelas" descriptas en
>>>>>> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt,
>>>>>>
>>> esto
>>>
>>>>>> deberia implementarse a nivel aplicacion, lo que agergaria
>>>>>>
>>> complejidad a
>>>
>>>>>> las aplicaciones (y ajeno a eso, la mayoria de las aplicaciones NO
>>>>>>
>>> hacen
>>>
>>>>>> esto).
>>>>>>
>>>>>> Cualquier cosa en la que pueda ayudar, estoy a tus ordenes.
>>>>>>
>>>>>> Un abrazo,
>>>>>> --
>>>>>> Fernando Gont
>>>>>> e-mail: fernando at gont.com.ar || fgont at acm.org
>>>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LACTF mailing list
>>>>>> LACTF at lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>>>>
>>>>>> --
>>>>>> This message has been scanned for viruses and
>>>>>> dangerous content by MailScanner, and is
>>>>>> believed to be clean.
>>>>>>
>>>>>>
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by MailScanner, and is
>>>>> believed to be clean.
>>>>>
>>>>> _______________________________________________
>>>>> LACTF mailing list
>>>>> LACTF at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>>>
>>>>>
>>>> _______________________________________________
>>>> LACTF mailing list
>>>> LACTF at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>>
>>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.237 / Virus Database: 270.11.6/1980 - Release Date:
>>> 03/02/09 23:02:00
>>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>>
>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>
>
>
More information about the LACTF
mailing list