Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

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

Imprimir amigável, PDF e e-mail

 Data: 19 de junho de 2019

Onde: Kampala, Uganda

Copresidentes: Adewole Ajao, Sami Salih (remoto) 

 

Versão PDF

 

Agenda

  1. Bem-vindo, introdução e visão geral da agenda
  2. Código de Conduta, O PDR AFRINIC
  3. Relatório de Experiência de Implementação de Política
  4. Proposta de política: Multihoming não exigido para ASN
  5. Proposta de política: IPv4 Inter-RIR Transferências de recursos herdados

Proposta de política: IPv4 Inter-RIR Transferências de recursos (escopo abrangente)

  1. Proposta de política: atualização SL
  2. Proposta de política: IPv6 Esclarecimento PI
  3. Proposta de política: abuso de atualização da política de contato
  4. Proposta de política: Revisão dos recursos de número da Internet por AFRINIC
  5. Proposta de política: disposições para o seqüestro de recursos
  6. Proposta de política: Processo de desenvolvimento de políticas da AFRINIC
  7. Eleições do PDWG
  8. Eleições ASO / AC
  9. Microfone de política aberta

 

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

Dewole deu as boas-vindas aos delegados na reunião, informou que esta seria sua última reunião como co-presidente e analisou a agenda do dia.

 

2.0 Código de Conduta, O PDR AFRINIC

Uma breve descrição do PDP foi compartilhada da seguinte forma:

  • É um processo aberto, de baixo para cima e transparente, onde qualquer pessoa pode enviar uma proposta e participar de discussões sobre políticas.
  • Uma proposta de política é enviada ao Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo. lista de discussão
  • A proposta é discutida na lista por um período mínimo de quatro semanas e apresentada em uma reunião de políticas públicas para discussões presenciais e busca de consenso.
  • Se houver consenso na reunião presencial, a proposta avança para um "período de última chamada" que deve durar uma duração mínima de 2 semanas, caso haja problemas de indivíduos que não tiveram a chance de participar. Se não houver consenso na reunião presencial, a proposta retornará à fase de discussão da lista de discussão.
  • Se o consenso for mantido após o encerramento da última chamada, os copresidentes recomendam que a Diretoria ratifique a proposta de política. O Conselho o ratificará e o AFRINIC o implementará como uma política.

 

No código de conduta, observou-se que:

  • A comunidade é formada por pessoas de diferentes origens e culturas
  • Qualquer pessoa que participe de discussões pessoalmente ou remotamente deve se comportar profissional e respeitosamente.
  • Assédio, intimidação ou comportamento ofensivo não são tolerados. Os participantes devem tratar os outros com polidez e respeito.
  • Comportamentos ou observações que ofendem ou discriminam com base em gênero, orientação sexual, religião, raça ou origem étnica, idioma ou outras diferenças sociais, culturais ou pessoais percebidas devem ser evitados.
  • Ataques pessoais devem ser evitados.
  • Comentários devem permanecer no tópico, respeitando o tempo permitido.

 

3.0 Relatório de Experiência de Implementação de Política (PIER) 

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/5785/1-2019%20PIER%20AIS19%20(1).pdf

Isso foi apresentado por Kheesun Fookeerah (equipe da AFRINIC), que informou que o PIER contém informações sobre políticas implementadas recentemente em uma parte e experiências e recomendações da equipe, enquanto coloca as políticas implementadas em prática na outra parte. O PIER também, como de costume, destacará a seção do CPM (manual de política consolidada) que ainda é ambígua para a equipe interpretar corretamente.

Keesun apontou que as políticas implementadas recentemente são IPv6 Atualização de PI, Esclarecimento sobre IPv6 subatribuições e Lame Delegations no DNS reverso. A implementação para alguns ainda não é de 100%, pois ainda existem algumas atividades de automação em andamento.

Destaques do PIER em conteúdo ambíguo de CPM: 

  • CPM seção 5.4 (Soft Landing) é considerada a política padrão usada nesta fase de exaustão de IPv4 espaço, entretanto, não se alinha com algumas outras seções do CPM, como a utilização de 90% em 5.4 para se qualificar para endereços adicionais vs.
  • CPM 5.7.1 permite Intra-RIR transferências de IPv4 espaço e não atende a outros recursos, como ASN e IPv6. Também não está claro como lidar com as transferências resultantes de fusões e aquisições.
  • A seção nas janelas de Subalocação com um limite de 12 meses no espaço permitido a ser subalocado não está alinhada com o limite de 8 meses na política de Soft Landing.
  • Durante a fase 2 do pouso suave, o máximo permitido IPv4 o espaço a ser emitido é / 22 vs as outras seções onde / 22 é o mínimo.

 

Kheesun instou os membros da comunidade a estudarem o exposto acima e se forem necessárias algumas novas propostas para alinhar o conteúdo do CPM, incentivamos os membros a participar na criação de propostas que melhorem a compreensão e a interpretação do CPM. 

 

4.0 Proposta de política: Multihoming não exigido para ASN 

URL da propostahttps://www.afrinic.net/policy/proposals/2019-asn-001-d2#proposal
Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/2-Jordi-AFPUB-2019-ASN-DRAFT02.pdf

 

O autor compartilhou os seguintes pontos em relação a esta proposta:

  • Quando o ASN A política de atribuição foi originalmente projetada, a principal preocupação era que 16 bits é um espaço de endereço limitado (RFC1930, seção 9).
  • Isso não é mais um problema com números AS de 32 bits (RFC6793). Se cada um dos cinco RIRs deviam atribuir 100 números AS por dia, 365 dias por ano, levaria mais de 20,000 anos para esgotar o espaço de 32 bits.
  • Quando inicial ASN políticas foram desenvolvidas, a confiabilidade das redes não era tão boa naquela época e fazia sentido que as empresas precisassem de um ASN ser multihomed.
  • Hoje, isso não é necessariamente um requisito razoável. Algumas redes podem exigir um ASN embora não esteja disposto a ser multihomed.
  • O aumento IPv6 implantação também exigiu a necessidade de as empresas anunciarem seus IPv6 espaço com seu próprio ASN sem a necessidade de ser multihomed.
  • O autor afirmou que o ARIN e o LACNIC já possuem essa política e que uma proposta equivalente alcançou consenso na APNIC47. Ele também afirmou que enviará uma proposta semelhante à comunidade RIPE muito em breve.

 

Esta proposta modifica o CPM, inserindo uma cláusula em 7.2, afirmando que as organizações que precisam de um exclusivo ASN deve demonstrar uma política de roteamento exclusiva ou um plano para interconectar com um ou mais outros Sistemas Autônomos. Se a organização também demonstrar que atenderá a qualquer um desses critérios de requisitos dentro de seis meses após o recebimento do ASN, então será elegível.

Uma visão geral das reações dos delegados: 

  • Multihoming ou não não tem nada a ver com o número de bits, já que isso não é mais uma preocupação ou qualquer significado porque todos ASNs são emitidos por todos RIRs de 32 bits ASN pool, tornando a declaração do problema imprecisa.
  • RFC1930 contém diretrizes para avaliar ASN pedidos e esta proposta não segue essas orientações. Os processos de avaliação precisam continuar seguindo as diretrizes da RFC1930, como sempre foi o caso.
  • Uma proposta equivalente adotada por alguns RIRs não causou impacto significativo para ASN consumo naqueles RIRs.
  • A proposta parece sugerir que toda organização com IPv6 o espaço pode se aproximar do AFRINIC para um ASN e receba imediatamente.
  • A proposta parece tirar a necessidade de avaliar ASN pedidos com base na necessidade desses recursos, o que apresenta algumas preocupações.
  • Alguns observaram que não há necessidade de alinhar com o RFC1930 e que a política deve ser flexível e não depender dos RFCs.

 

Decisão do copresidente:

Sem consenso - A proposta precisa de discussão adicional, portanto, retorna ao estágio de discussão na lista de discussão. 

 

5.0 Propostas de política: IPv4 Inter-RIR Transferências de recursos herdados

IPv4 Inter-RIR Transferências de recursos (escopo abrangente)

URLs da proposta:

https://www.afrinic.net/policy/proposals/2019-v4-001-d1#proposal

https://www.afrinic.net/policy/proposals/2019-v4-002-d1#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2019-v4-001-002.pdf 

 

O autor explicou que essas duas propostas permitem a transferência de IPv4 espaço de e para AFRINIC, mas um permite apenas a transferência de legado IPv4 espaço de dentro do AFRINIC enquanto o outro permite todos os tipos de IPv4 espaço.

Ele afirmou que essas são duas propostas de políticas diferentes tentando abordar o mesmo problema e, em vez de fazer duas apresentações, é muito mais fácil ter um único conjunto de slides, porque a diferença entre o conteúdo dessas duas propostas de políticas é apenas uma frase.

A primeira proposta política - IPv4 Inter-RIR Transferências de recursos herdados permite que o AFRINIC receba qualquer tipo de IPv4 recursos, mas ser capaz de transferir apenas para outras regiões, aqueles IPv4 recursos que são estritamente legados.

A segunda proposta de política -  IPv4 Inter-RIR Transferências de recursos (escopo abrangente)

Permite a transferência bidirecional de qualquer tipo de IPv4 Recursos.

A razão de ter essas duas propostas é porque há muita preocupação de algumas pessoas que se a porta para as transferências for aberta, todos IPv4 recursos que temos na região vão sair. As preocupações dessas pessoas são tratadas pela primeira proposta, para que apenas o espaço legado possa sair do continente. O autor observou que qualquer proposta aceita fará com que a outra seja automaticamente abandonada.

Mais comentários do autor:

  • No momento, todas as outras regiões já adotaram uma proposta de política para transferências e todas elas não têm restrições.
  • Com a África não tendo o suficiente IPv4 recursos, limitando a opção de transferências de entrada de IPv4 espaço torna difícil a oportunidade de criar novos negócios que precisarão IPv4 Recursos. Para piorar as coisas, a fase 2 do soft-landing diminuirá muito o número de recursos que as organizações da AFRINIC podem obter.
  • Já existe uma situação de mercado em que as organizações membros da AFRINIC estão vendendo recursos ilegalmente e por baixo da mesa, esta política apenas torna oficial para que tais transações sejam realmente refletidas oficialmente no whois db quando eles acontecem.
  • Implantando IPv6 agora requer algum IPv4 espaço. Se não sobrar nenhum e nenhum mecanismo de transferência para trazer alguns para o continente, IPv6 a adoção ficará estagnada.

 

Reações do chão e remotamente:

  • Várias declarações foram lidas em apoio à proposta de permitir o Inter RIR transferências de IPv4 espaço.
  • Foram levantadas preocupações sobre o fato de que não temos necessariamente que fazer o que o outro RIRs fizeram, pois suas especificidades podem não se aplicar à África e AFRINIC.
  • Observou-se que os recursos AFRINIC devem ser estritamente utilizados na África, pois a região ainda está crescendo em conectividade com a Internet.
  • Houve pedidos para que uma auditoria do uso de recursos, especialmente aqueles no mercado, conforme declarado pelo autor, fosse conduzida para orientar a comunidade no caminho a seguir.
  • Observou-se que a declaração do problema não é precisa e contém algum conteúdo que deve ser removido.
  • Alguns palestrantes afirmaram que quando IPv4 o espaço eventualmente se esgota no AFRINIC, esta proposta permitirá o movimento interno do espaço para a África, o que é uma coisa boa para o continente.
  • Os recursos da AFRINIC devem ser transferidos apenas para o continente por enquanto, mesmo depois da exaustão, e não para o exterior. No entanto, os recursos recebidos não devem causar danos, desde que não haja saída.
  • Assinalou-se que comunidades como a ARIN insistirão na reciprocidade pela justiça, de modo que não permitirão a transferência para a África se a África não puder transferir para elas.

 

Decisão do copresidente:

Sem consenso - Essas duas propostas precisam de discussão adicional; portanto, retornem ao estágio de discussão na lista de discussão.

 

6.0 Proposta de política: atualização SL 

URL da proposta:

https://www.afrinic.net/policy/2018-v4-001-d1#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2019-v4-001-002.pdf

Os autores compartilharam os seguintes destaques desta proposta:

  • Na seção 5.4.7.1 do CPM (política de aterragem suave), a / 12 é reservada a partir do último / 8 para alguns usos futuros imprevistos.
  • No mesmo CPM 5.4.7.2, o Conselho, a seu critério e considerando a demanda e outros fatores no momento em que AFRINIC não pode mais atender a mais solicitações de espaço de endereço do último / 8 ou qualquer outro espaço de endereço disponível, pode 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 seja no melhor interesse da comunidade. 

A seção 5.4.7.2, portanto, dá ao conselho autoridade exclusiva para decidir sobre como usar o bloco reservado / 12 para, eventualmente, reabastecer o pool de exaustão e determinar suas regras de alocação e designação. Este mandato deve ser determinado pela comunidade e não pelo conselho.

  • 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 pode agir a seu critério com ou sem o envolvimento e consentimento da comunidade.
  • A comunidade está em melhor posição para determinar o que é do seu interesse e isso é melhor discutido através do PDP.

 

Portanto, os autores propõem que 5.4.7.2 tenha a seguinte redação: “Se o / 12 reservado não for usado até o momento em que o espaço disponível restante foi alocado, o / 12 será retornado ao pool do AFRINIC para distribuição nas condições da fase 2 do política de pouso suave ”- portanto, dando poder à comunidade para decidir como usar isso / 12.

Os autores também apontaram que essa proposta de política foi apresentada inicialmente na Hammamet, na Tunísia, mas enviada de volta à lista de discussão para obter mais contribuições e aprimoramentos da comunidade. No entanto, nenhum foi recebido, portanto, ainda é a mesma versão do Hammamet.

 

Decisão do copresidente:

Consenso - A proposta avança para Última chamada.

 

7.0 Proposta de política: IPv6 Esclarecimento PI

URL da proposta: https://www.afrinic.net/policy/proposals/2019-v6-001-d2#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/2-Jordi-AFPUB-2019-v6-001-DRAFT02.pdf

O autor compartilhou os seguintes destaques desta proposta de política:

  • Uma proposta de política chamada “IPv6 PI Update ”foi aprovado em Hammamet na última reunião do AFRINIC e foi implementado.
  • Essa proposta negligenciou alguns problemas da política existente, nomeadamente - a necessidade de demonstrar que o PI IPv6 o espaço emitido deve ser anunciado dentro de doze meses e, se não for anunciado, o espaço deve ser recuperado e devolvido ao pool gratuito pela AFRINIC.
  • Em alguns casos de uso, porém, como nos IXPs, o espaço nunca será anunciado.
  • Portanto, esta proposta corrige isso com o novo texto proposto: “Se o espaço de endereçamento emitido sob esta política for anunciado, na medida do possível, a organização deve agregar qualquer anúncio de prefixo para minimizar o crescimento da tabela de roteamento global”

As reações recebidas foram principalmente declarações de apoio à proposta de política.

 

Decisão do copresidente:

Consenso - A proposta avança para Última chamada. 

 

8.0 Proposta de política: abuso de atualização da política de contato

URL da proposta: https://www.afrinic.net/policy/proposals/2018-gen-001-d3#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/3-Jordi-AFPUB-2018-GEN-001-DRAFT03.pdf

Resumo do problema, conforme compartilhado pelo autor: 

  • A atual política de registro de contatos de abuso não tem a simples obrigação de registrar um contato de abuso em relação a um único endereço de e-mail destinado a esse fim.
  • Como resultado, alguns membros podem não ter essas informações de contato registradas e atualizadas para seus recursos. De fato, existem até casos de membros que usam uma caixa de correio inexistente ou uma que não é monitorada ativamente.
  • Na prática, esse contato se torna ineficaz por relatar atividades de abuso de rede e geralmente gera problemas de segurança e custos relacionados às vítimas.
  • Esta proposta visa solucionar este problema e garantir a existência de um contacto adequado de abusos e de um processo para a sua validação, que o torne uniforme em todos RIRs. Isso, por sua vez, facilita a denúncia de abusos entre regiões.
  • A política existente refere-se a um “Documento de Boas Práticas”, que não é considerado obrigatório - na verdade, não está sendo usado pela comunidade. Essa proposta não altera o escopo desse documento e, de fato, um vínculo entre os poucos objetos IRT existentes e a nova caixa de correio de abuso proposta aqui deve ser estabelecido automaticamente.
  • Esta proposta permite uma verificação periódica simples de um contato de abuso declarado e estabelece as regras básicas para a realização dessas verificações.

 

O autor afirmou que o atributo abuse-c proposto será obrigatório nos objetos "aut-num", "inetnum" e "inet6num", bem 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". 

As reações foram recebidas da seguinte forma: 

  • A equipe comentou que já existe um objeto IRT no banco de dados que pode conter mais informações além de um endereço de email e recomendou que seja melhor tornar obrigatório o IRT.
  • O autor esclareceu que o IRT pode ficar e pode ser transformado em pseudônimo. Ele também afirmou que outro RIRs não estão usando o IRT.
  • A equipe esclareceu que é confuso usar a TRI como alias e não saberia como implementar esse requisito.
  • Observou-se que o AFRINIC como registro deve garantir que, por contrato com os membros, tenha informações mais precisas sobre esses membros. A equipe apontou que as informações de contato de abuso geralmente não são solicitadas nos contratos assinados com os membros.
  • Assinalou-se que antes havia negação ou direito de voto se contatos de abuso não pudessem ser verificados, cuja punição não é proporcional à causa.
  • Havia várias preocupações de que essa política talvez não fosse necessária e que o AFRINIC possa ter esse mecanismo internamente por meio da RSA. Foi proposto que isso se tornasse um processo interno do AFRINIC (em vez de uma política) para coletar e validar contatos de abuso, assim como o AFRINIC deve estar coletando e validando outros tipos de contatos sem a necessidade de uma política.
  • Foram recebidas algumas declarações contrárias à proposta, algumas notando que o AFRINIC é um registro, não a polícia da Internet e deve atuar como um registro.

 

Decisão do copresidente:

Sem consenso - A proposta precisa de discussão adicional, portanto, retorna ao estágio de discussão na lista de discussão.

 

9.0 Proposta de política: Revisão dos recursos de número da Internet por AFRINIC

URL da proposta: https://www.afrinic.net/policy/proposals/2016-gen-001-d8#proposal

Apresentação: N / A

Os autores compartilharam estas observações:

  • Esta proposta de política permite que o AFRINIC realize uma auditoria ou revisão de todos os recursos mantidos pelos membros.
  • Os autores observaram que os recursos da AFRINIC não estão à venda - mas são comunitários e existem para atender às necessidades do continente. É contra essa crença que esta proposta e seus sentimentos se baseiam.
  • É muito importante que os recursos dos membros estejam em conformidade com o RSA assinado pelos mesmos membros.
  • A proposta evoluiu através de muitas alterações até a versão mais recente.
  • Para a maioria das disposições políticas da proposta, os autores acreditam que, apesar da política e dos sentimentos, todas as questões foram abordadas até o momento.

Reações do chão e participantes remotos:

  • Na última reunião da AFRINIC, os autores tentaram forçar o público a aceitar a proposta que não estava certa.
  • A proposta levará à instabilidade na comunidade se os recursos forem recuperados sempre que um membro parecer violar a política.
  • O AFRINIC pode não ter os recursos para lidar com o volume de auditorias ou revisões que podem surgir se a proposta for aprovada.
  • A proposta pode não ser aplicável por AFRINIC. A proposta poderia ser aprimorada para atingir aqueles que usam os endereços no mercado negro, a fim de minimizar o mercado negro. Embora os autores tenham declarado que os recursos não estão à venda, as vendas reais estão ocorrendo em um mercado secundário.
  • É necessário estabelecer por que alguns recursos não podem ser usados ​​para o propósito original para o qual foram emitidos, pois essa parece ser a base da política. A necessidade pode ter mudado, mas ainda pode ser legítima.
  • Muitos argumentos contra esta proposta foram submetidos à lista de discussão várias vezes, estão registrados e a proposta não conseguiu consenso muitas vezes antes e deve ser abandonada.
  • Foi proposto que, devido às muitas vezes em que a proposta foi apresentada e não obteve consenso, os autores deveriam retirá-la.
  • O RSA já possui disposições para revisões sugeridas por esta proposta, portanto, a proposta é uma duplicação do RSA, o que é desnecessário. A RSA exige que os recursos sejam recuperados se um membro estiver violando.
  • Esta proposta está alinhada com a abordagem baseada nas necessidades exigida pela política e, portanto, uma auditoria para as necessidades é sempre relevante para verificar se esse ainda é o caso.
  • Houve várias outras declarações contra e algumas outras em apoio.

 

Decisão do copresidente:

Sem consenso - A proposta precisa de discussão adicional, portanto, retorna ao estágio de discussão na lista de discussão.

 

10.0 Proposta de política: disposições para o seqüestro de recursos

URL da proposta: https://www.afrinic.net/policy/proposals/provisions-for-resource-hijacking#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/Provision%20for%20Resource%20Hijacking.pdf 

O autor observou que esta proposta é sobre o respeito dos direitos exclusivos dos membros aos recursos alocados / atribuídos, quando outras partes não estão autorizadas a usar esses recursos sem consentimento.

O autor reconheceu que esta proposta não é uma questão de encaminhamento porque o AFRINIC não é a polícia de encaminhamento e que as violações da política serão consideradas como aqueles casos em que houve seqüestro e uso claro e intencional de recursos por outra parte.

O autor propôs um processo simples em que a vítima relata um sequestro de recursos, as partes envolvidas são notificadas sobre o assunto, os especialistas revisam e investigam com base nos dados disponíveis e emitem um relatório a partir de sua investigação. É permitido um período para as partes enviarem objeções, e um recurso poderá ser submetido após isso. Se a apelação falhar, o relatório será ratificado e o problema será considerado uma violação da política; caso contrário, o assunto será julgado improcedente. Todo esse processo deve levar no máximo 6 semanas.

O autor observou que é melhor para a comunidade ter tal processo, em vez de deixar que os governos controlem e intervenham. Ele também afirmou que apresentou uma proposta semelhante para cada RIR comunidades.

 

Reações:

  • Foi observado por algumas pessoas que, embora o problema de sequestro de espaço de endereço IP seja real, o PDP em um RIR comunidade é o fórum errado para abordá-lo, pois não há mecanismo de aplicação.
  • RIRs não têm o direito de determinar o direito de uso do espaço de endereço, embora, por meio de um registro preciso, seja possível alguma verificação.
  • Outros notaram que o RIR pode determinar o direito de uso desses recursos, e que o LIR também pode determinar até certo ponto.
  • Houve algumas declarações contrárias à proposta e nenhuma em apoio.

 

Decisão do copresidente:

Sem consenso - A proposta precisa de discussão adicional, portanto, retorna ao estágio de discussão na lista de discussão. 

 

11.0 Proposta de política: Processo de desenvolvimento de políticas da AFRINIC

URL da proposta: https://www.afrinic.net/policy/proposals/2017-gen-002-d5#proposal

Apresentação: https://2019.internetsummit.africa/components/com_afmeeting/speakers/3283/Provision%20for%20Resource%20Hijacking.pdf

Os autores indicaram que neste 5th versão da proposta, a declaração do problema permaneceu basicamente a mesma. As políticas para gerenciar recursos de números IP na região de serviço do AFRINIC são criadas por meio de um Processo de Desenvolvimento de Políticas, que descreve as etapas pelas quais as propostas de políticas são enviadas, consideradas, debatidas e adotadas. O atual manual de políticas consolidadas não possui disposições para adoção de propostas, que analisam a duplicação de propostas que lidam com o mesmo problema, falta de clareza nas declarações e propostas de problemas fora do escopo do PDP. Também não define métodos claros para avançar as propostas.

O processo de consenso para a tomada de decisões também não está definido, abrindo portas para diferentes interpretações e inações. O PDP atual também não possui provisões para a diretoria adotar políticas, conforme a seção 11.4 do estatuto da AFRINIC na variação do processo. 

Declarou-se que, desde a reunião de políticas públicas da AFRINIC em Hammamet, os co-presidentes convidaram os que se opunham a trabalhar com os autores e emitiram uma solicitação para melhorar a última definição de chamada, bem como a definição de consenso.

Os autores também tentaram esclarecer o tempo de implementação após a ratificação e propuseram uma duração máxima de duas semanas para os presidentes moverem uma proposta para a última chamada. A questão das propostas concorrentes é, portanto, abordada desde o início. Havia também a necessidade de os funcionários fornecerem mais informações em seus relatórios de avaliação.

Novas inclusões na versão 5 também incluem o fato de que o consenso é declarado após a última chamada (fase de conclusão) e que recursos podem ser interpostos contra os resultados da fase de adoção.

Há um documento de diretrizes incluído nesta proposta e será parte integrante da proposta e, finalmente, o CPM, se adotado. Este documento contém a adição de assistência em viagem aos autores da proposta (a critério da equipe).

As reações recebidas foram as seguintes:

  • A proposta aborda muitos problemas atuais no PDP, muitos deles testemunhados pelos apelos que tivemos até agora e as muitas ameaças a apelar.
  • A proposta foi contestada por alguns devido à sua complexidade. As várias fases e a documentação separada apenas tornam a implementação mais complexa.
  • Um PDP que não permite propostas concorrentes não é bom, pois a concorrência é saudável e permite melhorias.
  • Um apelo deve ser iniciado por vários membros da comunidade e não apenas por uma pessoa.
  • Os presidentes não devem decidir sobre o conteúdo da declaração do problema, pois isso significa que eles estão gerenciando minuciosamente a comunidade e o processo.
  • O processo precisa permitir que as discussões na lista de discussão contribuam igualmente para as discussões cara a cara.
  • Algumas declarações apoiam a proposta como um passo na direção certa para melhorar o atual PDP.
  • Assinalou-se que problemas específicos do PDP atual não foram tratados adequadamente, um de cada vez, e uma tentativa complexa como essa não será eficaz.

 

Decisão do copresidente:

Sem consenso - A proposta precisa de discussão adicional, portanto, retorna ao estágio de discussão na lista de discussão. 

 

12.0 Eleições do copresidente do PDWG 

A eleição foi para os co-presidentes do PDWG substituirem Sami Salih e Dewole Ajao. A sessão foi liderada por Serge-Parfait Goma, presidente do comitê de indicações de 2019 que informou que havia 8 candidatos para os 2 cargos. Os indicados apresentados foram:

 

Mark Elkins

Caleb Ogundele

Komi ELitcha

Sami Hassan

Moses Serugo

Taiwo Oyewande

Ikechukwu Anthony Ubah

Abdulkarim Oloyede

 

Depois que os candidatos conversaram com os delegados, o comitê de eleições conduziu um exercício de votação em que os participantes foram convidados a selecionar seus dois candidatos preferidos - o candidato com o maior número de votos no mandato de dois anos e o vice-campeão no mandato de 1 ano .

A votação retornou os seguintes vencedores:

Moses Serugo (UG) foi eleito para um mandato de dois anos, de junho de 2019 a junho de 2021;

Abdulkarim Oloyede (NG) foi eleito para um mandato de um ano de junho de 2019 a junho de 2020.

 

13.0 Eleições ASO / AC

O presidente da comissão de nomeações apresentou os candidatos da seguinte forma:

Mike Silber

Mustafa Ben Jemaa

 

O comitê de eleições realizou um exercício secreto de votação para selecionar uma pessoa que substituirá Omo Oaiya cujo mandato expira no final de 2019. Após a votação, Mike Silber (ZA) foi eleito para um mandato de três anos, de janeiro de 2020 a dezembro 2022

 

14.0 Microfone de política aberta

Dewole informou que o MIC aberto é para permitir comentários que foram adiados durante o dia, bem como outros dos participantes remotos e aqueles que poderiam ter sido levantados na lista de discussão.

  • Revise o código de conduta e como ele é aplicado. Muitos comentários na lista e na reunião violam esse código. Não devemos ser hostis e rudes um com o outro, o que torna o ambiente PDP também prejudicial.
  • Os co-presidentes foram aconselhados a usar seus poderes para ligar para pedir a alguém que seja rude e desrespeitoso com os outros.
  • O CPM não indica como deve ser o processo eleitoral do co-presidente do PDWG. Ele afirma que a comunidade deve participar, mas não indica quem constitui a comunidade. Isso precisa de um processo claro para avançar.
  • Houve várias mensagens de parabéns aos novos co-presidentes, bem como votos de agradecimento aos co-presidentes de saída por um trabalho bem-feito.
  • Um voto de agradecimento a Alan por fazer um ótimo trabalho como CEO cessante.
  • O código de conduta em LACNIC tinha problemas semelhantes e eles criaram uma Política de Uso Aceitável, que resolveu esses problemas. Seria bom para um voluntário trazer algo semelhante. A região de LACNIC também propôs um processo de copresidência das eleições para organizá-las e estar funcionando bem.
  • É necessário envolver mais pessoas nas discussões da lista de discussão.
  • Também poderia haver algumas reuniões informais, mas abertas, para discutir propostas de políticas dias antes de serem apresentadas, pois isso poderia melhorar o envolvimento.
  • Um participante mencionou que está feliz em ajudar alguém com uma idéia de uma proposta de política para ajudá-lo a fazê-lo, mesmo que ele não seja reconhecido como coautor.
  • O presidente do Conselho da AFRINIC agradeceu aos copresidentes de saída por um trabalho bem feito e parabenizou os novos copresidentes.
  • É necessário reconhecer participantes remotos nas discussões sobre políticas e votar em todas as eleições.
  • Os copresidentes de saída foram instados a prestar apoio aos de entrada. Os co-presidentes entrantes foram aconselhados a não ter medo de procurar aconselhamento e consultar sempre que necessário. 
Última modificação em -
Data e hora nas Maurícias -