[LACNIC/Politicas] (no subject)

Enrique Torres eta at millicomperu.com.pe
Thu Jul 21 15:56:15 BRT 2005 

Si Daniel, seria solo declarar el nombre del beneficiario de la sub delegacion 
manteniendose en reserva todos los datos de contacto relativos a ese 
beneficiario y llenandose los mismos con los datos del ISP propietario del 
bloque.

Si hacemos esto podemos saber quien se beneficia con la sub delegacion del 
bloque y para casos de incidentes que es cuando se deberia usar los datos de 
contacto es el ISP quien actua como un intermediario entre el que Reporta el 
Incidente y el Beneficiario final.

German corrigeme si me equivoco pero creo que la informacion relativa a los 
contactos de a quien sub delegan los bloques los ISP no tiene mayor 
relevancia para LACNIC o la utilizan para algun proceso especifico ?  Solo se 
me ocurre que quiza la podrian utilizar para procesos de validacion de la 
utilizacion de los bloques asignados al ISP cuando este solicita uno nuevo ?

Por otro lado viendolo friamente quiza solo tenga valor para LACNIC la 
informacion relativa a:

- el bloque asignado y su tamaño
- el pais desde el cual se hace la sub delegacion
- el Beneficiario directo por parte de LACNIC del bloque
- status de la sub delegacion

Enrique







> Enrique:
>
> Saludos.
> Por la experiencia de ustedes tu propuesta seria poner solo publico el
> nombre de la entidad a la cual se delego el bloque y todo el resto de la
> información seria referido al ISP..
>
> ejemplo:
>  Copyright LACNIC lacnic.net
> %  The data below is provided for information purposes
> %  and to assist persons in obtaining information about or
> %  related to AS and IP numbers registrations
> %  By submitting a whois query, you agree to use this data
> %  only for lawful purposes.
> %  2005-07-21 14:34:02 (BRT -03:00)
>
> inetnum:     200.55.129.0/25
> status:      reallocated
> owner:       Servicios Empresariales
> ownerid:     CU-SEEM-LACNIC
> responsible: ISP
> address:    Direccion del ISP.
> address:     10600 - Ciudad de la Habana -
> country:     CU
> phone:       +53 7 Phone del ISP []
> owner-c:     DAR
> tech-c:      DAR
> created:     20040420
> changed:     20040420
> inetnum-up:  200.55.128/19
>
> nic-hdl:     DAR
> person:      Daniel Ramos
> e-mail:      infocom at ENET.CU
> address:     Ave Independencia y 19 de Mayo, 0,
> address:     10600 - La Habana -
> country:     CU
> phone:       +53 7 337337 []
> created:     20021011
> changed:     20021209
>
> % whois.lacnic.net accepts only direct match queries.
> % Types of queries are: POCs, ownerid, CIDR blocks, IP
> % and AS numbers.
>
> Sustituyendo los datos del cliente por el del ISP.
>
> Seria bueno ver otras criterios....
>
> Daniel Ramos
>
>
>
> ----- Original Message -----
> From: "Enrique Torres" <eta at millicomperu.com.pe>
> To: <politicas at lacnic.net>
> Sent: Thursday, July 21, 2005 12:26 PM
> Subject: Re: [LACNIC/Politicas] [LAC-TF] Fwd:I-D
> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>
> > El Jue 21 Jul 2005 10:29, Enrique Torres Angeles escribió:
> >> Hola Todos
> >>
> >> Les cuento un poco la experiencia que tuvimos aqui en Peru al respecto
> >> de la confidencialidad de los datos cuando hace unos años comenzamos a
> >> implementar el WHOIS y zonas WHOIS delegadas para alimentar los
> >> registros de ARIN.
> >>
> >> Con respecto a la declaracion de los datos completos en el WHOIS la
> >> problematica que se dio fue la siguiente:
> >>
> >> 1- Utilizacion de la base de datos whois por otros operadores de
> >> telecomunicaciones para atacar la base de clientes internet de la
> >> competencia
> >>
> >> 2- Utilizacion de las bases de datos whois para crear bases de datos de
> >> publicidad o telemercadeo
> >>
> >> 3- Utilizacion en contadas oportunidades para fraudes basandose en la
> >> informacion de la base WHOIS.
> >>
> >>
> >> Contra esta problematica se opto en dos alternativas y creo que son las
> >> que se deben analizar
> >>
> >> 1- Declarar el bloque IP con el nombre de la Organizacion que lo tenia
> >> delegado pero en la seccion de contactos administrativos y tecnicos que
> >> son los datos visibles se publico la informacion del contacto tecnico y
> >> administrativo del ISP que delega el numero.
> >>
> >> Internamente existian datos que no eran mostrados donde estaba la data
> >> real del usuario.
> >>
> >> 2- Tuvimos solo un caso en donde el cliente no quiso que apareciera
> >> ninguna informacion sobre el y se declaro como si el bloque estuviera
> >> utilizado por el ISP y con sus contactos administrativos y tecnicos.
> >>
> >> Cabe mencionar que en este caso fue el que mas complicacion nos creo
> >> porque nos llevo a analizar la opcion de añadir un campo que indique el
> >> Representante y el Beneficiario del bloque a fin de que solo se publique
> >> en el WHOIS los datos del Representante.
> >>
> >>
> >> En conclusion lo que les quiero decir es que este no es un problema
> >> complicado de solucionar es un problema mas que todo del tipo
> >> administrativo que implica adicionar datos al WHOIS algunos de los
> >> cuales no son publicados y definir una opcion al momento de que registra
> >> el usuario los datos en que le permite decidir si quiere mantener los
> >> datos confidenciales o no.
> >>
> >> Es claro que ante los RIR esta opcion no era aplicable era solo
> >> aplicable para declarar la sub delegaciones hechas por el ISP.
> >>
> >>
> >> Saludos,
> >>             Enrique
> >>
> >> > !
> >> > Pues como diria un abogado amigo mio: "desconozco mayormente"!
> >> >
> >> > No que sepa.
> >> >
> >> > Erick
> >> >
> >> > At 09:09 a.m. 20/07/2005, rgaglian at adinet.com.uy wrote:
> >> > >Erik,
> >> > >
> >> > >Sabes si LacTLD esta trabajando en este tema tambien?
> >> > >
> >> > >Roque
> >> > >
> >> > > >-- Mensaje original --
> >> > > >Date: Wed, 20 Jul 2005 01:13:40 -0500
> >> > > >To:
> >> > > > german at lacnic.net,<lactf at lac.ipv6tf.org>,<rgaglian at adinet.com.uy>
> >> > > > From: Erick Iriarte Ahon <faia at amauta.rcp.net.pe>
> >> > > >Subject: Re: [LACNIC/Politicas] [LAC-TF]
> >> > > >  Fwd:I-D      ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> >> > > >Cc: politicas at lacnic.net
> >> > > >
> >> > > >
> >> > > >Hola German.
> >> > > >
> >> > > >>Creo que Roque ha hecho una observacion muy interesante.
> >> > > >> Efectivamente,
> >> > > >
> >> > > >las
> >> > > >
> >> > > >>reasignaciones de un /48 deberan registrarse en el WHOIS asi sea a
> >> > > >> usuarios residenciales por lo que la politica de privacidad que
> >> > > >> se planteo dias
> >> > >
> >> > >atras
> >> > >
> >> > > >>vuelve a resultar interesante analizar.
> >> > > >
> >> > > >Concuerdo con lo que indicas, el punto claro es establecer el dato
> >> > > > del whois hasta que nivel lo queremos llevar?.
> >> > > >
> >> > > >>La decision de implementar o no esquemas de privacidad de datos en
> >> > > >> la base de datos WHOIS de LACNIC es un tema que recae
> >> > > >> directamente en los miembrosde la lista de politicas y asistentes
> >> > > >> al foro publico. Si bien
> >> > > >>
> >> > > >>tiene aristas
> >> > > >>legales la decision de si LACNIC debe implementar una politica
> >> > > >> similar
> >> > >
> >> > >es
> >> > >
> >> > > >de
> >> > > >
> >> > > >>ustedes.
> >> > > >
> >> > > >En general, las aristas legales (y en todos los casos existen las
> >> > > > mismas),
> >> > > >
> >> > > >no deben ser entendidas como "bloqueos" sino como "encaminadores"
> >> > > > dentro de
> >> > > >procesos sociales en los cuales vivimos.
> >> > > >
> >> > > >>  En otras regiones tal como lo menciona Marcelo  el tema de
> >> > > >>privacidad de datos fue resuelto dejando a decision del ISP cuales
> >> > > >>asignaciones de sus clientes serian publicos a traves del WHOIS
> >> > > >> pero en definitiva todas las reasignaciones se registran la
> >> > > >> diferencia es
> >> > >
> >> > > determinar
> >> > >
> >> > > >>si son publicas o no.
> >> > > >
> >> > > >Pero tengamos en cuenta, que en otras regiones (como es el caso
> >> > > > europeo
> >> > >
> >> > >en
> >> > >
> >> > > >particular), esta claramente definido normativas sobre datos
> >> > > >personales/privacidad,  mientras que en nuestra region asi de
> >> > > > explicito
> >> > > >
> >> > > >solo Argentina.
> >> > > >
> >> > > >>La cuestion es determinar si hay una necesidad de un cambio asi y
> >> > > >> si hay quienes lo apoyen
> >> > > >
> >> > > >SIn embargo creo que sera una interesante experiencia el poder
> >> > > > trabajar
> >> > >
> >> > >en
> >> > >
> >> > > >politicas de privacidad en relacion al whois.
> >> > > >
> >> > > >Erick
> >> > > >
> >> > > >>Saludos
> >> > > >>
> >> > > >>  German Valdez
> >> > > >>LACNIC
> >> > > >>Potosi 1517
> >> > > >>Montevideo Uruguay 11500
> >> > > >>http://www.lacnic.net
> >> > > >>Participe en el desarrolo de politicas publicas en LACNIC
> >> > > >>Suscribase en http://lacnic.net/sp/lists.html
> >> > > >>
> >> > > >> > -----Mensaje original-----
> >> > > >> > De: lactf-bounces at lac.ipv6tf.org
> >> > > >> > [mailto:lactf-bounces at lac.ipv6tf.org] En nombre de marcelo
> >> > > >> > bagnulo braun
> >> > > >> > Enviado el: Martes, 19 de Julio de 2005 06:00 a.m.
> >> > > >> > Para: rgaglian at adinet.com.uy
> >> > > >> > CC: lactf at lac.ipv6tf.org; politicas at lacnic.net
> >> > > >> > Asunto: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
> >> > > >> > ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> >> > > >> >
> >> > > >> > Hola Roque,
> >> > > >> >
> >> > > >> > no he seguido muy de cerca este ultimo tema que mencionas,
> >> > > >> > pero creo recordar que en otras regiones solucionaron esto
> >> > > >> > dejando a discrecion del ISP si poner o no en el WHOIS los
> >> > > >> > datos de los clientes finales, por lo que no me queda claro
> >> > > >> > que esto sea un problema grave, pero como dije no estoy muy
> >> > > >> > puesto en esto, asi que si me podes corregir...?
> >> > > >> >
> >> > > >> > saludos, marcelo
> >> > > >> >
> >> > > >> > El 19/07/2005, a las 2:10, rgaglian at adinet.com.uy escribió:
> >> > > >> > > Creo que un punto que no podemos perder desde el punto de
> >> > > >> >
> >> > > >> > vista de los
> >> > > >> >
> >> > > >> > > operadores es que si se mantiene el /48 como unidad de
> >> > > >> >
> >> > > >> > asignación, se
> >> > > >> >
> >> > > >> > > deberá registrar a cada usuario residencial (ADSL, etc) en
> >> > > >> >
> >> > > >> > la base de
> >> > > >> >
> >> > > >> > > datos Whois, con el correspondiente costo administrativo y
> >> > > >> > > con un agravamiento de los problemas de confidencialidad ya
> >> > > >> > > planteados en esta lista.
> >> > > >> > >
> >> > > >> > > Roque
> >> > > >> > >
> >> > > >> > >> -- Mensaje original --
> >> > > >> > >> Cc: lactf at lac.ipv6tf.org, politicas at lacnic.net
> >> > > >> > >> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
> >> > > >> > >> Subject: Re: [LACNIC/Politicas] Fwd:
> >> > > >> > >> I-D       
> >> > > >> > >> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Date:
> >> > > >> > >> Sun, 17 Jul 2005 12:52:02 +0200
> >> > > >> > >> To: rgaglian at adinet.com.uy
> >> > > >> > >>
> >> > > >> > >>
> >> > > >> > >> Hola Roque,
> >> > > >> > >>
> >> > > >> > >> si, a mi me parece un disparate tambien
> >> > > >> > >>
> >> > > >> > >> tener en cuenta que la eficiencia requerida resultante del
> >> > > >> >
> >> > > >> > uso del HD
> >> > > >> >
> >> > > >> > >> ratio para un /19 es de 1,8%!!!!
> >> > > >> > >>
> >> > > >> > >> ademas, en
> >> > > >> >
> >> > > >> > draft-narten-iana-rir-ipv6-considerations-00.txt se lantea
> >> > > >> >
> >> > > >> > >> un ejemplo que me parece ilustrar muy bien tu preocupacion,
> >> > > >> > >> lo transcribo para uds.
> >> > > >> > >>
> >> > > >> > >>
> >> > > >> > >> 4.1.  An example: Cable Modem/DSL Service in US
> >> > > >> > >>
> >> > > >> > >>    In the hallway at a recent ARIN meeting, I was cornered
> >> > > >> >
> >> > > >> > by someone
> >> > > >> >
> >> > > >> > >>    who had done a back-of-the envelope calculation that led
> >> > > >> > >> him to believe the current policies needed adjustment. The
> >> > > >> >
> >> > > >> > argument went
> >> > > >> >
> >> > > >> > >>    like:
> >> > > >> > >>
> >> > > >> > >>       If I assign 4M /48Ç«÷s of IPv6 (one to each cable
> >> > > >> > >> modem on
> >> > >
> >> > >my
> >> > >
> >> > > >> > >>       network), according to the HD-ratio I am justified to
> >> > > >> > >> obtain something around a /20 of IPv6 addresses.  In other
> >> > > >> >
> >> > > >> > words, I am
> >> > > >> >
> >> > > >> > >>       justified in getting 268M /48Ç«÷s even though I am
> >> > > >> >
> >> > > >> > only using
> >> > > >> >
> >> > > >> > >> 4M
> >> > > >> > >>
> >> > > >> > >> of
> >> > > >> > >>       them.  That would be enough for me to assign at least
> >> > > >> > >> two for every household in the US (not just the 19M on my
> >> > > >> > >> network).
> >> > > >> > >>
> >> > > >> > >>       Now if all the cable providers (e.g., Comcast, Cox,
> >> > > >> > >> Adelphia, Cablevision, Time-Warner, etc.) did the same for
> >> > > >> >
> >> > > >> > their networks;
> >> > > >> >
> >> > > >> > >>       and each of the DSL companies made a similar move
> >> > > >> >
> >> > > >> > (SBC, Verizon,
> >> > > >> >
> >> > > >> > >>       Quest, etc.); perhaps we could easily see the
> >> > > >> >
> >> > > >> > broadband market
> >> > > >> >
> >> > > >> > >> in
> >> > > >> > >>       the US alone obtaining some 16 /20Ç«÷s of IPv6 or a
> >> > > >> > >> total of /16.
> >> > > >> > >>       There are only 8192 of those available in the current
> >> > > >> > >> global unicast space of 2001::/3.
> >> > > >> > >>
> >> > > >> > >>       Anyhow, you can see where this might lead...
> >> > > >> > >>
> >> > > >> > >>
> >> > > >> > >> Saludos, marcelo
> >> > > >> > >>
> >> > > >> > >> PD: este tema se esta discutiendo en la lista global-v6
> >> > > >> > >> global-v6 mailing list
> >> > > >> > >> global-v6 at lists.apnic.net
> >> > > >> > >> http://mailman.apnic.net/mailman/listinfo/global-v6
> >> > > >> > >> seria bueno que enviaramos nuestros comentarios ahi, de
> >> > > >> >
> >> > > >> > forma que las
> >> > > >> >
> >> > > >> > >> opiniones del lacnic tambien se tomen en cuenta
> >> > > >> > >>
> >> > > >> > >> El 17/07/2005, a las 6:56, rgaglian at adinet.com.uy escribió:
> >> > > >> > >>> Marcelo,
> >> > > >> > >>>
> >> > > >> > >>> Hace tiempo que queria contestarte este correo con un
> >> > > >> >
> >> > > >> > comentario que
> >> > > >> >
> >> > > >> > >>> he escuchado más de una vez.
> >> > > >> > >>>
> >> > > >> > >>> ¿¿¿Cómo hizo D-Telecom para justificar un /19???
> >> > > >> > >>>
> >> > > >> > >>> No he estudiado mucho las políticas actuales de RIPE pero
> >> > > >> >
> >> > > >> > claramente
> >> > > >> >
> >> > > >> > >>> se desprende del resto de los RIR por estos bloques
> >> > > >> > >>> gigantes de direcciones asignados a algunos proveedores.
> >> > > >> > >>>
> >> > > >> > >>> Un /19 se podría dividir en 539 millones de /48. Es mi
> >> > > >> >
> >> > > >> > impresión que
> >> > > >> >
> >> > > >> > >>> el plan de numeración que utilizaron (y amparados en el
> >> > > >> >
> >> > > >> > RFC vigente)
> >> > > >> >
> >> > > >> > >>> da un
> >> > > >> > >>> /48
> >> > > >> > >>>
> >> > > >> > >>> a
> >> > > >> > >>> cada usuario DSL y A CADA CELULAR.
> >> > > >> > >>>
> >> > > >> > >>> Lo que es interesante es que el draft, a primera vista,
> >> > > >> >
> >> > > >> > no estudia
> >> > > >> >
> >> > > >> > >>> la
> >> > > >> > >>>
> >> > > >> > >>> asignación
> >> > > >> > >>> de direcciones para empresas celulares/moviles.
> >> > > >> > >>>
> >> > > >> > >>> Un abrazo
> >> > > >> > >>>
> >> > > >> > >>> Roque
> >> > > >> > >>>
> >> > > >> > >>>> -- Mensaje original --
> >> > > >> > >>>> To: lactf at lac.ipv6tf.org, politicas at lacnic.net
> >> > > >> > >>>> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
> >> > > >> > >>>> Date: Wed, 13 Jul 2005 11:39:33 +0200
> >> > > >> > >>>> Subject: [LACNIC/Politicas] Fwd: I-D
> >> > > >> > >>>>  ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> >> > > >> > >>>>
> >> > > >> > >>>>
> >> > > >> > >>>> fyi
> >> > > >> > >>>>
> >> > > >> > >>>> Inicio mensaje reenviado:
> >> > > >> > >>>>> De: Internet-Drafts at ietf.org
> >> > > >> > >>>>> Fecha: 12 de julio de 2005 21:50:03 GMT+02:00
> >> > > >> > >>>>> Para: i-d-announce at ietf.org
> >> > > >> > >>>>> Asunto: I-D
> >> > > >> > >>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> >> > > >> > >>>>> Responder a: internet-drafts at ietf.org
> >> > > >> > >>>>>
> >> > > >> > >>>>> A New Internet-Draft is available from the on-line
> >> > > >> >
> >> > > >> > Internet-Drafts
> >> > > >> >
> >> > > >> > >>>>> directories.
> >> > > >> > >>>>>
> >> > > >> > >>>>>
> >> > > >> > >>>>>         Title           : IPv6 Address Allocation to End
> >> > > >> > >>>>> Sites Author(s)       : T. Narten, et al.
> >> > > >> > >>>>>         Filename        :
> >> > > >> >
> >> > > >> > draft-narten-ipv6-3177bis-48boundary-00.txt
> >> > > >> >
> >> > > >> > >>>>>         Pages           : 8
> >> > > >> > >>>>>         Date            : 2005-7-12
> >> > > >> > >>>>>
> >> > > >> > >>>>>    This document revisits the IAB/IESG recommendations on
> >> > > >> > >>>>> the assignment
> >> > > >> > >>>>>    of IPv6 address space to end sites. Specifically, it
> >> > > >> >
> >> > > >> > indicates
> >> > > >> >
> >> > > >> > >>>>> that
> >> > > >> > >>>>>    changing the default end-site assignment for typical
> >> > > >> >
> >> > > >> > home and
> >> > > >> >
> >> > > >> > >>>>> SOHO
> >> > > >> > >>>>>    sites from /48 to /56 is consistent with the goals
> >> > > >> >
> >> > > >> > of IPv6 and
> >> > > >> >
> >> > > >> > >>>>> RFC
> >> > > >> > >>>>>    3177. Although it is for the RIR community to make
> >> > > >> >
> >> > > >> > adjustments
> >> > > >> >
> >> > > >> > >>>>> to
> >> > > >> > >>>>>
> >> > > >> > >>>>> the
> >> > > >> > >>>>>    IPv6 address space allocation and end site
> >> > > >> >
> >> > > >> > assignment policies,
> >> > > >> >
> >> > > >> > >>>>> the
> >> > > >> > >>>>>    IETF community would be comfortable with RIRs changing
> >> > > >> > >>>>> the default
> >> > > >> > >>>>>    assignment size to /56 for smaller end sites. This
> >> > > >> > >>>>> document obsoletes
> >> > > >> > >>>>>    RFC 3177 and reclassifies it as historic.
> >> > > >> > >>>>>
> >> > > >> > >>>>> A URL for this Internet-Draft is:
> >> > > >> > >>>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-317
> >> > > >> > >>>>>7bi s -48boundary-00.txt
> >> > > >> > >>>>>
> >> > > >> > >>>>> To remove yourself from the I-D Announcement list, send
> >> > > >> >
> >> > > >> > a message
> >> > > >> >
> >> > > >> > >>>>> to i-d-announce-request at ietf.org with the word
> >> > > >> >
> >> > > >> > unsubscribe in the
> >> > > >> >
> >> > > >> > >>>>> body
> >> > > >> > >>>>>
> >> > > >> > >>>>> of
> >> > > >> > >>>>>
> >> > > >> > >>>>> the message.
> >> > > >> > >>>>> You can also visit
> >> > > >> > >>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >> > > >> > >>>>> to change your subscription settings.
> >> > > >> > >>>>>
> >> > > >> > >>>>>
> >> > > >> > >>>>> Internet-Drafts are also available by anonymous FTP.
> >> > > >> > >>>>> Login with the username "anonymous" and a password of
> >> > > >> > >>>>> your e-mail address. After logging in, type "cd
> >> > > >> > >>>>> internet-drafts" and then "get
> >> > > >> > >>>>> draft-narten-ipv6-3177bis-48boundary-00.txt".
> >> > > >> > >>>>>
> >> > > >> > >>>>> A list of Internet-Drafts directories can be found in
> >> > > >> > >>>>> http://www.ietf.org/shadow.html or
> >> > > >> > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >> > > >> > >>>>>
> >> > > >> > >>>>>
> >> > > >> > >>>>> Internet-Drafts can also be obtained by e-mail.
> >> > > >> > >>>>>
> >> > > >> > >>>>> Send a message to:
> >> > > >> > >>>>>         mailserv at ietf.org.
> >> > > >> > >>>>> In the body type:
> >> > > >> > >>>>>         "FILE
> >> > > >> > >>>>> /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.
> >> > > >> > >>>>>txt ".
> >> > > >> > >>>>>
> >> > > >> > >>>>> NOTE:   The mail server at ietf.org can return the
> >> > > >> > >>>>> document in MIME-encoded form by using the "mpack"
> >> > > >> > >>>>> utility.
> >> > > >> >
> >> > > >> >  To use this
> >> > > >> >
> >> > > >> > >>>>>         feature, insert the command "ENCODING mime"
> >> > > >> >
> >> > > >> > before the "FILE"
> >> > > >> >
> >> > > >> > >>>>>         command.  To decode the response(s), you will
> >> > > >> >
> >> > > >> > need "munpack" or
> >> > > >> >
> >> > > >> > >>>>>         a MIME-compliant mail reader.  Different
> >> > > >> >
> >> > > >> > MIME-compliant mail
> >> > > >> >
> >> > > >> > >>>>> readers
> >> > > >> > >>>>>         exhibit different behavior, especially when
> >> > > >> > >>>>> dealing with "multipart" MIME messages (i.e. documents
> >> > > >> > >>>>> which
> >> > > >> >
> >> > > >> > have been split
> >> > > >> >
> >> > > >> > >>>>>         up into multiple messages), so check your local
> >> > > >> >
> >> > > >> > documentation on
> >> > > >> >
> >> > > >> > >>>>>         how to manipulate these messages.
> >> > > >> > >>>>>
> >> > > >> > >>>>>
> >> > > >> > >>>>> Below is the data which will enable a MIME compliant
> >> > > >> >
> >> > > >> > mail reader
> >> > > >> >
> >> > > >> > >>>>> implementation to automatically retrieve the ASCII
> >> > > >> >
> >> > > >> > version of the
> >> > > >> >
> >> > > >> > >>>>> Internet-Draft.
> >> > > >> > >>>>> Content-Type: text/plain
> >> > > >> > >>>>> Content-ID: <2005-7-12130012.I-D at ietf.org>
> >> > > >> > >>>>>
> >> > > >> > >>>>> _______________________________________________
> >> > > >> > >>>>> I-D-Announce mailing list
> >> > > >> > >>>>> I-D-Announce at ietf.org
> >> > > >> > >>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> >> > > >> > >>>>
> >> > > >> > >>>> _______________________________________________
> >> > > >> > >>>> Politicas mailing list
> >> > > >> > >>>> Politicas at lacnic.net
> >> > > >> > >>>> http://www.lacnic.net/mailman/listinfo/politicas
> >> > > >> > >>>
> >> > > >> > >>> Ing.Roque Gagliano
> >> > > >> > >>> rgaglian at adinet.com.uy
> >> > > >> > >>>
> >> > > >> > >>>
> >> > > >> > >>> _______________________________________________
> >> > > >> > >>> Politicas mailing list
> >> > > >> > >>> Politicas at lacnic.net
> >> > > >> > >>> http://www.lacnic.net/mailman/listinfo/politicas
> >> > > >> > >
> >> > > >> > > Ing.Roque Gagliano
> >> > > >> > > rgaglian at adinet.com.uy
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > _______________________________________________
> >> > > >> > > Politicas mailing list
> >> > > >> > > Politicas at lacnic.net
> >> > > >> > > http://www.lacnic.net/mailman/listinfo/politicas
> >> > > >> >
> >> > > >> > _______________________________________________
> >> > > >> > LACTF mailing list
> >> > > >> > LACTF at lac.ipv6tf.org
> >> > > >> > http://lacnic.net/mailman/listinfo/lactf
> >> > > >>
> >> > > >>_______________________________________________
> >> > > >>Politicas mailing list
> >> > > >>Politicas at lacnic.net
> >> > > >>http://www.lacnic.net/mailman/listinfo/politicas
> >> > >
> >> > >Ing.Roque Gagliano
> >> > >rgaglian at adinet.com.uy
> >> >
> >> > _______________________________________________
> >> > Politicas mailing list
> >> > Politicas at lacnic.net
> >> > http://www.lacnic.net/mailman/listinfo/politicas
> >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > http://www.lacnic.net/mailman/listinfo/politicas
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 7/20/2005

More information about the Politicas mailing list