AFRINIC-29 Reunião de Políticas Públicas

Reunião de políticas públicas AFRINIC-29

Ata da reunião do PDWG realizada em 29 de novembro de 2018

Hammamet, Tunísia

 

Versão PDF 

 

Co-presidentes da sessão: Sami Salih, Dewole Ajao

 

Agenda:

1. Bem-vindo, introdução e visão geral da agenda
2. O AFRINIC PDP
3. Relatório de Experiência de Implementação de Política
4. Atualização de desenvolvimento de política de outro RIRs
5. Proposta: Processo de Desenvolvimento de Políticas AFRINIC Bis v4
6. Proposta: Atualização Simples do PDP
7. Proposta: atualização da política de contato de abuso
8. Proposta: revisão dos recursos de números da Internet pela AFRINIC
9. Proposta: Esclarecimento sobre IPv6 Subatribuições
10. Proposta: Inter-RIR Transferência de Recursos
11. Proposta: IPv4 BIS de pouso suave
12. Proposta: SL-Update
13. Microfone de política aberta

 

1. Boas-vindas, introdução e visão geral da agenda

A sessão foi introduzida por Ernest Byaruhanga, que deu as boas-vindas aos delegados à reunião, apresentou os co-presidentes (Dewole e Sami), agradeceu-lhes por seus esforços e instou os delegados a lhes oferecer total cooperação. 

Sami apresentou o draft agenda que foi aprovada sem alterações.

Ele também afirmou que o Código de Conduta AFRINIC deve orientar as discussões do dia, e que enfatiza a polidez, respeito mútuo, sem discriminação, sem ataques pessoais, respeito pela agenda e tempo, tolerância às diferenças de idioma e a necessidade de sempre agir em os melhores interesses da comunidade AFRINIC.

 

2. O PDP AFRÍNICO

Sami apresentou o Processo de Desenvolvimento de Políticas AFRINIC e afirmou que se baseia nos princípios de uma abordagem ascendente e de abertura. Uma proposta pode ser postada por qualquer pessoa na lista de políticas de rpd, que é aberta, discutida por pelo menos 4 semanas e então apresentada em uma reunião de políticas públicas. Uma proposta é então enviada para última chamada se obtiver consenso na reunião de políticas públicas (caso contrário, ela volta à lista para outra discussão de 4 semanas). Se não houver problemas durante a última chamada, os co-presidentes enviam um relatório ao Conselho recomendando a ratificação, e o Conselho ratifica e pede à equipe para implementar, desde que o processo tenha sido seguido corretamente.

 

Reações e perguntas recebidas:

• Como os co-presidentes aplicam o Código de Conduta? Os copresidentes esclareceram que se trata de um assunto interno que fica a critério dos copresidentes no momento. 

• O Conselho sempre ratifica uma proposta quando assessorado por copresidentes? Quando a diretoria pode contestar / rejeitar uma política ou pedir que a comunidade faça contribuições extras? Os copresidentes afirmam que o Conselho só ratifica com base no fato de a proposta seguir o processo ou não. Acrescentaram que a proposta volta à lista se a Diretoria não a ratificar.

• Algumas propostas na pauta parecem violar o PDP, devido ao prazo de envio de 1 semana antes do PDP. Os co-presidentes esclarecem que a proposta em questão foi apresentada dentro do prazo, mas não foi publicada (nem publicada na lista) dentro do prazo. Eles propuseram que, no futuro, os co-presidentes não esperem pela publicação no site de uma proposta recebida, e a postem na lista logo após o recebimento.

 

3. Relatório de experiência de implementação de política

Esta foi apresentada por James Chirwa, Analista Sênior de IP da AFRINIC. O relatório destaca os principais aspectos da política (e lacunas) cuja implementação (traduzindo-se na distribuição real de recursos numéricos aos membros durante o tratamento de solicitações) poderia ser mais bem esclarecida para que a equipe possa entender e interpretar melhor esses aspectos e fechar essas lacunas.

 

Destaques do relatório:

• As políticas recentemente ratificadas são as seguintes:
  • IPv6 Atualização de política e referências - implementada em 23 de novembro de 2018 e ativa.
  • IPv6 Atualização de alocação inicial - também implementada em 23 de novembro de 2018 e está ativa.
  • IPv6 PI Update - em implementação, automação pendente de alguns requisitos de política (ferramentas para verificar se IPv6 O espaço PI que foi atribuído aos membros é roteado e não desagregado).
  • Lame Delegations no AFRINIC DNS reverso - foi implementado (parcialmente) em 28 de setembro de 2018. Os registros Lame para domínios e servidores de nomes ainda não foram excluídos e a página de estatísticas está em andamento. A AFRINIC está apoiando os membros preocupados em corrigir essas delegações coxas.
• Conflitos e Ambiguidades no Manual de Políticas:
  • O CPM 5.4.6.1 estipula a utilização de 90% de todo o espaço emitido antes que um membro possa receber o espaço subsequente, o que conflita com 5.5.1.4.1 (80% de utilização) e 5.6.3 (Taxas de utilização de 50% em 1 ano)
  • CPM 5.7.1 permite inter-RIR transferências de IPv4 espaço, mas há alguns membros que desejam transferir ASN e IPv6 recursos devido, por exemplo, a fusões.
  • CPM 7.4.2 sobre o requisito de multi-homing para um ASN a ser emitido - ainda alguns membros precisam de um ASN e estão executando o BGP - mas com um provedor de conectividade.
  • CPM 5.2.1.2 - o requisito de que um LIR registre atribuições de endereço IP para seus clientes. Algumas dessas atribuições mostram nomes de empresas que não são exatos ou corretos, às vezes criadas intencionalmente pelo LIR para falsificar informações.

No caso das ambiguidades acima, a comunidade é instada a examinar o CPM e propor mudanças de política para corrigir esses problemas.

Reações:

• Um membro indicou que está feliz em escrever propostas de política para cada um dos itens listados acima, mas incentivou os indivíduos que não criaram políticas antes a se apresentarem e escreverem políticas para tratar desses problemas.
• Foi sugerido que membros específicos da AFRINIC que desencadearam os problemas acima (e foram diretamente afetados) poderiam ser incentivados a propor políticas para lidar com essas ambigüidades.
• Foi sugerido que a equipe redigisse um plano de implementação de política pública contendo as diferentes maneiras como a política impactará os membros. Este documento deve ser anunciado aos membros quando disponível. Um participante sugeriu que esta seção poderia fazer parte do relatório de avaliação da equipe como um primeiro draft.
• Sobre a questão de vários conflitos no CPM, o método ARIN de indicar o que foi excluído pode ser usado, de forma que as exclusões possam ser facilmente conhecidas ou vistas publicamente.

 

4. Atualização de desenvolvimento de política de outros RIRs

As atualizações foram recebidas e compartilhadas pelos respectivos RIR representantes da seguinte forma:

APNIC:

• A validação da proposta de política de caixa de correio de abuso (semelhante à que será discutida aqui) foi aprovada na apnic-46 e está aguardando a consideração do Conselho Executivo.
• A política “Não há necessidade” com o objetivo de abolir a verificação de avaliação de necessidades em todos os pedidos de transferência no APNIC não passou pelo APNIC46
• Esclarecimentos sobre IPv6 subatribuições (também semelhante àquela na agenda para esta reunião) introduz um processo que não permite o provisionamento de espaço v6 para dispositivos de terceiros fora da infraestrutura de rede do proprietário do espaço PI. Isso não chegou a um consenso no APNIC46.
• Atualização do PDP - uma proposta que atualiza o APNIC PDP para incluir a participação remota em decisões de consenso, ajustar o tempo necessário para enviar uma proposta antes de uma reunião de política pública e colocar em prática um mecanismo de apelação mais simples. Não atingiu consenso no APNIC46

 

ARIN:

• Esclarecimento para a alocação inicial do ISP: Ajusta o IPv4 política de alocação inicial para permitir que empresas sem IPv4 espaço para se qualificar para um / 24 automaticamente, e maior se necessário for demonstrado.
• Proibir a criação de registros de organizações de terceiros: exige que os registros da organização sejam criados pela entidade representada pelo registro da organização e somente por meio de uma solicitação explícita ao ARIN.
• Esclareça os requisitos de reatribuição em 4.2.3.7.1: Simplifica os requisitos de reatribuição de modo que apenas o nome do cliente é necessário e não qualquer outra informação.

  

LACNIC:

• Inter RIR política de transferência. Isso estabelece um mecanismo para permitir a transferência de recursos (IPv4, IPv6, ASNs) entre diferentes regiões e alinhar o LACNIC com um mercado existente do qual a região não participa atualmente. A proposta é semelhante à que está em pauta para AFRINIC29, e permite apenas legado IPv4 espaço a ser transferido fora do LACNIC
• Política de Uso Aceitável para a lista de políticas: Propõe uma Política de Uso Aceitável (AUP) para a Lista de Políticas, visto que atualmente não existe tal documento no LACNIC. É proposto como resultado de várias incidências de atividades incômodas e contrárias ao propósito e ao espírito da lista de políticas do LACNIC, incluindo casos de uso indevido, vários ataques pessoais e propaganda eleitoral muitas vezes vistos na lista de políticas do LACNIC.
• Revisão menor do PDP: Corrigir uma falha no PDP de LACNIC onde se uma proposta de política não chega a um consenso e os comentários que recebe não são suficientes para mostrar ao autor “um caminho a seguir”, como está escrito, o texto atual forçaria os autores submeter “artificialmente” uma nova versão para manter a proposta original em discussão.
• Esclarecimentos sobre IPv6 subatribuições - também semelhante ao que está na pauta desta reunião) introduz um processo que não permite o provisionamento de IPv6 Espaço PI para dispositivos de terceiros fora da infraestrutura de rede do detentor do espaço PI.
• Registro e validação de abuse-c e abuse-mailbox: Porque não está claro se os dados de contato de abuso podem ser anexados a alguns dados de recursos no LACNIC whois db. Não está claro se as informações de contato de abuso podem ser anexadas a alguns dados de recursos no LACNIC whois banco de dados
• Esta proposta visa resolver o problema garantindo a existência de um contato abuse-c adequado e um processo para sua utilização; esta proposta visa resolver o problema garantindo a existência de um contato abuse-c adequado e implementa um processo para sua utilização.

  

MADURO: 

• Validação abuse-c regular: Dá ao RIPE NCC o mandato de validar anualmente endereços de e-mail de abuso e fazer o acompanhamento quando eles forem inválidos. A proposta foi aprovada na última reunião do RIPE.
• Esclarecimento de LIR da organização no IPv6 política: Esclarece sobre as alocações de LIR por conta LIR - a política antiga usada para afirmar que IPv6 alocação é dada a uma organização e não esclarece o tipo de organização. Isso também já está implementado.
• Corrigindo informações desatualizadas no IPv4 política: Esta proposta remove algumas referências desatualizadas no relevante IPv4 políticas./
• Esclarecimento do PDP: Deixa claro quais ações podem acontecer na “fase de revisão”, o que não estava muito claro.
• Esclarecimento de atribuições em IPv6 atribuições - visa esclarecer a definição de “atribuição” em IPv6 .
• Publicação do endereço legal dos detentores de recursos no banco de dados RIPE: O objetivo é publicar as informações de endereço legal e validado dos detentores de recursos na região RIPE. O autor foi solicitado a fazer alguns esclarecimentos.
• Limpeza de objetos de rota não autoritativos do banco de dados RIPE NCC IRR: O objetivo é excluir objetos de rota não autoritativos armazenados no registro de roteamento RIPE se houver conflito com um RPKI ROA. 

 

5. Proposta: Processo de Desenvolvimento de Políticas AFRINIC Bis v4

A proposta foi apresentada pelos autores, que compartilharam os seguintes destaques:

• O PDP atual tem 10 anos e os autores iniciaram o processo de alteração em abril de 2017, agora na versão 4.
• O feedback recebido na última reunião foi para remover o anonimato dos autores da proposta, remover a possibilidade de co-presidentes de política serem editores de documentos, remover a inclusão para Conselho de Anciãos e permitir cerca de 2 semanas para que os co-presidentes declarem consenso (após a adoção fase) e após a reunião de políticas públicas.
• A proposta foi atualizada para incluir todos os comentários da comunidade acima.
• Não houve discussões substanciais sobre a proposta atualizada e nenhuma sugestão ou contribuição da comunidade (incluindo o texto prometido por alguns membros).
• No entanto, uma nova proposta concorrente foi recebida (atualização de PDP simples).
• Os autores pediram aos co-presidentes um caminho a seguir.

As reações foram recebidas da seguinte forma:

• Os co-presidentes indicaram que as propostas devem ser consideradas no melhor interesse da comunidade, não das pessoas que as elaboram.
• Os co-presidentes pediram que o autor da proposta “Atualização simples do PDP” também a apresentasse, de modo que as discussões sobre os méritos de ambos possam ocorrer depois de ambos terem sido apresentados, permitindo que a comunidade discuta objetivamente e os co-presidentes tomem melhor decisão depois disso.

 

6. Proposta: Atualização Simples do PDP

O autor compartilhou os seguintes destaques desta proposta:

• Embora qualquer pessoa possa participar de discussões sobre políticas na lista de mala direta (RPD) e / ou nas reuniões de políticas públicas semestrais, nem todos os participantes do RPD podem participar de todas as reuniões presenciais em que os presidentes determinam um consenso aproximado sobre as propostas - e esta é a seção maior da comunidade. Com esse requisito de tomar decisões de consenso em reuniões face a face, isso pode ser em parte a causa dos baixos níveis de participação da comunidade no processo político.
• Esta proposta simplifica o processo ao não exigir a participação pessoal nas Reuniões de Políticas Públicas para obter consenso - em vez disso, o consenso seria determinado equilibrando as contribuições da lista de mala direta e da reunião - o que aumentaria a participação da comunidade.
• Os vários cronogramas também são adaptados a esta mudança, com alguns cenários como segue
  • Uma proposta (ou uma nova versão) é enviada 8 semanas (ou um período mais longo) antes do PPM. O consenso será determinado pelos presidentes em no máximo duas semanas.
  • Uma proposta (ou uma nova versão) é enviada menos de 8 semanas antes do PPM. O consenso será determinado pelos presidentes em no máximo duas semanas, uma vez que as 8 semanas de tempo de discussão da lista terminem.
  • O tempo dos minutos também é adaptado, pois parece desnecessário aguardar 3 semanas, se a determinação de consenso for feita em 2 semanas.
• A proposta, portanto, elimina a exigência de que o consenso só deve ser alcançado no PPM. Adapta os horários relevantes e, ao mesmo tempo, clarifica a definição de “consenso” e “última chamada”.
• A definição de consenso é adaptada para se alinhar com o conceito de consenso aproximado da IETF.
• Várias mudanças nos cronogramas são propostas, incluindo o fato de que os co-presidentes apenas anunciam mudanças nas decisões de consenso anteriores dentro de 1 semana após o período da última chamada.
• O autor indicou que uma proposta semelhante alcançou consenso na região de LACNIC em maio de 2018 e já foi implementada.

Reações recebidas:

• O autor da proposta “PDP-bis” indicou que há muitas semelhanças entre as duas propostas, como a avaliação da equipe e o processo de consenso aproximado (já que não se trata apenas da definição). O autor de “Simple PDP Update” indicou que a proposta do PDP-bis é complexa, devido às muitas (cinco) fases diferentes, e que precisa ser simplificada.
• Observou-se que as propostas do AFRINIC não devem ser comparadas às da região do LACNIC e de outras regiões.
• O autor desta proposta disse que leu a proposta do PDP-bis cuidadosamente e encontrou 15 pontos muito fracos e muitos problemas ausentes que ele apontou para os autores e está disposto a apontá-los se ambos os lados estiverem abertos para discussão.
• Os copresidentes indicaram que não há registro oficial das questões acima na lista de mala direta.
• Vários indivíduos notaram que há muitos pontos em ambas as propostas de política que são muito construtivos e, portanto, os autores dos dois lados devem trabalhar juntos para chegar a uma versão da proposta que seja muito melhorada.
• Algumas pessoas indicaram que o PDP atual não tem grandes problemas que precisem ser consertados, em vez disso, muitas pessoas estão procurando maneiras de manipular o processo para interesses pessoais - e esse problema pode permanecer independente.
• Alguns membros pediram aos co-presidentes que evitem aceitar essas propostas concorrentes, mas os co-presidentes indicaram que eles não têm tal mandato de acordo com o PDP, mas podem incentivar as partes a trabalharem juntas.
• Conforme mencionado anteriormente, embora o processo permita que várias propostas concorrentes estejam sobre a mesa, boa vontade deve ser usada para que não acabemos em tal situação. O autor de “Simple PDP Update” indicou que não é necessariamente uma má ideia ter propostas concorrentes, pois permite que a comunidade estude diferentes pontos de vista.
• Uma das propostas favorece os participantes remotos, e isso é bom, pois muitas pessoas não podem viajar devido a restrições de tempo e financeiras.

Os co-presidentes informaram que os autores das duas propostas concorrentes considerem trabalhar juntos para chegar a uma proposta unificada que combine os dois pontos fortes de ambas as propostas, para o benefício da comunidade que tem um PDP muito mais amplo e aprimorado.

O autor de “Atualização simples do PDP” decidiu retirar sua proposta de política e indicou que tem grande expectativa de trabalhar em conjunto com os autores da proposta de política “AFRINIC PDP-bis”Neste esforço para melhorar o PDP.

Os autores do “AFRINIC PDP-bis” insistem que, no esforço de trabalhar em conjunto, é necessário que haja respeito mútuo, pois isso incluirá a fusão de opiniões fortes de duas partes distintas.

Os co-presidentes decidiram devolver a proposta AFRINIC PDP-bis à lista e iniciar um processo de envolvimento das duas partes para trabalharem no sentido de uma versão melhorada, levando em consideração os pontos das duas propostas.

 

7. Proposta: Atualização da Política de Abuso de Contato

O autor compartilhou os seguintes destaques da proposta:

• O CPM 8.0 atual (especificação de informações de contato de abuso) não torna obrigatório registrar um contato de abuso. Como resultado, muitos membros podem não ter essas informações de contato para seus recursos registrados e atualizados.
• Pode haver casos em que os membros usem endereços de e-mail inexistentes ou que não sejam monitorados ativamente, o que torna difícil relatar abusos de tais redes e geralmente dá origem a problemas de segurança e até mesmo custos para as vítimas.
• Esta proposta visa solucionar esse problema, garantindo a existência de um contato de abuso adequado para cada recurso emitido e também um processo para manter essas informações corretas. A política foi proposta em tudo RIRs ter um método uniforme globalmente para denúncias de abuso entre regiões.
• A política existente no CPM 8.0 faz referência a um “Documento de Boas Práticas”, que não é obrigatório e não aparece como sendo usado pela comunidade.
• O documento de práticas recomendadas sugere um objeto IRT e esta proposta recomenda que o abuse-c proposto e o IRT no BCP sejam vinculados automaticamente. Desta forma, os processos de contato de abuso AFRINIC irão se alinhar com outros RIRs. APNIC agora está usando o IRT, mas uma vez que uma proposta equivalente foi aceita, um “link” automatizado com o IRT existente será criado, então abuse-c e abuse-mailbox ainda prevalecerão.
• Não há necessidade de excluir outros dados opcionais hoje incluídos no IRT. Essa política apenas garante que a caixa de correio de abuso esteja disponível e verificada periodicamente.
• Embora a comunidade da Internet seja baseada na colaboração, em muitos casos isso não é suficiente e todos nós precisamos ser capazes de entrar em contato com os ISPs que podem estar enfrentando um problema em suas redes e não estão cientes da situação.
• Esta proposta cria uma nova seção no Manual de Política para resolver esse problema por meio de uma verificação simples e periódica, e estabelece as regras básicas para a realização dessa verificação e, assim, evita custos desnecessários a terceiros que precisam entrar em contato com as pessoas responsáveis ​​pela solução do problema. abusos de uma rede específica.
• A proposta garante que o custo do processamento do abuso recai sobre o LIR cujo cliente está causando o abuso (e de quem recebe uma compensação financeira pelo serviço), em vez de recair sobre a vítima, como seria o caso se tivesse que recorrer aos tribunais, evitando custos (advogados, solicitadores, etc.) e poupando tempo a ambas as partes.
• Para isso, o atributo abuse-c se torna obrigatório nos objetos "aut-num", "inetnum" e "inet6num", assim como em qualquer outro que possa ser usado no futuro. Este atributo é um contato de abuso, que deve conter pelo menos o atributo "abuse-mailbox".
• Espera-se que a proposta seja implementada pela AFRINIC dentro de um prazo razoável que permita ao pessoal desenvolver o software necessário e aos membros atualizarem seus contatos abuse-c.
• O autor indicou que, embora a AFRINIC tenha proposto que detalhes operacionais e verificações complexas fossem removidos da proposta, é importante que eles permaneçam, pois são uma função central nas verificações de e-mail de abuso.
• Uma proposta semelhante foi aceita no APNIC (está sendo implementada) e está em discussão nas regiões de LACNIC e RIPE.

As reações da comunidade foram as seguintes:

• A verificação das informações de contato é importante a partir do contexto e do trabalho dos CERTs.
• O que acontece quando os membros não respondem aos pedidos de verificação da AFRINIC? O autor afirmou que AFRINIC irá bloquear o acesso a MyAFRINIC conforme indicado no texto da proposta.
• Foi esclarecido pelo autor que o que está bloqueado é o acesso a MyAFRINIC, não o uso de recursos para revogá-los ou recuperá-los. No entanto, a reclamação faz parte do acordo entre o membro e a AFRINIC.
• O texto da proposta menciona “bloqueio de acesso da conta a recursos”, o que pode ser interpretado erroneamente como revogação de recursos ”. O autor esclareceu novamente que este é o acesso a MyAFRINIC.
• Houve apoio para a ideia de verificação de endereços de e-mail.
• Foi observado que um único objeto ou atributo de contato de abuso é mais fácil de manter.
• Observou-se também que, durante a verificação, a AFRINIC não deve tomar medidas punitivas contra membros que não respondem às verificações, por não ser a Polícia da Internet. A AFRINIC poderia apenas marcar aqueles que não respondem e tornar a lista pública para que a comunidade de operadores decida o que fazer, como o de-peering.
• Bloqueando o acesso a MyAFRINIC foi suportado, mas havia uma proposta para permitir o login, mas havia uma mensagem após o login para indicar que o membro deve primeiro atualizar / verificar suas informações de contato de abuso antes que qualquer outra funcionalidade possa ser acessada.
• Houve uma preocupação com as taxas de resposta geral dos membros quando o AFRINIC tentou fazer com que os membros atualizassem seus contatos imprecisos. O CEO afirmou que em esforços semelhantes anteriores, houve uma taxa de resposta de mais de 90%.
• Foi sugerido que é melhor manter o uso atual do objeto IRT, pois ele armazena mais do que apenas um endereço de e-mail e já é amplamente utilizado.
• Um membro observou que o AFRINIC deve ser capaz de intervir se os membros estiverem usando os recursos emitidos de maneira inadequada.
• O cronograma para que uma conta seja bloqueada e uma conta bloqueada seja desbloqueada não são indicados, e isso deve ser esclarecido no texto da proposta. O autor esclareceu que os prazos são claros no texto da proposta.
• Foi observado que MyAFRINIC é usado para votar, e esse bloqueio de acesso a MyAFRINIC durante o período eleitoral, tira os direitos dos membros. O autor afirmou que são essas as questões que motivariam os membros a manterem seus cadastros atualizados, mas que o login para MyAFRINIC pode ser usado para votar, mas não para gerenciar recursos.
• A equipe da AFRINIC indicou que a política precisa ser explicitamente clara sobre como o IRT existente se relacionará com o abuso-c.

 

Decisão do copresidente: Sem consenso - a proposta retorna à lista de e-mails para mais contribuições e refinamento da comunidade.

 

8. Proposta: revisão dos recursos de números da Internet pela AFRINIC

Os autores desta proposta procederam da seguinte forma:

• Os autores não vão se deter muito no conteúdo, pois a proposta evoluiu ao longo de dois anos (por meio de seis versões diferentes) e é considerada madura o suficiente para eles.
• Um caminho a seguir é, portanto, a melhor abordagem para seguir em frente.
• Os co-presidentes concluíram na última reunião de Dacar que, como resultado tanto da forte oposição quanto do forte apoio à proposta de política por uma variedade de razões expressas online e no PPM, a proposta retorna à lista de rpd para posterior discussão e refinamento. Os co-presidentes também sugeriram (depois de Dacar) que a comunidade discuta mais para ver se há melhores maneiras para a AFRINIC lidar com o problema percebido / observado de uso irresponsável (ou aplicações fraudulentas de) recursos de numeração da Internet.
• Os autores perguntaram como os co-presidentes podem quebrar o vínculo entre forte apoio e forte oposição, uma vez que muitos concordam que a revisão e auditoria dos recursos alocados é necessária. Os autores sugeriram uma possível alteração do 13.4b ao não exigir uma revogação de fato dos recursos e ao estabelecer disposições para que a equipe gerencie o não cumprimento caso a caso.

 

Reações da comunidade:

• A política nega aos usuários finais o acesso à Internet, embora eles não tenham conhecimento de quaisquer auditorias e acionadores dessas auditorias no nível do ISP.
• Também seria caro e impraticável, uma vez que a AFRINIC precisaria contratar terceiros para realizar auditorias / análises. O autor respondeu que apenas questões são bem-vindas, e declarações de apoio ou não.
• Alguns membros indicaram que AFRINIC está atualmente conduzindo análises ou esforços de devida diligência sobre a utilização dos recursos emitidos, e isso não é uma coisa nova, portanto, esta proposta pode não ser necessária, afinal.
• Um membro esclareceu que poucos concordam que a política seja necessária e que também não há consenso de que esta proposta seja necessária. Notou-se também que a mesma versão e texto da proposta não foram aprovados na reunião anterior e que logicamente não deveriam ser aprovados nesta reunião. De notar também que esta proposta faz da AFRINIC uma espécie de polícia da Internet, o que não faz parte do seu mandato, e que deve concentrar-se nas suas funções essenciais.
• O consultor jurídico da AFRINIC indicou que não há problemas jurídicos e outros com esta versão depois de ter trabalhado com os autores para tratar de questões levantadas nas avaliações de pessoal.

 

Decisão do copresidente: A proposta vai para a última chamada, mas mais compromissos com a comunidade ainda estão abertos durante esse período.

(Observação: com base nas discussões e compromissos na lista após a reunião, a proposta foi devolvida à lista de mala direta.)

 

9. Proposta: Esclarecimento sobre IPv6 Subatribuições

Os destaques da proposta foram compartilhados pelo autor da seguinte forma:

• A proposta foi submetida a todos os cinco RIR comunidades.
• Quando a inicial IPv6 política era drafted, o conceito de atribuições / subatribuições não considerou uma prática muito comum em IPv4 que é replicado e até amplificado em IPv6 - o uso de endereços IP para links ponto a ponto ou VPNs.
• In IPv4, normalmente, isso não é um problema devido ao uso do NAT.
• No caso de IPv6, em vez de endereços exclusivos, o uso de prefixos exclusivos (/ 64) é cada vez mais comum. Da mesma forma, a política deixou de considerar o uso de endereços IP em hotspots, ou o uso de endereços IP por convidados ou funcionários em Bring Your Own Device (BYOD) e muitos outros casos.
• Há momentos em que um usuário final contrata um terceiro para fazer alguns serviços em sua própria rede e eles precisam implantar seus próprios dispositivos, até mesmo servidores, equipamentos de rede, etc. Por exemplo, serviços de vigilância de segurança podem exigir que o contratante forneça suas próprias câmeras, sistema de gravação, até mesmo seu próprio firewall e / ou roteador para uma VPN dedicada, etc. É claro que, em muitos casos, esse sistema de vigilância pode precisar usar o espaço de endereçamento do usuário final.
• O IETF aprovou recentemente o uso de um prefixo / 64 exclusivo por interface / host (RFC8273) em vez de um endereço exclusivo. Isso, por exemplo, permite que os usuários se conectem a um hotspot, recebam um / 64 de forma que fiquem isolados de outros usuários (por motivos de segurança, requisitos regulatórios, etc.) e também possam usar várias máquinas virtuais em seus dispositivos com um endereço único para cada um (dentro do mesmo / 64).
• A seção 2.6 (Definições Gerais / Atribuição) proíbe explicitamente tais atribuições, declarando que as atribuições não devem ser subatribuídas a outras partes. Existem duas opções, em primeiro lugar - pedir aos usuários finais para se certificar de que estão usando a política corretamente e aplicá-la, e recuperar os recursos em caso de uso indevido e, em segundo lugar, corrigir nossos erros no atual IPv6 política - esta última opção é a abordagem seguida com a introdução desta proposta.
• Esta proposta esclarece esta situação e define melhor o conceito, particularmente considerando novos usos de IPv6 (RFC 8273), por meio de texto novo ao final de qualquer texto disponível no IPv6 Política de atribuições de PI. Também esclarece que não é permitido o uso de subatribuições em ISPs, data centers e casos semelhantes.
• Em resumo, esta proposta apenas estipula que IPv6 O espaço PI pode ser usado na rede do titular da atribuição e apenas dispositivos de terceiros operando estritamente dentro dessa infraestrutura, incluindo quaisquer interconexões. No entanto, não é permitido o uso emitido IPv6 Espaço PI para fornecer serviços aos clientes, como ISPs e data center ou casos semelhantes. Tais são os casos aqui considerados como subatribuições.
• Uma proposta semelhante está em discussão nas comunidades LACNIC, RIPE e APNIC.
• A equipe indicou que não havia preocupações em sua avaliação.

Reações da comunidade:

• Houve uma declaração de apoio à proposta e nenhuma declaração contra.
• Uma preocupação com a numeração da equipe foi levantada - e o autor esclareceu que o texto da proposta deve ser inserido logo após o texto existente no artigo 6.8 do CPM, pois é mais fácil de ler e interpretar.

Decisão do copresidente: A proposta vai para a última chamada - mas mais compromissos com a comunidade ainda estão abertos durante esse período.

 

10. Proposta: Inter-RIR Transferências de Recursos

A proposta foi apresentada por seu autor - que apontou o seguinte:

• Permite AFRINIC entrar em um mercado existente de transferências para IPv4, IPv6 e ASN Recursos.
• Foi notado que IPv6 transferências ajudam no caso de uma empresa se mudar para outra RIR região e querem mover seus recursos para essa nova RIR.
• Não fazer parte do mercado durante as fases de IPv4 a exaustão prejudicará os ISPs AFRINIC.
• Para limitar muito IPv4 espaço de saída do continente, a proposta só permite a transferência de legado IPv4 espaço. Isso é importante porque o registro preciso desses recursos é fundamental, embora eles provavelmente estejam em uso fora da região.
• Os tamanhos mínimos transferíveis são / 24 para IPv4 e / 48 para IPv6. Em qualquer dos casos, o destinatário deve demonstrar a necessidade de o recurso ser transferido.
• In IPv6 bloco não pode ser transferido até 2 anos após a alocação ou atribuição inicial.
• No que diz respeito à transferência de outros tipos de recursos, a AFRINIC já salientou (no relatório de implementação da política) que oRIR transferência só permite IPv4 transferências, e não outros tipos de recursos.
• Os recursos transferidos não podem ser retransferidos antes de 1 ano da transferência mais recente.
• Existem políticas equivalentes em outras regiões, e LACNIC está discutindo um texto quase idêntico. ARIN está exportando o maior número de recursos do mercado de transferências.

 

As reações e comentários foram recebidos da seguinte forma: 

• Notou-se que um bloco como o 196 tem espaço legado e não legado que existe tanto no AFRINIC quanto em outras regiões.
• A política deve ser feita apenas para transferências de entrada, para que os recursos da AFRINIC permaneçam na África. O autor observou que outras regiões precisam de reciprocidade, daí a necessidade de fornecer opções de saída.
• Foi notado por alguns que, uma vez que a política só permite saídas IPv4 apenas espaço legado, é uma boa política.
• A política foi apoiada porque permite que a AFRINIC participe no mercado global, e a política conforme redigida é aceitável.
• Observou-se que é necessário haver transferências bidirecionais para que a proposta seja recíproca e compatível com a política de transferências do ARIN.
• O autor foi questionado por que não havia bloco máximo transferível (enquanto existem tamanhos mínimos). O autor indicou que ninguém sugeriu essa ideia ainda, mas sugeriu que pode não haver necessidade - mas está aberto a sugestões da comunidade.

  

Decisão do copresidente: Sem consenso - a proposta retorna à lista de e-mails para mais contribuições e refinamento da comunidade.

 

11. Proposta: IPv4 BIS de pouso suave

As observações dos autores foram as seguintes:

• A proposta de pouso suave-bis tinha como objetivo atualizar a atual política de pouso suave adotada em 2011.
• Ficou claro no relatório de implementação da política AFRINIC que algumas das preocupações mencionadas são abordadas nesta proposta.
• Uma das questões a serem abordadas já é tratada na outra proposta de política dos autores a seguir na agenda, intitulada “Atualização do SL”.
• Os autores, portanto, decidiram permitir a proposta “IPv4 Soft Landing bis ”para expirar.

[Observação: a proposta de política expirou em 01 de dezembro de 2018 de acordo com o PDP]

 

12. Proposta: SL-Update 

Os destaques foram compartilhados pelos autores da seguinte forma:

• A seção 5.4.7.1 do CPM da atual política de pouso suave reserva um / 12 do último / 8 para usos futuros imprevistos.
• A seção 5.4.7.2 do CPM permite que a Diretoria AFRINIC a seu critério (considerando a demanda e outros fatores) - no momento em que a AFRINIC não puder mais atender a nenhuma solicitação de espaço de endereço do último / 8 ou qualquer outro espaço de endereço disponível, para reabastecer o pool de exaustão com qualquer espaço de endereço (ou parte dele), que possa estar disponível no momento e faça isso de uma maneira que atenda aos melhores interesses da comunidade.
• A seção 5.4.7.2, portanto, dá ao Conselho autoridade absoluta e única para decidir sobre como usar o bloco reservado para, eventualmente, reabastecer o pool de exaustão e pode até mesmo determinar as regras de alocação / atribuição.
• O problema é que, se nenhuma política voltada para a comunidade for adotada para determinar como usar o espaço reservado antes do esgotamento da piscina, o Conselho poderá agir a seu critério com ou sem o envolvimento e consentimento da comunidade.
• A comunidade está, portanto, em uma posição melhor para determinar o que é melhor para ela e isso é melhor discutido por meio do PDP.
• Esta proposta, portanto, reformula 5.4.7.2 para cancelar a discrição do Conselho, para: "Se o / 12 reservado permanecer sem uso até o momento em que o espaço disponível restante tenha sido alocado, o / 12 será devolvido ao pool AFRINIC para distribuição nas condições da fase 2 da política de pouso suave.

 

As reações e comentários da comunidade foram recebidos da seguinte forma:

• A AFRINIC foi solicitada a esclarecer se os pedaços de pequenos blocos recebidos de IANA também serão emitidos sob a política de pouso suave. A AFRINIC esclareceu que o pouso suave começou quando o AFRINIC começou a alocar a partir do último / 8, e que todo o espaço dentro do estoque (e não necessariamente apenas o último / 8) seria todo emitido sob o mecanismo de pouso suave.
• Nada indica que o Conselho deve seguir a política de pouso suave ao determinar o que fazer com a reserva, portanto, é bom corrigir esse risco e incerteza caso o Conselho decida gerenciar a reserva fora dos processos de pouso suave.
• As políticas devem se concentrar em melhorar e promover IPv6, e não adicionando mais restrições à diminuição IPv4 piscina. Os autores afirmaram que IPv4 ainda é relevante, pois há discussões ativas sobre IPv4 transferências e como a comunidade AFRINIC ainda pode se beneficiar do mercado.
• Notou-se que a região ARIN não tinha IPv4 política de pouso suave e que existe um mercado vibrante na região ao mesmo tempo maior IPv6 taxas de adoção.

Decisão do copresidente: Sem consenso - a proposta retorna à lista de e-mails para mais contribuições e refinamento da comunidade.

 

13. Microfone de política aberta

Os seguintes pontos foram levantados pela comunidade durante a sessão de microfone aberto: 

• Quanto à decisão de encaminhar propostas para a última chamada, ou devolvê-las ao mailing list, é melhor que os co-presidentes indiquem os motivos pelos quais a proposta foi reenviada à lista, para que fique claro para todos. Sobre a questão da proposta do SL-Update, os co-presidentes esclareceram que a proposta precisa de mais tempo para ser discutida, embora os autores observem que o tempo foi suficiente, de acordo com o que o PDP prevê. Um membro indicou que existem disposições no PDP para apelar das decisões dos co-presidentes em caso de descontentamento.
• Observou-se que enviar dentro do prazo exigido não se traduz em discussões suficientes e que a reunião presencial também dá à comunidade uma visão melhor do espírito da proposta, o que permite discussões adicionais informadas e enriquecidas.
• Jordi ofereceu-se para ajudar qualquer pessoa que não tenha contribuído para o processo político a abordá-lo, de modo que as questões levantadas no Relatório de Implementação de Política pelo pessoal da AFRINIC possam ser abordadas por meio de propostas de política por essas pessoas.
• Um membro aplaudiu os co-presidentes por seus esforços em seu trabalho, bem como vários autores de políticas por seus esforços.
• Notou-se que as discussões nesta reunião foram cordiais e não houve ataques insultuosos como pode ter sido o caso antes, e que a maneira cordial das discussões deve ser mantida tanto na lista de mala direta quanto em reuniões futuras.
• Um colega agradeceu à AFRINIC em nome de todos os outros bolsistas pela oportunidade e exposição da AFRINIC aos compromissos que aconteceram durante esta reunião. Outro colega também gostou de experimentar essas discussões cara a cara, em oposição ao que tem visto na lista, e agradeceu a Jordi pela oferta de recrutar novos autores de políticas.
• A comunidade deve se concentrar menos na política e mais no aprimoramento de políticas melhores, embora elas possam não ser 100% perfeitas, assim como outros tópicos como RPKI.
• Um participante remoto pediu aos co-presidentes que reconsiderassem sua decisão de avançar a proposta de revisão dos recursos de números da Internet para a última chamada e devolvê-la à lista, pois havia questões significativas levantadas contra ela e que algumas pessoas definitivamente apelarão - o que criará trocas desnecessárias. Ele também exortou os autores a considerarem retirá-lo, uma vez que pode não haver qualquer consenso em torno dele no futuro.
• Houve um inquérito sobre a possibilidade de a AFRINIC pagar a participação de autores de políticas em reuniões de políticas públicas.
• Observou-se que, uma vez que a equipe apontou no Relatório de Implementação de Política sobre diferentes inconsistências, há necessidade de consistência, e as propostas de revisão estabelecem o caminho para a consistência na direção certa. 

 

Resumo das decisões do copresidente sobre propostas de política 

Proposta	Decisão	Comentários
Processo de Desenvolvimento de Políticas AFRINIC Bis v4	De volta à lista
Atualização simples do PDP		Retirado por autor
Atualização da política de contato de abuso	De volta à lista
Revisão dos Recursos de Número da Internet pela AFRINIC	De volta à lista	A decisão inicial mudou após a reunião
Esclarecimentos sobre IPv6 Subatribuições	Última Chamada
inter-RIR Transferência de Recursos	De volta à lista
IPv4 BIS de pouso suave		Retirado pelos Autores
Atualização SL	De volta à lista