[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 ]
Edward Shryane
eshryane at ripe.net
Mon Jul 11 11:39:15 CEST 2022
Hello Sylvain, Colleagues, > On 9 Jul 2022, at 22:52, Sylvain Baya via db-wg <db-wg at ripe.net> wrote: > ... > > Is your issue simply with using 128.9.0.0/16 <http://128.9.0.0/16> and 128.9.128.5/32 <http://128.9.128.5/32> as > examples rather than a prefix reserved for documentation or something > like 192.168.0.0/16 <http://192.168.0.0/16>? > > > No! as i have tried to say, it's about using an active > prefix, as an example of unreachable network's > prefix. > > ...i understand that it's out there well before it > became reachable; but imho there is no reason > to keep using it for such usecase :-/ > Thank you for pointing this out. The paragraph following the "holes:" attribute definition is intended to describe the format of an address prefix, and the prefixes listed are not examples of holes. I will replace the examples with prefixes reserved for documentation from RFC 5737. Regards Ed Shryane RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20220711/1362948e/attachment.html>
- 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 ]