[LAC-TF] (no subject)
Ramos
ramos at enet.cu
Thu Jul 21 16:44:33 BRT 2005
Enrique y German
Creo que así cumpliríamos con Lacnic y la privacidad de la cual hablamos. No
se que piensa Jordi al respecto
Saludos Daniel Ramos
----- Original Message -----
From: "Enrique Torres" <eta at millicomperu.com.pe>
To: "Ramos" <ramos at enet.cu>
Cc: <politicas at lacnic.net>
Sent: Thursday, July 21, 2005 2:56 PM
Subject: Re:
> 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
>
>
>
> --
> 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 LACTF
mailing list