[LAC-TF] FAQ: Grupo2 - Pregunta "a"

Jorge Villa villa at reduniv.edu.cu
Tue Mar 10 09:53:05 BRT 2009 

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.
> 


-- 
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