Email: jordi.palet@consulintel.es

Email: jordi.palet@theipv6company.com

A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe
cífico, e se pode ser aplicada a outros casos de registros no whois.

A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder a
ssim informar os casos de abuso e resolvê-los.

A comunidade da Internet é baseada na colaboração, mas muitas vezes isso não é suficiente, pelo que seria necessário que
todos nós pudéssemos contatar com aqueles LIRs ou outros receptores de recursos de LACNIC que têm um problema na rede,
mas não o conhecem.

Esta proposta cria uma nova seção no manual de políticas, para permitir resolver este problema mediante uma simples veri
ficação periódica, e estabelece as regras básicas para isso e, assim, evitar custos desnecessários para terceiros em sua
função de contatar com os responsáveis de resolver os abusos de uma determinada rede.

A proposta garante que o custo do processamento dos abusos fica por conta do LIR cujo cliente está causando o abuso (e d
o qual recebe compensação financeira pelo serviço), em vez de recair sobre a vítima, como aconteceria se houvesse que ir
ao tribunal, evitando assim o agravamento econômico (advogados, procuradores, etc.) e no tempo, para ambas as partes.

Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o
bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co
ntato de abuso, que deve conter no mínimo o atributo "abuse-mailbox".

A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe
cífico, e se pode ser aplicada a outros casos de registros no WHOIS.

Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou a
inda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativame
nte monitorada.

A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos pa
ra as vítimas.

Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos
desnecessários para terceiros.

A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente (
seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sob
re a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem
para essa instância.

Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o
bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co
ntato de abuso, que irá conter no mínimo o atributo "abuse-mailbox".

Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final
do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as nova
s seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta passa a
ser, portanto, a seção 12.

12. Registro e validação de "abuse-c" e "abuse-mailbox"

12.2. Características do "abuse-mailbox"

Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e
não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo
por spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam, evite sua rece
pção.

A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número
de ticket, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer
o uso de um formulário, pois isso implicaria que cada empresa que precise denunciar abusos, geralmente de forma automat
izada,

seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que far
ia com que o custo do processado dos abusos caísse em quem envia a reclamação e, portanto, é vítima de abuso, em vez de
ser paga por aquele cujo cliente (e de quem recebe renda), causa o abuso.

Para fins de informação, vale a pena mencionar que o razoável é que a pessoa que denuncia o abuso, faça isso desde o pri
meiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou se
us cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial d
e auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunida
de de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban,
SpamCop ou outros, com um custo mínimo para ambas as partes.

12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"

1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem os relatórios de abuso, ver
ificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolve
r riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação.

2) Impedir um processo exclusivamente automatizado.

3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox"
, que toma medidas e responde ao relatório de abuso.

4) Prazo de validação “inicial” não superior a 15 dias.

5) Se não for validado corretamente, “escalado” com o receptor do recurso (LIR, usuário final, etc.) e um novo prazo,
não superior a 15 dias.


Os prazos de validação "inicial" e "escalado" poderão ser modificados por LACNIC, se considerar apropriado, informando a
comunidade dos motivos. Por exemplo, poderiam ser reduzidos uma vez que uma alta porcentagem de contatos tenha sido val
idada de forma inicial, de modo que a qualidade dos contatos é incrementada e o tempo de resposta para os casos de abuso
é reduzido.

(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).

12.4. Validação do "abuse-c"/"abuse-mailbox"

LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são
criados quanto modificados, periodicamente, não menos de duas vezes por ano e a qualquer momento que LACNIC considerar o
portuno..

A frequência periódica de validação poderia ser modificada por LACNIC, se considerar apropriada, informando à comunidade
os motivos. Por exemplo, uma única validação poderia ser realizada no primeiro ano, para facilitar o tempo de adaptação
à política e, posteriormente, progressivamente, aumentar o número de validações anuais, chegando a ser inclusive trimes
trais ou mensais, com o objetivo de aumentar a qualidade dos contatos.

A critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalad
o de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.
*, e até mesmo modificar o assunto e o corpo da mensagem,

A violação por parte de qualquer organização, implicará inicialmente o bloqueio de "milacnic" para todos os recursos ass
ociados com essa organização, exceto para a atualização dos contatos abuse-c/abuse-mailbox, de tal forma que possam ser
revalidados para permitir o desbloqueio de "milacnic".

LACNIC realizará um acompanhamento mais exaustivo e, no caso em que na validação automática seguinte continue sendo conf
irmado o descumprimento, agirá de acordo com as políticas e procedimentos pertinentes de LACNIC e, especialmente, "7.1.
Recuperação de recursos”.

12.5. Mecanismo de escalado para LACNIC

CA fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assu
nto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos d
e abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC será disponi
bilizada uma caixa de correio (por exemplo, “escalado-abusos@lacnic.net”), que permita escalar as referidas situações, p
ermitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a
aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos”.

12.1. Descrição do "abuse-c" e "abuse-mailbox"

Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre
spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado
e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e
semelhantes.

O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.

O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de
spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de
resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportu
nidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2
ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete ti
ver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).

12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"

Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.

(Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).

12.4. Validação do "abuse-c"/"abuse-mailbox"

LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c"
forem criados ou modificados.

Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi
so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina
l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod
erão ser usados.

Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.

12.6. Mecanismo de escalado para LACNIC

Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ
ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a
buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.

Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final
do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as nova
s seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta passa a
ser, portanto, a seção 12.

12. Registro e validação de "abuse-c" e "abuse-mailbox"

12.2. Características do "abuse-mailbox"

Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e
não podem estar filtrados, pois isso poderia impedir, que em alguns casos, o envio de um relatório de abuso, por exemplo
por spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam, evite sua rece
pção.

A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número
de ticket, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer
o uso de um formulário, pois isso implicaria que cada empresa que precise denunciar abusos, geralmente de forma automat
izada,

seja forçada a desenvolver uma interface específica para cada caso de abuso, o que é inviável e ilógico, uma vez que far
ia com que o custo do processado dos abusos caísse em quem envia a reclamação e, portanto, é vítima de abuso, em vez de
ser paga por aquele cujo cliente (e de quem recebe renda), causa o abuso.

Para fins de informação, vale a pena mencionar que o razoável é que a pessoa que denuncia o abuso, faça isso desde o pri
meiro momento e nesse primeiro relatório, enviando os logs ou cópia do spam (anexando um exemplo do e-mail de spam ou se
us cabeçalhos completos) ou similares, que demonstrem o abuso. Da mesma forma, é razoável esperar que o e-mail inicial d
e auto-resposta indique que, se esses registros não tiverem sido enviados, não serão atendidos, dando assim a oportunida
de de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban,
SpamCop ou outros, com um custo mínimo para ambas as partes.

12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"

1) Processo simples que garanta a sua funcionalidade e permita aos "helpdesk" que atendem os relatórios de abuso, ver
ificar que os pedidos de validação são realmente provenientes de LACNIC e não de terceiras fontes (o que poderia envolve
r riscos de segurança), evitando, por exemplo, uma única URL "direta" para a validação.

2) Impedir um processo exclusivamente automatizado.

3) Confirmar que quem valida garante conhecer o procedimento, a política, que monitora regularmente o "abuse-mailbox"
, que toma medidas e responde ao relatório de abuso.

4) Prazo de validação “inicial” não superior a 15 dias.

5) Se não for validado corretamente, “escalado” com o receptor do recurso (LIR, usuário final, etc.) e um novo prazo,
não superior a 15 dias.


Os prazos de validação "inicial" e "escalado" poderão ser modificados por LACNIC, se considerar apropriado, informando a
comunidade dos motivos. Por exemplo, poderiam ser reduzidos uma vez que uma alta porcentagem de contatos tenha sido val
idada de forma inicial, de modo que a qualidade dos contatos é incrementada e o tempo de resposta para os casos de abuso
é reduzido.

(como exemplo, propõe-se um procedimento detalhado em "Informações adicionais" desta proposta de política).

12.4. Validação do "abuse-c"/"abuse-mailbox"

LACNIC validará o cumprimento dos pontos acima, tanto no momento em que os atributos "abuse-c" e/ou "abuse-mailbox" são
criados quanto modificados, periodicamente, não menos de duas vezes por ano e a qualquer momento que LACNIC considerar o
portuno..

A frequência periódica de validação poderia ser modificada por LACNIC, se considerar apropriada, informando à comunidade
os motivos. Por exemplo, uma única validação poderia ser realizada no primeiro ano, para facilitar o tempo de adaptação
à política e, posteriormente, progressivamente, aumentar o número de validações anuais, chegando a ser inclusive trimes
trais ou mensais, com o objetivo de aumentar a qualidade dos contatos.

A critério de LACNIC, em forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalad
o de acordo com o ponto 12.5), LACNIC, para realizar as referidas validações, poderá usar domínios que não sejam lacnic.
*, e até mesmo modificar o assunto e o corpo da mensagem,

A violação por parte de qualquer organização, implicará inicialmente o bloqueio de "milacnic" para todos os recursos ass
ociados com essa organização, exceto para a atualização dos contatos abuse-c/abuse-mailbox, de tal forma que possam ser
revalidados para permitir o desbloqueio de "milacnic".

LACNIC realizará um acompanhamento mais exaustivo e, no caso em que na validação automática seguinte continue sendo conf
irmado o descumprimento, agirá de acordo com as políticas e procedimentos pertinentes de LACNIC e, especialmente, "7.1.
Recuperação de recursos”.

12.5. Mecanismo de escalado para LACNIC

CA fim de evitar engano (por exemplo, "abuse-mailbox" que respondem somente aos e-mails de LACNIC, a um determinado assu
nto ou corpo da mensagem), ou a violação do restante dos aspectos desta política (a incorreta ou não atenção dos casos d
e abuso) e, portanto, para garantir a qualidade dos serviços na região com os recursos alocados por LACNIC será disponi
bilizada uma caixa de correio (por exemplo, “escalado-abusos@lacnic.net”), que permita escalar as referidas situações, p
ermitindo assim a revalidação (de acordo com o ponto 12.4 acima) e até a intermediação de LACNIC e, quando apropriado, a
aplicação das políticas/procedimentos pertinentes e, principalmente, "7.1. Recuperação de recursos”.

12.1. Descrição do "abuse-c" e "abuse-mailbox"

Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre
spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado
e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e
semelhantes.

O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.

O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de
spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de
resposta automática indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportu
nidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2
ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete ti
ver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).

12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"

Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.

(Na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).

12.4. Validação do "abuse-c"/"abuse-mailbox"

LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c"
forem criados ou modificados.

Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi
so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina
l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod
erão ser usados.

Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.

12.6. Mecanismo de escalado para LACNIC

Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ
ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a
buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.

Exemplo de procedimento de validação.

1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "ab
use-mailbox".

2) Esses e-mails terão exclusivamente formato de texto (e, portanto, ocultam URLs que correspondem a ataques como "ph
ishing" etc.).

3) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e p
oderá conter informações sobre o procedimento, extrato desta política, etc.

4) O segundo dos e-mails vai conter um código alfanumérico único de validação.

5) O receptor que atende o "abuse-mailbox" deverá acessar à URL e colar no formulário o código recebido no segundo e-
mail.

6) Essa URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um
texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-
mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que
deve ser necessariamente aceito.

7) O código alfanumérico apenas será válido por um máximo de 2 dias úteis.

8) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará
a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.

9) No caso de não obter uma resposta com a confirmação da correção da situação, em um período adicional de 3 dias úte
is, o "abuse-c" será marcado de forma permanente como "inválido".

O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como
"válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política.

Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final
do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as nov
as seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna-
se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consen
so tenha sido alcançado.

O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de aju
da), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quand
o este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de dis
cussões relacionadas a políticas de abuse-c na comunidade global.

1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse
-mailbox".

2) Esses e-mails terão exclusivamente formato de texto (e, portanto, ocultam URLs que correspondem a ataques como "phish
ing" etc.).

3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de esca
lado de acordo com o ponto 12.6), LACNIC, para realizar as referidas validações, poderá usar domínios diferentes a lacni
c.*, e até mesmo modificar o assunto e corpo da mensagem.

4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e pode
rá conter informações sobre o procedimento, extrato desta política, etc.

5) O segundo dos e-mails vai conter um código alfanumérico único de validação.

6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e colar no formulário o código recebido no segundo e-ma
il.

7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um te
xto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mai
lbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que de
verá ser necessariamente aceito.

8) O código alfanumérico apenas será válido por um máximo de 15 dias.

9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a
equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.

10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "ab
use-c" será marcado de forma permanente como "inválido".

11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado c
omo "válido" se for satisfatório, caso contrário, seria um caso de incumprimento da política.

12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se quei
ra denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação da
s políticas, procedimentos e requisitos contratuais em vigor.

Uma proposta semelhante está sendo encaminhada no RIPE, embora ainda esteja em debate e tenha alcançado consenso. Trata-
se de uma versão muito mais simples, e foi apresentada uma nova versão equivalente a esta mesma proposta. Em APNIC alcan
çou consenso uma versão equivalente a esta proposta. No AfriNIC, foi apresentada a mesma proposta.

Em APNIC, uma versão equivalente a esta proposta chegou a consenso.

No RIPE, uma proposta semelhante foi adotada, mas apenas para verificação automática, e o recente debate na lista indico
u precisamente a necessidade de fazê-lo de maneira "não exclusivamente automática", uma vez que o procedimento atual per
mite inúmeras fraudes.

Além disso, uma proposta equivalente está sendo processada e será publicada em breve.

Em AfriNIC e ARIN se apresentou uma proposta equivalente.