From plzak at arin.net Mon Sep 1 00:24:01 2003 From: plzak at arin.net (Ray Plzak) Date: Sun, 31 Aug 2003 18:24:01 -0400 Subject: [address-policy-wg] WG Charter In-Reply-To: <20030831213357.GB803@dhcp-9-224.ripemtg.ripe.net> Message-ID: <000001c3700e$962c8920$698888c0@arin.net> Not exactly. I would say that instead of IANA that it would be the organization performing the IP Number Resouce Management of the IANA function. More fundamentally why would this working group do this? The policy relationship between IANA and the RIRs is a matter of global policy. It would seem to me that this would be an interface between the RIRs (in this case RIPE NCC amongst others) and a body concerned with global policy. In current circumstances that would be the ASO AC to the ICANN Board, but of course until the RIRs and ICANN can reach agreement on an ASO MoU, that can change as well. Ray "The WG coordinates its work with the appropriate bodies of the other RIRs and the IANA." > -----Original Message----- > From: 'Daniel Karrenberg' [mailto:daniel.karrenberg at ripe.net] > Sent: Sunday, August 31, 2003 5:34 PM > To: Ray Plzak > Cc: 'Hans Petter Holen'; 'Rob Blokzijl'; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] WG Charter > > > On 31.08 16:44, Ray Plzak wrote: > > > > 2. IANA does not exist as an organization. ICANN performs the IANA > > functions under a contract with the US DoC. There is nothing to > > preclude any other organization to perform all or part of > this function. > > Under the current circumstances that could be either as a > subcontractor > > to ICANN under the current contract or as a separate > contractor to the > > US DoC. > > > > Point 2 has some interesting scenarios if looked at in the long run. > > I read that to mean that you are in agreement with my > suggestion. Correct? > > Daniel > From gert at space.net Mon Sep 1 16:33:06 2003 From: gert at space.net (Gert Doering) Date: Mon, 1 Sep 2003 16:33:06 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal) In-Reply-To: <5.1.0.14.2.20030826125314.03befe68@mailhost.ripe.net>; from dominic@ripe.net on Tue, Aug 26, 2003 at 12:57:13PM +0200 References: <5.1.0.14.2.20030826125314.03befe68@mailhost.ripe.net> Message-ID: <20030901163306.K67740@Space.Net> Hi, On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote: > You both made several points and I hope I can explain our thinking on them > for you. We think these new forms represent a change in the way we provide > services to LIRs so we've addressed this answer to the NCC Services WG list. > We don't think they represent a change to the RIPE community's policy. Actually, I tend to disagree, at least for some parts. Which is why I've put the APWG list back into the CC: (sorry for duplicates). Some of the criticism voiced is that the NCC is asking questions and enforcing rules that are more strict than what the policy demands - and this is certainly relating to policy. [..] > You asked about the requirement for a network diagram to be supplied when > requesting an IPv6 allocation. There are two reasons for this. Firstly, the > RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 > networks is limited and we need network operators to show us how they intend > to use IPv6 address space in their networks. I agree with the assessment that "more experience for the NCC is a good thing". On the other hand, many startup IPv6 deployments are extremely trivial ("one access server with 1000 DSL circuits, serving /48s to DSL end users" would certainly qualify for the policy requirements). So I don't think it's appropriate to enforce this "you send us an interesting picture, otherwise you won't get an IPv6 allocation" approach. Make it optional. > Secondly, the current IPv6 > policy does not allow stockpiling of IPv6 address space. One way of > distinguishing a genuine request from one that is intended for stockpiling > reasons is to request a diagram showing how the address space will be used. > It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn > diagram instead of sending one by e-mail. When we have more experience with > IPv6 I expect we will make the diagram optional. This is "conservationism striking again", and this is BAD. The idea behind the current policy is "make IPv6 address blocks available to anybody who is asking for them" (and can reasonably claim 200 future IPv6 customers). For that, you don't *need* a fancy network, so why do you have to demonstrate it at all? What are you worrying about? Address wastage is really not a problem right now. Obstacles on the way to IPv6 deployments are a problem, and we don't want the NCC to be an obstacle. Now come and flame me :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Mon Sep 1 16:57:44 2003 From: gert at space.net (Gert Doering) Date: Mon, 1 Sep 2003 16:57:44 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: ; from hpholen@tiscali.no on Fri, Aug 29, 2003 at 02:00:03PM +0200 References: <20030828131859.A13958@mama.baycix.de> Message-ID: <20030901165744.L67740@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From slz at baycix.de Tue Sep 2 05:36:02 2003 From: slz at baycix.de (Sascha Lenz) Date: Tue, 2 Sep 2003 05:36:02 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: <20030901165744.L67740@Space.Net>; from gert@Space.Net on Mon, Sep 01, 2003 at 04:57:44PM +0200 References: <20030828131859.A13958@mama.baycix.de> <20030901165744.L67740@Space.Net> Message-ID: <20030902053602.E27955@mama.baycix.de> 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 at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From slz at baycix.de Tue Sep 2 07:56:42 2003 From: slz at baycix.de (Sascha Lenz) Date: Tue, 2 Sep 2003 07:56:42 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal) In-Reply-To: <20030901163306.K67740@Space.Net>; from gert@space.net on Mon, Sep 01, 2003 at 04:33:06PM +0200 References: <5.1.0.14.2.20030826125314.03befe68@mailhost.ripe.net> <20030901163306.K67740@Space.Net> Message-ID: <20030902075642.F27955@mama.baycix.de> Hay, On Mon, Sep 01, 2003 at 04:33:06PM +0200, Gert Doering wrote: > Hi, > > On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote: > > You both made several points and I hope I can explain our thinking on them > > for you. We think these new forms represent a change in the way we provide > > services to LIRs so we've addressed this answer to the NCC Services WG list. > > We don't think they represent a change to the RIPE community's policy. > > Actually, I tend to disagree, at least for some parts. Which is why > I've put the APWG list back into the CC: (sorry for duplicates). > > Some of the criticism voiced is that the NCC is asking questions and > enforcing rules that are more strict than what the policy demands - and > this is certainly relating to policy. Yes, in the case of the requirement of a network topolocy map, it looks like it always was part of the request form for the initial IPv6 Allocation, but never part of the policy. Just that noone complained yet. > [..] > > You asked about the requirement for a network diagram to be supplied when > > requesting an IPv6 allocation. There are two reasons for this. Firstly, the > > RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 > > networks is limited and we need network operators to show us how they intend > > to use IPv6 address space in their networks. > > I agree with the assessment that "more experience for the NCC is a good > thing". > > On the other hand, many startup IPv6 deployments are extremely trivial > ("one access server with 1000 DSL circuits, serving /48s to DSL end > users" would certainly qualify for the policy requirements). > > So I don't think it's appropriate to enforce this "you send us an > interesting picture, otherwise you won't get an IPv6 allocation" > approach. Make it optional. Full-ACK. The main reason i came up with the idea that i can save some time and not paint a pointless map was, that it's just not in the policy. So i didn't consider it a nescessary requirement. We almost have have such a trivial setup as you mention. We're still using an IPv6 overlay network, no joint IPv4+IPv6 backbone yet due to vendor limitations, i.e. many tunnels. It's subject to change at any time anyways, there's absolutely no way to tell how the final network will look like until all vendors support IPv6 in mainline firmware releases. So where is the point in doing so? What benefit has the RIPE NCC from a map which doesn't need to be a fancy diagram and even can be a handwritten drawing as Dominic suggest? And no, "overlay network" doesn't mean it's a test setup not qualifying for production IPv6 space either. The reason for requesting a production IPv6 Allocation is, that one wants to start to actually assign /48s to endusers and make sub-allocations to downstream organisations. I also consider the "have a plan for making at least 200 /48 assignments to other organisations within two years." requirement quite dim. But since it's in the policy and i initially supported a slow-start mechanism, i have no problems with that. It's not that hard to fulfill for most early adoptors anyways, not even for my LIR :) ("Tunnels, free Tunnels, Tunnels for all! Take two - get one for free!") Though... see below. > > Secondly, the current IPv6 > > policy does not allow stockpiling of IPv6 address space. One way of > > distinguishing a genuine request from one that is intended for stockpiling > > reasons is to request a diagram showing how the address space will be used. > > It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn > > diagram instead of sending one by e-mail. When we have more experience with > > IPv6 I expect we will make the diagram optional. > > This is "conservationism striking again", and this is BAD. > > The idea behind the current policy is "make IPv6 address blocks available > to anybody who is asking for them" (and can reasonably claim 200 future > IPv6 customers). For that, you don't *need* a fancy network, so why > do you have to demonstrate it at all? > > What are you worrying about? Address wastage is really not a problem > right now. Obstacles on the way to IPv6 deployments are a problem, and > we don't want the NCC to be an obstacle. ? Full-ACK, again. But, even more generally speaking: Look at the current IPv4 policy discussion. It shows that more and more LIRs are very small LIRs, probably using only IP-space for themselves and very few customers. Even the initial allocation size is subject to be reduced again. What do those LIRs do if they want to start deloying IPv6? They probably can't show 200 potential /48 customers. And don't have the manpower or any interest in painting topology maps. They are cut off from IPv6 then and need to get a suballocation from another LIR? Why do they pay the full RIPE fee then? I guess the whole policy currently is a bit outdated. In my eyes it prevents IPv6 deployment. Not to a degree like the hardware/software support situation, but it adds obstacles for some organisations and they rather just don't care about IPv6, "too complicated". The main reason i supported the slow-start mechanism was, that there was no experience in first place, and for example not even the initial IPv6 Allocation size was settled. And as we know, it changed in the meantime. Currently there's still the discussion about weather to make reservations and fragment the 2001::/16 space or not, but most of the policy is quite final i think, so i'm not very positive about the need for RIPE to continue with that slow-start thing for much longer. On the other hand, just look who currently alrady got some IPv6 Allocation and how many of them are just unused. I only looked for de.* LIRs on my search for some IPv6 uplink who probably can offer IPv6 natively, but already was amazed about the results. For starters, i was quite happy that our main uplink got an IPv6 Allocation for almost a year now, just to notice that their Prefix is not in the BGP tables shortly afterwards, and there are no assignments yet. Asking our tech contacts there, the first one at least knew what IPv6 is, but then i got a "no, we don't have any IPv6 at all, not even via tunnel". Sales Department then even told me "IPv6? No, we don't even have plans for that at the moment, sorry." So, hm. Someone can tell me how they got the Allocation? Because they are a big IPv4 LIR and someone gave RIPE a high-gloss Network map which their Marketing people produce all the time? RIPE, do you really WANT to be lied to? (DISCLAIMER: I'm not accusing anyone of lying here, that's just a question as stylistic device :) ) Of course i can just comply with that and make up thousands of dial-customers who all want to have IPv6, i know that they do! And of course we have a BIIIIG IPv6 network in 2years, see my nice map? So my point is, one really should start thinking about a change. There is the idea of "One IPv6 Allocation for every LIR on request." on some mailinglists for quite a while. I'd support this now for the future (not nescessarily imemdiately). > Now come and flame me :-) Certainly not :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From Ludger.Bornhorst at telekom.de Fri Sep 19 13:31:45 2003 From: Ludger.Bornhorst at telekom.de (Bornhorst, Ludger) Date: Fri, 19 Sep 2003 13:31:45 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal Message-ID: Hi Christian, > 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%. Yes, but I don't have any problem to ask endusers about their (planned) hardware and to document their needs in the way we've done it since several years now, like "We have 20 PC's, 5 routers, 200 dial-in-ports and so on..." This general information will (in most cases) be sufficient to evaluate IP requests. > 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. Right, but there are still enduser who don't know about classless addressing. That means they are asking for "Class-C" nets just because they think its hip. So I think it's responsibility of the LIR's to tell this endusers about CIDR and its outcomes. And, yes I agree: If an enduser wants to cheat at you, I can't see a way to prevent this. > 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. ACK! This way it would be possible to serve the main part of the customers at a simple level and only ask reasonable questions (hardware documentation) if the request exceeds a certain level. I would like to stress that the /24 border should be the maximum limit of "freedom" given here. Maybe it's better to decrease this "HW-documentation-border" down to /25 or /26 ? What do you think? mit freundlichen Gruessen/with best regards Ludger Bornhorst ______________________________________________________________________ Deutsche Telekom AG T-Com Headquarters Network Information Center Ammerlander Heerstr. 138, D-26129 Oldenburg Hotline +49 441 234 4581 (phone) +49 800 3301180 +49 441 234 4589 (fax) +49 800 3301179 ludger.bornhorst at telekom.de (mail) dk.call-center at telekom.de From axel.pawlik at ripe.net Tue Sep 23 11:12:56 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 23 Sep 2003 11:12:56 +0200 Subject: [address-policy-wg] Proposed Open Letter to ICANN and Related Documents Message-ID: <5.2.0.9.2.20030923104551.034192d8@localhost> Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments at apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments at apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC From axel.pawlik at ripe.net Tue Sep 23 11:12:56 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 23 Sep 2003 11:12:56 +0200 Subject: [address-policy-wg] [local-ir@ripe.net]Proposed Open Letter to ICANN and Related Documents Message-ID: <5.2.0.9.2.20030923104551.034192d8@localhost> Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments at apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments at apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC From axel.pawlik at ripe.net Tue Sep 23 11:12:56 2003 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 23 Sep 2003 11:12:56 +0200 Subject: [address-policy-wg] [ncc-co@ripe.net] Proposed Open Letter to ICANN and Related Documents Message-ID: <5.2.0.9.2.20030923104551.034192d8@localhost> Dear Colleagues, The Regional Internet Registries (RIR) have published three (3) documents: a. Proposed Open Letter to ICANN from the Regional Internet Registries b. Proposed Agreement between the RIRs to create the Number Resource Organization c. Proposed Agreement between the RIRs (acting through the NRO) and ICANN concerning the Address Supporting Organization These documents are available on a single web page at: http://www.ripe.net/ripencc/about/regional/draft-public-comment.html In order to ensure that RIR members and address communities in every region have the opportunity to comment, the Board of the RIRs have requested that RIRs post the documents for a period of 30 days. The comment period closes at midnight (UTC) on the 22nd October 2003. Each of the RIR Boards will consider the comments as they are received, and each RIR Board intends to make a decision whether to adopt these documents following this comment period. If these documents are adopted by all the RIR Boards, it is the present intention to formally pass the following open letter to ICANN on the 24th of October. On the same date the Boards of the RIRs currently intend to direct their CEOs to sign the MoU concerning the establishment of the Number Resource Organization. All comments should be addressed to: nro-comments at apnic.net. The comments will be passed to all the Boards of the RIRs, and will also be published on the web site http://www.apnic.net/nro-comments. Any dialogue that arises from such comments will also be published on this site. Subscription information for the nro-comments mailing list is available at: http://mailman.apnic.net/mailman/listinfo/nro-comments All postings to this mail address (nro-comments at apnic.net) are public, and will be published at the following URL: http://www.apnic.net/nro-comments kind regards, Axel Pawlik Managing Director RIPE NCC From gert at space.net Thu Sep 25 15:57:49 2003 From: gert at space.net (Gert Doering) Date: Thu, 25 Sep 2003 15:57:49 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: upda ted and available on LIR Portal In-Reply-To: ; from Ludger.Bornhorst@telekom.de on Fri, Sep 19, 2003 at 01:31:45PM +0200 References: Message-ID: <20030925155749.N67740@Space.Net> Hi, On Fri, Sep 19, 2003 at 01:31:45PM +0200, Bornhorst, Ludger wrote: > I would like to stress that the /24 border should be the maximum limit of > "freedom" given here. Maybe it's better to decrease this "HW-documentation-border" > down to /25 or /26 ? What do you think? I think this is something that should be handled between the LIR and its customers - after all, if you *know* that the customer has 500 machines (because you have seen their office rooms) what good is requiring lots of detailed proof with serial numbers and what else? If someone you don't know claims he has 1000 machines, it's the LIRs job to obtain whatever level of confirmation they feel necessary. The RIR->LIR level has the AW to express a given level of trust. Remember: please don't feed the buerocracy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56833 (55575) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From dominic at ripe.net Mon Sep 29 08:59:08 2003 From: dominic at ripe.net (Dominic Spratley) Date: Mon, 29 Sep 2003 08:59:08 +0200 Subject: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Message-ID: <5.2.1.1.2.20030929083537.024258e0@mailhost.ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce an updated draft of the revised RIPE IPv4 policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (currently ripe-234). The major change from the draft published on 21st July is that the existing "status:" attribute values are kept for inetnum objects with the addition of a new value for sub-allocations. The updated draft can be downloaded from the "Drafts" section in the RIPE Document Store, found at: The major updates to the current policy text in this draft IPv4 policy document are: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). Feedback on this document should be sent to the address-policy-wg at localhost mailing list for a period of two weeks. This review period will end on TWO WEEKS FROM ANNOUNCEMENT. Dominic Spratley Registration Services Manager RIPE NCC