Hay, On Mon, Sep 01, 2003 at 04:57:44PM +0200, Gert Doering wrote:
Hi,
On Fri, Aug 29, 2003 at 02:00:03PM +0200, Hans Petter Holen wrote: [..]
Don't get me wrong. I'm talking about a special case here, respectively about detailed information as in "equipment specs, model number...ect." as well as stuff like "network plans".
I think the criteria to reveal your network plan has been there since RIPE 185 and even before that.
The network *plan*, yes, but that was mostly unspecific, like "this is the office network, 100 PCs", without having to prove more detail.
...right, and that's perfectly OK. ripe-185 talks about "special circumstances" there, too. [...] Special Circumstances: Sometimes, due to the use of old systems or special purpose hardware, the user is unable to make use of assignments based on classless addressing. If this is the case, information should be gathered from the user as to the specific hard- ware or software which presents a problem. Moreover, it is useful to know how long the user will be using the hardware or software which presents a problem. [...] Nowerdays this would mean "unusual big requests" or so probably. That's OK then of course. I'd be interested in what hardware or software vendor requires a /24 for one host and IP address nowerdays myself for example. ...but a customer still can tell you "all confidental, i tell you i need 250 IP adresses, you give them to me or i go to the next ISP". If you specialize in Security&VPN stuff, it's quite amazing how often you get such answers. Fortunately most customers don't require a big public IP network, using RfC1918 IPs internally so one doesn't have to care about their network plan then.
[..]
I wonder if somebody can point me to when documenting the make, model and version became a generic requirement to get address space became part of the policy.
(Yes I know I have said in (private) conversations that IF this information is a requirement is part of the policy THEN it should be part of the form.)
I agree with you - if it is policy, then it has to be asked by the form.
On the other hand, as for the IPv6 thing, I oppose asking for very fine details that are really not *that* relevant, except for cases that warrant an exception from the usual rules (like in the classful context that you've quoted).
I don't see the need for a _graphical_topology_map_ to be a requirement for any IP request. (even ripe-185 declares that clearly optional :) ) In particular not for an IPv6 Allocation request. Especially if there is a textual description of the IPv6 deployment included in the request. A topology map might be useful to explain unusual request, like big IPv4 request or IPv6 request bigger than a /48 for one end-site or so. I agree that it might be easier to explain things by painting maps and diagrams for some people. It's very nice that RIPE NCC accepts this method if needed. Although, some like me, prefer to explain things in text form and consider that a more efficient way. RIPE hostmasters should be trained to understand explainations from the written word, too. I understand that this might delay requests, that's perfectly OK though. Given the current response times which are quite excellent, i still see an advantage of answering specific question about unclear issues rather than investing time in painting a map. Probably i'm the only one, but well. Unfortunately, in the special case of my own IPv6 Allocation request for my LIR, i read it like "you don't submit a topology map, we don't even read your request, your explainations are irrelevant, you are being ignored". I didn't expect the request to go right through but kindly layed down all my arguments in a 2nd reply to the ticket. Let alone that the idea to make a network topology map a requirement for an IPv6 allocation (and btw, this is only in the reuqest-form, the policy itself doesn't say anything about it!) is quite off the trolley. This is very annyoing and i'm currently prevented from doing my duties as a LIR, assigning IP(v6) networks, because some people at RIPE seem to have a map fetish (must be managers :-). The good thing and the reason for why i don't just paint a silly handwritten map with some lines and boxes on it for RIPE is, that my personal vendetta here probably leads into some discussion about this issue, so other LIRs might benefit from any change in the future. (I'm obviously trying hard to get something positive out of this.) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================