AFRINIC-21 Ata da Reunião do PDWG

Ata da reunião de política presencial

Onde: AFRINIC21, Cybercity, Maurício

Quando: 28 de novembro de 2014, 1100-1800

Copresidentes: Seun Ojedeji, Adam Nelson

agenda

Sessão 1: 11:00 - 12:30

1.   O Processo de Desenvolvimento de Políticas (PDP)

2.   Relatório de status de implementação da política

3.   Resumo das propostas em discussão no AFRINIC

4.   Resumo de propostas interessantes em outras regiões

5.   Relatório de Status do Manual de Política de Recursos (RPM)

6.   Proposta: Uso fora da região de recursos de números da Internet AFRINIC

Sessão 2: 14:00 - 16:00

7.   Proposta: AFRINIC whois Processo de atualização do banco de dados

8.   Proposta: qualquer transmissão Atribuições de recursos na região AFRINIC

Sessão 3: 1600 - 1730

9.   Proposta: Reserva de Recursos para Pontos de Troca de Internet

10.  Proposta: Diretrizes de serviço AFRINIC

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

12.  Microfone aberto

1.0 O processo de desenvolvimento de políticas

A reunião começou com o co-presidente Adam Nelson conduzindo os participantes através do processo de desenvolvimento de políticas da região AFRINIC (PDP). Mais informações sobre o PDP podem ser encontradas SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

2.0 Relatório de Status de Implementação de Política

Ernest Byaruhanga relatou sobre as seguintes propostas de política que foram implementadas desde AFRINIC20 em Djibouti, junho de 2014:

• qualquer transmissão Tarefas na região AFRINIC (AFPUB-2012-v4-001)
• Sem reverso, a menos que seja atribuído (AFPUB-2012-dns-001)

Ernest afirmou que o atraso de implementação foi devido a alterações de código no AFRINIC whois sistema de banco de dados, que foi atualizado com sucesso e as políticas consequentemente implementadas.

3.0  Resumo das propostas em discussão no AFRINIC

Foram apresentadas as propostas a serem discutidas durante a reunião:

• Uso fora da região de recursos de números da Internet AFRINIC
• AFRINIC whois Processo de atualização do banco de dados
• qualquer transmissão Atribuições de recursos na região AFRINIC
• Reserva de Recursos para Pontos de Troca na Internet
• Diretrizes de serviço do AFRINIC

4.0  Resumo de propostas interessantes em outras regiões

As seguintes propostas de políticas ativas / em andamento de outras regiões foram apresentadas ao reunião pois foram considerados relevantes para a nossa região:

• ARIN-2014-1: Fora da região IPv4 uso de endereço: um detentor de recurso ARIN pode usar seus recursos fora da região, desde que estejam usando o equivalente a IPv4 / 22, IPv6 / 44, 1 ASN dentro da região de serviço ARIN.
• RIPE-623: Política para Inter-RIR Transferência de recursos de números da Internet: A política descreve como a transferência de recursos entre RIPE NCC e outros RIRs (e da mesma forma) ocorrerá.

5.0  Relatório de status do manual de política de recursos

Ernest relatou sobre o Resource Policy Manual (RPM), que é um documento de referência único para todas as políticas usadas no AFRINIC região que esteve em draft nível (Publicados SUA PARTICIPAÇÃO FAZ A DIFERENÇA) e foi recentemente ratificado / aprovado pelo conselho da AFRINIC. Os seguintes destaques foram mencionados sobre o draft versão do RPM:

• A versão inicial foi publicada pela equipe AFRINIC.
• Nenhuma mudança nas políticas existentes foi feita; as propostas foram combinadas em apenas um documento, para facilitar a consulta, referência e atualização. (O documento é uma simples reformatação de documentos de política existentes e nenhuma alteração de conteúdo nas políticas)
• Todas as propostas de políticas futuras, após a implementação, serão refletidas como alterações nas seções do RPM.
• Uma proposta de política deve indicar que seção do manual será afetada.
• Todos os documentos de política anteriores serão arquivados para referência futura.
• As diretrizes de atualização de RPM serão incorporadas ao PDP quando apropriado e publicadas online.

Ernest afirmou que o RPM foi apresentado à comunidade inicialmente em novembro de 2013, publicado para comentários públicos em janeiro de 2014, recomendado ao Conselho para aprovação em abril de 2014 e recebeu a aprovação do Conselho em novembro de 2014. O AFRINIC implementará o RPM em janeiro de 2015 e todos as diretrizes para a comunidade trabalhar com o novo RPM serão publicadas no site da AFRINIC.

Um novo formato de numeração de ID de proposta de política também foi compartilhado com a reunião, e terá o formato afyyyy-nnn-vvv, Onde "af”Prefixo denota AFRINIC,“aaaa”O ano em que a proposta é recebida,“nnn”É um dígito que aumenta a cada nova proposta recebida, bem como“vvvv”Sendo o número da versão (prefixado pela letra“ v ”).

6.0 Uso fora da região de recursos de números da Internet da AFRINIC

Esta proposta foi apresentada por Douglas Onyango, e é publicado SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

 Comentários recebidos:

• A política não deve ser aplicada ao espaço de endereçamento adquirido antes que a política seja ratificada. O autor afirmou que consideraria reformular se este isum problema.
• Sugeriu-se que a proposta não fosse retroativa, mas restrita apenas a recursos futuros, e que a AFRINIC conduzisse uma análise minuciosa e relatasse quantos membros seriam afetados se a política redigida fosse ratificada.
• As disposições da RFC2050 e da RFC7020 devem orientar a equipe. Se as redes abrangem regiões, o solicitante deve ir para outras RIR atender a região onde suas outras redes estão localizadas no princípio de agregação. As alocações não devem ser baseadas em porcentagens, mas na necessidade, e as necessidades devem ser baseadas na agregação e no tamanho mínimo.
• O autor comentou sobre a necessidade de aplicar a política apenas aos LIRs, em reação ao comentário do AFRINIC de que não há como medir a utilização do espaço do usuário final / PI. Foi sugerido que todos os tipos de membros deveriam ter as mesmas regras; a política encorajará o abuso do sistema.
• Vários palestrantes apoiaram a intenção da proposta, mas sugeriram que a forma como está escrita não resolve o problema de uso de recursos fora da região devido a desafios na aplicação.
• Houve sugestões de que uma definição clara de “uso fora da região” fosse colocada em prática, já que este será o ponto de partida para resolver ambigüidades.

Decisão: Não houve consenso para mover a proposta para a última chamada. Portanto, foi enviado de volta à lista de discussão para uma discussão mais aprofundada.

7.0 AFRINIC WHOIS Processo de atualização do banco de dados

Esta proposta foi apresentada por Jean-Robert Hountomey, e é publicadoSUA PARTICIPAÇÃO FAZ A DIFERENÇA.

O autor afirmou que os membros são obrigados pela RSA a manter whois eMyAFRINIC dados precisos. Ele indicou que o objetivo da proposta é atingir qualidade whois dados e ter algo feito pela AFRINIC todos os anos sobre isso.

O seguinte comentário foi recebido:

• O autor perguntou o que impede o AFRINIC de aplicar a cláusula RSA que exige que os membros mantenham informações de contato corretas no whois banco de dados e que capacidade deve ser dada ao pessoal para fazer cumprir esta cláusula RSA.
•  O assessor jurídico da AFRINIC declarou que o RSA é bilateral, portanto, qualquer violação deve responsabilizar a parte violadora. Ele afirmou que embora a política pudesse ajudar a definir alguns procedimentos ou processos de fiscalização, o RSA é muito claro e já define autoridade.
• O autor foi aconselhado a remover a declaração “A necessidade de precisão whois os dados estão nos noticiários há anos em todo o mundo ”, pois não têm base.
• Assinalou-se que uma vez que o AFRINIC RSA já possui as disposições necessárias que instruem os membros a manter whois eMyAFRINIC dados atualizados e precisos, esta política ainda não é necessária. As “Melhores Práticas Atuais (BCP)” ou documento de apoio podem, entretanto, ser implementados para ajudar a equipe a implementar esta cláusula com sucesso.
• O Presidente do Conselho da AFRINIC declarou que não apoiaria uma proposta que, quando implementada, teria ramificações financeiras para a empresa. Esta proposta significaria a revogação de centenas de membros, o que tem implicações financeiras para a AFRINIC.

Decisão: O autor retirou a proposta imediatamente após a apresentação e a equipe sugerida usa as disposições do RSA para garantir a conformidade.

8.0 Anycast  atribuições de recursos na região AFRINIC

Esta proposta foi apresentada por Mark Elkins, e está publicada Aqui.

Já existe uma política ativa que permite IPv4 espaço a ser emitido paraqualquer transmissão finalidades, mas esta política não inclui IPv6 e ASN tipos de recursos. Esta proposta atende a esta omissão.

Os comentários abaixo foram recebidos:

• A proposta recebeu o apoio de várias pessoas no encontro.
• Notou-se a necessidade de definir qualquer transmissão serviços alinhados com BCP126 foram removidos da proposta, e o autor foi solicitado a explicar o porquê.
• Foi notado que os BCPs estão sempre mudando, portanto, não é uma boa prática basear a política em BCPs, uma vez que as políticas precisariam ser revisadas quando os BCPs mudam.
• Foi sugerido que a política só deveria ser ratificada para cobrirgTLDs, RIRs, ccTLD e operadores de servidor raiz, pois esses são os únicos que exigem qualquer transmissão provisionamento. No entanto, outros se opuseram a isso, e afirmaram que quaisquer serviços podem ser anycast 'ed, e a proposta deve ser aberta para acomodar qualquer tipo de operadora de rede IP que deseje servir qualquer transmissão.
• Ficou acordado que as seguintes alterações sejam feitas à proposta do autor:

• Seção 1, mudança “E um número AS” para “Ou um número AS”
• Seção 3.1, alterar “Um número AS deve ” a "Um número AS pode ”
• Modifique a seção 1 e 3.1 para incluir as disposições de BCP126 na definição qualquer transmissão serviços.

Decisão: Houve consenso para mover a proposta para a última convocação com as modificações discutidas na reunião. Uma proposta revisada com as alterações no parágrafo anterior deverá ser submetida pelo autor e irá diretamente para o período de “última chamada”.

9.0 Reservas de recursos para pontos de troca na Internet

Esta proposta foi apresentada por Nishal Goburdhan, e é publicado Aqui.

A proposta reserva IPv4 espaço (/ 16 para peering e / 16 sub-redes de gerenciamento) e um bloco de 2 bytes ASNs (114 ou metade do inventário AFRINIC) para IXPs na região de serviço AFRINIC e garante que haveria recursos discretos para permitir o estabelecimento de novos IXPs e o crescimento dos IXPs atuais.

Comentários recebidos:

• Observou-se que agora existe uma política que todos RIRProblema s (AFRINIC incluído) ASNs do pool de 32 bits e não deve haver uma diferenciação agora.
• AFRINIC observou que embora a política esteja em vigor, RIRs dividiram distintamente o pool de 32 bits em 3 categorias - apenas 16 bits, apenas 32 bits e 32 bits, e que essas políticas parecem atingir o pool apenas de 16 bits, que é 0-65536.
• Observou-se que a descrição do problema não estava totalmente clara e o autor foi solicitado a esclarecê-la. O autor esclareceu que a declaração do problema é bem explicada na Seção 3.3 da proposta.
• Alguns membros notaram que:

A seção 5 da “Política para atribuições de usuário final” já pede à AFRINIC para reservar blocos para uso do espaço de endereço IXP, e que esta proposta é uma duplicata da existente.

• A política de pouso suave pode ser suficiente se esta proposta está tentando lidar com a incerteza de IXPs não obter IPv4 espaço, e ser capaz de crescer, como o IPv4 a política de pouso suave garantirá o abastecimento prolongado de pequenos blocos na região.
• Um membro sugeriu adotar a proposta de incluir NREN, ccTLDs, etc. e não se limitar apenas a IXPs.
• No entanto, foi notado que mais grupos de interesse especiais poderiam continuar surgindo pedindo reservas (como um precedente que esta política poderia criar).
• Política global para aquisição ASNs - tenha cuidado porque pode não ser possível obter mais ASNs.
• O autor foi aconselhado a tomar nota do seguinte e talvez modificar a proposta para atender a esses fatores:                 
  • Incorpore um texto mais claro sobre a declaração do problema.
  • Adicione uma provisão para que os recursos reservados sejam devolvidos ao pool em uma determinada data se não forem usados.
  • Analise as preocupações da comunidade e represente uma versão atualizada da proposta

Decisão: Não houve consenso para mover a proposta para a última chamada. Portanto, ele volta para a lista de discussão para uma discussão mais aprofundada.

10.0 Diretrizes de serviço AFRINIC

Esta proposta foi apresentada por Karmann Olumomo, e é publicado Aqui.

Comentários recebidos:

• Não é razoável emitir recursos automaticamente após um certo período de atraso, uma vez que a política pode ser enganada e abusada intencionalmente.
• Houve várias declarações de objeção e nenhuma pessoa apoiou a proposta.

Decisão: Não houve consenso para mover a proposta para a última chamada. Portanto, ele volta para a lista de discussão para uma discussão mais aprofundada. além do que, além do maisA os co-presidentes aconselharam o autor a considerar a retirada da proposta, pois ela não recebeu nenhum apoio da comunidade.

11.0 Relatório de Implementação de Experiência de Política 

Esta sessão foi apresentada por Madhvi Gokhool, Gerente de serviços de registro, AFRINIC.Madhvi levantou as seguintes questões que são ambíguas nos estatutos e documentos de políticas e instou a comunidade a implementar políticas que ajudariam a equipe a compreendê-las e interpretá-las mais facilmente.

• Cláusula 6.1 (i) do estatuto: “qualquer Pessoa que esteja geograficamente baseada e fornecendo serviços na região africana, e que esteja envolvida no uso ou no fornecimento de serviços de rede de protocolo de sistema aberto; ou ”. A cláusula não é muito clara sobre “prestação de serviços na região africana” e precisa ser esclarecida.

• Política de alocação adicional: “Um LIR pode receber uma alocação adicional quando 80% de todo o espaço de endereço atualmente alocado a ele tiver sido utilizado em atribuições e / ou subalocações válidas”.A AFRINIC encontrou repetidamente problemas em que os LIRs não desejam registrar o uso de seus clientes para questões de privacidade e isso precisa da opinião da comunidade por meio de políticas sobre como lidar com o problema.

• Política para usuário final IPv4 (PI) espaço exige que os membros “Mostram uma utilização existente de pelo menos / 25 de seu provedor de upstream ou justificam a necessidade imediata de pelo menos 50% do espaço solicitado atualmente”. Observou-se que muitas organizações de usuários finais não atendem a essas condições, mas precisam legitimamente do espaço por motivos como multi-homing.

• Constatou-se que não existe uma política de tratamento de transferências internas de recursos em função de fusões, aquisições e solicitações de transferências voluntárias.

12.0 Horário da Política de Abertura