[LACNIC/Politicas] New Proposal / Nueva Propuesta / Nova Proposta - LAC-2011-08

Flavio Marcelo fmca at yahoo-inc.com
Fri Aug 26 18:54:23 BRT 2011


Holla Carlos,

Usted estás 100% correcto. El objectivo no es usar el WHOIS para prover 
un canal seguro.

Y si, un "disclaimer" seria bueno para explicar mejor.

Saludos,

Flávio

On 8/25/11 6:38 PM, Carlos Martinez-Cagnazzo wrote:
> Hola Hugo,
>
> <hablando a titulo personal>
>
> Tal como entiendo la politica, en realidad el WHOIS solo tendria
> punteros hacia donde se puede bajar la información validable, y que la
>   fuente autoritativa de los objetos criptográficos sigue siendo el
> repositorio RPKI.
>
> No es el objetivo de la politica (tal como yo la entiendo, le pido a
> Flavio que me corrija en caso contrario), user el WHOIS para proveer
> un canal seguro de donde obtener datos para validar información de
> enrutamiento.
>
> Por otra parte, no me parece mal lo del disclaimer tampoco.
>
> </hablando a titulo personal>
>
> s2
>
> Carlos
>
> 2011/8/25 Hugo Salgado<hsalgado at nic.cl>:
>> Hola.
>> Me preocupa un poco que se utilice un protocolo inseguro como whois
>> para dar información de validez criptográfica. Entiendo que es en
>> un carácter solamente informativo, y que cualquier cliente debiera
>> de todas formas seguir la cadena de validación partiendo de algún
>> certificado raíz que disponga, pero me preocupa que se le empiece a dar
>> una importancia mayor que la que corresponde. El whois actual es
>> fácilmente sujeto a ataques MitM, y la fortaleza de RPKI está en que
>> una información inyectada así sería facilmente detectable.
>>
>> Creo que podría aclararse esto en alguna sección de "disclaimer", en la
>> misma salida del whois.
>>
>> Además, con el mismo sentido de invitar a hacer la validación por
>> parte de cada cliente, sería util incluir la URI del ROA en el
>> repositorio.
>>
>> Saludos,
>>
>> Hugo Salgado
>> NIC Chile - .CL
>>
>> On 08/24/2011 06:21 PM, Flavio Marcelo wrote:
>>> Arturo,
>>>
>>> Gracias por su comentários.
>>>
>>> (comentários abaixo)
>>>
>>> On 8/23/11 11:49 AM, Arturo Servin wrote:
>>>> Ricardo,
>>>>
>>>>           De tu comentario sobre:
>>>>
>>>>           "whois -h whois.lacnic.net 200.7.85/24 AS28001"
>>>>
>>>>           Y la respuesta de whois:
>>>>
>>>>           VALID AS28001 (existe el roa 200.7.85/24 y AS28001)
>>>>>> NOT-FOUND (no existe ningún roa valido para el 200.7.85/24)
>>>>>> INVALID AS28002 (existe un ROA con el bloque 200.7.85/24 pero el
>>>>>> ASN es 28002, como verán el AS del ROA no coincide con el AS de la
>>>>>> consulta)
>>>>
>>>>           Creo que tienes razón en decir que se está mezclando el
>>>> origin-validation con la información autoritaria extraída de los
>>>> certificados y ROAs firmados por LACNIC.
>>>>
>>>>           Quizá debamos quedarnos con queries al prefijo nada más y
>>>> como salida los ROAs válidos para ese prefijo, del ejemplo de Gerardo
>>>> sería:
>>>>
>>>>>> "whois -h whois.lacnic.net 200.7.85/24"
>>>>>> la respuesta debería ser algo como esto:
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>>
>>>>>> ROA1
>>>>>> Origin ASN AS28001
>>>>>> Not valid Before 2011-01-07 02:00:00
>>>>>> Not valid After 2012-08-05 03:00:00
>>>>>> prefix 200.7.85.0/24 (max length /24)
>>>>>>
>>>>>> ROA2
>>>>>> Origin ASN AS28003
>>>>>> Not valid Before 2011-01-07 02:00:00
>>>>>> Not valid After 2012-08-05 03:00:00
>>>>>> prefix 200.7.85.0/24 (max length /24)
>>>>>> .
>>>>>> .
>>>>>> .
>>>
>>> Concordo com o explicado acima. Ficaria mais completo e sem dúvidas.
>>>
>>> Flávio
>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Saludos,
>>>> .as
>>>>
>>>>
>>>> On 23 Aug 2011, at 11:33, Ricardo Patara wrote:
>>>>
>>>>> Hola Gerardo, como estas?
>>>>>
>>>>> Muy buenas las contribuciones, pero tengo algunos comentários a
>>>>> continuación:
>>>>>
>>>>> On Tue, 2011-08-23 at 10:08 -0300, Gerardo Rada wrote:
>>>>>> Hola a todos me incorporé un poco tarde a la discusión, disculpas por
>>>>>> eso :)
>>>>>> Me parece muy interesante esta propuesta mi aporte es el siguiente:
>>>>>>
>>>>>> El 23/08/11 09:25, Ricardo Patara escribió:
>>>>>>> Olá Flávio. Tudo bem por aqui.
>>>>>>>
>>>>>>> Comentários abaixo.
>>>>>>>
>>>>>>>> On 8/16/11 10:31 AM, Ricardo Patara wrote:
>>>>>>>>> Flávio. Tudo bem?
>>>>>>>>>
>>>>>>>>> Imagino que o objetivo principal dessa implementação seria
>>>>>>>>> informativo,
>>>>>>>>> correto?
>>>>>>>> Sim. Correto. Seria inserir no Whois essa informação.
>>>>>>> ok.
>>>>>>>
>>>>>>>>> Tentei ver outros aspectos e implicações da proposta e me veio as
>>>>>>>>> seguintes dúvidas:
>>>>>>>>>
>>>>>>>>> - que passaria se o EE certificate que assinou a ROA expira ou é
>>>>>>>>> revocado? Deve-se publicar a informação no Remark e indicar como
>>>>>>>>> "invalido", ou se deixa de publicar tal informação?
>>>>>>>> Sugiro colocar como inválido. É melhor colocar uma informação para
>>>>>>>> facilitar a automatização da verificação dessa informação.
>>>>>> Como yo lo entiendo esta información debe ser consultada de los
>>>>>> repositorios
>>>>>> públicos de las CAs, así que en este caso si el EE de un ROA esta
>>>>>> vencido o revocado
>>>>>> ese ROA no se publica mas, así que el estado de esa consulta debería
>>>>>> ser NOT-FOUND.
>>>>>>
>>>>>> Estaría bueno colocar ese estado porque es coherente con la
>>>>>> siguiente propuesta.
>>>>>> Incluir en el whois consultas de este tipo
>>>>>>
>>>>>> "whois -h whois.lacnic.net 200.7.85/24 AS28001"
>>>>>
>>>>> de acuerdo a lo que sugeris, implica un cambio en el whois de lacnic,
>>>>> pues el formato de consulta en tu ejemplo no es acepto actualmente.
>>>>>
>>>>>
>>>>>
>>>>>> y el whois debe responder
>>>>>> VALID AS28001 (existe el roa 200.7.85/24 y AS28001)
>>>>>> NOT-FOUND (no existe ningún roa valido para el 200.7.85/24)
>>>>>> INVALID AS28002 (existe un ROA con el bloque 200.7.85/24 pero el
>>>>>> ASN es 28002, como verán el AS del ROA no coincide con el AS de la
>>>>>> consulta)
>>>>>
>>>>> y aqui me preocupa un poco lo que se propone para información en el
>>>>> whois con la validación de rutas a ejecutada por ruteadores o caches.
>>>>>
>>>>> Los terminos VALID, NOT FOUND, INVALID son los que se proponen en la
>>>>> validación de rutas.
>>>>>
>>>>> Una consulta que de INVALID, por ejemplo, asume que el usuario buscó por
>>>>> un bloque IP y ASN.
>>>>>
>>>>> Saludos
>>>>> Ricardo
>>>>>
>>>>>>> ok. me parece melhor assim, em especial se anteriormente havia a
>>>>>>> informação e era válida.
>>>>>>>
>>>>>>>>> - que passa se para o bloco consultado houver mais de uma ROA
>>>>>>>>> válida?
>>>>>>>> Estou tentando visualizar essa situação, mas estou na dúvida se estou
>>>>>>>> entendendo mesmo a sua pergunta. Você poderia dar mais detalhes dessa
>>>>>>>> situação?
>>>>>> Con ejemplos: Asumimos que el bloque 200.7.85/24 tienen 2 ROAs uno
>>>>>> con el AS28001 y otro con AS28003 si la consulta es
>>>>>>
>>>>>>
>>>>>> "whois -h whois.lacnic.net 200.7.85/24"
>>>>>> la respuesta debería ser algo como esto:
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>>
>>>>>> ROA1
>>>>>> Origin ASN AS28001
>>>>>> Not valid Before 2011-01-07 02:00:00
>>>>>> Not valid After 2012-08-05 03:00:00
>>>>>> prefix 200.7.85.0/24 (max length /24)
>>>>>>
>>>>>> ROA2
>>>>>> Origin ASN AS28003
>>>>>> Not valid Before 2011-01-07 02:00:00
>>>>>> Not valid After 2012-08-05 03:00:00
>>>>>> prefix 200.7.85.0/24 (max length /24)
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>>
>>>>>>
>>>>>> Si la consulta es "whois -h whois.lacnic.net 200.7.85/24 AS28001"
>>>>>> Respuesta: VALID AS28001
>>>>>>
>>>>>>
>>>>>> Si la consulta es "whois -h whois.lacnic.net 200.7.85/24 AS28003"
>>>>>> Respuesta: VALID AS28003
>>>>>>
>>>>>> Si la consulta es "whois -h whois.lacnic.net 200.7.85/24 AS28666"
>>>>>> Respuesta: INVALID. AS authorized AS28001, AS28003
>>>>>>
>>>>>>
>>>>>> Resumen:
>>>>>> Siempre que haya AL MENOS UN ROA que cubra el bloque y el AS
>>>>>> consultado coincide, la respuesta VALID.
>>>>>> Si el bloque esta cubierto, pero el ASN no coincide, la respuesta es
>>>>>> INVALID.
>>>>>> Si no se encuentra el bloque en algún ROA, la respuesta es NOT-FOUND
>>>>>>
>>>>>>
>>>>>>> de acordo com a especificação, um mesmo bloco pode ter várias ROAs.
>>>>>>> Vamos supor o caso (não muito comum, mas tecnicamente possível), de
>>>>>>> uma
>>>>>>> organização com bloco IP a ser anunciado por dois ou mais ASs
>>>>>>> distintos
>>>>>>> (multiplos upstreams).
>>>>>>> No caso que o administrador da rede dessa organização tenha um
>>>>>>> certificado RPKI para o bloco, ele geraria múltiplas ROAs para o bloco
>>>>>>> em questão. Cada uma autorizando um ASN diferente como origem.
>>>>>>>
>>>>>>> E a razão da pergunta é para ver se não seria melhor ao invés de
>>>>>>> publicar a ROA, publicar a URL do ponto de publicação do material
>>>>>>> desse
>>>>>>> Certificado.
>>>>>>>
>>>>>>> sds
>>>>>>> Ricardo Patara
>>>>>>>
>>>>>>>> Flávio
>>>>>>>>
>>>>>>>>> Sds
>>>>>>>>> Ricardo Patara
>>>>>>>>>
>>>>>>>>> On Mon, 2011-08-15 at 19:21 -0300, Flavio Marcelo wrote:
>>>>>>>>>> Arturo,
>>>>>>>>>>
>>>>>>>>>> Concordo.
>>>>>>>>>>
>>>>>>>>>> A validade é do ROA e a listagem é do conteúdo do ROA que
>>>>>>>>>> "match" o prefixo.
>>>>>>>>>>
>>>>>>>>>> Flávio
>>>>>>>>>>
>>>>>>>>>> On 8/11/11 2:21 PM, Arturo Servin wrote:
>>>>>>>>>>>           Una nota con la validez que se pondría.
>>>>>>>>>>>
>>>>>>>>>>>           Sería la validez del ROA, no del anuncio (esto se hace
>>>>>>>>>>> en los routers).
>>>>>>>>>>>
>>>>>>>>>>>           En el caso del ROA se valida que efectivamente venga
>>>>>>>>>>> firmado por las entidades correspondientes con la cadena de
>>>>>>>>>>> confianza.
>>>>>>>>>>>
>>>>>>>>>>>           De lo que pregunta Ricardo supongo que sería listar el
>>>>>>>>>>> contenido del ROA con el que el prefijo del query hace match.
>>>>>>>>>>>
>>>>>>>>>>>           Por ejemplo: whois -h whois.lacnic.net 200.7.87.0/24
>>>>>>>>>>>
>>>>>>>>>>> inetnum:     200.7.86/23
>>>>>>>>>>> status:      assigned
>>>>>>>>>>> owner:       LACNIC - Latin American and Caribbean IP address
>>>>>>>>>>> ownerid:     UY-LACN-LACNIC
>>>>>>>>>>>
>>>>>>>>>>> etc …
>>>>>>>>>>>
>>>>>>>>>>> remark: ROA
>>>>>>>>>>> remark: Origin ASN AS28001
>>>>>>>>>>> remark: Not valid Before 2011-01-07 02:00:00
>>>>>>>>>>> remark: Not valid After 2012-08-05 03:00:00
>>>>>>>>>>> remark: prefix 200.7.86.0/23 (max length /24)
>>>>>>>>>>> remark: prefix 2001:13c7:7012::/47 (max length /47)
>>>>>>>>>>> remark: prefix 200.3.12.0/22 (max length /24)
>>>>>>>>>>> remark: prefix 2001:13c7:7002::/48 (max length /48)
>>>>>>>>>>>
>>>>>>>>>>> Saludos,
>>>>>>>>>>> .as
>>>>>>>>>>>
>>>>>>>>>>> On 11 Aug 2011, at 06:19, Ricardo Patara wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Flavio,
>>>>>>>>>>>> Me parece uma proposta muito interessante, mas tenho algumas
>>>>>>>>>>>> dúvidas:
>>>>>>>>>>>>
>>>>>>>>>>>> - a ideia é mostrar a ROA em seu formato "blob" na saída do
>>>>>>>>>>>> whois, ou um
>>>>>>>>>>>> resumo legível da mesma (ASN origem, bloco, prefixo máximo
>>>>>>>>>>>> permitido) e
>>>>>>>>>>>> sua "validez" ?
>>>>>>>>>>>>
>>>>>>>>>>>> - o whois deverá mostrar essa informação para o bloco exatamente
>>>>>>>>>>>> consultado ou caso bloco mais/menos específico tenha ROA
>>>>>>>>>>>> mostrar então
>>>>>>>>>>>> essa informação.
>>>>>>>>>>>>
>>>>>>>>>>>> Abraços
>>>>>>>>>>>> --
>>>>>>>>>>>> Ricardo Patara
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> DADOS DOS AUTORES:
>>>>>>>>>>>> Nome:  Flavio Marcelo Amaral
>>>>>>>>>>>> eMail:   fmca at yahoo-inc.com
>>>>>>>>>>>> Organização: Yahoo! Brasil Internet LTDA
>>>>>>>>>>>>
>>>>>>>>>>>> DADOS da PROPOSTA:
>>>>>>>>>>>> Título da Proposta:  Inclusão de informações do ROA no whois
>>>>>>>>>>>> quando a mesma estiver disponível
>>>>>>>>>>>> Tipo de Proposta: LACNIC
>>>>>>>>>>>> Id: LAC-2011-08
>>>>>>>>>>>>
>>>>>>>>>>>> RESUMO DA PROPOSTA:
>>>>>>>>>>>> Inclusão de informações de ROAs (Route Origin Authorization)
>>>>>>>>>>>> responsáveis por um prefixo nas informações de WHOIS de todos os
>>>>>>>>>>>> prefixos recebidos pelo LACNIC.
>>>>>>>>>>>>
>>>>>>>>>>>> JUSTIFICAÇÃO:
>>>>>>>>>>>> A proposta visa ajudar a identificar e validar a origem dos
>>>>>>>>>>>> prefixos.
>>>>>>>>>>>>
>>>>>>>>>>>> TEXTO DA PROPOSTA:
>>>>>>>>>>>> Visando a autenticação de prefixos utilizados na nossa região,
>>>>>>>>>>>> sugiro
>>>>>>>>>>>> a inclusão obrigatória de de informações de ROAs (Route Origin
>>>>>>>>>>>> Authorization) nas informações de WHOIS de todos os prefixos
>>>>>>>>>>>> recebidos do LACNIC. Nas situações onde essa informação não
>>>>>>>>>>>> estiver
>>>>>>>>>>>> especificada, a resposta do WHOIS deve indicar o fato.
>>>>>>>>>>>> O campo remarks deve conter informações sobre el prefixo de como
>>>>>>>>>>>> ele é exportado (tamanho máximo).
>>>>>>>>>>>> Isso ajudaria em ferramentas e em verificações de propriedades de
>>>>>>>>>>>> prefixos.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 2011-08-10 at 13:40 -0300, Sofia Silva wrote:
>>>>>>>>>>>>> Dear Policy-list Members,
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is a new Policy Proposal; it was assigned the number
>>>>>>>>>>>>> 2011-08:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [LAC-2011-08] Including ROA data in the Whois database when
>>>>>>>>>>>>> available
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://lacnic.net/documentos/politicas/LAC-2011-08-EN.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your comments are welcome.
>>>>>>>>>>>>> =====================================================================
>>>>>>>>>>>>>
>>>>>>>>>>>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Se recibió una nueva propuesta de Política; se le asignó el
>>>>>>>>>>>>> número 2011-08:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [LAC-2011-08] Inclusión de datos de los ROA en el whois
>>>>>>>>>>>>> cuando estuviera
>>>>>>>>>>>>> disponible
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://lacnic.net/documentos/politicas/LAC-2011-08-SP.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> Esperamos sus comentarios.
>>>>>>>>>>>>> =====================================================================
>>>>>>>>>>>>>
>>>>>>>>>>>>> Prezados membros da lista políticas do LACNIC,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Se recebeu a seguinte proposta de Política se lhe designo o
>>>>>>>>>>>>> numero 2011-08:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [LAC-2011-08] Inclusão de informações do ROA no whois quando
>>>>>>>>>>>>> a mesma
>>>>>>>>>>>>> estiver disponível
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://lacnic.net/documentos/politicas/LAC-2011-08-PT.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> Esperamos seus comentários.
>>>>>>>>>>>>> =====================================================================
>>>>>>>>>>>>>
>>>>>>>>>>>>> AUTHOR DATA:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Name: Flavio Marcelo Amaral
>>>>>>>>>>>>> Email: fmca at yahoo-inc.com
>>>>>>>>>>>>> Organization: Yahoo! Brasil Internet LTDA
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PROPOSAL DATA:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Policy Proposal Title: Including ROA data in the Whois
>>>>>>>>>>>>> database when
>>>>>>>>>>>>> available
>>>>>>>>>>>>>
>>>>>>>>>>>>> Policy Proposal Type: LACNIC
>>>>>>>>>>>>>
>>>>>>>>>>>>> Id: LAC-2011-08
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Proposal Summary:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Including data of the ROAs (Route Origin Authorizations)
>>>>>>>>>>>>> covering a
>>>>>>>>>>>>> prefix as part of the WHOIS data of all prefixes received
>>>>>>>>>>>>> from LACNIC.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Rationale:
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proposal seeks to help identify and validate prefix origins.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Proposal Text:
>>>>>>>>>>>>>
>>>>>>>>>>>>> With the purpose of authenticating the prefixes used in our
>>>>>>>>>>>>> region, we
>>>>>>>>>>>>> suggest the mandatory inclusion of ROA (Route Origin
>>>>>>>>>>>>> Authorization) data
>>>>>>>>>>>>> as part of the WHOIS data of all prefixes received from
>>>>>>>>>>>>> LACNIC. If this
>>>>>>>>>>>>> information is not available, the WHOIS response shall
>>>>>>>>>>>>> explicitly state
>>>>>>>>>>>>> this fact.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The remarks field should contain information about the prefix
>>>>>>>>>>>>> and how it
>>>>>>>>>>>>> is exported (maximum size).
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would help tools verify prefix properties.
>>>>>>>>>>>>> =====================================================================
>>>>>>>>>>>>>
>>>>>>>>>>>>> DATOS DE LOS AUTORES:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nombre: Flavio Marcelo Amaral
>>>>>>>>>>>>> Email: fmca at yahoo-inc.com
>>>>>>>>>>>>> Organización: Yahoo! Brasil Internet LTDA
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> DATOS de la PROPUESTA:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Título de la Propuesta: Inclusión de datos de los ROA en el
>>>>>>>>>>>>> whois cuando
>>>>>>>>>>>>> estuviera disponible
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tipo de Propuesta: LACNIC
>>>>>>>>>>>>>
>>>>>>>>>>>>> Id: LAC-2011-08
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Resumen de la Propuesta:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Inclusión de datos de los ROA (Route Origin Authorization)
>>>>>>>>>>>>> responsables
>>>>>>>>>>>>> por un prefijo en los datos del WHOIS de todos los prefijos
>>>>>>>>>>>>> recibidos de
>>>>>>>>>>>>> LACNIC.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Justificación:
>>>>>>>>>>>>>
>>>>>>>>>>>>> La propuesta busca ayudar a identificar y validar el origen
>>>>>>>>>>>>> de los prefijos.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Texto de la Propuesta:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Con el objetivo de autenticar los prefijos utilizados en
>>>>>>>>>>>>> nuestra región,
>>>>>>>>>>>>> se sugiere la inclusión obligatoria de datos de los ROA
>>>>>>>>>>>>> (Route Origin
>>>>>>>>>>>>> Authorization) en las informaciones de WHOIS de todos los
>>>>>>>>>>>>> prefijos
>>>>>>>>>>>>> recibidos de LACNIC. En las situaciones en las que esta
>>>>>>>>>>>>> información no
>>>>>>>>>>>>> estuviera especificada, la respuesta del WHOIS deberá indicar
>>>>>>>>>>>>> ese hecho.
>>>>>>>>>>>>>
>>>>>>>>>>>>> El campo remarks debe contener datos sobre el prefijo y sobre
>>>>>>>>>>>>> cómo el
>>>>>>>>>>>>> mismo es exportado (tamaño máximo).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Esto ayudaría a las herramientas a verificar las propiedades
>>>>>>>>>>>>> de los
>>>>>>>>>>>>> prefijos.
>>>>>>>>>>>>> =====================================================================
>>>>>>>>>>>>>
>>>>>>>>>>>>> DADOS DOS AUTORES:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nome:  Flavio Marcelo Amaral
>>>>>>>>>>>>> eMail:   fmca at yahoo-inc.com
>>>>>>>>>>>>> Organização: Yahoo! Brasil Internet LTDA
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> DADOS da PROPOSTA:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Título da Proposta:  Inclusão de informações do ROA no whois
>>>>>>>>>>>>> quando a
>>>>>>>>>>>>> mesma estiver disponível
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tipo de Proposta: LACNIC
>>>>>>>>>>>>>
>>>>>>>>>>>>> Id: LAC-2011-08
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Resumo da Proposta:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Inclusão de informações de ROAs (Route Origin Authorization)
>>>>>>>>>>>>> responsáveis por um prefixo nas informações de WHOIS de todos os
>>>>>>>>>>>>> prefixos recebidos pelo LACNIC.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Justificação:
>>>>>>>>>>>>>
>>>>>>>>>>>>> A proposta visa ajudar a identificar e validar a origem dos
>>>>>>>>>>>>> prefixos.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Texto da Proposta:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Visando a autenticação de prefixos utilizados na nossa
>>>>>>>>>>>>> região, sugiro a
>>>>>>>>>>>>> inclusão obrigatória de de informações de ROAs (Route Origin
>>>>>>>>>>>>> Authorization) nas informações de WHOIS de todos os prefixos
>>>>>>>>>>>>> recebidos
>>>>>>>>>>>>> do LACNIC. Nas situações onde essa informação não estiver
>>>>>>>>>>>>> especificada,
>>>>>>>>>>>>> a resposta do WHOIS deve indicar o fato.
>>>>>>>>>>>>>
>>>>>>>>>>>>> O campo remarks deve conter informações sobre el prefixo de
>>>>>>>>>>>>> como ele é
>>>>>>>>>>>>> exportado (tamanho máximo).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Isso ajudaria em ferramentas e em verificações de
>>>>>>>>>>>>> propriedades de prefixos.
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> _______________________________________________
>>>>>>>>> Politicas mailing list
>>>>>>>>> Politicas at lacnic.net
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>> _______________________________________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gerardo Rada.
>>>>>> Ingeniero de software
>>>>>> LACNIC - http://www.lacnic.net
>>>>>
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>
>
>
> --
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =========================
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas

-- 
--
Flavio
Amaral

operations engineer - yahoo! brasil

Yahoo! Messenger ID: flavio_marcelo - "Once a man starts moving he can 
not be sure of his end" - Kingdom of Heaven
GPG - Key fingerprint = 9FE0 1B34 34BA C3CE F68F 3BAE AC81 ED20 DA29 7BF6

fmca at yahoo-inc.com
direct +55-11-3046-5470

r fidencio ramos 195 - 12o andar, sao paulo, 04551-010, br
phone +55-11-3054-5200    fax +55-11-3054-5470



More information about the Politicas mailing list