[LACNIC/Politicas] Reflexiones acerca del PDP

[angel david melendez]

cierto lo que dices jordi no todos pueden ir a los foros públicos deberian 
por lo menos inventar reuniones virtuales como un canal irc para aprobar 
politícas sin necesidad de esperar un año al próximo foro.


>From: JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
>Reply-To: jordi.palet at consulintel.es,LACNIC Policy mailling list 
><politicas at lacnic.net>
>To: LACNIC Policy mailling list <politicas at lacnic.net>
>Subject: Re: [LACNIC/Politicas] Reflexiones acerca del PDP
>Date: Wed, 30 May 2007 01:10:02 +0200
>MIME-Version: 1.0
>Received: from mail.lacnic.net ([200.160.2.16]) by 
>bay0-mc9-f6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 29 
>May 2007 16:10:23 -0700
>Received: from localhost (localhost [127.0.0.1])by mail.lacnic.net 
>(Postfix) with ESMTP id 8C3E2B9E8;Tue, 29 May 2007 20:10:22 -0300 (BRT)
>Received: from mail.lacnic.net ([127.0.0.1])by localhost (mail.lacnic.net 
>[127.0.0.1]) (amavisd-new, port 10024)with ESMTP id L9t-ZVAnT7ox; Tue, 29 
>May 2007 20:10:22 -0300 (BRT)
>Received: from mail.lacnic.net (localhost [IPv6:::1])by mail.lacnic.net 
>(Postfix) with ESMTP id 55220B960;Tue, 29 May 2007 20:10:20 -0300 (BRT)
>Received: from localhost (localhost [127.0.0.1])by mail.lacnic.net 
>(Postfix) with ESMTP id 21394B956for <politicas at lacnic.net>; Tue, 29 May 
>2007 20:10:19 -0300 (BRT)
>Received: from mail.lacnic.net ([127.0.0.1])by localhost (mail.lacnic.net 
>[127.0.0.1]) (amavisd-new, port 10024)with ESMTP id oaNhJl8lE31Q for 
><politicas at lacnic.net>;Tue, 29 May 2007 20:10:18 -0300 (BRT)
>Received: from consulintel.es (mail.consulintel.es [213.172.48.142])by 
>mail.lacnic.net (Postfix) with ESMTP id E77D5B960for 
><politicas at lacnic.net>; Tue, 29 May 2007 20:10:16 -0300 (BRT)
>Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R)with 
>ESMTP id md50002525644.msgfor <politicas at lacnic.net>; Wed, 30 May 2007 
>01:07:21 +0200
>X-Message-Info: 
>LsUYwwHHNt3x8ONbmeDgOfMXs2oS45DXDpWnzrKr5/uHbJw3jXGFIgaR62hncz5K
>X-Virus-Scanned: amavisd-new at lacnic.net
>X-Original-To: politicas at lacnic.net
>Delivered-To: politicas at lacnic.net
>X-Virus-Scanned: amavisd-new at lacnic.net
>User-Agent: Microsoft-Entourage/11.3.3.061214
>Thread-Topic: [LACNIC/Politicas] Reflexiones acerca del PDP
>Thread-Index: AceiRnxKup+29g45Edy3fAAX8sYbNQ==
>X-Authenticated-Sender: jordi.palet at consulintel.es
>X-HashCash: 
>1:20:070529:politicas at lacnic.net::qr2NiZPL9sKc85sQ:000000000000000000000000000000000000000001dVk
>X-MDRemoteIP: 217.126.187.160
>X-Return-Path: jordi.palet at consulintel.es
>X-MDaemon-Deliver-To: politicas at lacnic.net
>X-Spam-Processed: consulintel.es, Wed, 30 May 2007 01:07:24 +0200
>X-MDAV-Processed: consulintel.es, Wed, 30 May 2007 01:07:25 +0200
>X-BeenThere: politicas at lacnic.net
>X-Mailman-Version: 2.1.9
>Precedence: list
>List-Id: LACNIC Policy mailling list <politicas.lacnic.net>
>List-Unsubscribe: 
><https://mail.lacnic.net/mailman/listinfo/politicas>,<mailto:politicas-request at lacnic.net?subject=unsubscribe>
>List-Archive: <http://mail.lacnic.net/pipermail/politicas>
>List-Post: <mailto:politicas at lacnic.net>
>List-Help: <mailto:politicas-request at lacnic.net?subject=help>
>List-Subscribe: 
><https://mail.lacnic.net/mailman/listinfo/politicas>,<mailto:politicas-request at lacnic.net?subject=subscribe>
>Errors-To: politicas-bounces at lacnic.net
>Return-Path: politicas-bounces at lacnic.net
>X-OriginalArrivalTime: 29 May 2007 23:10:24.0229 (UTC) 
>FILETIME=[898A2150:01C7A246]
>
>Idem, sigo debajo.
>
>Saludos,
>Jordi
>
>
>
>
> > De: Nicolás Ruiz <nicolas at ula.ve>
> > Organización: ULA
> > Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> > Fecha: Tue, 29 May 2007 18:24:16 -0400
> > Para: LACNIC Policy mailling list <politicas at lacnic.net>
> > Asunto: Re: [LACNIC/Politicas] Reflexiones acerca del PDP
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Mis comentarios, que ya he repetido, en otros correos. Y perdonen lo
> > largo; como dice el dicho, no he tenido tiempo de hacerlo más corto:
> >
> > JORDI PALET MARTINEZ wrote:
> >> Hola a todos,
> >>
> >> Este correo es un poco largo pero ruego que lo leais atentamente, pues 
>es
> >> muy importante.
> >>
> >> Estoy trabajando en el desarrollo de una propuesta de politica para
> >> modificar el PDP, pues creo que tiene ciertas inconsistencias algunas 
>de las
> >> cuales han quedado patentes en la ultima reunion, asi que me gustaria 
>tener
> >> comentarios al respecto para ultimar la propuesta (algo que, mea culpa,
> >> debiera de haber hecho hace un año para haber intentado buscar consenso 
>en
> >> esta ultima reunion y asi no perder un año completo).
> >>
> >> Voy a utilizar algunos *ejemplos* basados en propuestas discutidas en 
>esta
> >> ultima reunion. Que conste que en NINGUN CASO, estoy discutiendo la 
>bondad
> >> de las propuestas presentadas, es decir, estoy totalmente deacuerdo con 
>la
> >> decision del foro al respecto de los meritos de una propuesta, tanto si 
>ha
> >> sido aceptada como si no, pero no necesariamente estoy deacuerdo con 
>que el
> >> procedimiento se este siguiendo *limpia* y *correctamente* (en parte 
>por
> >> falta de claridad en el mismo, y es lo que intento remediar con esta
> >> iniciativa).
> >>
> >> 1) No queda claro si el consenso se busca SOLO en el foro o se analiza 
>en
> >> consenso conjunto entre la lista y el foro (como es el caso de otras
> >> regiones). Es decir, una propuesta que parece tener consenso en el 
>foro,
> >> puede no tenerlo en la reunion, pero puede ser que el numero de 
>"objeciones"
> >> en la reunion sea muy inferior al numero de "soportes" en la lista. Por
> >> supuesto que se puede dar tambien el caso contrario. Creo que la 
>decision
> >> debe venir determinada por el consenso de ambos, porque muchos 
>participantes
> >> de la lista no necesariamente pueden atender al foro. En otras regiones 
>es
> >> como se mide, no solo por la reunion presencial. En IETF incluso, la 
>lista
> >> pesa mas que la reunion presencial al buscar consenso.
> >
> > De acuerdo en que tenemos que aclararlo. Prefiero que el consenso
> > dependa de la cantidad total de opiniones a favor y en contra, en la
> > cual la última opinion sea la definitiva, es decir, si primero digo en
> > la lista que estoy a favor, luego que estoy en contra y en el foro digo
> > que estoy a favor, cuenta como una opinion a favor (por ser la última
> > expresión). Si el nivel de discusión/aprobación/rechazo en la lista es
> > muy bajo ("muy bajo" queda a juicio del moderador), se trata de alcanzar
> > consenso en el foro.
>
>Si pero la ventaja de aceptar el consenso de la lista como suficiente, es
>que cambios o politicas sin implicaciones y que se evidente que no hay
>oposisicion, podrian avanzar sin esperar a la reunion. Asi es como se hace
>en RIPE NCC.
>
> >
> >> 2) Un año para aprobar una propuesta puede ser un tiempo demasiado 
>largo.
> >> Deberian de articularse otros medios alternativos como por ejemplo:
> >> a) Aprobacion por medio electronico (reunion no presencial)
> >> b) Aprobacion solo por la lista cuando no haya objecciones, 
>especialmente en
> >> el caso de propuestas cuya urgencia sea importante para la region (a
> >> determinacion del moderador ?)
> >> c) Procedimiento de urgencia para politicas que puedan ser 
>indispensables ?
> >
> > De acuerdo. Que tan factible es una reunion presencial adicional? Al
> > menos (a) deberia ser posible.
>
>Supongo que la reunion presencial es una cuestion de recursos para
>organizarla, y recursos de los asistentes para participar. Creo que no 
>seria
>buena idea hasta que la region avance mas en el campo de las politicas y la
>participacion en la lista sea tal que sea evidente que la gente tiene
>interes en una reunion para politicas.
>
> >
> >> 3) Quizas deberia de plantearse la necesidad de que en lugar de un solo
> >> moderador, haya 2-3 (co-moderadores), como en APNIC, RIPE NCC y ARIN 
>(en
> >> AfricNIC tambien se esta modificando el PDP incluyendo este punto). No 
>solo
> >> es una cuestion de que el moderador puede ponerse enfermo o no poder 
>atender
> >> todos los temas rapidamente, sino facilitar su trabajo y la objetividad 
>y
> >> neutralidad (no digo que no sea el caso ahora, pero todo es mejorable), 
>por
> >> ejemplo eligiendo un conjunto de moderadores de diferentes sectores y 
>no
> >> solo de ISPs.
> >
> > Prefiero la idea del moderador/co-chair suplente.
>
>Me he perdido, entendi en tu correo electronico que preferias la otra 
>opcion
>:-)
>
> >
> > Que otros sectores te parecen que deben estar representados?
>
>Por ejemplo, Universidades u otras instituciones que no son "exactamente"
>ISPs, pero son tan grandes que funcionan como ISPs para sus propias
>entidades, ISPs pequeños y grandes (no solo grandes o pequeños), industrias
>relacionadas, etc. En la variedad esta el gusto.
>
>En APNIC y RIPE NCC son 3 co-chairs. En AfriNIC se va a presentar una
>propuesta de cambio del PDP para que sean 2 o 3 (aun no esta decidido), y 
>en
>ARIN es algo equivalente (AC, Advisory Council) que creo que son 13
>miembros.
>
> >
> >> 4) Como medimos el consenso ? Esta claro que no es por mayoria, sino 
>por
> >> falta de un numero importante de objeciones a una determinada 
>propuesta. En
> >> algunos casos puede no haber ninguna objeccion ni comentario, por eso
> >> indicaba antes que en esos casos, especialmente si la politica es 
>necesaria
> >> para asignar un recurso (es decir, hay un "cliente" de la politica), no
> >> parece logico que tenga que esperar hasta un año completo para obtener 
>ese
> >> recurso. Es preciso buscar una definicion lo mas objetiva posible para
> >> evitar diferenciaciones injustas entre diversas propuestas.
> >
> > Para mi no está bien que un consenso deba definirse como falta de
> > objeciones. Entiendo que es una solución tolerable en el caso en que hay
> > poca participación y aquellos que tienen mayor incentivo para elevar su
> > voz son quienes objetan, y en ese caso acepto esa definición de
> > consenso, pero a regañadientes. Prefiero una manifestación explicita a
> > favor de una propuesta (incluso si hay un número importante de 
>objeciones).
>
>Concurro contigo, y asi se pide en RIPE NCC.
>
> >
> >> 5) Las propuestas, antes de llegar al plazo de tiempo de discusion en 
>el
> >> foro presencial, deben de pasar una revision por parte del staff para
> >> indicar posibles fallos, problemas de implementacion, discrepancias con
> >> otras politicas, etc. Esto deberia de realizarse a ser posible en un 
>plazo
> >> maximo de 48 horas habiles tras el envio de la propuesta por parte del
> >> autor(es). Si el staff se demora, y se traspasa el plazo (30 dias) de
> >> presentacion para poder ser incluidas en el foro, dicho plazo deberia 
>de ser
> >> ampliado para que el autor disponga de un minimo de 48 horas 
>adicionales
> >> para una nueva version del texto. Por ejemplo, este ha sido el caso de 
>la
> >> propuesta LAC-2006-08 en la que no se ha podido buscar consenso por una
> >> discrepancia en el texto que solo ha sido informada por el staff en la
> >> propia reunion.
> >
> > Que hacemos en el caso que una propuesta es recibida a tiempo, pero las
> > 96 horas hábiles (48 de revisión del staff + 48 para introducir una
> > versión corregida) terminan a menos de 30 dias del foro? Yo digo que se
> > acepta para ser discutida, incluyendo si hay múltiples iteraciones del
> > staff + reescritura, siempre y cuando el moderador del foro lo considere
> > aceptable.
>
>Mi idea es que estos plazos no corran en contra de la propuesta, es decir,
>que si en lugar de 30 dias de discusion antes de la reunion (o de la 
>llamada
>a consenso si se hace en la lista, como en RIPE), son solo 26 dias, no pasa
>nada.
>
> >
> >> 6) En la reunion se ha indicado que el directorio tenia atribuciones 
>para
> >> modificar "ligeramente" una politica que fuera aprobada por la 
>comunidad.
> >> Creo que si es el caso, esto es muy peligroso y rompe el PDP. Ademas, 
>creo
> >> que es incorrecto, no veo por ningun sitio del PDP actual NINGUN texto 
>que
> >> parezca siquiera indicar esto (si estoy equivocado por favor que
> >> inmediatamente se indique el texto que lo permite). Por otro lado, ese 
>texto
> >> tiene que ser muy claro al respecto de los "limites" de dicha 
>modificacion,
> >> y creo que esto es casi imposible, al menos yo no alcanzo a ver como
> >> hacerlo. Por otro lado, dado que el PDP esta basado en la comunidad, y 
>el
> >> directorio es el organo de direccion de la membresia, y comunidad y
> >> membresia no son lo mismo, creo que esto no es posible, pues seria una 
>clara
> >> inconsistencia entre ambos grupos (en uno participan todos los 
>interesados,
> >> de todo el mundo, y en el otro, solo las entidades con servicios en la
> >> region que pagan sus cuotas). El ejemplo en este caso seria la 
>propuesta
> >> LAC-2007-07, con lo cual esta votacion estaria viciada y habria de ser
> >> declarada nula por el moderador de forma immediata.
> >>
> >> 7) Es imprescindible que llege al foro una sola version de una 
>propuesta o
> >> pueden llegar 2 o mas y ser votadas para ver cual alcanza el consenso ? 
>Esto
> >> esta muy ligado a la decision de si el consenso se busca solo en el 
>foro, o
> >> en la lista y el foro solo lo refrenda, o en ambos. Ejemplo la 
>propuesta
> >> LAC-2007-01, la cual ha llegado viciada al foro, porque los autores de 
>la
> >> idea no contestaron (si no me equivoco) a una propuesta alternativa en
> >> busqueda de consenso entre ambas versiones, y el staff de LACNIC indico 
>a
> >> los autores de la alternativa que se tratarian/presentarian ambas en la
> >> reunion, cosa que sin embargo no fue el caso.
> >
> > Es válido que se presenten múltiples propuestas que colisionen. Se
> > presentan, discuten y se establece un mecanismo para elegir entre todas
> > las competidoras.
>
>Como indique, en ARIN hubo 2 de IPv6 PI, y creo que se hizo una ronda de
>votacion para intentar ver puntos en comun y divergentes y buscar consenso 
>o
>eliminar una de ellas (o ambas).
>
> >
> >> 8) En la reunion se ha indicado que es preciso que un documento del 
>IETF
> >> respalde las politicas. Esto no es correcto, en ningun punto del PDP 
>indica
> >> esto. Ademas, los unicos documentos del IETF que son standards son los 
>STD,
> >> no los RFCs, con lo cual todas las politicas existentes serian nulas, 
>puesto
> >> que todas han sido basadas en RFCs o Internet Drafts. Por ejemplo, la
> >> politica de 4-byte ASN ha sido aceptada (el año anterior), cuando los
> >> documentos eran Internet Drafts. En cambio se ha argumentado que la
> >> propuesta LAC-2007-06. Igualmente, no hay ningun documento del IETF
> >
> > Yo prefiero que solamente se hagan referencias a documentos
> > "archivables". Creo que un internet draft no es archivable porque se
> > espera que se modifiquen antes de alcanzar el status de RFC, STD o BCP o
> > similar.
>
>No sirve, hay muchas politicas que no dependen de IETF, y es dificil 
>decidir
>de antemano, en el proceso, si algo esta "dentro" o fuera del "IETF", 
>porque
>el proceso es bottom-up, y esta comunidad puede decidir dejar algo dentro o
>fuera del IETF. No estamos atados al IETF.
>
>Los draft expirados tambien se archivan, asi que eso no es excusa tampoco.
>
> >
> > Por ejemplo, que pasa si discutimos el draft-ietf-v6ops-nap-06, se
> > aprueba como política y es finalmente el draft-ietf-v6ops-nap-08 el que
> > se convierte en RFC? Hemos definido una política basados en un documento
> > obsoleto.
>
>Por eso en mi documento se hacia referencia a la ultima version :-)
>
> >
> > En la misma medida, las politicas de LACNIC deben ser actualizadas
> > cuando los documentos a los que hacen referencia se vuelven obsoletos
> > por la publicación de una nueva versión.
>
>Perfecto, y cual es el problema ? Ninguno en realidad. Las politicas estan
>sujetas SIEMPRE a ser actualizadas.
>
> >
> >> 9) Manipulacion del proceso. En esta reunion se ha podido producir una
> >> manipulacion del proceso, bajo mi punto de vista en dos casos, que de 
>nuevo
> >> insisto, en este email son solo ejemplos y no la discusion de los casos 
>en
> >> si mismos:
> >> a) LAC-2007-07. Se ha votado bajo la premisa de que el directorio puede
> >> cambiar un parametro. Si fuera el caso que no se puede demostrar que 
>esto
> >> esta documentado de forma precisa, determinante, fehaciente y con 
>antelacion
> >> a la reunion, dado que el voto para buscar consenso se produjo bajo esa
> >> premisa, seria nulo e impugnable de pleno derecho.
> >> b) LAC-2007-06. Se ha manifestado que es imprescindible que haya un 
>RFC,
> >> como se ha indicado antes. Ademas IANA ha dado un mensaje 
>contradictorio al
> >> dado en una reunion con el autor de la propuesta.
> >>
> >> El proceso no solo tiene que ser transparente, sino tambien limpio. 
>Deben de
> >> rechazarse radicalmente las posibles manipulaciones y a sus actores. 
>Por
> >> ejemplo, si en la presentacion de una politica el autor o cualquier de 
>los
> >> participantes, hacen afirmaciones ERRONEAS *acerca de detalles del PDP* 
>(no
> >> de la propuesta), que pueden influenciar y de hecho influencian la 
>busqueda
> >> del consenso, el moderador *tiene* que detener dichas afirmaciones e
> >> informar taxativamente que las mismas no son ciertas, no son relevantes 
>y
> >> *bajo ningun concepto* los presentes tienen que teneralas en cuenta a 
>la
> >> hora de tomar su decision.
> >>
> >> En cualquier caso eso *siempre afecta* a la decision de algunos, porque 
>no
> >> todos los asistentes tienen conocimientos de todos los campos (del 
>propio
> >> PDP, del IETF, etc.), lo cual es dificilmente evitable, asi que quizas 
>es
> >> imprescindible que:
> >> a) Se prohiban estos comentarios y solo puedan ser realizados y 
>clarificados
> >> a traves del moderador bien por correo privado o bien de forma 
>presencial en
> >> la reunion (antes de la discussion de la propuesta en cuestion).
> >> b) Los que hagan dichos comentarios y por tanto manipulen, consciente o
> >> inconscientemente el PDP, deben de ser excluidos del mismo por un 
>periodo de
> >> un año (y si insiten se va multiplicando por dos el plazo de 
>exclusion),
> >> para lo cual se les impide participar en la lista y en la reunion 
>presencial
> >> siguiente. Especialmente cuando es evidente su malintencion, y se 
>genere una
> >> diferencia entre politicas que puedan haber estado en la misma 
>situacion. El
> >> desconocimiento no exime del cumplimiento de las normas y los 
>paritipantes
> >> deben conocerlas, leer el PDP, y en el foro debe de ser presentado y se
> >> deben de explicar las "reglas del juego". Esto es algo que se hace muy 
>bien
> >> en ARIN, por ejemplo.
> >
> > Apoyo el evitar que se manipule el proceso, pero creo que esto es una
> > solución buscando un problema. Prefiero que el moderador/chairs del foro
> > manejen estas situaciones en lugar de reglamentarlo.
>
>El problema es que ya es tarde si se ha producido esa brecha. Mi propuesta
>es simple y funciona, no le veo trabas: Las discusiones relativas a si una
>propuesta esta dentro del PDP o no, deben de consultarse con el moderador
>previa la reunion/busqueda de consenso para evitar sentar cualquier tipo de
>duda.
>
>Nos deja una mayor claridad y transparencia y evita dudas que generen
>suspicacias.
>
> >
> >> Hay que tener en cuenta que las propuestas pasaran a partr de ahora, 
>una
> >> revision del staff y del moderador. Por tanto, por definicion es 
>dificil que
> >> una propuesta pase a ser discutida si no cumple el PDP. Por tanto es 
>aun mas
> >> grave que se de el caso a o b anteriores. Es decir, nadie puede dudar 
>de
> >> aspectos del PDP de una determinada propuesta, al menos no 
>publicamente,
> >> solo con el moderador, de lo contrario, es de suma gravedad la 
>manifiesta
> >> manipulacion.
> >>
> >> 10) Hay otras discrepancias en el proceso del que se nos informa y el
> >> publicado en la web (http://lacnic.net/sp/politicas/desarrollo.html), 
>por
> >> ejemplo, no son 30 dias antes del foro publico, sino 2 semanas (en el 
>texto,
> >> el grafico habla de 30 dias). No se cual es lo correcto, pero esta 
>situacion
> >> debe de ser clarificada bajo mi parecer, por el bien de todos y
> >> especialmente por la transparencia y limpieza del PDP, INMEDIATAMENTE.
> >
> > Yo seria menos estricto, proponemos un nuevo PDP, y luego vemos como lo
> > aprobamos.
> >
> > - --
> > A: Because it destroys the flow of conversation.
> > Q: Why is top posting dumb?
> > - --
> > Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
> >                      | Centro de Cálculo Cientifico ULA
> > nicolas at ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
> > +58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
> > PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.5 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGXKgPmjsZS9ZBxv8RAt3NAJ96mT3l1G/+pVUawtIPReH9yNrBbgCfe+af
> > W8ZrkV47IJWE6lA/DHYhvd8=
> > =orY/
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>
>
>**********************************************
>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.
>
>
>
>_______________________________________________
>Politicas mailing list
>Politicas at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/politicas

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/