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

Mon Oct 10 15:23:32 BRT 2011

Olá Pedro,

Tal qual Christian, peço desculpas por não ter comentado antes essa
proposta. Por alguma razão, que não serve de justificativa, o email
original foi desmarcado com "nao lido" no folder e não teve a atenção
devida.

Durante o fórum eu coloquei que estou de acordo em regularizar a questão
dos requisitos. Que seja a necessidade de apresentar um uso de 25% do
bloco solicitado.

Mas, coloquei também, que não estou de acordo e remover o critério de
multi-homed.

Expliquei que originalmente as políticas para usuários finais eram mais
"restritivas" pois alocavam somente /20. E devido a necessidades de
organizações onde as mesmas precisavam contar com alta disponibilidade
mas nao muitos endereços se criou essa política que atualmente está em
vigor.

Remover o critério de multi-homed afeta a razão da criação dessa
política.

Foi comentado que há organizações em regiões onde não existem opções de
mais que um provedor. Argumentei então que o problema nesse caso era
outro.
O problema ai é de conectividade e não de endereçamento.

Em seguida foi comentado também que para algumas a renumeração é um
problema.
No entanto, que fique claro que renumeração ou necessidade de fazer-la
não é justificativa 'unica'  ou suficiente para obtenção de endereços.

Ainda mais, se para algumas organizações não há mais que uma opção de
provedor, a renumeração não deveria ser uma preocupação. Pois essas não
teriam que renumerar pois não teriam alternativa de provedor.

Sds
Ricardo Patara

On Fri, 2011-10-07 at 17:49 -0300, Pedro Torres wrote: 
> 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] Modificação dos requerimentos para solicitação
> >> >> inicial de endereçamento IPv4 para Usuá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
> >> >> ==============================================================
> >> >>
> >> >> INFORMAÇÃO DO AUTORES:
> >> >>
> >> >> Nome - eMail - Telefone - Organização Pedro R Torres Jr -
> >> >> torres at pop-pr.rnp.br - +554199177753 - UFPR e RNP/PoP-PR
> >> >>
> >> >> DADOS DO PROPOSTA:
> >> >>
> >> >> Titulo da Proposta: Modificação dos requerimentos para
> >> >> solicitação inicial de endereçamento IPv4 para Usuários Finais
> >> >> Tipo de Proposta: LACNIC Id: LAC-2011-09
> >> >>
> >> >> Versão: 1
> >> >>
> >> >> Proposal Summary: Esta proposta tem a intenção de homogeneizar a
> >> >> subseção 2.3.3.4.3 do Manual de Políticas do LACNIC, sem deixar de
> >> >> lado as qualificações necessárias do bloco IPv4 que está sendo
> >> >> solicitado. Um novo texto modifica essa subseção de tal maneira que
> >> >> não se faça distinção entre Usuários Finais Multiprovedor e Não
> >> >> Multiprovedor e remove a necessidade de qua lificação baseado em
> >> >> alocação(ões) de ISP(s) já existente(s).
> >> >>
> >> >> Rationale: Atualmente o texto da subseção 2.3.3.4.3, que se refere
> >> >> ao Status do Solicitante para designações iniciais para Usuários
> >> >> Finais, impõe requisitos não necessários. Um exemplo é para um
> >> >> Usuário Final Multiprovedor, com necessidade de um /24. Segundo o
> >> >> subseção 2.3.3.4.2 este deve estar utilizando 25% do bloco
> >> >> solicitado, ou seja 64 endereços IP. Por outro lado, a subseção
> >> >> 2.3.3.4.3 exige que esse Usuário Final já conte com um /25 (128
> >> >> endereços IP) designado pelo seu provedor de serviço.
> >> >>
> >> >> Atualmente também se faz uma distinção pouco necessária entre
> >> >> Usuários Finais Multiprovedor e Não Multiprovedor, impondo tamanhos
> >> >> mínimos de designação distintos para cada categoria. Um agravante
> >> >> nas designações feitas por um ISP a Usuários Finais é o
> >> >> esgotamento de endereços IPv4. Desta forma, a cada dia, torna-se
> >> >> mais difícil obter uma designação de um /25 (para Mu ltiprovedor)
> >> >> ou 8 /24 (para Não Multiprovedor), ainda que
> >> >>
> >> >> exista uma justificativa válida para se ter este endereçamento.
> >> >>
> >> >> Outra exigência que por vezes é difícil de se cumprir e ser
> >> >> Usuário Final Multiprovedor. Devido a falta de opção em contratar
> >> >> dois ou mais provedores em algum local da nossa região, isso acaba
> >> >> redirecionando um Usuário Final a ter que justificar um /20, de
> >> >> acordo com o texto atual da subseção 2.3.3.4.3 para designações para
> >> Não Multiprovedor.
> >> >>
> >> >> Prós do autor: - Resolve o problema em que algum ISP se recusa a
> >> >> designar mais endereços IP para um Usuário Final ou cobra muito
> >> >> caro por isso. O staff do LACNIC pode se esforçar para atender essa
> >> >> demanda de Usuários Finais utilizando pequenos espaços de
> >> >> endereçamento disponíveis no pool. - Não força um Usuário Final
> >> >> a ter que justificar um /20, mesmo quando necessita de menos endereços.
> >> >>
> >> >> Contras do autor: Pequenas designações impactam diretamente no
> >> >> tamanho da tabela de roteamento (ainda que esse aumento já venha
> >> >> ocorrendo devido a tentativa de se fazer balanceamento de tráfego em
> >> >> pequenos blocos que carregam muita quantidade de tráfego devido ao
> >> >> uso intenso de NAT).
> >> >>
> >> >> Proposal Text: 2.3.3.4.3. Requerimentos do Solicitante. O tamanho da
> >> >> designação mínima de endereços IPv4 para um Usuário Final é de
> >> >> um bloco / 24.
> >> >>
> >> >> Para qualificar a designação de um bloco
> >> >> IPv4 inicial, o Usuário Final deverá: - Justificar a já
> >> >> utilização de endereços de acordo com a subseçã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 Usuário Final tiver
> >> >> recebido a(s) designação(ões) de seu(s)
> >> >> ISP(s) equivalente a um bloco / 25 ou menos, deverá devolver em um
> >> >> prazo de até 3 meses. No caso de que a(s) designação(ões) por
> >> >> parte de seu(s)
> >> >> provedore(s) seja(m) superior(es) a um bloco /25, a
> >> >>
> >> >> devolução deverá ocorrer em um prazo de até 12 meses.
> >> >>
> >> >> Para designações adicionais se seguirão as políticas incluídas
> >> >> na seção 2.3.4 aplicadas a Usuários Finais.
> >> >>
> >> >> INFORMAÇÃO ADICIONAL:
> >> >>
> >> >> Tempo de implementação: Imediato Grupo de
> >> >> trabalho: Propostas previas relacionadas: Referencias:
> >> >>
> >> >> Changelog: versã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
> >
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas