Re: Question on "Network Number Usage Survey"
- Date: Tue, 23 Jan 1996 02:26:37 -0800 (PST)
- Posted-date: Tue, 23 Jan 1996 02:26:37 -0800 (PST)
>
> Hi Bill (and Suzane and the robot :-)!
Howdy... :)
> > As far as I can tell, RIPE NCC was never delegated this block.
>
> I think that's not *completely* true.
> At least (a small) part of 192 addresses was allocated in Europe by way
> of the RIPE-NCC and the Local Internet Registries.
>
True, and the contacts for the folks will be getting the can'ed
email.
This points out a minor problem with the earlier SWIP efforts:
Taking the first block on your list:
192.162/16 "Various assignments"
36% whois 192.162
RIPE NCC (NETBLK-EUNET-C) EUNET-C 192.162.0.0 - 192.162.255.0
Research Institute for Informatics (NET-RO-EARN) RO-EARN 192.162.16.0
Universidade do Minho (NET-CCDINET-C5-1) CCDINET-C5-1 192.162.128.0
Universidade do Minho (NET-CCDINET-C5-2) CCDINET-C5-2 192.162.129.0
Universidade do Minho (NET-CCDINET-C5-3) CCDINET-C5-3 192.162.130.0
Universidade do Minho (NET-CCDINET-C5-4) CCDINET-C5-4 192.162.131.0
Universidade do Minho (NET-CCDINET-C5-5) CCDINET-C5-5 192.162.132.0
Thats seven queries. The last five could/should be consolidated into
a cidr entries, like the first one.
192.167/16 "GARR NIS" (Italy)
This one is even worse.... :-(
( 192.168/16 "RIPE NCC - RFC 1597" )
And this is one simply appears to be a marker
38% whois 192.168
IANA (IANA-CBLK-RESERVED)
Internet Assigned Numbers Authority
Information Sciences Institute
University of Southern California
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292-6695
Netname: IANA-CBLK1
Netblock: 192.168.0.0 - 192.168.255.0
> > was to use the authoritative delegation registry to verify use.
>
> Formally, I agree.
>
> What hits us here is the fact that we still don't have regular updates
> performed between the "major" rgistries.
> You might even be able to promote that idea...
Interesting point. This is being hashed out with the folks doing
routing registries as well. (there are a few more of them :-)
At least there is a syncronization method (albeit a poor one)
in that venue. Perhaps there should be a strict rule on each IR
(delegation registry) only recording data that it is authoritative
for? We then raise the pointy questions of authority transfer,
granularity of update, validation of "guardian/maintainer", and
a host of others. And life is harder when we have multiple models
on support of the delegation and announcement registries.
> > - If the idea of using the same delegation and routing registry
> > appeals to you, you may want to consider how to return those old,
> > nasty 192 delegations and use the clean blocks from the RIPE NCC.
> > (Here is where PIER might be of help)
>
> Wearing my hat as the RIPE Database WG coordinator,
> could you please point me to the proper place (and procedures)
> to participate in that effort(s).
>
> Thanks
> Wilfried.
Sure. PIER is an IETF WG. See http://www.isi.edu:80/div7/pier/
for more details.
--bill
