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

[Pedro Torres]

Nicolas,

Concordo que poderíamos tratar de maneira separada. Porém, como se
trata da mesma seção, não gostaria de gerar um relação de dependência.
Por enquanto vou considerar alguma modificação que contemple apenas um
pedido de alteração de poltítica. Caso observe falta de consenso,
poderei quebrar em duas.

Ainda não está claro para mim por que devemos manter separados
usuários finais multiprovedor e não-multiprovedor. Sinto que falta uma
justificava.

A justificativa para tratemos iguais é que não devemos dificultar a
alocação de um bloco IPv4. Por que para não-multiprovedor o bloco
justificado precisa ser maior? E se o usuário final não tiver isso
alocado do seu ISP por problema de sobre preço devido a excasses?

Dificultar a alocação de bloco IPv4 quando se pode justificar, mas não
se tem alocado de ISP só prejudica o desenvolvimento da Internet,
possivelmente aumentando o uso de NAT. Eu vou insitir um pouco mais em
remover as frases com "Contar con" da política. O que acham?

Ainda estou procurando a justificativa de manter separado
não-multiprovedor e multiprovedor. Me ajudem.
Qual seria o tamanho apropriado para não-multiprovedor e multiprovedor?

PS: Eu não acho que está explicito em "necessidade de interconexão" a
obrigatoriedade de ser "multi-provedor". Seria menos ambiguo na
política atual se estivesse escrito: Se o solicitante for um usuário
final multiprovedor ou tiver necessidades de *Interconexão com mais de
um provedor ou pontos de troca de tráfego*. Em 2.3.3.3 está bem
aplicado a frase.

--
Pedro

2011/10/7 Nicolas Antoniello <nantoniello at gmail.com>:
> Estimados,
>
> Planteo la posibilidad para que la evalúen, de separar en 2 políticas: una
> que resuelva sobre la justificación del 25% (sin mencionar ni requerir nada
> sobre multiproveedor o no) y la otra política que resuelva sobre el asunto
> de ser o no multiproveedor.
>
> De esa forma atacaríamos los problemas por separado, podemos fácilmente
> lograr consenso en una de ellas y pasar a discutir en profundidad la otra.
>
> Que opinan los autores y el resto de la lista?
>
> Saludos,
> Nicolas
>
> co-Chair LACNIC PPF
>
>
>
> 2011/10/7 ALEJANDRO GUZMAN GIRALDO <aguzman at internexa.com>
>
>> Concuerdo con Christian y con lo expresado con Ricardo Patara en el foro
>> Público.
>>
>> Creo que equiparar la condición que era "irregular" está bien, pero la
>> condición de multiproveedor o "con necesidades de interconexión" aprobado en
>> el último año debe permanecer.
>>
>> Saludos
>>
>> Alejandro Guzmán G.
>> Especialista de Línea de Negocios IP
>> IP Business Line Specialist
>> aguzman at internexa.com
>> Medellín, Colombia
>> T: +57(4) 3157580
>> M: +57 (314) 6162930
>>
>>
>>
>> Este mensaje es para uso exclusivo de su destinatario intencional.
>> Cualquier uso de la información contenida en este mensaje sin la aprobación
>> expresa de INTERNEXA constituye una violación de la propiedad intelectual.
>> Hemos realizado las verificaciones requeridas para que este mensaje no
>> contenga virus ni otros defectos. No obstante, es necesario que el
>> destinatario igualmente efectúe esta revisión. INTERNEXA no se hace
>> responsable por daños derivados del uso de este mensaje y/o sus anexos.
>>
>>
>>
>>
>> -----Mensaje original-----
>> De: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] En
>> nombre de Christian O'Flaherty
>> Enviado el: viernes, 07 de octubre de 2011 04:02 p.m.
>> Para: Lista para discusion de politicas de la comunidad de LACNIC
>> Asunto: Re: [LACNIC/Politicas] New Proposal / Nueva Propuesta / Nova
>> Proposta - LAC-2011-09
>>
>> Antes de hacer mi comentario tengo que disculparme por no haber hecho el
>> comentario en la lista cuando la politica fue enviada. Tenemos que mejorar
>> el PDP para evitar esto...
>>
>> Me parece correcto premitir una asignacion justificando el 25% en uso pero
>> considero necesario mantener la condicion de "multiproveedor o necesidades
>> de interconexion" para las asignaciones de un /24 (pequenas).
>>
>> Para bloques mayores, cuando tenga en uso un /24 completo, podriamos
>> permitir la asignacion de un /22.
>>
>> Christian
>>
>>
>> 2011/10/7 Pedro Torres <torres at pop-pr.rnp.br>:
>> > Olá,
>> >
>> > Gostaria que os comentários feitos no Fórum Publico possam ser
>> > colocados aqui pois não compreendi todos muito bem. Não pude estar
>> > presente no Forum e o acompanhamento remoto não foi fácil.
>> >
>> > Obrigado,
>> > Pedro
>> >
>> >
>> > 2011/9/6 Max Larson Henry <maxlarson.henry at transversal.ht>:
>> >> Prezados membros da lista políticas do LACNIC,
>> >>
>> >> Se recebeu a seguinte proposta de Política se lhe designo o numero
>> 2011-09:
>> >> [LAC-2011-09] Modificação dos requerimentos para solicitação
>> >> inicial de endereçamento IPv4 para Usuários Finais
>> >>
>> >> http://lacnic.net/documentos/politicas/lac-2011-09.pdf
>> >>
>> >> Esperamos seus comentários.
>> >>
>> >> Nicolás Antoniello
>> >> Max Larson Henry
>> >> Moderadores do Foro Público de Políticas - LACNIC
>> >> ==============================================================
>> >>
>> >> INFORMAÇÃO DO AUTORES:
>> >>
>> >> Nome - eMail - Telefone - Organização Pedro R Torres Jr -
>> >> torres at pop-pr.rnp.br - +554199177753 - UFPR e RNP/PoP-PR
>> >>
>> >> DADOS DO PROPOSTA:
>> >>
>> >> Titulo da Proposta: Modificação dos requerimentos para
>> >> solicitação inicial de endereçamento IPv4 para Usuários Finais
>> >> Tipo de Proposta: LACNIC Id: LAC-2011-09
>> >>
>> >> Versão: 1
>> >>
>> >> Proposal Summary: Esta proposta tem a intenção de homogeneizar a
>> >> subseção 2.3.3.4.3 do Manual de Políticas do LACNIC, sem deixar de
>> >> lado as qualificações necessárias do bloco IPv4 que está sendo
>> >> solicitado. Um novo texto modifica essa subseção de tal maneira que
>> >> não se faça distinção entre Usuários Finais Multiprovedor e Não
>> >> Multiprovedor e remove a necessidade de qua lificação baseado em
>> >> alocação(ões) de ISP(s) já existente(s).
>> >>
>> >> Rationale: Atualmente o texto da subseção 2.3.3.4.3, que se refere
>> >> ao Status do Solicitante para designações iniciais para Usuários
>> >> Finais, impõe requisitos não necessários. Um exemplo é para um
>> >> Usuário Final Multiprovedor, com necessidade de um /24. Segundo o
>> >> subseção 2.3.3.4.2 este deve estar utilizando 25% do bloco
>> >> solicitado, ou seja 64 endereços IP. Por outro lado, a subseção
>> >> 2.3.3.4.3 exige que esse Usuário Final já conte com um /25 (128
>> >> endereços IP) designado pelo seu provedor de serviço.
>> >>
>> >> Atualmente também se faz uma distinção pouco necessária entre
>> >> Usuários Finais Multiprovedor e Não Multiprovedor, impondo tamanhos
>> >> mínimos de designação distintos para cada categoria. Um agravante
>> >> nas designações feitas por um ISP a Usuários Finais é o
>> >> esgotamento de endereços IPv4. Desta forma, a cada dia, torna-se
>> >> mais difícil obter uma designação de um /25 (para Mu ltiprovedor)
>> >> ou 8 /24 (para Não Multiprovedor), ainda que
>> >>
>> >> exista uma justificativa válida para se ter este endereçamento.
>> >>
>> >> Outra exigência que por vezes é difícil de se cumprir e ser
>> >> Usuário Final Multiprovedor. Devido a falta de opção em contratar
>> >> dois ou mais provedores em algum local da nossa região, isso acaba
>> >> redirecionando um Usuário Final a ter que justificar um /20, de
>> >> acordo com o texto atual da subseção 2.3.3.4.3 para designações para
>> Não Multiprovedor.
>> >>
>> >> Prós do autor: - Resolve o problema em que algum ISP se recusa a
>> >> designar mais endereços IP para um Usuário Final ou cobra muito
>> >> caro por isso. O staff do LACNIC pode se esforçar para atender essa
>> >> demanda de Usuários Finais utilizando pequenos espaços de
>> >> endereçamento disponíveis no pool. - Não força um Usuário Final
>> >> a ter que justificar um /20, mesmo quando necessita de menos endereços.
>> >>
>> >> Contras do autor: Pequenas designações impactam diretamente no
>> >> tamanho da tabela de roteamento (ainda que esse aumento já venha
>> >> ocorrendo devido a tentativa de se fazer balanceamento de tráfego em
>> >> pequenos blocos que carregam muita quantidade de tráfego devido ao
>> >> uso intenso de NAT).
>> >>
>> >> Proposal Text: 2.3.3.4.3. Requerimentos do Solicitante. O tamanho da
>> >> designação mínima de endereços IPv4 para um Usuário Final é de
>> >> um bloco / 24.
>> >>
>> >> Para qualificar a designação de um bloco
>> >> IPv4 inicial, o Usuário Final deverá: - Justificar a já
>> >> utilização de endereços de acordo com a subseção 2.3.3.4.2 ou a
>> >> necessidade imediata. - Concordar em devolver todos os blocos
>> >> designados por seu(s) ISP(s), caso exista. Se o Usuário Final tiver
>> >> recebido a(s) designação(ões) de seu(s)
>> >> ISP(s) equivalente a um bloco / 25 ou menos, deverá devolver em um
>> >> prazo de até 3 meses. No caso de que a(s) designação(ões) por
>> >> parte de seu(s)
>> >> provedore(s) seja(m) superior(es) a um bloco /25, a
>> >>
>> >> devolução deverá ocorrer em um prazo de até 12 meses.
>> >>
>> >> Para designações adicionais se seguirão as políticas incluídas
>> >> na seção 2.3.4 aplicadas a Usuários Finais.
>> >>
>> >> INFORMAÇÃO ADICIONAL:
>> >>
>> >> Tempo de implementação: Imediato Grupo de
>> >> trabalho: Propostas previas relacionadas: Referencias:
>> >>
>> >> Changelog: versão inicial.
>> >> _______________________________________________
>> >> 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
>>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>