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]/
[routing-wg] AS201640
- Previous message (by thread): [routing-wg] AS201640
- Next message (by thread): [routing-wg] AS201640
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Sun Nov 9 20:33:21 CET 2014
In message <35CC580F-0722-4973-A1E6-9F14A63A6D64 at steffann.nl>, Sander Steffann <sander at steffann.nl> wrote: >> Everybody is _supposed_ to have working e-mail address contacts in their >> IP allocation records within the WHOIS data bases of the various RiRs, >> yes? So suppose that there had been a protocol in place that required >> an affirmative e-mail response from at least one legitimate IP address >> block registrant (in some/any region) before the allocation of an AS >> number would proceed. Such a protocol would have forestalled the >> situation that we now see with AS201640, would it not? > >It is a possible implementation but one that only has a one-time check. >It wouldn't keep track of changes to resources in other regions. The >working group asked the RIPE NCC to look into the possibilities and >report back to the working group. Let's see if there is a easy to use >solution that makes sure we don't import data into our database that >then end up being invalid or outdated. I agree that this is an emminently reasonable way to proceed. And yes, as we now know, a simple one-time up-front check of the kind I described would _not_ have prevented the sitiation with AS201640 from arising, because that AS _did_ start out life with its own legitimate /24 allocation... which was subsequently withdrawn. So in this case, the kind of consistancy check I proposed would have been no help at all in preventing what ultimately ensued. (And in fact, that initial & temporary /24 allocation for AS201640 would seem to have been deliberately *engineered* to defeat exactly such a check, even if such a thing had been in place at the time AS201640 was created.) Regards, rfg
- Previous message (by thread): [routing-wg] AS201640
- Next message (by thread): [routing-wg] AS201640
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]