Dear DB-WG,

Hopefully this email finds you in good health!

While exploring some RIPE Whois DB classes [1],

i discovered some examples, i thought to be

inappropriate [3].

...i would like to draw to your attention, on the

presence of some INRs [2] managed [3] by an

other RIR, which appear in content returned when

the RIPE Database is queried [2].

__

[1]: <paste1>

cacty@shalom:~$ whois -h whois.ripe.net -t route | grep --regexp="^holes" --after-context=0
holes:          [optional]   [multiple]   [ ]
[2]: <paste2>

cacty@shalom:~$ whois -h whois.ripe.net -v route | grep --regexp="^holes$" --after-context=11
holes

   Lists the component address prefixes that are not reachable through
   the aggregate route(perhaps that part of the address space is
   unallocated).

     An address prefix is represented as an IPv4 address followed
     by the character slash "/" followed by an integer in the
     range from 0 to 32.  The following are valid address
     prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the
     following address prefixes are invalid: 0/0, 128.9/16 since
     0 or 128.9 are not strings containing four integers.

</paste2>

[3]: <https://www.iana.org/assignments/ipv4-address-space/>

Maybe it's the only description which contains such

non-RIPE INRs; other than of RFC 5737 [4]...

__

[4]: <https://www.iana.org/assignments/iana-ipv4-special-registry/>

...but perhaps someone, from the Staff, should check?

Thanks.

Shalom,

--sb.