This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
- Previous message (by thread): [db-wg] Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
- Next message (by thread): [db-wg] Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cynthia Revström
me at cynthia.re
Sat Jul 9 19:04:05 CEST 2022
Hi Sylvain, Is your issue simply with using 128.9.0.0/16 and 128.9.128.5/32 as examples rather than a prefix reserved for documentation or something like 192.168.0.0/16? (there is no /16 for documentation purposes afaik) It is a bit difficult for me to understand what you mean so please correct me if I misunderstood. I assume INR means Internet Number Resource? -Cynthia On Fri, Jul 8, 2022 at 10:37 PM Sylvain Baya via db-wg <db-wg at ripe.net> wrote: > > 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 at shalom:~$ whois -h whois.ripe.net -t route | grep --regexp="^holes" --after-context=0 > holes: [optional] [multiple] [ ] > </paste1> > [2]: <paste2> > cacty at 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. > > > -- > > Best Regards ! > baya.sylvain [AT cmNOG DOT cm] |cmNOG's Structure|cmNOG's Surveys > Subscribe to the cmNOG's Mailing List > __ > #LASAINTEBIBLE|#Romains15:33«*Que LE #DIEU de #Paix soit avec vous tous! #Amen!*» > #MaPrière est que tu naisses de nouveau. #Chrétiennement > «*Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!*» (#Psaumes42:2) > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
- Previous message (by thread): [db-wg] Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
- Next message (by thread): [db-wg] Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]