[GTER] Fwd: IP Geofeed Tuner for RFC8805 feeds - AI Skill tool @ v0.0.9 pre-release

[Douglas Fischer]

Olá, Job!.
Não sei se eu te entendi bem, mas creio que o ponto de dor aqui é outro.

Na atual metodologia implementada pelo Registro.BR, se eu sou Owner dos
blocos 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, eu tenho que criar e
publicar um arquivo diferente para cada um desses blocos.
Se eu publico as Geofeeds de todos esses blocos num mesmo arquivo, o
mecanismo de validação do Registro.BR "reclama" de que há inconsistências
no arquivo e não permite efetivar a inserção da informação de Geofeed.
Algo que não faz nenhum sentido do ponto de vista operacional para o
dia-a-dia de um operador de redes.
- Torna mais complicado se for implementação manual.
- Torna mais complicado se for implementação automatizada.

Torna simples operacionalizar a validação dos dados do conteúdo do arquivo
apontado do ponto de vista de quem se propõe a fazer essa validação.
Mas torna bastante mais complicado operacionalizar os geofeeds no dia-a-dia.


Em qui., 14 de mai. de 2026 às 16:23, Job Snijders <job at bsd.nl> escreveu:

> On Thu, May 14, 2026 at 09:47:01AM -0300, Douglas Fischer via gter wrote:
> > Em seg., 4 de mai. de 2026 às 15:34, Marcelo Gondim via gter <
> > gter at eng.registro.br> escreveu:
> >
> > > Na própria RFC8805 [1] encontramos diversos exemplos com apenas 1
> > > arquivo contendo as informações:
> >
> > Exato! Disse tudo!
> >
> > Entendo (e admiro, e defendo) a preocupação do Registro.BR de sempre
> gerar
> > informações consistentes!
> > P.S.: Exemplo disso é o quanto eu apanho LACNOG que os prefixos deveriam
> > estar obrigatoriamente vinculados a um ASN do mesmo Owner. Jeito certo
> que
> > o Registro.BR faz!
> >
> > No entanto, não cabe ao RIR/NIR/LIR validar se tudo que está no arquivo
> > contendo a lista de geofeed está correto por inteiro.
> > Cabe ao consumidor das informações saber filtrar e consumir apenas as
> > entradas da lista que se referem ao bloco cujo qual o geofeed apontou
> para
> > aquele arquivo[1].
> >
> > Sendo assim, pedimos que re-avaliem esta restrição de um arquivo por
> bloco,
> > que salvo engano não está coberto nem pelos MUST/MUST-NOT e nem pelos
> > SHOULD/SHOULD-NOT da RFC.
>
>
> I thought the Finding Geofeed idea was that multiple blocks can refer to
> a single Geofeed file, NOT that a single block can refer to multiple
> geofeed files (which sounds inefficient). See section 3 in RFC 9632:
>
>         """
>         Any particular inetnum: object SHOULD have, at most, one geofeed
>         reference, whether a remarks: or a proper geofeed: attribute when
> it is
>         implemented.
>         """
>
> Kind regards,
>
> Job
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação