Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
Hay, On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote:
Hi Daniel,
I hope I can clarify some of your points below:
actually i didn't really want to get into this discussion, but it looks like _noone_ else has anything to say about the issues Daniel raised? Than can't be since he is right in most points.
At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote: [...]
most points have been more-or-less clearified by Dominic's answer, but:
- [EQUIPMENT DESCRIPTION]
This requirement _can't_ be meant serious. We're not on April 1st, are we? The silliness of such information requirement was already recognized within the IPv6 allocation realm, so why introducing it now again for IPv4?
This is a difficult one as it does require the LIR to do more preparation on their side. The less time a Hostmaster spends sending E-mails asking for additional information, the sooner the LIR gets their requested resource. Asking for the type of equipment used really helps the Hostmaster understand what and why IP addresses are being requested.
... i still have a problem here if that should be a "must provide this information". I have no much problems with questions like "why-pi" or "routing-reasons" because they can obviously be answered with standard phrases (which renders them useless again, but if RIPE NCC sees that many "bad" requests from many LIRs (aren't they trained?), it's OK for me, no much work, no stupid questions). BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information). Besides that it's way too much work to fill that in seriously for big requests, and doesn't really make sense for small requests. This should be _optional_ information in cases where it's needed to explain an unusual request, whatever, "we have only one machine but it has 500 IP Adresses due to this and that special purpose which can't be handled otherwise due to these and those hardware and software limitations". Is it really only me who is of that opinion, or noone recognized this problem or doesn't think it's a problem? Or isn't it meant as _required_ information anyways and a "N/A" is enough in most cases as answer to this part of the request? ...curious. The reason i noticed that this might get a problem was due to the unholy [...] #[REQUIRED INFORMATION]# [...] % % 2. Please provide a network diagram in PostScript or JPEG % format showing your IPv6 network. Submission instructions % can be found in the RIPE document "Supporting Notes for the % Initial IPv6 Allocation Request Form in the RIPE NCC Service % Region" found at: % % http://www.ripe.net/ripe/docs/ipv6-support-initial.html % % The diagram should indicate expected completion dates of % construction as well as how much IPv6 address space is % expected to be used in each subnet. % % [...] in the (old and new) IPv6 Initial Allocation request form. Since it says "required information" there, i already assumed that it might get a problem to get the IPv6 Allocation for us without providing this one. But i didn't see the point in doing so if i can make our network plans clear in text form, and explain the reasons why a network diagram for an IPv6 network is _completely_useless_ in general at the moment and especially in our case. Though, even on my 2nd mail on that request i just got the reply from some RIPE Hostmistress that "the inability to provide this network topology map calls into question the need for the IPv6 addresses being requested.". At the moment i'm really mad about this. We are currently prevented from deploying IPv6 addresses immediately because i don't have any Windows PC with Viso or something at hand, let alone the time to paint a very useless topology of our IPv6 overlay network, though i explained it in detail in text. (Not to mention that the statement that an active LIR which assigns IPv4 addresses for years is questioned that it will assign IPv6 addresses just because it doesn't like to waste time on painting network maps of some routers and tunnels is VERY doubiously to me.) Why the hell is such information _required_? Information about what equipment being used and a network topology map on a picture might be additional information at best. I fear that IP(v4) request will be denied or at least delayed in future if the RIPE Hostmasters are gonna complain about missing or unsatisfying information about the equipment in the future, too. That's not acceptable i think. But i might be wrong, we're realatively small and don't have that many requests in general, i just wonder why noone of the "big LIRs" sees this problem? You all have AWs that big that you don't care about filling in RIPE forms anyways and have payed managers to paint network diagrams all day? *hint* :)
Further, the term "peer" is used in a very unclear way in the ASN request form and the supporting notes.
Formerly, one uplink and one peer (commercial term) were enough to justify an ASN, as this constitutes a "unique routing policy". The ASN request form allows this interpretation of "peering partners" with "peering" in the technical sense. BUT the supporting notes specifically mention the requirement for two peers to "ensure that the organisation is multihomed". For me, multihoming means to have at least two _upstreams_. This would be a more stricter policy than before. What was the real intention behind these phrases? These documents should be very specific in the usage of "peer". It might be interpreted technically or commercially, each implying different constraints. I suggest changing the wording from "peer" to "upstream" in order to avoid ambiguities.
Again this is a good point. However I don't think that either term is appropriate for all situations. When writing these documents we used the word peer as we wanted to emphasise it was the routing policy which was important.
So, the policy didn't change to "you have to have two _upstreams_ to get an ASN" but it's only a language-confusion here? P.S.: I think this discussion belongs to the address-policy-wg, not ncc-services-wg? Sorry for crossposting, remove the latter in any replies if i'm right. -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
Hi, I agree with Daniel and Sascha, these issues are very important and needs to be discussed! As Daniel points out, these radical changes haven't been discussed in the maillinglists before beeing implemented - why? It seems reasonable enough to update the old forms, but I cannot see any big advantages in the new versions? Presently it is rather complex and time consuming to gather all the information needed to apply for IP addresses, especially since most customers do have other things than Internet on their mind, so they have to be given a very thorough explanation in order to make sense of such an application. The question is what information is needed and why? As a general rule, endusers are allowed to expect a maximum increase of 100% pr. year of IP addresses - so, to find out the number of IP addresses to assign the enduser simply needs to tell how many nodes requiring IP addresses they have, in case the endusers IP address requirement is higher than the number of nodes, a detailed technical documentation justifying this need is required. I don't see much reason for going into details about the organizational structure of the enduser neither the reason for requesting detailed information about each node.. either its there or its not! Of course there are situations when enduser informations sounds rather unrealistic, but if an enduser intentionally lies about their need in order to get more IP addresses than justifable, should the LIR be responsible for this? Regarding PI-space, in case an enduser can justify for example a /24, unless the enduser intends to be become LIR, should there be any reason for the enduser not to get a PI assignment if this is the endusers request? About the new forms, I assume the "ADDRESS SPACE USER" is intended to replace Organization overview so it is no longer required to explain the organization of a enduser in detail? If so, I think this is a good idea. "Does the organisation already have address space that ...." The only reason I can see is if the enduser has a connection to the Internet and buys another, probably on another location (of course the enduser could request extra IP addresses unjustifably, if so, the LIR should not waste time filling out the form but just explain the situation to the enduser), could there be other reasons for this? If not, I think the question should be clarified if not omitted. The whole address-space-returned-situation as well as stating exactly which IP nets the enduser has are a bit tricky.. Sometimes the enduser does not know exactly what IP addresses they have (or forgets to mention it..), the LIR has no way to be sure that the received information is correct (especially if the LIR, at which the enduser is also customer, has not registered the IP net). Who's responsibility is it that IP addresses are returned? I would think that it might be the LIR registering the IP assigment, but I haven't been able to find it? If so, why? #[EQUIPMENT DESCRIPTION]# % % Please describe the equipment that will be used in the % network. Indicate the function of the equipment and provide % information regarding the way it uses IP address space. equipment-name: manufacturer-name: model-number: other-data: What is the reason for requesting the model-number and the other details!??! According to Dominic's responds it seems that this information is necessary for the hostmaster to evaluate the request, but how does it help to find out the number of IP addresses to assign if you know if a node is manufactored by IBM/HP/whatever? Or if is a model with 1,4 GHz CPU or 1,7 GHz? I don't believe there is any reason for this, if others could agree the hostmasters could save a lot of time by not having to look at these details. As both Daniel and Sascha has said it is simply not reasonable to request a network diagram, of course it can be optional. Dominic says that a reason for the thorough questions regarding PI-space is that some LIRs do not understand the difference between PA and PI!! But how can this justify consuming time at all the other LIRs?! But I don't understand how you can be LIR without understanding PA/PI? You have to state that you have read the relevant documents in order to become contact person, if PA/PI is not clear after reading the documents then the documents of course needs to be updated - but it doesn't make sense to have LIRs assign IP addresses without understanding the basic principals. I agree with Sascha that its not acceptable to have requests delayed because the forms requires these unreasonable informations! If other LIRs do not see this as a problem simply because of their large AW it doesn't make much sense; even if you assign most of your requests without consulting a Ripe hostmaster you're still required to have the information for the relevant form available... Anyway, I do not understand who benefits from having irrelevant information gathered! I hope somebody have comments to the above and can explain the reason for these to-be time consuming tasks, if not, these forms should be radically simplified. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net]On Behalf Of Sascha Lenz Sent: 25. august 2003 11:43 To: Dominic Spratley Cc: ncc-services-wg@ripe.net; address-policy-wg@ripe.net Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
Hay,
On Thu, Aug 21, 2003 at 04:02:16PM +0200, Dominic Spratley wrote:
Hi Daniel,
I hope I can clarify some of your points below:
actually i didn't really want to get into this discussion, but it looks like _noone_ else has anything to say about the issues Daniel raised? Than can't be since he is right in most points.
At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote: [...]
most points have been more-or-less clearified by Dominic's answer, but:
- [EQUIPMENT DESCRIPTION]
This requirement _can't_ be meant serious. We're not on April 1st, are we? The silliness of such information requirement was already recognized within the IPv6 allocation realm, so why introducing it now again for IPv4?
This is a difficult one as it does require the LIR to do more preparation on their side. The less time a Hostmaster spends sending E-mails asking for additional information, the sooner the LIR gets their requested resource. Asking for the type of equipment used really helps the Hostmaster understand what and why IP addresses are being requested.
... i still have a problem here if that should be a "must provide this information".
I have no much problems with questions like "why-pi" or "routing-reasons" because they can obviously be answered with standard phrases (which renders them useless again, but if RIPE NCC sees that many "bad" requests from many LIRs (aren't they trained?), it's OK for me, no much work, no stupid questions).
BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information).
Besides that it's way too much work to fill that in seriously for big requests, and doesn't really make sense for small requests.
This should be _optional_ information in cases where it's needed to explain an unusual request, whatever, "we have only one machine but it has 500 IP Adresses due to this and that special purpose which can't be handled otherwise due to these and those hardware and software limitations".
Is it really only me who is of that opinion, or noone recognized this problem or doesn't think it's a problem? Or isn't it meant as _required_ information anyways and a "N/A" is enough in most cases as answer to this part of the request? ...curious.
The reason i noticed that this might get a problem was due to the unholy
[...] #[REQUIRED INFORMATION]# [...] % % 2. Please provide a network diagram in PostScript or JPEG % format showing your IPv6 network. Submission instructions % can be found in the RIPE document "Supporting Notes for the % Initial IPv6 Allocation Request Form in the RIPE NCC Service % Region" found at: % % http://www.ripe.net/ripe/docs/ipv6-support-initial.html % % The diagram should indicate expected completion dates of % construction as well as how much IPv6 address space is % expected to be used in each subnet. %
% [...]
in the (old and new) IPv6 Initial Allocation request form.
Since it says "required information" there, i already assumed that it might get a problem to get the IPv6 Allocation for us without providing this one. But i didn't see the point in doing so if i can make our network plans clear in text form, and explain the reasons why a network diagram for an IPv6 network is _completely_useless_ in general at the moment and especially in our case.
Though, even on my 2nd mail on that request i just got the reply from some RIPE Hostmistress that "the inability to provide this network topology map calls into question the need for the IPv6 addresses being requested.".
At the moment i'm really mad about this. We are currently prevented from deploying IPv6 addresses immediately because i don't have any Windows PC with Viso or something at hand, let alone the time to paint a very useless topology of our IPv6 overlay network, though i explained it in detail in text. (Not to mention that the statement that an active LIR which assigns IPv4 addresses for years is questioned that it will assign IPv6 addresses just because it doesn't like to waste time on painting network maps of some routers and tunnels is VERY doubiously to me.)
Why the hell is such information _required_? Information about what equipment being used and a network topology map on a picture might be additional information at best.
I fear that IP(v4) request will be denied or at least delayed in future if the RIPE Hostmasters are gonna complain about missing or unsatisfying information about the equipment in the future, too.
That's not acceptable i think. But i might be wrong, we're realatively small and don't have that many requests in general, i just wonder why noone of the "big LIRs" sees this problem? You all have AWs that big that you don't care about filling in RIPE forms anyways and have payed managers to paint network diagrams all day? *hint* :)
Further, the term "peer" is used in a very unclear way in the ASN request form and the supporting notes.
Formerly, one uplink and one peer (commercial term) were enough to justify an ASN, as this constitutes a "unique routing policy". The ASN request form allows this interpretation of "peering partners" with "peering" in the technical sense. BUT the supporting notes specifically mention the requirement for two peers to "ensure that the organisation is multihomed". For me, multihoming means to have at least two _upstreams_. This would be a more stricter policy than before. What was the real intention behind these phrases? These documents should be very specific in the usage of "peer". It might be interpreted technically or commercially, each implying different constraints. I suggest changing the wording from "peer" to "upstream" in order to avoid ambiguities.
Again this is a good point. However I don't think that either term is appropriate for all situations. When writing these documents we used the word peer as we wanted to emphasise it was the routing policy which was important.
So, the policy didn't change to "you have to have two _upstreams_ to get an ASN" but it's only a language-confusion here?
P.S.: I think this discussion belongs to the address-policy-wg, not ncc-services-wg? Sorry for crossposting, remove the latter in any replies if i'm right.
-- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ================================================================== ========
BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information).
This indeed an interesting point of view. It has been the practice for as long as I can remember for the RIPE NCC to ask for documnetation for the need for IP addresses. Is there strong support in the community to remove this cirteria ? If not, how should the LIR/RIR verify this criteria ? Best Regards, Hans Petter
Hay, On Fri, Aug 29, 2003 at 12:51:31PM +0200, Hans Petter Holen wrote:
BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information).
This indeed an interesting point of view. It has been the practice for as long as I can remember for the RIPE NCC to ask for documnetation for the need for IP addresses.
Is there strong support in the community to remove this cirteria ?
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". If some company doesn't want to reveal such information, there's not legal way to force them to do. If one does, there is certainly another ISP with an AW big enough who gets the customer the IP adresses he needs without asking such detailed information, regardless what RIPE wants (that's just the real world situation nowerdays). What i'm not talking abut is general information about the network like "we have 5 PCs, 7 servers with 10 Interfaces and two routers with 5 Interfaces and a fridge with ethernet" or so. That's needed information as always. But say if some company doesn't want to tell what product they use for whatever, VPN dialin and they only say "we have 120 dialin lines for our employees" that has to be enough. It doesn't matter if that's a Cisco or a Bintec or whatever anyways. I've seen such information being confidental in the eyes of security managers. Let alone sending bills of the equipment or so to RIPE as verfication.
If not, how should the LIR/RIR verify this criteria ?
How does a LIR verify this today? You go to every customer and let you show everything? -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
This indeed an interesting point of view. It has been the practice for as long as I can remember for the RIPE NCC to ask for documnetation for the need for IP addresses.
Is there strong support in the community to remove this cirteria ?
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. Its even a requirement in RIPE 185 (from 1998) "Docu- mentation needs to include the precise nature of the restriction, the make, model and version of the hardware or software causing the restriction, and its precise location in the network. " But note that this is qouted _out of context_ this requirement was prenset to get addressess for CLASSFULL addressing (!) 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.) Hans Petter
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. [..]
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). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
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 * = ==========================================================================
Hi Hans, The question is how complex an evaluation must be? The facts needed to evaluate a normal IP requests are simply the number of nodes needing a public IP address. In case one or more nodes needs more than 1 IP address then documentation is needed to explain why to exceed the normal rules, also in case the expected growth pr. year exceeds 100%. It would of course be easier to falsify the number of nodes than to falsify the documentation, but in case an end user intends to falsify information in order to get more IP addresses than justifyable, then I don't see any easy way to prevent this. But is there actually any other reasons for extensive documentation? Who benefits from the work all LIRs are obligated to perform by gathering this documentation? If normal requests did not need any documentation it would make it MUCH easier for all LIRs and of course for the customers who would not need to take the time to answer a lot of complex questions. If you as an end user only had to document your needs in case you were trying to get more IP addresses than normal justifyable, then it would probably also discourage a lot of the unserious requests. I would find it reasonable if larger requests still required some form of documentation, for example /24 and above. But it would of course still be very important for all LIRs to stress that the information received from the enduser must be correct. This proposal probably goes against one of the basic goals; conservation, but is it reasonable to spend so many ressources on conserving IP addresses when we actually don't have any immediate problem? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net]On Behalf Of Hans Petter Holen Sent: 29. august 2003 12:52 To: Sascha Lenz Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
BUT... information like the equipment being used or a network plan or so _must_ be optional information, not _required_ information. It can't be that a company is _required_ to make statements about their network and equipment if they want to have IP-Adresses! (and no, RIPE doesn't always qualify for receiving such information).
This indeed an interesting point of view. It has been the practice for as long as I can remember for the RIPE NCC to ask for documnetation for the need for IP addresses.
Is there strong support in the community to remove this cirteria ?
If not, how should the LIR/RIR verify this criteria ?
Best Regards,
Hans Petter
participants (4)
-
Christian Rasmussen -
Gert Doering -
Hans Petter Holen -
Sascha Lenz