From hpholen at tiscali.no Thu Aug 7 04:39:45 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 7 Aug 2003 01:39:45 -0100 (GMT+1) Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 Message-ID: Dear WG; Here are some items for a draft agenda, please send me comments as soon as possible; - wg-charter - policy process - PI policy - initial IPv4 allocation size - RIR- IANA relationship and procedures - RIPE-152 Charging by local registries - Final revised IPv4 policy From leo at ripe.net Thu Aug 7 10:18:51 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 7 Aug 2003 10:18:51 +0200 Subject: [Fwd: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46] In-Reply-To: <3F32090C.4040309@ripe.net> References: <3F32090C.4040309@ripe.net> Message-ID: Hi, Shane Kerr wrote: >Did we want "status:" added? It sort of comes under the policy as it is specified there, too. Regards, -leo >-----Original message----- >Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 >To: address-policy-wg at ripe.net >From: Hans Petter Holen >Date: Thu, 7 Aug 2003 01:39:45 -0100 > >Dear WG; > >Here are some items for a draft agenda, please send me comments as soon as >possible; > > >- wg-charter >- policy process >- PI policy >- initial IPv4 allocation size >- RIR- IANA relationship and procedures >- RIPE-152 Charging by local registries >- Final revised IPv4 policy > > > >-----End of original message from Hans Petter Holen----- -- leo vegoda RIPE NCC Registration Services Manager From leo at ripe.net Thu Aug 7 14:35:16 2003 From: leo at ripe.net (leo vegoda) Date: Thu, 7 Aug 2003 14:35:16 +0200 Subject: [address-policy-wg] Updated 'RIR Comparative Policy Overview' - Version 2.1 Message-ID: Dear Colleagues, Version 2.0 of the 'RIR Comparative Policy Overview', found at: has been updated to correct an error in the information for LACNIC in Section 2.4.1. "Assignments by RIRs (Independent/Portable)" To be eligible for an independent/portable assignment from LACNIC, the corrected text now reads: "Show need for at least a /21, based on demonstrated need, according to the criteria listed above." the old text read: "Need to be multihomed and show need for at least a /21. Based on demonstrated need, according to the criteria listed above." Please accept our apologies for any confusion or inconvenience caused. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From leo at ripe.net Mon Aug 11 08:19:46 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 11 Aug 2003 08:19:46 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions Message-ID: <+f6cKhCCWzN$EwbX@ripe.net> Dear Colleagues, Below is a summary of the recent discussions on the PI TF mailing list. The policy for portable address space is on the draft agenda for the Address Policy WG's session at RIPE 46 on 3 September. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager A summary of the PI TF's initial discussions was agreed and posted to the mailing list on 6 May 2003. It can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/2003/msg00265.html Gert D?ring presented on the discussion at the RIPE 45 LIR WG session. His slides can be found at: http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pi-tf. pdf At RIPE 45 there was an agreement that the Task Force should continue its work. There was also an agreement that the PI policy is tied to the qualifying criteria for an initial IPv4 allocation. Discussion focused around a straw-man proposal to make four related policy changes. The proposed changes are outlines below along with a summary of comments received on them. 1. Reduce the minimum allocation size from /20 to /21 - There was some support for this point. There were requests for /21 allocations to come from a new and separately identified address blocks. 2. Remove the requirement to show an immediate need for 25% of the allocated address space (a /23 in this case) - There was no objection to this point. It was pointed out that with a lower barrier to entry the overhead of checking each requester is ready to use 512 IP addresses straight away would be unlikely to be equal to the value of the work. 3. No longer assign PI (Portable) address space to End Users - There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. 4. End Users requiring a portable address block could become an LIR and receive a /21 allocation. - There was some support for this point. The costs of operating an LIR were raised as an issue. It was also noted that everyone may become an LIR. There is no barrier to membership of the RIPE NCC. There was a suggestion for a one-time service fee. There were also some additional comments: It was noted that if the policy allows for address allocations based on other criteria than prior demonstrated need some providers may filter those allocations. It was also noted that the RIPE NCC cannot provide any guarantee as to whether address space will or will not be routed of filtered by network operators. Some statistics were requested and provided for the first half of 2003: ASN assignments: 599 Allocation: 377 PI Assignments: 408 Number of /20s allocated per month for the same period: 200301 7 200302 20 200303 14 200304 16 200305 35 200306 24 Finally, it was noted that there is a requirement for globally unique addresses that will not be routed on the Internet. From bortzmeyer at nic.fr Mon Aug 11 10:29:53 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 10:29:53 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <+f6cKhCCWzN$EwbX@ripe.net> References: <+f6cKhCCWzN$EwbX@ripe.net> Message-ID: <20030811082953.GA24572@nic.fr> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote a message of 91 lines which said: > 3. No longer assign PI (Portable) address space to End Users > > - There some support for to this point. The issue of Root DNS > Servers was raised but it was noted that all Root DNS Servers > operating in this region already have address assignments. And what about ccTLD name servers? From gert at space.net Mon Aug 11 11:16:20 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 11:16:20 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811082953.GA24572@nic.fr>; from bortzmeyer@nic.fr on Mon, Aug 11, 2003 at 10:29:53AM +0200 References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> Message-ID: <20030811111620.P67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 10:29:53AM +0200, Stephane Bortzmeyer wrote: > > 3. No longer assign PI (Portable) address space to End Users > > > > - There some support for to this point. The issue of Root DNS > > Servers was raised but it was noted that all Root DNS Servers > > operating in this region already have address assignments. > > And what about ccTLD name servers? What's special about ccTLD name servers? "Special" in the sense of "needs an IP address that cannot ever change because it cannot be looked up by DNS"? There's nothing more special about ns.nic.de than about www.google.com - if the service moves, the address in the DNS changes, and people won't even notice. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) 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 Aug 11 11:36:54 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 11:36:54 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811092016.GA25538@nic.fr>; from bortzmeyer@nic.fr on Mon, Aug 11, 2003 at 11:20:16AM +0200 References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> Message-ID: <20030811113654.Q67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 11:20:16AM +0200, Stephane Bortzmeyer wrote: > > There's nothing more special about ns.nic.de than about > > www.google.com - if the service moves, the address in the DNS > > changes, and people won't even notice. > > Hmmm, Gert, sorry if I seem rude, but did you heard of glue records? Of course. > If not, "whois -h whois.iana.org de" and you'll understand the > difference with Google (the last change we requested from IANA, adding > a new name server, ns3.domain-registry.nl, for ".re" is now three > weeks old and still not performed... DENIC has similar experience.). That's an operational problem, not a technical one. If IANA/ICANN isn't working, give them a good beating, but please don't break policy to cover for human deficiencies. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) 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 Aug 11 11:46:28 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 11:46:28 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811094307.GA25832@nic.fr>; from bortzmeyer@nic.fr on Mon, Aug 11, 2003 at 11:43:07AM +0200 References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> Message-ID: <20030811114628.S67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 11:43:07AM +0200, Stephane Bortzmeyer wrote: > > If IANA/ICANN isn't working, give them a good beating, but please > > don't break policy to cover for human deficiencies. > > It is completely unrealistic. Do you really expect the European ccTLD > to be able to change Uncle Sam's policies and practices in the next > few years? As far as I understand, the threat from APNIC and RIPE to just ditch ICANN and get on without it seems to have had quite some effect. If all non-US-ccTLD registries (of which there are lots more than US-based) start beating ICANN with joint forces, I'm pretty sure that this will have an effect. > Change the policy to disallow any new IPv4 allocation and > assignment. After all, IPv6 works, technically speaking, so it is > "just an operational problem" now, do not create convoluted policies > because of IPv4 addresses scarcity. Fine with me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From joao at psg.com Mon Aug 11 11:48:28 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Mon, 11 Aug 2003 11:48:28 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811082953.GA24572@nic.fr> Message-ID: I have one question, trying to understand the main goal of the exercise: * Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name? Joao On Monday, August 11, 2003, at 10:29 AM, Stephane Bortzmeyer wrote: > On Mon, Aug 11, 2003 at 08:19:46AM +0200, > leo vegoda wrote > a message of 91 lines which said: > >> 3. No longer assign PI (Portable) address space to End Users >> >> - There some support for to this point. The issue of Root DNS >> Servers was raised but it was noted that all Root DNS Servers >> operating in this region already have address assignments. > > And what about ccTLD name servers? > > From gert at space.net Mon Aug 11 11:50:59 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 11:50:59 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from joao@psg.com on Mon, Aug 11, 2003 at 11:48:28AM +0200 References: <20030811082953.GA24572@nic.fr> Message-ID: <20030811115059.V67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote: > I have one question, trying to understand the main goal of the exercise: > > * Is the aim of the a new PI policy to adjust the policy to the > requests and needs of the industry or is it a way of getting a "special > allocation" policy by another name? My aim is to adjust the policy (actually both PA and PI policy) to match observed need. People are requesting *multiple* PI blocks because they can't get a PA allocation, and that seems to be just wrong to me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From cfriacas at fccn.pt Mon Aug 11 12:00:02 2003 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 11 Aug 2003 11:00:02 +0100 (WEST) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811114628.S67740@Space.Net> Message-ID: On Mon, 11 Aug 2003, Gert Doering wrote: > Hi, > > On Mon, Aug 11, 2003 at 11:43:07AM +0200, Stephane Bortzmeyer wrote: > > > If IANA/ICANN isn't working, give them a good beating, but please > > > don't break policy to cover for human deficiencies. > > > > It is completely unrealistic. Do you really expect the European ccTLD > > to be able to change Uncle Sam's policies and practices in the next > > few years? > > As far as I understand, the threat from APNIC and RIPE to just ditch > ICANN and get on without it seems to have had quite some effect. > > If all non-US-ccTLD registries (of which there are lots more than > US-based) start beating ICANN with joint forces, I'm pretty sure that > this will have an effect. Has anyone tried serious reasoning with them about these delays??? ./Carlos "Upgrade the Internet! -- Now!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup FCCN - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 "Internet is just routes (125953/461), naming (millions) and... people!" From bortzmeyer at nic.fr Mon Aug 11 11:20:16 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 11:20:16 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811111620.P67740@Space.Net> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> Message-ID: <20030811092016.GA25538@nic.fr> On Mon, Aug 11, 2003 at 11:16:20AM +0200, Gert Doering wrote a message of 28 lines which said: > "Special" in the sense of "needs an IP address that cannot ever > change because it cannot be looked up by DNS"? Right. > There's nothing more special about ns.nic.de than about > www.google.com - if the service moves, the address in the DNS > changes, and people won't even notice. Hmmm, Gert, sorry if I seem rude, but did you heard of glue records? If not, "whois -h whois.iana.org de" and you'll understand the difference with Google (the last change we requested from IANA, adding a new name server, ns3.domain-registry.nl, for ".re" is now three weeks old and still not performed... DENIC has similar experience.). From mansaxel at sunet.se Mon Aug 11 11:31:32 2003 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Mon, 11 Aug 2003 11:31:32 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811111620.P67740@Space.Net> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> Message-ID: <96360000.1060594292@localhost.besserwisser.org> --On Monday, August 11, 2003 11:16:20 +0200 Gert Doering wrote: > What's special about ccTLD name servers? Nothing -- your analysis is correct. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bortzmeyer at nic.fr Mon Aug 11 11:35:17 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 11:35:17 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <96360000.1060594292@localhost.besserwisser.org> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <96360000.1060594292@localhost.besserwisser.org> Message-ID: <20030811093517.GA25725@nic.fr> On Mon, Aug 11, 2003 at 11:31:32AM +0200, M?ns Nilsson wrote a message of 32 lines which said: > > What's special about ccTLD name servers? > > Nothing -- your analysis is correct. No, it is not. IANA does not store the IP address of www.google.com in the DNS zone file of the root. From bortzmeyer at nic.fr Mon Aug 11 11:43:07 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 11:43:07 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811113654.Q67740@Space.Net> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> Message-ID: <20030811094307.GA25832@nic.fr> On Mon, Aug 11, 2003 at 11:36:54AM +0200, Gert Doering wrote a message of 29 lines which said: > That's an operational problem, not a technical one. Policy is only about operational problems (filtering by operators, for instance, otherwise we would just use a /29 - more than enough for the nameserver and its close friends - and announce it with BGP). > If IANA/ICANN isn't working, give them a good beating, but please > don't break policy to cover for human deficiencies. It is completely unrealistic. Do you really expect the European ccTLD to be able to change Uncle Sam's policies and practices in the next few years? Change the policy to disallow any new IPv4 allocation and assignment. After all, IPv6 works, technically speaking, so it is "just an operational problem" now, do not create convoluted policies because of IPv4 addresses scarcity. From beri at eurorings.net Mon Aug 11 11:59:34 2003 From: beri at eurorings.net (Berislav Todorovic) Date: Mon, 11 Aug 2003 11:59:34 +0200 (MET DST) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811113654.Q67740@Space.Net> Message-ID: On Mon, 11 Aug 2003, Gert Doering wrote: >> That's an operational problem, not a technical one. >> If IANA/ICANN isn't working, give them a good beating, but please don't >> break policy to cover for human deficiencies. Well, the policies should created for humans that deal with machines, not for machines that have to deal with humans. Renumbering Google means a change of an A (or CNAME) record. And people can still use Altavista or Lycos, so no big deal. Renumbering a ccTLD DNS is painful - even a secondary one. Not to mention what happens to the primary, if the operator providing connectivity to the registry bankrupts. Remember the ns.EU.net case? And what about public exchange points? Regards, Beri ---------------------------------------------------------- Berislav Todorovic, Designer KPN Telecom B.V. - OER IP Design and Engineering Phone: +31 70 343 1950 * Email: beri at eurorings.net ---------------------------------------------------------- From gert at space.net Mon Aug 11 12:04:42 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 12:04:42 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from beri@eurorings.net on Mon, Aug 11, 2003 at 11:59:34AM +0200 References: <20030811113654.Q67740@Space.Net> Message-ID: <20030811120442.Y67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 11:59:34AM +0200, Berislav Todorovic wrote: > Renumbering Google means a change of an A (or CNAME) record. And > people can still use Altavista or Lycos, so no big deal. If one DNS server for a ccTLD goes down, there are lots of secondaries that queries can go to. A normal end user won't even notice. If the primary goes down and needs to change IPs, that's primarily a non-user-visible change in the configuration of the secondary name servers. > Renumbering a ccTLD DNS is painful - even a secondary one. Not to > mention what happens to the primary, if the operator providing > connectivity to the registry bankrupts. Remember the ns.EU.net case? Distribute your secondary name servers well, and a single nameserver going down won't do that much hurt. Of course procedures should be into place to change the glue records quickly (in the range of "hours", instead of "months"). > And what about public exchange points? In which way are ccTLDs related to public exchange points? Or are you referring to the discussed "abandon PI" policy change? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) 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 Aug 11 12:23:31 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 12:23:31 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from beri@eurorings.net on Mon, Aug 11, 2003 at 12:20:27PM +0200 References: <20030811120442.Y67740@Space.Net> Message-ID: <20030811122331.C67740@Space.Net> hi, On Mon, Aug 11, 2003 at 12:20:27PM +0200, Berislav Todorovic wrote: > >> > And what about public exchange points? > >> > >> In which way are ccTLDs related to public exchange points? Or are you > >> referring to the discussed "abandon PI" policy change? > > In no way ... that was a separate question related to the PI policy > change. I should have put a "P.S." in front. Sorry for confusion. ;-) Okay :-) - I have no clear answer on the exchange point question. Many of them are LIR already anyway (so they use PA). The approach with a one-time service fee to get "PI-like" space might work out for them. But yes, this needs discussion. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From joao at psg.com Mon Aug 11 12:27:06 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Mon, 11 Aug 2003 12:27:06 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions Message-ID: <5B551210-CBE6-11D7-B092-003065521028@psg.com> Gert, On Monday, August 11, 2003, at 11:50 AM, Gert Doering wrote: > Hi, > > On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote: >> I have one question, trying to understand the main goal of the >> exercise: >> >> * Is the aim of the a new PI policy to adjust the policy to the >> requests and needs of the industry or is it a way of getting a >> "special >> allocation" policy by another name? > > My aim is to adjust the policy (actually both PA and PI policy) to > match > observed need. > That is good. > People are requesting *multiple* PI blocks because they can't get a PA > allocation, and that seems to be just wrong to me. > Just to spell it out clearly: - Is it people who do not meet the minimum allocation size for PA? I guess these ones would ask for a single PI assignment? - Is it people who find it to be so much hassle to get an allocation that they end up requesting multiple PI blocks with the same amount of addresses? - People who have multiple sites and if they get a normal PA block will need to split it and end up with a bunch of non-routable sites? Other? Just trying to understand. One last thing. There is something that makes it unusually attractive to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) where you don't have to bother with anyone filtering you if you have at least a /24 (damn easy to justify). Joao From oliver at bartels.de Mon Aug 11 12:27:51 2003 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 11 Aug 2003 12:27:51 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811113654.Q67740@Space.Net> Message-ID: <200308111027.h7BARKbw013507@alpha.bartels.de> On Mon, 11 Aug 2003 11:36:54 +0200, Gert Doering wrote: >That's an operational problem, not a technical one. > >If IANA/ICANN isn't working, give them a good beating, but please don't >break policy to cover for human deficiencies. Well, the policy is for the humans and not the humans for the policy. We are all *service* providers and thus we should deliver the *service* the customer which the customer demands. If there is a reasonable demand for PI (whether v4 or currently unsolved v6), we should try to do our best to serve this demand. Just my 2 cent for your "I don't like independend address space" position, which I don't believe is the position of the majority of the ISP's. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From gert at space.net Mon Aug 11 12:29:54 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 12:29:54 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from joao@isc.org on Mon, Aug 11, 2003 at 12:24:14PM +0200 References: <20030811115059.V67740@Space.Net> Message-ID: <20030811122954.D67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 12:24:14PM +0200, Joao Damas wrote: > > People are requesting *multiple* PI blocks because they can't get a PA > > allocation, and that seems to be just wrong to me. > > Just to spell it out clearly: > > - Is it people who do not meet the minimum allocation size for PA? I > guess these ones would ask for a single PI assignment? The ones I've heard about is "people that are startup ISPs, and still too small for PA". So they get a PI (because that's all they can get), and when that's full, they get another PI, and so on, until they can demonstrate "utilization of a /21" - and then they go for PA. They are effectively using PI as a "easier to get PA substitute" - which is wrong, but points at a serious problem in the policy. > - Is it people who find it to be so much hassle to get an allocation > that they end up requesting multiple PI blocks with the same amount of > addresses? After a while, they move from your first category to this one... > - People who have multiple sites and if they get a normal PA block will > need to split it and end up with a bunch of non-routable sites? As far as I know, not this. [..] > One last thing. There is something that makes it unusually attractive > to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) > where you don't have to bother with anyone filtering you if you have at > least a /24 (damn easy to justify). But this only works if you actually *get* a /24. So people that run two servers have to lie to the NCC to get a /24 (instead of a /29 or a /28), which is also a hint at a broken policy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From beri at eurorings.net Mon Aug 11 12:20:27 2003 From: beri at eurorings.net (Berislav Todorovic) Date: Mon, 11 Aug 2003 12:20:27 +0200 (MET DST) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811120442.Y67740@Space.Net> Message-ID: On Mon, 11 Aug 2003, Gert Doering wrote: >> > And what about public exchange points? >> >> In which way are ccTLDs related to public exchange points? Or are you >> referring to the discussed "abandon PI" policy change? In no way ... that was a separate question related to the PI policy change. I should have put a "P.S." in front. Sorry for confusion. ;-) ---------------------------------------------------------- Berislav Todorovic, Designer KPN Telecom B.V. - OER IP Design and Engineering Phone: +31 70 343 1950 * Email: beri at eurorings.net ---------------------------------------------------------- From joao at isc.org Mon Aug 11 12:24:14 2003 From: joao at isc.org (Joao Damas) Date: Mon, 11 Aug 2003 12:24:14 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811115059.V67740@Space.Net> Message-ID: Gert, On Monday, August 11, 2003, at 11:50 AM, Gert Doering wrote: > Hi, > > On Mon, Aug 11, 2003 at 11:48:28AM +0200, Joao Luis Silva Damas wrote: >> I have one question, trying to understand the main goal of the >> exercise: >> >> * Is the aim of the a new PI policy to adjust the policy to the >> requests and needs of the industry or is it a way of getting a >> "special >> allocation" policy by another name? > > My aim is to adjust the policy (actually both PA and PI policy) to > match > observed need. > That is good. > People are requesting *multiple* PI blocks because they can't get a PA > allocation, and that seems to be just wrong to me. > Just to spell it out clearly: - Is it people who do not meet the minimum allocation size for PA? I guess these ones would ask for a single PI assignment? - Is it people who find it to be so much hassle to get an allocation that they end up requesting multiple PI blocks with the same amount of addresses? - People who have multiple sites and if they get a normal PA block will need to split it and end up with a bunch of non-routable sites? Other? Just trying to understand. One last thing. There is something that makes it unusually attractive to have PI space: it usually comes from "old" blocks (192/8, 193-195/8) where you don't have to bother with anyone filtering you if you have at least a /24 (damn easy to justify). Joao From mansaxel at sunet.se Mon Aug 11 12:31:31 2003 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Mon, 11 Aug 2003 12:31:31 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811093517.GA25725@nic.fr> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <96360000.1060594292@localhost.besserwisser.org> <20030811093517.GA25725@nic.fr> Message-ID: <147270000.1060597891@localhost.besserwisser.org> --On Monday, August 11, 2003 11:35:17 +0200 Stephane Bortzmeyer wrote: >> > What's special about ccTLD name servers? >> >> Nothing -- your analysis is correct. > > No, it is not. IANA does not store the IP address of www.google.com in > the DNS zone file of the root. Which is easily editable, and has the ability to propagate to all root servers in a fast and timely manner, using a well-known and defined interaction system. The root server operators will probably be happy to ensure us that this is the fact. There is no magic here -- just ordinary DNS. The ONLY magic addresses in the DNS are the root server IP addresses, because they need to be in the hint file; the rest is nothing special. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Marcus.Ruchti at colt.de Mon Aug 11 12:59:02 2003 From: Marcus.Ruchti at colt.de (Marcus.Ruchti at colt.de) Date: Mon, 11 Aug 2003 11:59:02 +0100 Subject: AW: [address-policy-wg] Summary of the PI Task Force's recent dis cussions Message-ID: so how should we connect multihomed customers?? a majority of the ISP's won't announce PA space of another AS. rgds, Marcus Ruchti COLT Telecom GmbH -----Urspr?ngliche Nachricht----- Von: Joao Luis Silva Damas [mailto:joao at psg.com] Gesendet am: Montag, 11. August 2003 11:48 An: Address Policy WG Betreff: Re: [address-policy-wg] Summary of the PI Task Force's recent discussions I have one question, trying to understand the main goal of the exercise: * Is the aim of the a new PI policy to adjust the policy to the requests and needs of the industry or is it a way of getting a "special allocation" policy by another name? Joao On Monday, August 11, 2003, at 10:29 AM, Stephane Bortzmeyer wrote: > On Mon, Aug 11, 2003 at 08:19:46AM +0200, > leo vegoda wrote > a message of 91 lines which said: > >> 3. No longer assign PI (Portable) address space to End Users >> >> - There some support for to this point. The issue of Root DNS >> Servers was raised but it was noted that all Root DNS Servers >> operating in this region already have address assignments. > > And what about ccTLD name servers? > > From chr at jay.net Mon Aug 11 13:43:15 2003 From: chr at jay.net (Christian Rasmussen) Date: Mon, 11 Aug 2003 13:43:15 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811122954.D67740@Space.Net> Message-ID: > > The ones I've heard about is "people that are startup ISPs, and still > too small for PA". So they get a PI (because that's all they can get), > and when that's full, they get another PI, and so on, until they can > demonstrate "utilization of a /21" - and then they go for PA. > > They are effectively using PI as a "easier to get PA substitute" - which > is wrong, but points at a serious problem in the policy. > If an end user needs between /24 and /21 and do not expect much growth within the next few years but would like to be able to easily change provider without renumbering then I believe PI space is a good solution. I do not see the reason for using PI space if you're an ISP intending to become LIR, this means you will need to renumber when you get your PA allocation no matter if you use PA or PI, so why not just get a PA assignment from your provider until you can justify the /21? Marcus Ruchti says that the majority of the ISPs will not announce PA space from another AS, does this include more specific announcements? If the community does not allow this, whats the point of this: 1. Why is PI space required rather than PA space? - If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route(with the PA block holder adding a more specific route too). (part of the questions which must be answered after applying for PI space). We set up a few customers requesting PI space, some of the bigger ones also set up BGP and gets their own AS, if they cannot justify (nor wishes) a PA allocation, they need to be able to get PI space. A very peculiar thing regarding policy, a customer of ours applied for a PA block but could not justify a /20 (a year ago), BUT, when we applied on their behalf for PA space (ours) we were allowed to assign them a /20....! I was then told that as they had now been assigned a /20 they would be allowed to become LIR...! Hopefully this was a misunderstanding, if not, I think this part of the policy might need a few changes.. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net From chr at jay.net Mon Aug 11 14:03:27 2003 From: chr at jay.net (Christian Rasmussen) Date: Mon, 11 Aug 2003 14:03:27 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811135432.A66996@cluecentral.net> Message-ID: Yes, I know, but I don't see any technical problems in doing this, and if the alternative is that the customer chooses another provider, then I would think that a lot of ISPs would accept. I think this is a better way than assigning a PI net which will only be used until the customer can justify the /21, I know there is some administrative tasks in doing it this way, but if the customer is willingly to pay an administrative fee I don't see the problem. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc at jay.net Personal email: chr at corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net > -----Original Message----- > From: Sabri Berisha [mailto:sabri at cluecentral.net] > Sent: 11. august 2003 13:55 > To: Christian Rasmussen > Cc: Gert Doering; Joao Damas; Address Policy WG > Subject: Re: [address-policy-wg] Summary of the PI Task Force's recent > discussions > > > On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote: > > > Marcus Ruchti says that the majority of the ISPs will not > announce PA space > > from another AS, does this include more specific announcements? If the > > community does not allow this, whats the point of this: > > You will need both parties. The first ISP to add a route-object, and the > second to be willing to announce. > > -- > Sabri Berisha "I route, therefore you are" > > user-specific rbl checking? http://sourceforge.net/projects/rblcheckd > > From gert at space.net Mon Aug 11 14:05:59 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 14:05:59 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from chr@jay.net on Mon, Aug 11, 2003 at 01:43:15PM +0200 References: <20030811122954.D67740@Space.Net> Message-ID: <20030811140559.G67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote: > I do not see the reason for using PI space if you're an ISP intending to > become LIR, this means you will need to renumber when you get your PA > allocation no matter if you use PA or PI, so why not just get a PA > assignment from your provider until you can justify the /21? That's what I thought people would do. But they don't. They want to be "independent", and so they go for PI, instead for a suballocation from one of their upstreams. (And they don't renumber, of course, but just keep the PI) > Marcus Ruchti says that the majority of the ISPs will not announce PA space > from another AS, does this include more specific announcements? I just disagree with that statement. PA-based multihoming is a valid approach to solve certain classes of problems. If some ISPs refuse to support this (because it creates more work for their NOC or whatever reason...), the market place has alternatives... [..] > A very peculiar thing regarding policy, a customer of ours applied for a PA > block but could not justify a /20 (a year ago), BUT, when we applied on > their behalf for PA space (ours) we were allowed to assign them a /20....! I > was then told that as they had now been assigned a /20 they would be allowed > to become LIR...! Hopefully this was a misunderstanding, if not, I think > this part of the policy might need a few changes.. Changing this is part of Leo's proposal :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Michael.Dillon at radianz.com Mon Aug 11 14:18:41 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 11 Aug 2003 13:18:41 +0100 Subject: [address-policy-wg] English Language (was: Summary of the PI Task Force's recent discussions) Message-ID: >People are requesting *multiple* PI blocks because they can't get a PA >allocation, and that seems to be just wrong to me. Something strange is happening to the English language here. Whenever I read PI and PA, I have a mental concept of independent blocks that I can announce, and borrowed blocks that I get from my provider's aggregate. In this set of mental concepts, a provider gets a PI block from an RIR and then allocates PA blocks to their customers. But after stumbling through this thread, I checked the RIPE website and discovered that the IPv4 policies state: LIRs are allocated Provider Aggregatable address space that they assign to their End Users and announced as one prefix. The problem is that the word "aggretable" means something that is capable of being aggregated. The block that a customer receives from the LIR is a part of a larger aggregate and is therefore "aggregatable". But the block that the LIR receives from the RIR is not necessarily aggregatable because there is no guarantee that the RIR will reserve adjacent blocks for the LIR. I know that the practice is to reserve the adjacent blocks for some period of time, but there are a lot of LIRs which have multiple non-aggregatable blocks from the RIRs. This is important because if we are not clear and consistent in our use of the language, then we create confusion and misunderstandings. For instance, in the ARIN world, PA stands for Provider Assigned in order to make it clear that the RIR gives providers PI space and the providers cut it up into PA blocks for their customers. It's like lending and borrowing. If I lend you a bicycle then you are borrowing it from me. Then you can lend the borrowed bicycle to your friend so that you are both a borrower and a lender of the bicycle. It seems to me that the distinction needs to be made between network-independent address blocks and network-dependent or network-attached ones. NI Network-Independent address blocks are allocated to an organization by the RIR and can be announced in whole or in part by any network with which the organization has a relationship. NA Network-Attached address blocks are assigned to an organization by an LIR and can only be used with the network(s) operated by that LIR. Then we could drop the acronyms and start talking about independent address blocks and attached network blocks. Personally, I don't believe that all 5 RIRs should have the same policies but I do believe that all 5 RIRs should use the same terminology and language to talk about addressing as long as the talking is done in English. --Michael Dillon From sabri at cluecentral.net Mon Aug 11 13:54:32 2003 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 11 Aug 2003 13:54:32 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from chr@jay.net on Mon, Aug 11, 2003 at 01:43:15PM +0200 References: <20030811122954.D67740@Space.Net> Message-ID: <20030811135432.A66996@cluecentral.net> On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote: > Marcus Ruchti says that the majority of the ISPs will not announce PA space > from another AS, does this include more specific announcements? If the > community does not allow this, whats the point of this: You will need both parties. The first ISP to add a route-object, and the second to be willing to announce. -- Sabri Berisha "I route, therefore you are" user-specific rbl checking? http://sourceforge.net/projects/rblcheckd From joao at isc.org Mon Aug 11 14:38:47 2003 From: joao at isc.org (Joao Damas) Date: Mon, 11 Aug 2003 14:38:47 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811140559.G67740@Space.Net> Message-ID: Gert, On Monday, August 11, 2003, at 02:05 PM, Gert Doering wrote: > Hi, > > On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote: >> I do not see the reason for using PI space if you're an ISP intending >> to >> become LIR, this means you will need to renumber when you get your PA >> allocation no matter if you use PA or PI, so why not just get a PA >> assignment from your provider until you can justify the /21? > > That's what I thought people would do. But they don't. They want to > be "independent", and so they go for PI, instead for a suballocation > from one of their upstreams. From an end user (enterprise) point of view, what is wrong with trying to minimise the pain of changing ISPs (renumbering)? On the other hand, it seems a waste of time and resources for all involved to give out blocks of size less than the minimum observed to be routed on the Internet. I know the registries can not guarantee routing of anything on the network but that does not mean the registries can not follow 'best common practice' as seen on the net, and I think everyone agrees that any prefix longer than a /24 doesn't make it past your border routers. > > (And they don't renumber, of course, but just keep the PI) > Well, yes, would anyone return it if it worked for them? Joao From randy at psg.com Mon Aug 11 16:13:22 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 07:13:22 -0700 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> Message-ID: >> 3. No longer assign PI (Portable) address space to End Users >> >> - There some support for to this point. The issue of Root DNS >> Servers was raised but it was noted that all Root DNS Servers >> operating in this region already have address assignments. > And what about ccTLD name servers? you can look them up in the dns. randy From randy at psg.com Mon Aug 11 16:18:31 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 07:18:31 -0700 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> Message-ID: > As far as I understand, the threat from APNIC and RIPE to just ditch > ICANN and get on without it seems to have had quite some effect. > > If all non-US-ccTLD registries (of which there are lots more than > US-based) start beating ICANN with joint forces, I'm pretty sure that > this will have an effect. and why should they trust ripe and apnic more than icann? all act from positions of power while claiming service. randy From randy at psg.com Mon Aug 11 16:37:14 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 07:37:14 -0700 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811141814.GA30990@nic.fr> Message-ID: >>> And what about ccTLD name servers? >> you can look them up in the dns. > Do you read all the thread before replying? That erroneous > argument has already been beaten to death. no. you just don't happen to like it. some decades ago, we moved from hosts.txt to a dynamic system to resolve names. part of its design was that it was rooted in a few well-known addresses, the ip addresses of the root servers. the protocol is such that you don't even need to have a completely correct list of those. now you want to fix the addresses of many names we worked hard to make dynamic. no thanks. randy From randy at psg.com Mon Aug 11 16:38:28 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 07:38:28 -0700 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811142952.GB31104@nic.fr> Message-ID: >> all act from positions of power while claiming service. > This is perfectly true. However, in practice, some are more > inefficient/ obtrusive/ obnoxious, than others. imiho, the contest has become quite keen From bortzmeyer at nic.fr Mon Aug 11 16:18:14 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 16:18:14 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> Message-ID: <20030811141814.GA30990@nic.fr> On Mon, Aug 11, 2003 at 07:13:22AM -0700, Randy Bush wrote a message of 10 lines which said: > > And what about ccTLD name servers? > > you can look them up in the dns. Do you read all the thread before replying? That erroneous argument has already been beaten to death. From bortzmeyer at nic.fr Mon Aug 11 16:29:52 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 16:29:52 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> Message-ID: <20030811142952.GB31104@nic.fr> On Mon, Aug 11, 2003 at 07:18:31AM -0700, Randy Bush wrote a message of 11 lines which said: > all act from positions of power while claiming service. This is perfectly true. However, in practice, some are more inefficient/ obtrusive/ obnoxious, than others. From bortzmeyer at nic.fr Mon Aug 11 16:36:14 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 16:36:14 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <20030811114628.S67740@Space.Net> Message-ID: <20030811143614.GA31246@nic.fr> On Mon, Aug 11, 2003 at 11:00:02AM +0100, Carlos Friacas wrote a message of 29 lines which said: > > If all non-US-ccTLD registries (of which there are lots more than > > US-based) start beating ICANN with joint forces, I'm pretty sure that > > this will have an effect. > > Has anyone tried serious reasoning with them about these delays??? Good Lord, on which planet were you, the last five years? All the ccTLD managers, as well as many governments, a lof of concerned individuals and so on, have tried to move IANA faster. If it does not, it is not a technical issue (unlike ".com" or even ".fr", the root is a very small zone, easily maintainable manually), it is a political one. IANA blackmails the ccTLD managers: if they do not sign the "sponsorship agreement" (not one in Europe did), even very trivial changes are delayed for ever. From gert at space.net Mon Aug 11 17:03:37 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 17:03:37 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from joao@isc.org on Mon, Aug 11, 2003 at 02:38:47PM +0200 References: <20030811140559.G67740@Space.Net> Message-ID: <20030811170337.J67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 02:38:47PM +0200, Joao Damas wrote: > On Monday, August 11, 2003, at 02:05 PM, Gert Doering wrote: > > On Mon, Aug 11, 2003 at 01:43:15PM +0200, Christian Rasmussen wrote: > >> I do not see the reason for using PI space if you're an ISP intending > >> to > >> become LIR, this means you will need to renumber when you get your PA > >> allocation no matter if you use PA or PI, so why not just get a PA > >> assignment from your provider until you can justify the /21? > > > > That's what I thought people would do. But they don't. They want to > > be "independent", and so they go for PI, instead for a suballocation > > from one of their upstreams. > > From an end user (enterprise) point of view, what is wrong with trying > to minimise the pain of changing ISPs (renumbering)? I wasn't judging, I was explaining why the mechanisms in the current policy don't work on real-world people - and as such, the policy is flawed in that respect. (Yes, I see a difference between "startup LIR having problems in getting an initial allocation -> fix policy" and "ccTLDs have problems in getting ICANN to change glue records -> fix ICANN"). > On the other hand, it seems a waste of time and resources for all > involved to give out blocks of size less than the minimum observed to > be routed on the Internet. I know the registries can not guarantee > routing of anything on the network but that does not mean the > registries can not follow 'best common practice' as seen on the net, > and I think everyone agrees that any prefix longer than a /24 doesn't > make it past your border routers. People actually do want PI space for other things (like "internal VPN connections that must be numbered unique but need not be routed"). But that's a different issue. > > (And they don't renumber, of course, but just keep the PI) > Well, yes, would anyone return it if it worked for them? No, and that's part of the problem. If it can be avoided in the first place to have people announce multiple prefixes, then we should aim for that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From bortzmeyer at nic.fr Mon Aug 11 16:43:07 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 16:43:07 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811141814.GA30990@nic.fr> Message-ID: <20030811144307.GA31457@nic.fr> On Mon, Aug 11, 2003 at 07:37:14AM -0700, Randy Bush wrote a message of 17 lines which said: > now you want to fix the addresses of many names we worked hard to > make dynamic. I'm fairly certain that many people here will like to read your proposal explaining how to suppress glue records in the root zone file. Send a copy to IANA, too. From daniel.karrenberg at ripe.net Mon Aug 11 17:10:05 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 11 Aug 2003 17:10:05 +0200 Subject: [address-policy-wg] ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> Message-ID: <20030811151005.GF490@reifa-wave.karrenberg.net> Randy, the RIPE NCC, imperfect as it may be, pre-dates ICANN by many years and has always been a bottom-up organisation driven by the ISPs. It is a response to the need of the ISPs to organise some technical aspects of the Internet infrastructure as a group, while going about their otherwise competitive business(es). The RIPE NCC is a neutral organisation providing professional services. The formal structure reflects this fully: a membership association directed by its members, the ISPs. Of curse the members have a task in this: to control and steer the association. RIPE itself has always been an open forum where even those wo are not members of the RIPE *NCC* can have great influence on what the RIPE *NCC* does. As such the RIPE NCC has *much* more legitimacy than ICANN, an organisation instigated by a policy need of one particular government. You know the history at least as well as I do. Other governments mostly jumped on the bandwaggon for varied reasons. ICANN still largely has to earn its legitimacy. This is a difficult task and I do not envy those undertaking it. But, through hard work of -among others- the RIPE NCC, ICANN's possibilities to interfere with ISP related matters without legitimacy, are extremely limited. I take offense if people put ICANN and the RIPE NCC in the same corner, especially people who know better. They are two totally different things. Randy, I would hope that you can stop sneering and help work towards improving the RIPE NCC, like you once did. Sincerely Daniel (first and longest serving of the RIPE NCC staff) On 11.08 07:18, Randy Bush wrote: > > As far as I understand, the threat from APNIC and RIPE to just ditch > > ICANN and get on without it seems to have had quite some effect. > > > > If all non-US-ccTLD registries (of which there are lots more than > > US-based) start beating ICANN with joint forces, I'm pretty sure that > > this will have an effect. > > and why should they trust ripe and apnic more than icann? all act > from positions of power while claiming service. > > randy From gert at space.net Mon Aug 11 17:14:49 2003 From: gert at space.net (Gert Doering) Date: Mon, 11 Aug 2003 17:14:49 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: ; from randy@psg.com on Mon, Aug 11, 2003 at 07:18:31AM -0700 References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> Message-ID: <20030811171449.K67740@Space.Net> Hi, On Mon, Aug 11, 2003 at 07:18:31AM -0700, Randy Bush wrote: > > As far as I understand, the threat from APNIC and RIPE to just ditch > > ICANN and get on without it seems to have had quite some effect. > > > > If all non-US-ccTLD registries (of which there are lots more than > > US-based) start beating ICANN with joint forces, I'm pretty sure that > > this will have an effect. > > and why should they trust ripe and apnic more than icann? all act > from positions of power while claiming service. I was just argueing that "the internet will work fine without ICANN, so maybe they should actually start being productive for the money they burn". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Mon Aug 11 17:25:08 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 08:25:08 -0700 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811151005.GF490@reifa-wave.karrenberg.net> Message-ID: daniel, and both of us predate ripe, icann, and so forth. and many folk here contributed to the formation of all of these administrative monsters. big whoopie-doo. i would gladly be 30 years younger and a newbie. as a user of ripe, apnic, icann, ... i am telling you that it is hard for me to tell the difference these days in arrogance, application of power, bureaucratic delay, political maneuvering, stonewalling, blah blah blah. and when you push back as opposed to seriously discussing my concerns, as has been the case for a few years now, all i can think is QED. like other representative systems such as legislatures, the RIRs have moved from being associations of their users to becoming self-perpetuating governmental bureaucracies, who are not actually users themselves, but speak for us, tell us what we think and should do, and how we are being uncooperative and sneering. but at least the RIRs are not invading foreign countries and murdering people, as my local governmental bureaucracy seems wont to do. and don't give me "why don't you help?" i have for decades. you recently stopped listening. randy From randy at psg.com Mon Aug 11 17:28:21 2003 From: randy at psg.com (Randy Bush) Date: Mon, 11 Aug 2003 08:28:21 -0700 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811171449.K67740@Space.Net> Message-ID: >> and why should they trust ripe and apnic more than icann? all act >> from positions of power while claiming service. > I was just argueing that "the internet will work fine without ICANN, so > maybe they should actually start being productive for the money they burn". s/icann/icann, the rirs, .../ all this is a social experiment to see how many bureaucrats, amateur politicians (though the professionals are entering the fray), bureaucrats, lawyers, and just plain slimeballs it takes to replace one part-time computer scientist (whose 60th birthday would have been last wednesday). randy From daniel.karrenberg at ripe.net Mon Aug 11 17:50:39 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 11 Aug 2003 17:50:39 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811151005.GF490@reifa-wave.karrenberg.net> Message-ID: <20030811155038.GH490@reifa-wave.karrenberg.net> I have not stopped listening to concrete ideas about improving the RIPE NCC. I am still here at the RIPE NCC working and listening. Of course the bureaucratic developments you sneer at *do* happen to some degree. This is inevitable and both you and I know it. The ability of individuals like you and me to influence things immediately and directly is reduced. Of course I personally I do not agree with all things the RIRs do and more often I do not agree with *how* things are done. What seems to divide us is that I still work to improve the 'least of all evils' structure and you sneer at it providing no alternative. I would hope that more people will chose the former instead of the latter. I also hope that people still see the relative mertis and the differences in legitimacy that exist between the various organisations. Sneering at the RIPE NCC without suggesting either alternatives or improvements does not help. Daniel From joao at isc.org Mon Aug 11 17:38:25 2003 From: joao at isc.org (Joao Damas) Date: Mon, 11 Aug 2003 17:38:25 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811170337.J67740@Space.Net> Message-ID: On Monday, August 11, 2003, at 05:03 PM, Gert Doering wrote: > > People actually do want PI space for other things (like "internal > VPN connections that must be numbered unique but need not be routed"). > That is what I am trying to see. The more exceptions and the more fine tuning a policy has, usually the worse it is when it gets applied. > >>> (And they don't renumber, of course, but just keep the PI) >> Well, yes, would anyone return it if it worked for them? > > No, and that's part of the problem. If it can be avoided in the first > place to have people announce multiple prefixes, then we should aim for > that. > I agree. In general, policies that encourage people to distort reality or look for workarounds are not good policies. In those cases you have to go and fix the offending policy and try not to teak the workarounds. So, can we enumerate 4 or 5 items that cover a wide range of cases where people asked for PI and see if the origin of the problem is with the PI policy or elsewhere? Leo's earlier mail included a reference to a change in the minimum allocation size from a /20 to a /21 (8x /24). Is this likely to have an impact such that the pressure to use PI is going to be less? Joao From md at ncuk.net Mon Aug 11 18:00:13 2003 From: md at ncuk.net (Sebastien Lahtinen) Date: Mon, 11 Aug 2003 17:00:13 +0100 (BST) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: Message-ID: On Mon, 11 Aug 2003, Joao Damas wrote: > Leo's earlier mail included a reference to a change in the minimum > allocation size from a /20 to a /21 (8x /24). Is this likely to have an > impact such that the pressure to use PI is going to be less? I think the minimum allocation size reduction is a good idea as it reduces the need for PI and waste in PA. PI should still be available for those who ask for it. There are indeed projects that would not be likely to need a /21 but might need independent space. It's a waste making them to take a /21. I can to some degree understand this desire for large PI blocks (/21 and above) but there should be place for the /24, /23 and /22 PI blocks. Sebastien. --- NetConnex Broadband Ltd. tel. +44 870 745 4830 fax. +44 870 745 4831 Court Farm Lodge, 1 Eastway, Epsom, Surrey, KT19 8SG. United Kingdom. From hpholen at tiscali.no Mon Aug 11 23:46:05 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Aug 2003 20:46:05 -0100 (GMT+1) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811094307.GA25832@nic.fr> Message-ID: > It is completely unrealistic. Do you really expect the European ccTLD > to be able to change Uncle Sam's policies and practices in the next > few years? Sligthly concerned that we should spend our time on "fixing" ICANNs operational pratices on ccTLD delegation trough IP addressing policy. -hph From hpholen at tiscali.no Mon Aug 11 23:47:38 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Aug 2003 20:47:38 -0100 (GMT+1) Subject: [address-policy-wg] WG Charter In-Reply-To: Message-ID: > Hans Petter, > > I would also mention the role of the working group in > - co-ordinating policies with other RIRs > - address policy issues that have to do with IANA/ICANN What about: The Address Policy WG develops policies relating to the management and registration of Internet resources (currently IPv4, IPv6 and AS Numbers) by the RIPE NCC and its LIRs within the RIPE NCC service region. It also co-ordinates policies with the other RIR communities and liaises with the IANA and ICANN on address policy issues. The Address Policy WG meets three times a year at RIPE meetings and has an open (publicly archived) mailing list. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. -hph From hpholen at tiscali.no Mon Aug 11 23:52:45 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Aug 2003 20:52:45 -0100 (GMT+1) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811094307.GA25832@nic.fr> Message-ID: > It is completely unrealistic. Do you really expect the European ccTLD > to be able to change Uncle Sam's policies and practices in the next > few years? Yes, I do. There are various ways to make this happen. They specificaly do not include * beating * calling eachother names (its ICANN not "Uncle Sam" * discussing ICANN ccTLD operational matters in the RIPE address policy WG. -hph From hpholen at tiscali.no Tue Aug 12 00:08:12 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Mon, 11 Aug 2003 21:08:12 -0100 (GMT+1) Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: Message-ID: Randy, You and Daniel outrank me with some years, but I still feel a need to comment on this: > like other representative systems such as legislatures, the RIRs > have moved from being associations of their users to becoming > self-perpetuating governmental bureaucracies, who are not actually > users themselves, but speak for us, tell us what we think and > should do, and how we are being uncooperative and sneering. but > at least the RIRs are not invading foreign countries and murdering > people, as my local governmental bureaucracy seems wont to do. Personally I think I have seen quite a few positive imporvements from the RIPE NCC over the last year. -hph From peter.galbavy at knowtion.net Mon Aug 11 20:33:32 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Mon, 11 Aug 2003 19:33:32 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <+f6cKhCCWzN$EwbX@ripe.net><20030811082953.GA24572@nic.fr><20030811111620.P67740@Space.Net><20030811092016.GA25538@nic.fr><20030811113654.Q67740@Space.Net><20030811094307.GA25832@nic.fr><20030811114628.S67740@Space.Net><20030811151005.GF490@reifa-wave.karrenberg.net> Message-ID: <00b501c36037$1194d460$24e0a8c0@HATMADDER> Randy Bush wrote: > like other representative systems such as legislatures, the RIRs > have moved from being associations of their users to becoming > self-perpetuating governmental bureaucracies, who are not actually > users themselves, but speak for us, tell us what we think and > should do, and how we are being uncooperative and sneering. but > at least the RIRs are not invading foreign countries and murdering > people, as my local governmental bureaucracy seems wont to do. I could not agree more. No, really. There is no way for anyone with 'opposing' views to make them heard in any relevant forum. Mailing lists are not classed as official, and unless you speak "bureauocratese" (as I have said before), you cannot be heard in any official forum. I expect the overstaffed gravy train that is RIPE to continue supporting it's implicit "jobs for friends and for life" policies to continue and for us "members" to be expected to pay without any real voice. Please don't bother telling me about "taking part" and "attending meetings", I did that in the past, now I cannot be bothered wasting the airfare. Peter From mansaxel at sunet.se Mon Aug 11 19:08:55 2003 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Mon, 11 Aug 2003 19:08:55 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811141814.GA30990@nic.fr> References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811141814.GA30990@nic.fr> Message-ID: <65470000.1060621735@localhost.besserwisser.org> --On Monday, August 11, 2003 16:18:14 +0200 Stephane Bortzmeyer wrote: > On Mon, Aug 11, 2003 at 07:13:22AM -0700, > Randy Bush wrote > a message of 10 lines which said: > >> > And what about ccTLD name servers? >> >> you can look them up in the dns. > > Do you read all the thread before replying? That erroneous argument > has already been beaten to death. dig fr ns +short | while read ns ; do dig $ns A +short dig $ns AAAA +short done 193.176.144.6 204.152.184.64 2001:4f8:0:2::13 128.105.2.10 193.51.208.13 128.112.129.15 128.112.128.1 192.93.0.1 192.93.0.4 192.134.0.49 2001:660:3006:1::1:1 I feel your pain -- I have once waited more than a month for an IANA ccTLD change, but do not let that pain mess up the allocation discussion -- they are separate issues. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bortzmeyer at nic.fr Mon Aug 11 23:06:49 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Aug 2003 23:06:49 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <20030811094307.GA25832@nic.fr> Message-ID: <20030811210649.GA2134@nic.fr> On Mon, Aug 11, 2003 at 08:52:45PM -0100, Hans Petter Holen wrote a message of 13 lines which said: > * beating I didn't. > * calling eachother names (its ICANN not "Uncle Sam" Yes, it is the same thing. Read www.icann.org and specially the parts about the various contracts with DoC (US Department of Commerce) which approves, in writing, every change in the root zone file. > * discussing ICANN ccTLD operational matters in the RIPE address > policy WG. I didn't want to discuss ICANN matters. On the contrary, I wanted to emphasize that ICANN practices are a fixed feature, like gravity, and therefore we should design policies that take this feature into account (if policies are meant to solve real-world problems, that is, and not just to be "elegant"). From anne at apnic.net Tue Aug 12 03:44:52 2003 From: anne at apnic.net (Anne Lord) Date: Tue, 12 Aug 2003 11:44:52 +1000 (EST) Subject: [hm-staff] [address-policy-wg] English Language (was: Summary of the PI Task Force's recent discussions) In-Reply-To: Message-ID: Hi Michael, Using identical terms to describe the same concepts is indeed a desirable goal imho. However what follows is a short description of the terms used in the APNIC region - which are again (unfortunately!) different to those used by the other RIRs. APNIC inherited the terms PA and PI and used these terms in the past. However the feedback received through the delivery of the training courses always pointed to a lot of confusion over the actual meaning. Most commonly the feedback was along the lines of "Isnt a PA block a PI block to the ISP using it?" As it seemed that the essential issue was one of portability, the terms 'portable' and 'non-portable' address space were subsequently introduced to replace 'PI' and 'PA' respectively. RIRs make portable allocations and assignments (small multihoming assignment policy, IXP policies, critical infrastructure etc) whilst LIRs make non-portable assignments and sub-allocations. regards, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 ---------------------------------------------------------------------- See you at APNIC 16 Seoul, Korea, 19-22 August 2003 http://www.apnic.net/meetings ---------------------------------------------------------------------- On Mon, 11 Aug 2003 Michael.Dillon at radianz.com wrote: > >People are requesting *multiple* PI blocks because they can't get a PA > >allocation, and that seems to be just wrong to me. > > Something strange is happening to the English language here. Whenever I > read PI and PA, I have a mental concept of independent blocks that I can > announce, and borrowed blocks that I get from my provider's aggregate. In > this set of mental concepts, a provider gets a PI block from an RIR and > then allocates PA blocks to their customers. > > But after stumbling through this thread, I checked the RIPE website and > discovered that the IPv4 policies state: > > LIRs are allocated Provider Aggregatable address space that they > assign to their End Users and announced as one prefix. > > The problem is that the word "aggretable" means something that is capable > of being aggregated. The block that a customer receives from the LIR is a > part of a larger aggregate and is therefore "aggregatable". But the block > that the LIR receives from the RIR is not necessarily aggregatable because > there is no guarantee that the RIR will reserve adjacent blocks for the > LIR. I know that the practice is to reserve the adjacent blocks for some > period of time, but there are a lot of LIRs which have multiple > non-aggregatable blocks from the RIRs. > > This is important because if we are not clear and consistent in our use of > the language, then we create confusion and misunderstandings. > > For instance, in the ARIN world, PA stands for Provider Assigned in order > to make it clear that the RIR gives providers PI space and the providers > cut it up into PA blocks for their customers. It's like lending and > borrowing. If I lend you a bicycle then you are borrowing it from me. Then > you can lend the borrowed bicycle to your friend so that you are both a > borrower and a lender of the bicycle. > > It seems to me that the distinction needs to be made between > network-independent address blocks and network-dependent or > network-attached ones. > > NI Network-Independent address blocks are allocated to an organization by > the RIR and can be announced in whole or in part by any network with which > the organization has a relationship. > > NA Network-Attached address blocks are assigned to an organization by an > LIR and can only be used with the network(s) operated by that LIR. > > Then we could drop the acronyms and start talking about independent > address blocks and attached network blocks. > > Personally, I don't believe that all 5 RIRs should have the same policies > but I do believe that all 5 RIRs should use the same terminology and > language to talk about addressing as long as the talking is done in > English. > --Michael Dillon > _______________________________________________ > Hostmaster-staff mailing list > Hostmaster-staff at apnic.net > http://mailman.apnic.net/mailman/listinfo/hostmaster-staff > From Bovio at aol.com Tue Aug 12 10:21:26 2003 From: Bovio at aol.com (Bovio at aol.com) Date: Tue, 12 Aug 2003 04:21:26 EDT Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... Message-ID: <197.1e4ec925.2c69fd86@aol.com> In a message dated 11/08/03 17:51:19 W. Europe Daylight Time, daniel.karrenberg at ripe.net writes: > I have not stopped listening to concrete ideas about improving the RIPE > NCC. > > I am still here at the RIPE NCC working and listening. Of course the > bureaucratic developments you sneer at *do* happen to some degree. This > is inevitable and both you and I know it. The ability of individuals > like you and me to influence things immediately and directly is reduced. > Of course I personally I do not agree with all things the RIRs do and > more often I do not agree with *how* things are done. > > What seems to divide us is that I still work to improve the 'least of > all evils' structure and you sneer at it providing no alternative. > I would hope that more people will chose the former instead of the latter. > I also hope that people still see the relative mertis and the > differences in legitimacy that exist between the various organisations. > Sneering at the RIPE NCC without suggesting either alternatives or > improvements does not help. > I stand 100% with Daniel here. I can't speak for the others RIRs but I strongly believe the RIPE-NCC has made significant efforts in the recent past to listen to its membership, streamline procedures, and positively react to constructive criticism. There is more work to do, no doubt about it, but I can't see how flaming on mailing lists helps. Whomever has concrete ideas: I propose we move this discussion to the ncc-services-wg list/group, that was created exactly for this purpose. Daniele -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburley at africonnect.com Tue Aug 12 11:16:30 2003 From: sburley at africonnect.com (Stephen Burley) Date: Tue, 12 Aug 2003 10:16:30 +0100 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811171449.K67740@Space.Net> Message-ID: <5.2.1.1.2.20030812101530.00a773c8@195.206.160.253> >. > >s/icann/icann, the rirs, .../ > >all this is a social experiment to see how many bureaucrats, >amateur politicians (though the professionals are entering the >fray), bureaucrats, lawyers, and just plain slimeballs it takes to >replace one part-time computer scientist (whose 60th birthday would >have been last wednesday). > >randy To: Randy Bush Subject: Re: [address-policy-wg] Summary of the PI Task Force's recent discussions >s/icann/icann, the rirs, .../ > >all this is a social experiment to see how many bureaucrats, >amateur politicians (though the professionals are entering the >fray), bureaucrats, lawyers, and just plain slimeballs it takes to >replace one part-time computer scientist (whose 60th birthday would >have been last wednesday). > >randy To some extent i have to agree with you Randy, but i also think we where taken advantage of by the suits. Once our computer scientist had passed on the community panicked, the last thing we wanted was a government agency running the show and the bureaucrats knew this. The bureaucrats held out their hands and we grabbed hold out of the fire into the fire some might say. But the bottom line is we can not change it now and to some extent it has stabilized, what we have to keep doing is not let them run the show and make sure it still works for us from the bottom up. Its easy to be bitter but lets channel that energy into making it better not complaining. The NCC lost their way for a bit and with some strong recommendations from the community pulled them selves back on track (not maybe all the way but at least what we have now is better than before the recommendations). Remember we ultimately hold the purse strings ;) BTW its good to be back. Stephen Burley Not working for a corporate corrupt giant anymore. Internet Communications Consultant Africonnect PS sorry if you got this mail twice. From peter.galbavy at knowtion.net Tue Aug 12 11:19:44 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 12 Aug 2003 10:19:44 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <197.1e4ec925.2c69fd86@aol.com> Message-ID: <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> Bovio at aol.com wrote: > I stand 100% with Daniel here. I can't speak for the others RIRs but I > strongly believe the RIPE-NCC has made significant efforts in the > recent past to listen to its membership, streamline procedures, and > positively react to constructive criticism. > > There is more work to do, no doubt about it, but I can't see how > flaming on mailing lists helps. > > Whomever has concrete ideas: I propose we move this discussion to the > ncc-services-wg list/group, that was created exactly for this purpose. OK, let me try to be clear and rational about my primary objections to the way that RIPE works now: 1. Everyone pussyfoots around the issue of RIPE =?= RIPE-NCC. As the funding for both are out of the same pockets, please STOP trying to make that distinction. If RIPE (as a natural monopoly) was classed like BT, then this practise would be seen as cross-subsidisation. 2. RIPE, again as a natural monopoly, does NOT offer "members" the choice of opting out of the "fluffy stuff". RIPE should, IMHO, provide registry services ONLY and base its costs on that. The other hand waving, experimental, attempted standard setting stuff should be optional and extra. At the moment, those of us who just want IPes and ASes have to pay for others to play with their academic toys. Why ? 3. The registry should be run efficiently, not just "quickly". From the reports that others have sent me off-list in the past, my suspicions are strong that there are basically too many staff at RIPE. We're back to the industrial rationalisation issues of the 80's for deities sake... Anyone in the UK remember the stories about Leyland workers on night shift being caught sleeping on cots they brough in to work ? I get that feeling about RIPE sometimes. Does anyone believe that RIPE is not a "natural monopoly" for IP registry services in Europe ? If it isn't, as I predicate it is, then I get choice and can take my business elsewhere. Going to an "ISP" is not the choice I can make, so don't try that one. rgds, -- Peter From gert at space.net Tue Aug 12 11:36:01 2003 From: gert at space.net (Gert Doering) Date: Tue, 12 Aug 2003 11:36:01 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com>; from peter.galbavy@knowtion.net on Tue, Aug 12, 2003 at 10:19:44AM +0100 References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> Message-ID: <20030812113601.K67740@Space.Net> Hi, On Tue, Aug 12, 2003 at 10:19:44AM +0100, Peter Galbavy wrote: > 1. Everyone pussyfoots around the issue of RIPE =?= RIPE-NCC. As the funding > for both are out of the same pockets, please STOP trying to make that > distinction. If RIPE (as a natural monopoly) was classed like BT, then this > practise would be seen as cross-subsidisation. You're confused. RIPE isn't funded in any way. RIPE is "all of us". The funding goes to the RIPE NCC, which has offices, employees, and needs money to do the work that RIPE (we) ask them to do. [..] > 2. RIPE, again as a natural monopoly, does NOT offer "members" the choice of > opting out of the "fluffy stuff". RIPE should, IMHO, provide registry > services ONLY and base its costs on that. The other hand waving, > experimental, attempted standard setting stuff should be optional and extra. > At the moment, those of us who just want IPes and ASes have to pay for > others to play with their academic toys. Why ? Because the majority of the members hasn't voted against it. [..] > Does anyone believe that RIPE is not a "natural monopoly" for IP registry > services in Europe ? If it isn't, as I predicate it is, then I get choice > and can take my business elsewhere. Going to an "ISP" is not the choice I > can make, so don't try that one. It is a natural monopoly in the way that you can't go elsewhere if you want RIPE member services. But then, how else do you want to do hierarchical distribution of a limited resource? On the other hand, if you just want IP addresses and AS numbers, you *can* go through an ISP (but it will reduce the number of options that you have). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.juul at uni-c.dk Tue Aug 12 11:39:15 2003 From: peter.juul at uni-c.dk (Peter B. Juul) Date: Tue, 12 Aug 2003 11:39:15 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> Message-ID: <20030812093915.GM5476@uni-c.dk> On Tue, Aug 12, 2003 at 10:19:44AM +0100, Peter Galbavy wrote: > 1. Everyone pussyfoots around the issue of RIPE =?= RIPE-NCC. As the funding > for both are out of the same pockets, please STOP trying to make that > distinction. If RIPE (as a natural monopoly) was classed like BT, then this > practise would be seen as cross-subsidisation. I agree. When I have to send off forms for allocations and such, I can't remember ever having said "RIPE NCC" instead of "RIPE". To most of us in the business - I think - "RIPE" is a general term for "those guys that will not give us more IP addresses unless we really, really need them." The distinction seems to be some bureaucratic necessity. I'd really rather the geeks ran this world :-) > 2. RIPE, again as a natural monopoly, does NOT offer "members" the choice of > opting out of the "fluffy stuff". RIPE should, IMHO, provide registry > services ONLY and base its costs on that. The other hand waving, > experimental, attempted standard setting stuff should be optional and extra. > At the moment, those of us who just want IPes and ASes have to pay for > others to play with their academic toys. Why ? To some extend, I agree with your notion. It can be irritating, indeed, to have to pay up for something you don't really see a purpose to. However, it seems to me to be much like the whole "should our tax euros really be spent paying for research into things that do not have an obvious practical implementation (yet)?"-discussion. Whatever non-IRR-stuff RIPE is doing _may_ turn out to be the next Big Thing on the nets. It may also fade away into the distance. Somebody, however, have to pay for research into that which will pay my salary in ten years, and the companies that will probably prosper from it are a reasonable suggestion for where to send the bill. > 3. The registry should be run efficiently, not just "quickly". From the > reports that others have sent me off-list in the past, my suspicions are > strong that there are basically too many staff at RIPE. The great big problem with anonymous off-list mails is the fact that they are anonymous. (Not to you, I know, but to the list). If there's a problem, those who know of the problem should inform the lists. > Does anyone believe that RIPE is not a "natural monopoly" for IP registry > services in Europe ? Nope. It definitely is. However, such seems basically unavoidable given the fact that we _need_ a central office to distribute IP addresses and AS numbers. Note that RIPE is only a monopoly on IPs and ASs in the sense that Volvo is a monopoly on Volvo cars. If you want to drive a Peugeot or want to make your own ipv4-internet, seperate from the one you use now, neither Volvo nor RIPE has any say. Peter B. Juul, Uni?C (PBJ255-RIPE) From sburley at africonnect.com Tue Aug 12 11:50:00 2003 From: sburley at africonnect.com (Stephen Burley) Date: Tue, 12 Aug 2003 10:50:00 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <20030812093915.GM5476@uni-c.dk> References: <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> Message-ID: <5.2.1.1.2.20030812104907.00af89a0@195.206.160.253> http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/May-17-Task-Force-summary/index.html Remember this? Seems we have come full circle again. From hank at att.net.il Tue Aug 12 11:53:24 2003 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 12 Aug 2003 12:53:24 +0300 (IDT) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <5.2.1.1.2.20030812101530.00a773c8@195.206.160.253> Message-ID: > >all this is a social experiment to see how many bureaucrats, > >amateur politicians (though the professionals are entering the > >fray), bureaucrats, lawyers, and just plain slimeballs it takes to > >replace one part-time computer scientist (whose 60th birthday would > >have been last wednesday). > > > >randy well said! Hank Nussbacher From bortzmeyer at nic.fr Tue Aug 12 12:17:26 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Aug 2003 12:17:26 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: References: <+f6cKhCCWzN$EwbX@ripe.net> <20030811082953.GA24572@nic.fr> <20030811111620.P67740@Space.Net> <20030811092016.GA25538@nic.fr> <20030811113654.Q67740@Space.Net> <20030811094307.GA25832@nic.fr> <20030811114628.S67740@Space.Net> <20030811171449.K67740@Space.Net> Message-ID: <20030812101726.GA7946@nic.fr> On Mon, Aug 11, 2003 at 08:28:21AM -0700, Randy Bush wrote a message of 14 lines which said: > it takes to replace one part-time computer scientist Do not paint the past in too bright colors. Besides the obvious (there was much less users of the Internet at this time, and a more closed community, which is easier to manage), Jon Postel made a lot of wrong decisions, too (such as denying ".tf" - French Southern Territories - to a French organization, then granting it without due process to a British one, in direct violation of his own RFC 1591 "For top-level domains that are country codes at least the administrative contact must reside in the country involved."). From peter.galbavy at knowtion.net Tue Aug 12 16:29:44 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 12 Aug 2003 15:29:44 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812113601.K67740@Space.Net> Message-ID: <03bb01c360de$2cabab00$7c28a8c0@cblan.mblox.com> Gert Doering wrote: > You're confused. RIPE isn't funded in any way. RIPE is "all of us". > > The funding goes to the RIPE NCC, which has offices, employees, and > needs money to do the work that RIPE (we) ask them to do. Then why do people (in RIPE / RIPC NCC) make a distinction ? >> 2. RIPE, again as a natural monopoly, does NOT offer "members" the >> choice of opting out of the "fluffy stuff". RIPE should, IMHO, >> provide registry services ONLY and base its costs on that. The other >> hand waving, experimental, attempted standard setting stuff should >> be optional and extra. At the moment, those of us who just want IPes >> and ASes have to pay for others to play with their academic toys. >> Why ? > > Because the majority of the members hasn't voted against it. Because the system is weighted in such a way that getting a vote proposed, let alone voted on by any real number of people, is difficult to impossible. This is getting recursive. > It is a natural monopoly in the way that you can't go elsewhere if you > want RIPE member services. But then, how else do you want to do > hierarchical distribution of a limited resource? > > On the other hand, if you just want IP addresses and AS numbers, you > *can* go through an ISP (but it will reduce the number of options that > you have). No you cannot, because you are then buying from your (potential) competition. RIPE/RIPE-NCC is supposed to be neutral, but is using that neutrality to assist in its own perpetualtion of the things I am complaining about. I am not looking to break the natural monopoly, but rather I am looking to move to a situation where the "monopoly" stuff is walled off from the optional stuff that RIPE/RIPE-NCC management (and friends) use to pay for their own pet projects. I am happy to pay on a cost basis for the "monopoly" stuff, but I don't get a choice. Peter Peter From peter.galbavy at knowtion.net Tue Aug 12 16:36:19 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 12 Aug 2003 15:36:19 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812093915.GM5476@uni-c.dk> Message-ID: <03c001c360df$18788170$7c28a8c0@cblan.mblox.com> Peter B. Juul wrote: > To some extend, I agree with your notion. It can be irritating, > indeed, to have to pay up for something you don't really see a > purpose to. However, > it seems to me to be much like the whole "should our tax euros really > be spent paying for research into things that do not have an obvious > practical implementation (yet)?"-discussion. Whatever non-IRR-stuff > RIPE is doing _may_ turn out to be the next Big Thing on the nets. It > may also fade away into the distance. Somebody, however, have to pay > for research into that which will pay my salary in ten years, and the > companies that will > probably prosper from it are a reasonable suggestion for where to send > the bill. How is the IETF funded ? The IETF doesn't do addressing, but seems to exist without me paying for it. In this instance, IMHO, academics should be funded by academic models and maybe by corporate sponsorship, they should not leach off "us" by the back door. BTW RIPE is not a government department funded by taxpayers, else it would be subject to audits by higher bodies, not by the collective apathy of a membership. > If there's a problem, those who know of the problem should inform the > lists. I was asked in this instance to not repeat names as one of the people was not available to approve the release of information they collected. I am happy to support people who wish to speak up. > Note that RIPE is only a monopoly on IPs and ASs in the sense that > Volvo is a monopoly on Volvo cars. If you want to drive a Peugeot or > want to make your own ipv4-internet, seperate from the one you use > now, neither Volvo nor RIPE has any say. Using this metaphor, RIPE has a monopoly on traffic signs and road numbers. I can build a road, but I cannot join it to the rest of the public road network without their involvement. Peter From peter.juul at uni-c.dk Tue Aug 12 18:56:15 2003 From: peter.juul at uni-c.dk (Peter B. Juul) Date: Tue, 12 Aug 2003 18:56:15 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <03c001c360df$18788170$7c28a8c0@cblan.mblox.com> Message-ID: <20030812165615.GI2447@uni-c.dk> On Tue, Aug 12, 2003 at 03:36:19PM +0100, Peter Galbavy wrote: > How is the IETF funded ? The IETF doesn't do addressing, but seems to exist > without me paying for it. Nope. You just pay in less obvious ways. Companies that sponsor their workers' trips to IETF meetings and their time doing IETF stuff grab the money when you buy their products. Which is pretty much what RIPE does, they just don't hide it behind "overhead expenses" as much. > In this instance, IMHO, academics should be funded > by academic models In the best of all worlds, yes. However, I am quite certain I am not the only one living in a country in which the government tend to find other uses for money than basic research. > and maybe by corporate sponsorship, that's pretty much what happens now, isn't it? OK, that's not what you meant, but corporate sponsorships rarely go to those that can't point clearly to the general use the results might have. > they should not leach > off "us" by the back door. BTW RIPE is not a government department funded by > taxpayers, else it would be subject to audits by higher bodies, not by the > collective apathy of a membership. True. I am not saying that I find everything about the membership-ocraty great. I am just saying that I, for one, don't think research is a bad way to use some of the money we pay. > I was asked in this instance to not repeat names as one of the people was > not available to approve the release of information they collected. I am > happy to support people who wish to speak up. Sure. But FOAF is bad argumentation. Especially on the net. > Using this metaphor, RIPE has a monopoly on traffic signs and road numbers. > I can build a road, but I cannot join it to the rest of the public road > network without their involvement. True. You are however welcome to dig tunnels under their roads. (layer 2) NAh, this is getting silly, let's forget the analogies: Of course (and out of necessity) RIPE has a monopoly on IP space. Anything else is an academic exercise. Peter B. Juul, Uni?C (PBJ255-RIPE) From sburley at africonnect.com Tue Aug 12 17:18:13 2003 From: sburley at africonnect.com (Stephen Burley) Date: Tue, 12 Aug 2003 16:18:13 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <03bb01c360de$2cabab00$7c28a8c0@cblan.mblox.com> References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812113601.K67740@Space.Net> Message-ID: <5.2.1.1.2.20030812160156.00aeffd0@195.206.160.253> >I am not looking to break the natural monopoly, but rather I am looking to >move to a situation where the "monopoly" stuff is walled off from the >optional stuff that RIPE/RIPE-NCC management (and friends) use to pay for >their own pet projects. I am happy to pay on a cost basis for the "monopoly" >stuff, but I don't get a choice. This was something i raised years ago prompted mainly by the test traffic white elephant which used registry monies to plod along and then eventually go on a subscription basis, and this something i had no intention of ever using but still the registry i was with paid its money and had no say over how it was used. Something that has been repeated over and over again is that the NCC should be a registry not a research dept for internet trends and toys. There should be 4 main functions 1.registry services (good and timely) 2. database repository (and related DB functions) 3. Training services (mainly for new LIR's to get them up to speed) 4. RIPE meeting organization All of which the NCC do well and should be commended, anything else is surplus to requirement there is one other thing the NCC has never done and never fully justified and that is a help desk you can talk to. Other RIR's do it. I think it helps cut away the sterile faceless image and lets you see what you are getting for your money - discuss Stephen Burley Internet Communications Consultant Africonnect From hpholen at tiscali.no Wed Aug 13 00:21:14 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Tue, 12 Aug 2003 21:21:14 -0100 (GMT+1) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811143614.GA31246@nic.fr> Message-ID: | > On Mon, Aug 11, 2003 at 11:00:02AM +0100, > Carlos Friacas wrote > a message of 29 lines which said: > > > > If all non-US-ccTLD registries (of which there are lots more than > > > US-based) start beating ICANN with joint forces, I'm pretty sure that > > > this will have an effect. > > > > Has anyone tried serious reasoning with them about these delays??? I have raised the question to the ASO address council and ICANN coordination list. I'll get back to the WG with the response and we can discuss a constructive approach to solve this. Hans Petter Holen RIPE Address Policy chair / ICANN ASO Address Council co-chair. > Good Lord, on which planet were you, the last five years? All the > ccTLD managers, as well as many governments, a lof of concerned > individuals and so on, have tried to move IANA faster. If it does not, > it is not a technical issue (unlike ".com" or even ".fr", the root is > a very small zone, easily maintainable manually), it is a political > one. > > IANA blackmails the ccTLD managers: if they do not sign the > "sponsorship agreement" (not one in Europe did), even very trivial > changes are delayed for ever. > From gert at space.net Tue Aug 12 20:43:01 2003 From: gert at space.net (Gert Doering) Date: Tue, 12 Aug 2003 20:43:01 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <03bb01c360de$2cabab00$7c28a8c0@cblan.mblox.com>; from peter.galbavy@knowtion.net on Tue, Aug 12, 2003 at 03:29:44PM +0100 References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812113601.K67740@Space.Net> <03bb01c360de$2cabab00$7c28a8c0@cblan.mblox.com> Message-ID: <20030812204301.H67740@Space.Net> Hi, On Tue, Aug 12, 2003 at 03:29:44PM +0100, Peter Galbavy wrote: > Gert Doering wrote: > > You're confused. RIPE isn't funded in any way. RIPE is "all of us". > > > > The funding goes to the RIPE NCC, which has offices, employees, and > > needs money to do the work that RIPE (we) ask them to do. > > Then why do people (in RIPE / RIPC NCC) make a distinction ? I don't understand that question. You were complaining that people make this distinction "just to confuse matters" - and I was trying to give a precise definition as for what is what. Especially it's not "RIPE *and* the RIPE NCC are both funded in some convoluted ways". RIPE is NOT (and can't be, by definition). [..] > >> be optional and extra. At the moment, those of us who just want IPes > >> and ASes have to pay for others to play with their academic toys. > >> Why ? > > > > Because the majority of the members hasn't voted against it. > > Because the system is weighted in such a way that getting a vote proposed, > let alone voted on by any real number of people, is difficult to impossible. I can't agree with that statement. I have been quite successful in changing some of those pieces that annoyed me. [..] > > On the other hand, if you just want IP addresses and AS numbers, you > > *can* go through an ISP (but it will reduce the number of options that > > you have). > > No you cannot, because you are then buying from your (potential) > competition. In what way is "getting an AS number from the competition" something that's harmful for your business in the long run? As far as I understand your situation, getting a PI address block through any other ISP, and announcing that via your AS (that you have already) should solve your needs without causing any competitive problems either. [..] > I am not looking to break the natural monopoly, but rather I am looking to > move to a situation where the "monopoly" stuff is walled off from the > optional stuff that RIPE/RIPE-NCC management (and friends) use to pay for > their own pet projects. I am happy to pay on a cost basis for the "monopoly" > stuff, but I don't get a choice. Isn't that exactly what the activity plan is about, which is agreed-upon on a very specific date that was announced *WELL* in advanced, and where every LIR can go and vote for or against? You can even bring proxy votes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hpholen at tiscali.no Wed Aug 13 01:43:07 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Tue, 12 Aug 2003 22:43:07 -0100 (GMT+1) Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <03c001c360df$18788170$7c28a8c0@cblan.mblox.com> Message-ID: > How is the IETF funded ? My understanding is that the IETF is funded the same way as the *RIPE* is funded: - meeting participants pay a fee to cover the meeting costs, with some sponsored events added - the IETF chair Harald Alvestrand works for Cisco Systems so I assume Cisco pays for his time (just as the RIPE chair works for NIKHEF who pays for Robs time, just as I work for Tiscali who pays for my time (well if you ask my family they will probably claim I do this out of office hours so its my own time) When it comes to the RIPE NCC of the IETF (just waiting for the flames on that one...) the RFC-editor it is funded by a membership organisation (the Internet Society) > The IETF doesn't do addressing, but seems to exist > without me paying for it. You probably do indireclty; if you look at the list of Area directors and WG chairs, and even the working group members spedning time on improving the Internet you probably pay trough some product you use If you dont want to pay the RIPE NCC for the service I (or somebody else for that matter) could probably offer you Internet transit with IP address registration bundled as a service for your customers. > In this instance, IMHO, academics should be funded > by academic models and maybe by corporate sponsorship, they should not leach > off "us" by the back door. BTW RIPE is not a government department funded by > taxpayers, else it would be subject to audits by higher bodies, not by the > collective apathy of a membership. I can agree on that principle - there will be an oportuity at the next RIPE meeting - both in the RIPE NCC services wg and in the general meeting to change the direction of the ship. -hph From peter.galbavy at knowtion.net Tue Aug 12 22:14:23 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 12 Aug 2003 21:14:23 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812113601.K67740@Space.Net> <03bb01c360de$2cabab00$7c28a8c0@cblan.mblox.com> <20030812204301.H67740@Space.Net> Message-ID: <004601c3610e$52ff3800$29e0a8c0@HATMADDER> Gert Doering wrote: > I don't understand that question. You were complaining that people > make > this distinction "just to confuse matters" - and I was trying to give > a precise definition as for what is what. > > Especially it's not "RIPE *and* the RIPE NCC are both funded in some > convoluted ways". RIPE is NOT (and can't be, by definition). I know it is not an English acronym, but perhaps someone could translate what RIPE stands for ? It is not "the European ISP club" is it ? It is the European IP coordination function (AFAICR). I dislike people pretending that RIPE-NCC membership fees do not fund RIPE activities. Else we would only see costs associated with running a registry in the *RIPE-NCC* annual report. >> Because the system is weighted in such a way that getting a vote >> proposed, let alone voted on by any real number of people, is >> difficult to impossible. > > I can't agree with that statement. > > I have been quite successful in changing some of those pieces that > annoyed me. But that is / was your job ? If you have close to 100% of your working day dedicated to RIPE / regulatory affairs / whatever, then getting involved is easy. People in(/friends with people in) RIPE/RIPE-NCC are basically in control. Most members do not even have anyone who reads this stuff. Hence my comment about apathy. >From reading the docs a few months ago, I need to find 5% of the membership to agree to any proposal I may make to be put before a RIPE annual meeting (for example to propose the RIPE/RIPE-NCC immediately cease all non-registry related activities and to begin a program of rationalisation that reflects the needs of the industry). I have NO communication path to approach this notional 5% as I do not have access to a membership list, and I dislike spamming folks anyway. Not all members are on an open mailing list (AFAIK) - or rather not all those who are in a position to vote on behalf oif their company. Without knowing who are members, and how many are "5%" I cannot try to put forward a democratic proposal of the sort above. On the other hand, the executive board can put forward proposals unconditionally - or have I remembered wrong ? > In what way is "getting an AS number from the competition" something > that's harmful for your business in the long run? AS is OK - it is for the lifetime of the assignment, except the maintainer object is required for changes and last time I asked, new maintainer objects are only for members. > As far as I understand your situation, getting a PI address block > through > any other ISP, and announcing that via your AS (that you have already) > should solve your needs without causing any competitive problems > either. PI is "wasteful" and not guarenteed (for some value of that word) routeable. PA is owned by the upstream, and also makes most multihoming impossible. I have pre-PI/PA space I can use for my own self, but some of this is not actually just about my specific case. > Isn't that exactly what the activity plan is about, which is > agreed-upon > on a very specific date that was announced *WELL* in advanced, and > where every LIR can go and vote for or against? You can even bring > proxy votes. I oppose the whole concept of having a plan, not the plan. If the sole activity was registry services, there would be no need for a plan. Peter From peter.galbavy at knowtion.net Tue Aug 12 22:16:18 2003 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 12 Aug 2003 21:16:18 +0100 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... References: <197.1e4ec925.2c69fd86@aol.com> <00a501c360b2$de400a90$7c28a8c0@cblan.mblox.com> <20030812113601.K67740@Space.Net> <5.2.1.1.2.20030812160156.00aeffd0@195.206.160.253> Message-ID: <004f01c3610e$975ac2d0$29e0a8c0@HATMADDER> Stephen Burley wrote: > 1.registry services (good and timely) > 2. database repository (and related DB functions) > 3. Training services (mainly for new LIR's to get them up to speed) > 4. RIPE meeting organization I agree with 1-3. I think 4 should be a "spare time" activity or one organised by an EU Internet "club". If 4 can be done part time by *one* person, then I am happy to pay for my part of the time. Peter From hank at att.net.il Wed Aug 13 08:48:41 2003 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 13 Aug 2003 09:48:41 +0300 (IDT) Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <004f01c3610e$975ac2d0$29e0a8c0@HATMADDER> Message-ID: On Tue, 12 Aug 2003, Peter Galbavy wrote: > Stephen Burley wrote: > > 1.registry services (good and timely) > > 2. database repository (and related DB functions) > > 3. Training services (mainly for new LIR's to get them up to speed) > > 4. RIPE meeting organization > > I agree with 1-3. I think 4 should be a "spare time" activity or one > organised by an EU Internet "club". If 4 can be done part time by *one* > person, then I am happy to pay for my part of the time. i agree with 1+2+4. 3 should be covered on a cost basis by the attendees. if the cost of a training session is 5000euro (room, lunch, instructor time, etc) and 25 attend, then the cost should be 200euro per attendee, with no affect on the overall ncc budget. > > Peter > Hank Nussbacher From CHallam at sdlintl.com Wed Aug 13 09:59:46 2003 From: CHallam at sdlintl.com (Chris Hallam) Date: Wed, 13 Aug 2003 16:59:46 +0900 Subject: [address-policy-wg] RIPE NCC Services Message-ID: <058E4C246CF26940A5D5EE0E3AE847555E5ECB@tokyomail1.sdlintl.com> Stephen Burley wrote: All of which the NCC do well and should be commended, anything else is surplus to requirement there is one other thing the NCC has never done and never fully justified and that is a help desk you can talk to. Other RIR's do it. I think it helps cut away the sterile faceless image and lets you see what you are getting for your money - discuss === I think the inclusion of a telephone help desk service would benefit a lot of members. I imagine it would be difficult to implement due to the number of bilingual staff that would be required. This would therefore require substantial funding which would probably affect member fees. In addition, most of the actual processes would have to remain based on the email system. Even so, if the operational scope was clearly defined it would be useful for help, advice, and a reliable point of contact. Chris ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. ********************************************************************** From shane at ripe.net Wed Aug 13 15:08:57 2003 From: shane at ripe.net (Shane Kerr) Date: Wed, 13 Aug 2003 15:08:57 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation Message-ID: <3F3A3869.1070105@ripe.net> All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC From gert at space.net Wed Aug 13 15:12:07 2003 From: gert at space.net (Gert Doering) Date: Wed, 13 Aug 2003 15:12:07 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <3F3A3869.1070105@ripe.net>; from shane@ripe.net on Wed, Aug 13, 2003 at 03:08:57PM +0200 References: <3F3A3869.1070105@ripe.net> Message-ID: <20030813151207.F67740@Space.Net> Hi, On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote: > In the meantime, we do not want to delay the implementation of the > Sub-Allocation policy. For that reason we'd like to have an interim > status attribute value for that. I like that. > Proposal: > > Add "SUB-ALLOCATED PA" to the allowed "status:" values. That would be in agreement with the original proposal, so "I like that" (obviously). > "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an > "LIR-PARTITIONED PA" less specific inetnum object. > > A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That > is, you cannot sub-allocate twice. I wouldn't force that on anyone. It might not always make sense, but we have at least one reseller that has a re-selling customer - so a two-level structure is already in place. So "please don't do that". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From sabt at sabt.net Wed Aug 13 16:12:36 2003 From: sabt at sabt.net (Sebastian Abt) Date: Wed, 13 Aug 2003 16:12:36 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813151207.F67740@Space.Net> References: <3F3A3869.1070105@ripe.net> <20030813151207.F67740@Space.Net> Message-ID: <20030813161236.646e930b.sabt@sabt.net> Hi *, * Gert Doering wrote: > I like that. Me too. > > A range of IP's can only have a single "SUB-ALLOCATED PA" in it. > > That is, you cannot sub-allocate twice. > > I wouldn't force that on anyone. It might not always make sense, but > we have at least one reseller that has a re-selling customer - so a > two-level structure is already in place. > > So "please don't do that". I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" block for his customer or otherwise if he want's to look like being independent to his customer, he should become RIPE member. I hardly can't see advantages of making sub-sub-allocations (maybe you could point them out?). regards, sebastian -- whois: sabt-ripe - phone: +49 (0)174 3420738 email: sabt at sabt.net - pgp-pubkey: 0x3B046B48 From sburley at africonnect.com Wed Aug 13 17:27:55 2003 From: sburley at africonnect.com (Stephen Burley) Date: Wed, 13 Aug 2003 16:27:55 +0100 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813161236.646e930b.sabt@sabt.net> References: <20030813151207.F67740@Space.Net> <3F3A3869.1070105@ripe.net> <20030813151207.F67740@Space.Net> Message-ID: <5.2.1.1.2.20030813162330.00ae53c0@195.206.160.253> > >I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" >block for his customer or otherwise if he want's to look like being >independent to his customer, he should become RIPE member. I hardly >can't see advantages of making sub-sub-allocations (maybe you could >point them out?). Oh i wish i had access to my old mail that i sent to this list. There is an argument for this but i fits the multi-national internet registry (MIR) structure much better. It is not necessarily for your customer but more a way of trying to control your internal routing tables. Does anyone have a copy of the MIR proposal they could repost. Which may help explain. Regards Stephen Burley Internet Communications consultant Africonnect From gert at space.net Wed Aug 13 17:26:32 2003 From: gert at space.net (Gert Doering) Date: Wed, 13 Aug 2003 17:26:32 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813161236.646e930b.sabt@sabt.net>; from sabt@sabt.net on Wed, Aug 13, 2003 at 04:12:36PM +0200 References: <3F3A3869.1070105@ripe.net> <20030813151207.F67740@Space.Net> <20030813161236.646e930b.sabt@sabt.net> Message-ID: <20030813172632.M67740@Space.Net> Hi, On Wed, Aug 13, 2003 at 04:12:36PM +0200, Sebastian Abt wrote: > > > A range of IP's can only have a single "SUB-ALLOCATED PA" in it. > > > That is, you cannot sub-allocate twice. > > > > I wouldn't force that on anyone. It might not always make sense, but > > we have at least one reseller that has a re-selling customer - so a > > two-level structure is already in place. > > > > So "please don't do that". > > I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" > block for his customer or otherwise if he want's to look like being > independent to his customer, he should become RIPE member. I hardly > can't see advantages of making sub-sub-allocations (maybe you could > point them out?). It's their suballocation, and their customer, not mine - how can I judge how big *their* customer is going to be, and how much address space they want? The whole point of suballocation is "give control to the people that actually hand out the addresses" - flexibility, instead of buerocracy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From carsten at ripe.net Wed Aug 13 17:43:23 2003 From: carsten at ripe.net (Carsten Schiefner) Date: Wed, 13 Aug 2003 17:43:23 +0200 (CEST) Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <5.2.1.1.2.20030813162330.00ae53c0@195.206.160.253> from "Stephen Burley" at Aug 13, 2003 04:27:55 PM Message-ID: <200308131543.h7DFhNaK019626@birch.ripe.net> Stephen, Stephen Burley wrote: > Oh i wish i had access to my old mail that i sent to this list. There is an > argument for this but i fits the multi-national internet registry (MIR) > structure much better. It is not necessarily for your customer but more a > way of trying to control your internal routing tables. Does anyone have a > copy of the MIR proposal they could repost. Which may help explain. I guess the RIPE mailing list archive could be of some help: http://www.ripe.net/cgi-bin/search/gdquery.cgi?header=ncc-head&footer=ncc-foot&terms=&record-type=paragraph&submit=Search&boolean=and&index=www-ripe-mail&show-context=1&max-results=100&page-results=10 And with the search terms "Stephen Burley MIR": http://www.ripe.net/cgi-bin/search/gdquery.cgi?index=www-ripe-mail&boolean=and&max-results=100&page-results=10&start-page=&header=ripe-mail-head&footer=ripe-mail-foot&record-type=paragraph&terms=Stephen+Burley+MIR&Search=Search&show-context=1°ree-of-error=0&sort=balanced&.cgifields=show-context&.cgifields=case-sensitive&.cgifields=search-substrings Sorry for the lengthy URLs - I directly copied them from my browser. Should work, though. Regards, Carsten Schiefner From sabt at sabt.net Wed Aug 13 19:05:43 2003 From: sabt at sabt.net (Sebastian Abt) Date: Wed, 13 Aug 2003 19:05:43 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813172632.M67740@Space.Net> References: <3F3A3869.1070105@ripe.net> <20030813151207.F67740@Space.Net> <20030813161236.646e930b.sabt@sabt.net> <20030813172632.M67740@Space.Net> Message-ID: <20030813190543.08bfb84a.sabt@sabt.net> Hi, * Gert Doering wrote: > It's their suballocation, and their customer, not mine - how can I > judge how big *their* customer is going to be, and how much address > space they want? You won't judge. You give your customer's customer the allocation he needs (and the one that fits into your assignment window - or "sub- allocation window") as well as you give your customer the allocation he needs. > The whole point of suballocation is "give control to the people that > actually hand out the addresses" - flexibility, instead of buerocracy. Of course, and indeed, that's a "nice to have", but who controls the customer's customer assignments? In the end you're responsible for everything they do, because you are the one RIPE is going to contact in case of any trouble (at least that's what I'm reading in the draft). Erm, and what an assignment window do they have (or "sub-allocation window")? That are the questions confusing me. regards, sebastian -- whois: sabt-ripe - phone: +49 (0)174 3420738 email: sabt at sabt.net - pgp-pubkey: 0x3B046B48 From hpholen at tiscali.no Thu Aug 14 00:15:50 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 13 Aug 2003 21:15:50 -0100 (GMT+1) Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: Message-ID: > > On Mon, Aug 11, 2003 at 11:00:02AM +0100, > > Carlos Friacas wrote > > a message of 29 lines which said: > > > > > > If all non-US-ccTLD registries (of which there are lots more than > > > > US-based) start beating ICANN with joint forces, I'm pretty sure that > > > > this will have an effect. > > > > > > Has anyone tried serious reasoning with them about these delays??? > > I have raised the question to the ASO address council and ICANN > coordination list. > > I'll get back to the WG with the response and we can discuss a > constructive approach to solve this. I have been in touch with ICANN staff regarding this, and from what I understand there are no open requests with IANA from the two previously mentioned ccTLDs. I got yet another example by private email, but it was from 2 years back. There is however an open request to add IPv6 addres recors to the root-zone. On this matter ICANN have asked for technical advice from the root server advisory group and are currently awaiting this advice before proceeding. If you have problems with the response time from IANA in such matters please first contact IANA staff with the ticketing number in question. Eventaly the CcNSO will be the forum to address such issues, until then feel free to contact me to use whatever connections I have with ICANN to solve operational problems. I hope this helps, Best Regards, Hans Petter Holen From hpholen at tiscali.no Thu Aug 14 00:26:05 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 13 Aug 2003 21:26:05 -0100 (GMT+1) Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: RIPE 46 Address Policy WG Draft Agenda (v4) A. Administrative Matters - scribe - list of participants - agenda - RIPE 45 lir-wg minutes http://www.ripe.net/ripe/wg/lir/r45-minutes.html - Actions B. Report from RIPE NCC Registration Services (Leo Vegoda) C. Internet Resource Status Report (Leo Vegoda) D. ICANN ASO Address Council Report E. Presentation of ASO Address Council Candidates http://www.ripe.net/ripencc/about/regional/aso2003/index.html Election in plenary F. Address Policy WG Charter http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00075.html G. RIPE-152 Charging by local registries http://www.ripe.net/ripe/docs/chargingbylirs.html H. Policy Development Process I. RIR-IANA relationship and procedures (Axel Pawlik) J. PI Address Policy & Initial IPv4 allocation size http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00030.html K Final revised IPv4 policy http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00010.html X. AOB Y. Summary of actions arising from this meeting Z. Open Microphone From hpholen at tiscali.no Thu Aug 14 00:41:39 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 13 Aug 2003 21:41:39 -0100 (GMT+1) Subject: [address-policy-wg] Policy making process Message-ID: Dear working group, In the beginning there was no documented process of making policy. At some point I started outlining the process in http://www.ripe.net/ripe/wg/lir/howto_develop.html The experience since then is that a couple of elements should be added to this - not necessarily to make a biger or more complicated process, but with the incentive to make the process more open and more transparent. * Proposals should be circulated in writing to the mailinglist in advance of the meetings. Currently we have started calling for contributions and requestion proposals. * There should be detailed technical discussion on the mailinglist before a proposal can be adapted * All policies should be published as RIPE documents * All RIPE documents setting new policies should be published as drafts before becoming final -hph From david at iprg.nokia.com Wed Aug 13 21:27:06 2003 From: david at iprg.nokia.com (David Kessens) Date: Wed, 13 Aug 2003 12:27:06 -0700 Subject: [address-policy-wg] Re: [db-wg] Draft: "status:" re-evaluation In-Reply-To: <3F3A3869.1070105@ripe.net>; from shane@ripe.net on Wed, Aug 13, 2003 at 03:08:57PM +0200 References: <3F3A3869.1070105@ripe.net> Message-ID: <20030813122705.C27936@iprg.nokia.com> Shane, On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote: > > We have received input from APNIC on the subject. They proposed a > simpler layout, and we think their suggestion makes sense. However, > we would like to go forward with a slightly modified version that > incorporates the "organisation" object we are working on. If you like their proposal, is there any reason why we cannot go ahead with their prososal instead of making yet another incompatible change between RIPE NCC and APNIC ?!? David K. --- From shane at ripe.net Thu Aug 14 09:26:52 2003 From: shane at ripe.net (Shane Kerr) Date: Thu, 14 Aug 2003 09:26:52 +0200 Subject: [address-policy-wg] Re: [db-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813122705.C27936@iprg.nokia.com> References: <3F3A3869.1070105@ripe.net> <20030813122705.C27936@iprg.nokia.com> Message-ID: <3F3B39BC.9010608@ripe.net> David Kessens wrote: > > On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote: > >>We have received input from APNIC on the subject. They proposed a >>simpler layout, and we think their suggestion makes sense. However, >>we would like to go forward with a slightly modified version that >>incorporates the "organisation" object we are working on. > > If you like their proposal, is there any reason why we cannot go ahead > with their prososal instead of making yet another incompatible > change between RIPE NCC and APNIC ?!? Aligning the policies and technologies as much as possible between the RIPE NCC and APNIC is indeed one of our goals. We have not rejected APNIC's input, but are rather working with them to refine the thinking on "status:" in both regions. We don't want to change the Database more than required, to avoid confusion and extra work for the users. Therefore we want the best solution to be the one we actually implement, hopefully in as many regions as possible. But it seems like this will take time, and we want to allow LIRs to sub-allocate as soon as possible. -- Shane Kerr RIPE NCC From joao at psg.com Thu Aug 14 11:08:28 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Thu, 14 Aug 2003 11:08:28 +0200 Subject: [address-policy-wg] Interesting APNIC proposal Message-ID: I have just noticed this quite interesting and well prepared policy proposal from APNIC regarding a different way of calculating address utilisation ratios. It seems of particular relevance in the cases of multiple levels of sub-allocation, a situation that has been the subject of debate in the RIPE region as well, therefore I believe it deserves consideration also in this region. The changes in address consumption derived from the proposal are addressed in section 5.2 The original posting on APNIC's mailing lists is available at http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/ msg00000.html Joao Damas ------------------------------------------------------------------------ Discussion Document Application of the HD-Ratio to IPv4 Prepared by: Paul Wilson, APNIC Secretariat Version: 1.0 Date: 7 August 2003 1 Summary Internet address space is managed hierarchically, by allocation from IANA to RIRs and from RIRs to LIRs (ISPs), and by assignment from LIRs to infrastructure components and customer networks. Within each level of allocation or assignment some address space is generally reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced into any address space, the overall efficiency of utilisation of that space (in terms of the total number of individual addresses actually used) will inevitably decrease. The HD Ratio (Host-Density Ratio) has been proposed as a practical mechanism for measuring the utilisation of addresses within hierarchically-managed Internet address blocks [RFC 3194]. A given HD Ratio value corresponds to a percentage utilisation which decreases as the size of the address space grows, thus allowing for the decreasing overall address management efficiency which is described above. The HD Ratio is currently used as the utilisation metric for IPv6 address space, under the current IPv6 management policy [ipv6-address-policy]. According to this policy, a block of IPv6 address space is considered to be effectively utilised when its HD-Ratio reaches 0.80. This value is said to represent a conservative but manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document explores the possible use of the HD Ratio for measurement of IPv4 utilisation, for the same purpose of determining when a given block of address space should be considered as fully utilised. 2 Background and problem The current management framework for IPv4 address space relies on policies developed within each RIR community [ipv4- address-policy]. These policies dictate, effectively, that a given block of IPv4 addresses should be considered "utilised" when at least 80% of the addresses within the block have been allocated or assigned. This measure is applied equally for address blocks held by small or large LIRs, regardless of their size. In any case, it is deemed that once 80% of the space held by an LIR has been allocated or assigned, that LIR may request more address space from its appropriate RIR. Current policies assume a hierarchical system of address space delegation (from IANA to RIRs to LIRs to customers, as described above), but they make no allowance for hierarchical address management within an organisation's own address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual POPs, regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are "hidden" in terms of recognition by the current RIR policy framework, and highly constrained by the 80% utilisation requirement. As a result, management of large blocks is often extremely difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space, and the 80% utilisation requirement may be justifiable on that basis. However address management policies must also be practical in terms of management overhead imposed. It may be argued that when large address spaces are involved, the "80% rule" imposes unreasonable management overheads on an LIR. A more reasonable approach should attempt to impose a uniform degree of management overhead, rather than penalising the holders of large address blocks. This may be achievable to some degree by basing utilisation requirements on the HD ratio rather than the fixed percentage-based measure which is in use today. 3 A Proposal In recognition of the problems outlined above, it is now proposed to consider replacing the current fixed percentage based utilisation requirement for IPv4 address space with an "HD Ratio" based requirement, referred to as the AD Ratio. 3.1 The HD Ratio According to RFC3194, The HD-Ratio is calculated as follows: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of site addresses (/48s) which are utilised. In order to calculate the HD-Ratio for a given IPv6 block, it is necessary to know the size of that block, and number of host addresses which are in use. The current IPv6 policies allow for this by requiring registration of address assignments to the /48 level, however this degree of registration is not appropriate under IPv4 management policies. 3.2 Definition - the AD Ratio IPv4 address space utilisation is measured in terms of the number of allocations or assignments which have been made from a given address block, rather than the number of host addresses which are in use within the block. We therefore use the term "Allocation Density" for the measure of address space utilisation within an IPv4 block, rather than the term "Host Density" which represents host-address utilisation in IPv6. Consequently, we refer propose a new utilisation metric for IPv4, to be known as the "AD Ratio" (for Allocation or Assignment Density Ratio). The AD Ratio measures the number of addresses allocated or assigned from a given block of address space, as follows: AD = log(A)/log(S) Where: S is the size of the of the address block, and A is the number of addresses allocated or assigned from that block. 3.3 Selection of AD Ratio value The appropriate AD Ratio value for the purposes of this proposal should be decided on a rational basis. In order to do this, we make certain assumptions about the depth of "hidden" hierarchy involved in managing address blocks of various sizes. We then assume that at each level of this assumed hierarchy, the currently accepted 80% utilisation requirement is achieved, in order for the entire address space to be considered as fully utilised. The following table proposes a set of assumed hierarchical depths which may be reasonably expected within hierarchically-managed address spaces of certain sizes. At each delegation level an allocation density of 80% is assumed, so that within a hierarchy of "n" levels, the overall address space utilisation is calculated as 0.80 to the power of "n". Size range Depth Util AD Ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 Note: the above AD Ratio values are derived directly from the formula above. For instance, a /20 block contains 4096 addresses, and 80% utilisation corresponds to 3276.8 addresses; therefore the corresponding AD Ratio is calculated as log(3276.8)/log(4096) = 0.973 The depths of address hierarchy listed above are notional approximations only, based on general assumptions about the likely size and structure of LIRs holding address blocks in the respective size ranges. From the table, a rational common AD ratio value may be determined as 0.966 (chosen as the most conservative value which is common to all of the listed ranges). For this value, the following table gives the percentage utilisation requirement for the full range of IPv4 address blocks (this is also derived directly from the AD ratio formula shown above). IPv4 Addresses Addresses Util% Prefix Total Utilised 32 1 1 100.00% 31 2 2 97.67% 30 4 4 95.40% 29 8 7 93.17% 28 16 15 91.00% 27 32 28 88.88% 26 64 56 86.81% 25 128 109 84.79% 24 256 212 82.82% 23 512 414 80.89% 22 1024 809 79.00% 21 2048 1580 77.16% 20 4096 3087 75.37% 19 8192 6030 73.61% 18 16384 11780 71.90% 17 32768 23010 70.22% 16 65536 44949 68.59% 15 131072 87804 66.99% 14 262144 171518 65.43% 13 524288 335046 63.90% 12 1048576 654485 62.42% 11 2097152 1278482 60.96% 10 4194304 2497408 59.54% 9 8388608 4878479 58.16% 8 16777216 9529704 56.80% 7 33554432 18615487 55.48% 6 67108864 36363809 54.19% 5 134217728 71033685 52.92% 4 268435456 138758413 51.69% 3 536870912 271053050 50.49% 2 1073741824 529479652 49.31% 1 2147483648 1034294583 48.16% 0 4294967296 2020408681 47.04% Note: This table provides values for CIDR blocks only, however for non-CIDR blocks the same calculations can be applied to produce equally meaningful results. 4 Implementation If implemented at any particular level in the IP address delegation chain, this proposal would have a number of impacts on administrative processes at that level. It is not currently proposed to apply this proposal to the relationship between RIRs and IANA, therefore the implementation of the proposal at the RIR-LIR level is discussed there. 4.1 RIR-LIR Procedures The impact of the proposal on the RIR-LIR administrative procedures would be to replace the current 80% utilisation requirement, with a 0.966 AD Ratio requirement. By way of examples, an LIR holding a total address space equal to a /16 would be able to receive more address space when they had allocated or assigned 68.59% of that space; while an LIR holding a /9 would be able to receive more space when they had allocated or assigned 58.16% of their address space. For blocks smaller than /22, it is proposed that the current 80% requirement be used, in order that this new policy does not impose tighter utilisation requirements than were previously imposed. The AD-Ratio calculation is trivial, but certainly more complex and less intuitive than the existing 80% calculation. Some APNIC members may in some circumstances require extra assistance, however for those using the MyAPNIC service, the calculation would be automatic and therefore no additional effort would be involved. 4.2 Assignment procedures In order to support consistent calculation of an LIR's AD Ratio, it would be preferable for each LIR to register infrastructure assignments in the same way as customer assignments. This could be done by whois update via email, or via the MyAPNIC service. It would not be necessary to register individual hardware components or subnets, but rather only the independent infrastructure blocks which are designated by the LIR, and which can be justified on the same basis as customer assignments. Such registrations would be publicly visible as normal whois records, unless database changes were implemented to specifically hide them. 4.3 Implementation timeline If implemented, this policy could be effective within 3 months of the implementation date. 5 Impacts 5.1 Administrative Impact The primary administrative impact of this proposal is to ease the administrative address management burden experienced by LIRs, especially those with large address space holdings. The proposal recognises the need to manage address space hierarchically within an LIR service infrastructure, and makes allowance for it through the use of the AD ratio for assessment of address utilisation. This proposal would impose a small administrative cost on LIRs. In the first place, an LIR's internal systems (manual or automated) would need to incorporate a new method of calculating address space utilisation (and especially when determining the point at which the LIR may request more space from APNIC). In the second place, an LIR would need to register infrastructure assignments in the same way as customer assignments, which would impose additional administrative cost. In both cases, LIRs using the MyAPNIC service would experience a small extra cost because these changes can be automated within that system. The administrative impact on internal systems of the APNIC Secretariat is also relatively small. APNIC hostmaster processes can be tailored easily to accommodate a changed method of calculating address space utilisation; and the whois database can certainly accommodate an increased number of registrations. 5.2 Address Space Consumption Because this proposal lowers the utilisation requirement for IPv4 address blocks, it would certainly increase the rate of deployment of IP addresses. In analysing this impact, we can identify two separate factors contributing to increased consumption: firstly, an initial impact resulting from increased "wastage" of deployed address space; and secondly, on ongoing impact as utilisation requirements continue to fall for individual LIRs' growing address holdings. 5.2.1 Initial impact The initial impact on address consumption can be estimated by calculating for each APNIC LIR the difference between the current 80% utilisation, and the AD-ratio-determined utilisation requirement. This calculation will indicate the amount of extra "wasted" address space which would result from the proposed policy change. Total LIRs in sample 788 Total address space held 4.17 (/8 blocks) Utilised addresses (80%) 3.32 Utilised addresses (AD 0.966) 2.53* Extra "wasted" space 0.81 Extra "wastage" as % of total 19% * This figure is calculated from the sample of 788 LIRs, according to actual address space holdings These figures show that by reducing the address space utilisation requirement from 80% to AD 0.966, an additional 0.81 blocks are consumed out of a total 4.17 blocks allocated. This corresponds to an additional of 19% of the total allocated address space. It should be noted that this assessment indicates a theoretical impact in terms of increased address consumption, assuming all deployed address space is actually utilised. The actual impact will be less than this due to underutilisation of address space; and furthermore the impact will not take place at one time, but progressively as part of ongoing address space allocations. 5.2.2 Ongoing impact The ongoing impact on address consumption can be estimated by distributing additional address space to the same set of LIRs, in proportion to their existing address space holdings. For the purposes of this analysis, an additional /8 block is distributed to the same set of 788 LIRs, in proportion to their existing address holdings. Initial address space held 4.17 (/8 blocks) Additional space allocated 1.00 Total address space now held 5.17 Utilised addresses (AD 0.966) 3.11* Additional addresses utilised 0.58* Utilised addresses (80%) 0.80 Extra "wasted" space 0.22 Extra "wastage" as % of allocation 22% * These figures are calculated from the same sample of 788 LIRs, assuming a proportional distribution of an additional /8 block These figures show that after an additional /8 block is distributed and utilised, 58% of that block would actually be utilised, rather than 80%. Therefore up to 22% of that block would be "wasted" by the use of AD 0.966 in place of 80% as the utilisation measure, resulting potentially in an increased consumption rate of up to 22%. Again, this calculation is theoretical only, and assumes that all address space which has been distributed will be utilised. 5.2.3 Conclusions on address consumption The above analysis indicates that the adoption of this proposal would cause an initial additional consumption of up to 19% of address space allocated. In APNIC's case, a total of 8.07 /8 blocks have been allocated (as of 1 July 2003), so up to an additional 1.53 blocks would eventually be consumed as a result of the change. The analysis also indicates that this proposal would cause an overall 22% increase in the rate of address consumption. In APNIC's case, a total of 1.90 /8 blocks per year are currently being allocated (in the 12 months to 1 July 2003), and this rate would therefore rise to 2.32 blocks per year. The assumptions on which the above analysis is made include: firstly, that the 788 LIRs in the sample are representative of all LIRs in the region; and secondly, that a consistent rate of growth will be experienced by all LIRs in the region. 6 References [RFC 3194] "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] APNIC document: "IPv6 Address Allocation and Assignment Policy" (http://www.apnic.net/docs/policy/ipv6-address-policy.html) [ipv4-address-policy] APNIC document: "Policies for IPv4 address space management in the Asia Pacific region" (http://www.apnic.net/docs/policy/add-manage-policy.html) From katri at swip.net Thu Aug 14 11:11:02 2003 From: katri at swip.net (Katri) Date: Thu, 14 Aug 2003 11:11:02 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) Message-ID: <5.1.0.14.0.20030814101242.00b9a960@pop.swip.net> Hello, I saw at RIPE 44 LIR WG Session regarding IP Addressing policy for always-on (residential broadband) Leo said the following: L.V : This should be registered in the database. If it's a residential user, their personal contact information cannot be registered in most countries due to the Data Protection laws. The Database object could then point to contact data at the ISP without identifying customer by name. This should be discussed by the WG if anyone is concerned by this. and I would like to discuss on how we should do with personal contact information in the RIPE db. I don?t only mean residential braodband services but all kind of services that might be available to customers. Should we or should we not register personal contact information that might conflict with Data Protection laws in some countries? How has it been solved earlier? What sort of criterias/ rules should we as an ISP have for the contact data? Regards Katri Forsberg Tele2/Swipnet IP Registry Local Internet Registry __________________________________________________________ Tele2/SWIPnet Tel: 08 5626 40 08 Box 62 Fax: 08 5626 42 10 164 94 Kista Email: ip at swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________ From Michael.Dillon at radianz.com Thu Aug 14 11:26:49 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 14 Aug 2003 10:26:49 +0100 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) Message-ID: >and I would like to discuss on how we should do with personal contact >information in the RIPE db. The db should only contain the contact information of people who are ready, willing and able to communicate regarding network issues and who are able to act on that communication. This means that much of the existing contact information in the db would disappear and LIRs would formally have the responsibility of relaying communications to their downstream networks. Some of these downstream networks MAY still be in the db but the network contacts MUST agree to be listed and MUST agree to be ready, willing and able to communicate regarding network issue and MUST be able to act on that communication. This would clean most of the useless garbage out of the db, solve the privacy issues, and focus the LIR's attention on the true purpose of the db. The RIPE db is not a general purpose telephone book, it is a contact directory for a specific purpose which is required by TCP/IP internetworking activity. There is no point in including contact data for people who are not ready, willing and able to communicate or who are not able to take any action. RIPE has a direct relationship with LIRs so there is the possibility to force them to have someone who is ready, willing and able to communicate and able to take action. Some LIRs may choose to force their customers to also provide such a contact person, but there is nothing wrong if an LIR chooses to be the direct contact for all of their customers. --Michael Dillon From joao at psg.com Thu Aug 14 11:35:56 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Thu, 14 Aug 2003 11:35:56 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: Hans Peter, what is your intention with regards to item J on the agenda? Leo's message gave inconclusive and incomplete information about the PI task force work, merely citing a few bullet points with expressions such as "there was some support for this". I have not seen any description of the background, relevant data available (types of PI requests, for instance) and general problem categorisation. I haven't seen any description of the options discussed at the TF and what were the arguments for some having "some support" and others "less support". I reckon background for this would help immensely in carrying out a sensible discussion. I guess that according to your mail regarding the policy process at RIPE, the item is not meant to rubber stamp any policy change at this time but if progress is to be expected on a timely manner, a concrete problem statement with options analysis would go a long way in avoiding discussion loops. Also, how does the outcome of item J affect item K? regards, Joao Damas On Thursday, August 14, 2003, at 12:26 AM, Hans Petter Holen wrote: > RIPE 46 Address Policy WG Draft Agenda (v4) > > A. Administrative Matters > - scribe > - list of participants > - agenda > - RIPE 45 lir-wg minutes > http://www.ripe.net/ripe/wg/lir/r45-minutes.html > - Actions > > B. Report from RIPE NCC Registration Services (Leo Vegoda) > > C. Internet Resource Status Report (Leo Vegoda) > > D. ICANN ASO Address Council Report > > E. Presentation of ASO Address Council Candidates > http://www.ripe.net/ripencc/about/regional/aso2003/index.html > Election in plenary > > F. Address Policy WG Charter > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > msg00075.html > > G. RIPE-152 Charging by local registries > http://www.ripe.net/ripe/docs/chargingbylirs.html > > H. Policy Development Process > > I. RIR-IANA relationship and procedures (Axel Pawlik) > > J. PI Address Policy & Initial IPv4 allocation size > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > msg00030.html > K Final revised IPv4 policy > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > msg00010.html > > X. AOB > > Y. Summary of actions arising from this meeting > > Z. Open Microphone > > > From pdg at euroconnect.fr Thu Aug 14 11:40:31 2003 From: pdg at euroconnect.fr (Pascal Julienne) Date: Thu, 14 Aug 2003 11:40:31 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: Message-ID: <015b01c36248$1addd9a0$0a0710ac@pdg> I fully agree with this. Further this is not a new problem. Some of us have been doing broadband always on since 1997 or even before - namely cable operators. I have myself raised the problem with the RIPE in 1997. In France there is such a thing as unlisted phone numbers which remain private and unknown. Further, the RIPE DB is becoming the best spam list in the world. So yes, responsability lays with LIR, yes let's clean the DB, yes respect privacy. Pascal Julienne President Directeur General EURO CONNECT SA 130, rue du Bourg-Bele - BP 21099 - 72001 LE MANS Cedex 1 - FRANCE Tel : (33) 02 43 14 12 76 - Fax : (33) 02 43 14 12 77 http://www.euroconnect.fr Le contenu de ce message ne represente en aucun cas un engagement de la part d'Euro Connect sous reserve de tout accord conclu par ecrit entre vous et Euro Connect. Toute publication ou diffusion, meme partielle, doit etre autorisee prealablement. -----Message d'origine----- De : address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net]De la part de Michael.Dillon at radianz.com Envoye : jeudi 14 aout 2003 11:27 A : address-policy-wg at ripe.net Objet : Re: [address-policy-wg] IP Addressing policy on personal contact info (kf) >and I would like to discuss on how we should do with personal contact >information in the RIPE db. The db should only contain the contact information of people who are ready, willing and able to communicate regarding network issues and who are able to act on that communication. This means that much of the existing contact information in the db would disappear and LIRs would formally have the responsibility of relaying communications to their downstream networks. Some of these downstream networks MAY still be in the db but the network contacts MUST agree to be listed and MUST agree to be ready, willing and able to communicate regarding network issue and MUST be able to act on that communication. This would clean most of the useless garbage out of the db, solve the privacy issues, and focus the LIR's attention on the true purpose of the db. The RIPE db is not a general purpose telephone book, it is a contact directory for a specific purpose which is required by TCP/IP internetworking activity. There is no point in including contact data for people who are not ready, willing and able to communicate or who are not able to take any action. RIPE has a direct relationship with LIRs so there is the possibility to force them to have someone who is ready, willing and able to communicate and able to take action. Some LIRs may choose to force their customers to also provide such a contact person, but there is nothing wrong if an LIR chooses to be the direct contact for all of their customers. --Michael Dillon From hpholen at tiscali.no Thu Aug 14 20:38:36 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 14 Aug 2003 17:38:36 -0100 (GMT+1) Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: > what is your intention with regards to item J on the agenda? > > Leo's message gave inconclusive and incomplete information about the PI > task force work, merely citing a few bullet points with expressions > such as "there was some support for this". If that is the case: the outcome of the agenda item should be one of two: a) Keep existing policy b) Find a way to conclude with a proposal that can gain consensus in the future. > I have not seen any description of the background, relevant data > available (types of PI requests, for instance) and general problem > categorisation. Maybe we can ask leo to produce some data here ? > I haven't seen any description of the options discussed at the TF and > what were the arguments for some having "some support" and others "less > support". > > I reckon background for this would help immensely in carrying out a > sensible discussion. I guess that according to your mail regarding the > policy process at RIPE, the item is not meant to rubber stamp any > policy change at this time but if progress is to be expected on a > timely manner, a concrete problem statement with options analysis would > go a long way in avoiding discussion loops. Very good point indeed. > > Also, how does the outcome of item J affect item K? Interesting question. I have not read all of the draft to answer that question yet. Anyone else ? Regards, -hph > > regards, > Joao Damas > > > On Thursday, August 14, 2003, at 12:26 AM, Hans Petter Holen wrote: > > > RIPE 46 Address Policy WG Draft Agenda (v4) > > > > A. Administrative Matters > > - scribe > > - list of participants > > - agenda > > - RIPE 45 lir-wg minutes > > http://www.ripe.net/ripe/wg/lir/r45-minutes.html > > - Actions > > > > B. Report from RIPE NCC Registration Services (Leo Vegoda) > > > > C. Internet Resource Status Report (Leo Vegoda) > > > > D. ICANN ASO Address Council Report > > > > E. Presentation of ASO Address Council Candidates > > http://www.ripe.net/ripencc/about/regional/aso2003/index.html > > Election in plenary > > > > F. Address Policy WG Charter > > > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > > msg00075.html > > > > G. RIPE-152 Charging by local registries > > http://www.ripe.net/ripe/docs/chargingbylirs.html > > > > H. Policy Development Process > > > > I. RIR-IANA relationship and procedures (Axel Pawlik) > > > > J. PI Address Policy & Initial IPv4 allocation size > > > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > > msg00030.html > > K Final revised IPv4 policy > > > > http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/ > > msg00010.html > > > > X. AOB > > > > Y. Summary of actions arising from this meeting > > > > Z. Open Microphone > > > > > > > From shane at ripe.net Thu Aug 14 18:04:09 2003 From: shane at ripe.net (Shane Kerr) Date: Thu, 14 Aug 2003 18:04:09 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: <015b01c36248$1addd9a0$0a0710ac@pdg> References: <015b01c36248$1addd9a0$0a0710ac@pdg> Message-ID: <3F3BB2F9.8080301@ripe.net> Pascale Julienne, Pascal Julienne wrote: > In France there is such a thing as unlisted phone numbers which > remain private and unknown. Further, the RIPE DB is becoming the > best spam list in the world. So yes, responsability lays with LIR, > yes let's clean the DB, yes respect privacy. I think there are two sides to this issue. One is what the RIPE NCC can and has done to increase the privacy of people who have contact information in the Database. We have been trying to increase the privacy protections in the Database over time: - person/role objects removed from public FTP site - DB automatically rate limits access to person/role objects - mntner/irt objects removed from public FTP site - .DE person object deletion - automatic cleanup of unreferenced person/role objects The Allocation Editor on the LIR Portal should allow LIRs to keep their contact data up-to-date. We have talked with the Dutch Data Protection Authority about the Database as well, to make sure that we don't run afoul of the EU privacy directives. There has been some discussion at the last RIPE meeting about how the Database both aids and hinders spammers. Suggestions such as checking validity of contact information, as well as possibly putting fake entries in the Database and tracking spam they receive were mentioned. The second issue is deciding on what contact data *should* be in the Database. This is the job of the address-policy-wg, and perhaps the db-wg. A related issue is how the data should be accessed, which is also something that can be decided by the same groups. Katri Forsberg did a service by raising the issue. As a final issue, I am curious why you say the RIPE Database is becoming the best spam list in the world! I think that it probably generates a lot of spam for LIRs, because they have their contact information on many objects in the Database. I don't know any way to avoid this if the Database is public. I hope that for the end users who's information is in the Database for only a small number of addresses that they do not get much spam originating from the publication in the Database. The RIPE NCC is certainly interested in mechanisms that we can set up to prevent such use, as it is explicitly *not* allowed by the license that we provide for the Database. -- Shane Kerr RIPE NCC From hpholen at tiscali.no Fri Aug 15 02:20:23 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Thu, 14 Aug 2003 23:20:23 -0100 (GMT+1) Subject: [address-policy-wg] Policy making process In-Reply-To: Message-ID: It may be of interest to the wg that a simmilar refinement of the policy making process is discussed at the coming APNIC meeting: http://www.apnic.net/mailing-lists/sig-policy/archive/2003/06/msg00001.html To: sig-policy at apnic.net Subject: [sig-policy]Revised APNIC Policy Process - Proposal From: Anne Lord Date: Wed, 11 Jun 2003 17:09:04 +1000 (EST) Dear colleagues, The text below is a revised proposal for developing policy in the APNIC region. It is based upon input received from the last APNIC meeting. This proposal should be read together with a companion proposal which will be postly to this shortly, which describes an amended APNIC document editorial policy. Comments and feedback are now sought on both proposals and should be made on this list. warm regards, Anne ___________________________________________________________ A revised proposal for an amended APNIC open policy process ___________________________________________________________ Proposed by: Anne Lord, Randy Bush Version: draft 2.0 Date: 10 June 2003 1. Summary ---------------- This document proposes a modified process for developing policies for managing Internet resources in the Asia Pacific region. This proposal is based upon input and discussion at the APNIC Open Policy meeting at APNIC15 in Taipei, February 27, 2003 and on the sig-policy at apnic.net mailing list. It is to be used as a basis for continued discussion on the mailing list. Note that a revised editorial process is being proposed to implement consensus policy decisions and will be circulated on the sig-policy at apnic.net mailing list. This was presented in draft at APNIC15 and is archived at: http://www.apnic.net/meetings/15/sigs/policy/docs/ addpol-prop-apnic-doc-review.doc 2. Background and problem ------------------ APNIC operates in a self-regulatory environment where the policies for managing Internet resources in the Asia Pacific region are created through open, consensus based processes. The processes for creating policy are evolving. APNIC has held open and public meetings since 1995(1). The early meetings were much simpler in structure and content than the meetings held today(?), where multiple sessions run in parallel over several days, and attendees convene in groups according to topics of special interest(?). The current processes for creating policy are documented at: http://www.apnic.net/docs/policy/dev/index.html and were presented at APNIC15 for review and discussion(4). While APNIC policy processes are open to all interested parties, there has been feedback to suggest that there is still insufficient opportunity for review and input from all constituencies in the policy development process. Specific suggestions for improvement were made at the Address Policy SIG at APNIC15 in a presentation 'APNIC policy process - provoking discussion'(5). 3. Other Regions ----------------- In the other RIR regions, reviews of the policy development processes have recently taken place with discussions still ongoing. Please refer to the individual RIR websites for details: * http://www.arin.net * http://www.lacnic.net * http://www.ripe.net 3.1. RIPE The processes for developing policy within the RIPE region are relatively informal. Proposals are normally sent to the relevant working group mailing list, however this is not a formal requirement in order for consideration within a RIPE meeting. A presentation and discussion may then take place at the working group session during the RIPE meeting. A measure of consensus to proceed with the proposal is taken at that meeting. The working group is empowered to make decisions and it reports its outcomes to the plenary session of the RIPE meeting. A summary of the outcome of discussions at the working group meeting is sent to the working group mailing list, usually with a deadline for comment. If the comment period expires and there are no major objections, the proposal will be implemented. 3.2. ARIN Full details of the ARIN policy process are described at: * http://www.arin.net/policy/ipep.html Key elements of the process include: * Formal period of 4 weeks for proposals to be circulated on a mailing list, prior to presentation at an ARIN meeting; * Formal period of 10 days after a meeting for gathering input on decisions from the meeting; * Advisory Council of 15 volunteer individuals whose responsibility it is to judge whether consensus has been reached on a particular proposal; * Board of Trustees who ratify any proposed policies before they can be accepted and implemented. 3.3. LACNIC The process for developing policies for managing address space in the LACNIC region is initiated by the identification of a need for a new or revised policy, followed by the formation of a small working group (of no more than 7 volunteers) who work on particular policy proposals. Proposals are circulated on mailing lists and are presented at the open policy meeting. Proposals on which consensus has been reached are then forwarded to the LACNIC board who assist in defining an implementation schedule. The working group is generally disbanded at this point. 4. Proposal -------------- For any policy proposal requiring consensus decisions of the APNIC Membership, the following procedure is proposed: 4.1. Discussion before the OPM A formal proposal paper must be submitted to the SIG mailing list and to the SIG Chair 4 weeks before the start of the OPM. The proposal must be in writing and in text which clearly expresses the proposal, with explicit mention of any changes being proposed to existing policies and the reasons for those changes. It is suggested to use a format for the proposal that includes an introduction, a summary of the current problem, the proposal, and advantages and disadvantages of adopting the proposed policy. It is useful to also review the comparable policy situation in the other RIR regions (if applicable) and include a section entitled 'how it will affect APNIC members?' If the above deadline is not met, proposals may still be submitted and presented for discussion at the meeting; however, no decision may be made by the meeting regarding the proposal. The proposal will need to be resubmitted in time for the following meeting if the author wishes to pursue the proposal. 4.2. Consensus at the OPM Consensus is defined as 'general agreement' as observed by the chair of the meeting. Consensus must be reached first at the SIG session and afterwards at the Members Meeting for the process to continue. If there is no consensus on a proposal at either of these forums, the SIG (either on the mailing list or at a future OPM) will discuss whether to amend the proposal or to withdraw it. 4.3. Discussion after the OPM Proposals that have reached consensus at the OPM will be circulated on the appropriate SIG mailing list for a defined 'comment period'. Two options have been put forward for the length of the comment period: * Option 1 - 8 weeks or * Option 2 - until 4 weeks before the next OPM (which is approximately 26 weeks) 4.4. Confirming consensus Consensus is assumed to continue unless there are substantial objections raised during the 'comment period'. When the 'comment period' has expired, the appropriate SIG chair (and co-chairs) will decide whether the discussions on the mailing list represent continued consensus. If the chair (and co-chairs) observe that there are no 'substantial objections' to the proposed policy, consensus is confirmed and the process continues as outlined in section 4.5 below. If it is observed that there have been 'substantial objections' raised to the proposed policy, consensus is not confirmed and the proposal will not be implemented. The SIG will then discuss (either on the mailing list or in the SIG) whether to pursue the proposal or withdraw it. 4.5. Endorsement from the EC The EC, in their capacity as representatives of the membership, will be asked to endorse the consensus proposals arising from the OPM and the SIG mailing lists for implementation at the next EC meeting. In reviewing the proposals for implementation, the EC may refer proposals back to the SIG for further discussion with clearly stated reasons. As per the APNIC By-laws, the EC may, at its discretion, refer the endorsement to a formal vote of adoption by the APNIC members. 4.6. Implementation In both options above, a 12 weeks period is allowed for implementation. This gives the Secretariat and the NIRs sufficient time to make internal changes to forms and procedures, as well as gives the community sufficient advance notification of the new policy. 4.7. Duration of the process Under option 1 the minimum amount of time that a policy could take from the initial proposal to implementation would be 26 weeks. Under option 2 it would be 43 weeks. 4.8. Flow diagram of policy process The revised flow diagram for developing policy is available at: http://www.apnic.net/images/other/policy-dev-20030611.gif 5. Implementation ------------- This proposal will be implemented upon formal endorsement by APNIC. 6. References ------------- (1) 1st APNIC Meeting: http://ftp.apnic.net/apnic/meetings/Jan95/agenda (?) 15th APNIC Open Policy Meeting: http://www.apnic.net/meetings/15/schedule/index.html (?) Special Interest Groups: http://www.apnic.net/meetings/archive/sigs/index.html (4) APNIC policy process http://www.apnic.net/meetings/15/sigs/policy/docs/ addrpol-pres-anne-policy-process.ppt (5) APNIC policy process - provoking discussion: http://www.apnic.net/meetings/15/sigs/policy/docs/ addrpol-pres-randy-policy-process-discussion.pdf From leo at ripe.net Fri Aug 15 11:17:05 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 15 Aug 2003 11:17:05 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: References: Message-ID: Hi, Hans Petter Holen wrote: [...] >> I have not seen any description of the background, relevant data >> available (types of PI requests, for instance) and general problem >> categorisation. > >Maybe we can ask leo to produce some data here ? I've run through our statistics and have some data for you. About 89% of requests are for End Users, about 5.4% of requests are for the LIRs' own infrastructure, about 2.5% are for IXPs and another 2.5% are closed by the LIR sending the request before it's clear who will use the space. I hope this is helpful. Regards, -- leo vegoda RIPE NCC Registration Services Manager From joao at psg.com Fri Aug 15 15:14:26 2003 From: joao at psg.com (Joao Luis Silva Damas) Date: Fri, 15 Aug 2003 15:14:26 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: <64F362EC-CF22-11D7-8D3B-003065521028@psg.com> Leo, thanks for the numbers. How about the rest of the information requested? On Friday, August 15, 2003, at 11:17 AM, leo vegoda wrote: > Hi, > > Hans Petter Holen wrote: > > [...] > >>> I have not seen any description of the background, relevant data >>> available (types of PI requests, for instance) and general problem >>> categorisation. >> >> Maybe we can ask leo to produce some data here ? > > I've run through our statistics and have some data for you. > > About 89% of requests are for End Users, about 5.4% of requests are > for the LIRs' own infrastructure, about 2.5% are for IXPs and another > 2.5% are closed by the LIR sending the request before it's clear who > will use the space. > This data, which I would guess the TF had access to, puzzles me when I re-read your summary posted earlier, specifically point 3. 3. No longer assign PI (Portable) address space to End Users - There some support for to this point. The issue of Root DNS Servers was raised but it was noted that all Root DNS Servers operating in this region already have address assignments. 89% of the requests seems to be an indication of a need for this type of assignments, yet there seems to be "some support" to end it. Can we have a look at the arguments that were discussed about this subject? Can we, in general, have more background on the arguments that were for and against the different options during the TF's work? > I hope this is helpful. > Yes, it is helpful, but more data ought to be released for a proper understanding of the problem to be possible, I believe. Joao Damas From shane at ripe.net Fri Aug 15 15:36:37 2003 From: shane at ripe.net (Shane Kerr) Date: Fri, 15 Aug 2003 15:36:37 +0200 Subject: [address-policy-wg] Draft: "status:" re-evaluation In-Reply-To: <20030813151207.F67740@Space.Net> References: <3F3A3869.1070105@ripe.net> <20030813151207.F67740@Space.Net> Message-ID: <3F3CE1E5.1030004@ripe.net> Gert Doering, Gert Doering wrote: > Hi, > > On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote: > >>In the meantime, we do not want to delay the implementation of the >>Sub-Allocation policy. For that reason we'd like to have an interim >>status attribute value for that. > > > I like that. > > >>Proposal: >> >>Add "SUB-ALLOCATED PA" to the allowed "status:" values. > > > That would be in agreement with the original proposal, so "I like that" > (obviously). > > >>"SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an >>"LIR-PARTITIONED PA" less specific inetnum object. >> >>A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That >>is, you cannot sub-allocate twice. > > > I wouldn't force that on anyone. It might not always make sense, but > we have at least one reseller that has a re-selling customer - so a > two-level structure is already in place. > > So "please don't do that". Okay, this makes sense. This restriction will not be added. -- Shane Kerr RIPE NCC From leo at ripe.net Mon Aug 18 09:09:05 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 18 Aug 2003 09:09:05 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: <64F362EC-CF22-11D7-8D3B-003065521028@psg.com> References: <64F362EC-CF22-11D7-8D3B-003065521028@psg.com> Message-ID: Hi Joao, Joao Luis Silva Damas wrote: >Leo, > >thanks for the numbers. How about the rest of the information requested? You wanted some information on the background, types of PI requests and other things. We don't keep statistics on the motivation for a request for PI address space. In fact, we don't ask for it in most cases. We just make sure that the requester is aware of the issues that come with small blocks of address space and any possible alternatives to PI address space. However, we do keep statistics on the stated use the address space will be put to. However, the majority of PI assignments we make will be used for more than one purpose. In these cases it is often impossible to label an assignment with a single category. Instead, we label it as "Miscellaneous". This year, the "Miscellaneous" category has been appropriate in about 69% of assignments. Another 19% were for office LANs. We also had 4% used for server hosting, 3% for broadband services, about 1% for P2P links and about 1% for GPRS services. [...] >89% of the requests seems to be an indication of a need for this type >of assignments, yet there seems to be "some support" to end it. > >Can we have a look at the arguments that were discussed about this >subject? I asked the PI Task Force whether it might be better to just publish an archive of the discussion on the web site. There was no object and so I have asked our Ops people to put it up later today. It will be available from: http://www.ripe.net/ripe/about/maillists.html Regards, -- leo vegoda RIPE NCC Registration Services Manager From webmaster at ripe.net Mon Aug 18 14:20:34 2003 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Mon, 18 Aug 2003 14:20:34 +0200 Subject: [address-policy-wg] Web archive of PI Task Force now available Message-ID: <200308181220.h7ICKY3j017997@birch.ripe.net> Dear Colleagues, As requested, the RIPE NCC has made the discussions of the PI Task Force available as a web archive. You can find the archive at: http://www.ripe.net/ripe/mail-archives/pi-tf/ The PI Task Force was established by the LIR WG at RIPE 44. Its purpose is to review the policy for Provider Independent (PI) address space. Regards, RIPE NCC Webmaster www.ripe.net ================== From joao at isc.org Mon Aug 18 15:32:05 2003 From: joao at isc.org (Joao Damas) Date: Mon, 18 Aug 2003 15:32:05 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: <5B8AACB0-D180-11D7-8F3D-000A959B2120@isc.org> Hi Leo, many thanks for making this material available. Thanks also for the additional IP request accounting information. Knowing that more than 2/3 of the requests need to be categorised under miscellaneous is already a useful piece of information. Is the task force now done and should further discussions on this topic be carried out in this list? Joao From pdg at euroconnect.fr Mon Aug 18 16:47:33 2003 From: pdg at euroconnect.fr (Pascal Julienne) Date: Mon, 18 Aug 2003 16:47:33 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: <3F3BB2F9.8080301@ripe.net> Message-ID: <000801c36597$a912bb30$0a0710ac@pdg> There are two things with regards the informations recorded in the data base. I am certainly glad that you talked with the Dutch Data Protection Authority but as fas as I know it is the laws and regulations of the country concerned which matters. Sure you could say that the RIPE DB is located in the Caymen Island but if we are a European Institution and if this Institution wants to be respected by the different EU countries, it has to follows the rules of the different countries. I can't talk about what rules are in other countries because I don't know them enough but in France you have to have done a proper declaration to a French body (CNIL) which takes care of this and you must have the authorisation from the people whose information is recorded. Other countries probably have other rules. I don't know if the RIPE DB has done the needed paper work with the French CNIL but if not, then NOT one French LIR should record information in the DB. The risk is heavy fine and jail. This is just an an example but with the EU Rules being somewhat different in each country this subject of privacy should be seriously reviewed and the right lawyer put onto it. This is not just privacy but even just recording information in a DB about the LIR's subscribers is forbidden in France unless properly declared through the body CNIL. As far as spam is concerned: spammers are using the e mail addresses recorded in the data base. I receive spams daily on the addresses (role addresses for that matter) which have been entered in the data base. THe RIPE DB is one of the best source to obtain mailing list: it has the name of the LIR and roles which in turns redistribute to internal mailing lists of the LIR or of subscribers of the LIR. I don't have solutions to the above points but these are important topics which could be discussed in the next Ripe meeting. I have seen the efforts to clean the DB. There are plenty of positive things but as far as I know the privacy and just recording personal infos in the DB could use a little review. Pascal Julienne President Directeur General EURO CONNECT SA 130, rue du Bourg-Bele - BP 21099 - 72001 LE MANS Cedex 1 - FRANCE Tel : (33) 02 43 14 12 76 - Fax : (33) 02 43 14 12 77 http://www.euroconnect.fr Le contenu de ce message ne represente en aucun cas un engagement de la part d'Euro Connect sous reserve de tout accord conclu par ecrit entre vous et Euro Connect. Toute publication ou diffusion, meme partielle, doit etre autorisee prealablement. -----Message d'origine----- De : address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net]De la part de Shane Kerr Envoye : jeudi 14 aout 2003 18:04 A : Pascal Julienne Cc : address-policy-wg at ripe.net; db-wg at ripe.net Objet : Re: [address-policy-wg] IP Addressing policy on personal contact info (kf) Pascale Julienne, Pascal Julienne wrote: > In France there is such a thing as unlisted phone numbers which > remain private and unknown. Further, the RIPE DB is becoming the > best spam list in the world. So yes, responsability lays with LIR, > yes let's clean the DB, yes respect privacy. I think there are two sides to this issue. One is what the RIPE NCC can and has done to increase the privacy of people who have contact information in the Database. We have been trying to increase the privacy protections in the Database over time: - person/role objects removed from public FTP site - DB automatically rate limits access to person/role objects - mntner/irt objects removed from public FTP site - .DE person object deletion - automatic cleanup of unreferenced person/role objects The Allocation Editor on the LIR Portal should allow LIRs to keep their contact data up-to-date. We have talked with the Dutch Data Protection Authority about the Database as well, to make sure that we don't run afoul of the EU privacy directives. There has been some discussion at the last RIPE meeting about how the Database both aids and hinders spammers. Suggestions such as checking validity of contact information, as well as possibly putting fake entries in the Database and tracking spam they receive were mentioned. The second issue is deciding on what contact data *should* be in the Database. This is the job of the address-policy-wg, and perhaps the db-wg. A related issue is how the data should be accessed, which is also something that can be decided by the same groups. Katri Forsberg did a service by raising the issue. As a final issue, I am curious why you say the RIPE Database is becoming the best spam list in the world! I think that it probably generates a lot of spam for LIRs, because they have their contact information on many objects in the Database. I don't know any way to avoid this if the Database is public. I hope that for the end users who's information is in the Database for only a small number of addresses that they do not get much spam originating from the publication in the Database. The RIPE NCC is certainly interested in mechanisms that we can set up to prevent such use, as it is explicitly *not* allowed by the license that we provide for the Database. -- Shane Kerr RIPE NCC From kurtis at kurtis.pp.se Tue Aug 19 20:40:48 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 20:40:48 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811122331.C67740@Space.Net> Message-ID: (I am late in this discussion due to vacation and a crashed laptop) >>>>> And what about public exchange points? >>>> >>>> In which way are ccTLDs related to public exchange points? Or are >>>> you >>>> referring to the discussed "abandon PI" policy change? >> >> In no way ... that was a separate question related to the PI policy >> change. I should have put a "P.S." in front. Sorry for confusion. ;-) > > Okay :-) - I have no clear answer on the exchange point question. Many > of them are LIR already anyway (so they use PA). This is not true. LIR - yes; PA - no. They do not met the requirements. That is part of the problem. > The approach with a > one-time service fee to get "PI-like" space might work out for them. Yes, that was the idea. - kurtis - From kurtis at kurtis.pp.se Tue Aug 19 21:04:54 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 21:04:54 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <00b501c36037$1194d460$24e0a8c0@HATMADDER> Message-ID: <04AA74B2-D278-11D7-A889-000A95880ECC@kurtis.pp.se> Peter, >> like other representative systems such as legislatures, the RIRs >> have moved from being associations of their users to becoming >> self-perpetuating governmental bureaucracies, who are not actually >> users themselves, but speak for us, tell us what we think and >> should do, and how we are being uncooperative and sneering. but >> at least the RIRs are not invading foreign countries and murdering >> people, as my local governmental bureaucracy seems wont to do. > > I could not agree more. No, really. There is no way for anyone with > 'opposing' views to make them heard in any relevant forum. Mailing > lists are > not classed as official, why not? There is now an entire WG set-up to discuss the performance and activities of the NCC. Feel free to join. > and unless you speak "bureauocratese" (as I have > said before), you cannot be heard in any official forum. Uhm, would you care to elaborate? > I expect the overstaffed gravy train that is RIPE to continue > supporting > it's implicit "jobs for friends and for life" policies to continue and > for > us "members" to be expected to pay without any real voice. This is not really a very professional nor constructive remark. I am sure you could move over to the ncc-services-wg mailinglist and explain your toughts on developing the NCC. > Please don't bother telling me about "taking part" and "attending > meetings", > I did that in the past, now I cannot be bothered wasting the airfare. Then send text. - kurtis - From kurtis at kurtis.pp.se Tue Aug 19 21:08:08 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 21:08:08 +0200 Subject: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <197.1e4ec925.2c69fd86@aol.com> Message-ID: <783E49DB-D278-11D7-A889-000A95880ECC@kurtis.pp.se> Daniele, > I stand 100% with Daniel here. I can't speak for the others RIRs but I > strongly believe the RIPE-NCC has made significant efforts in the > recent past to listen to its membership, streamline procedures, and > positively react to constructive criticism. I think it a bit to early to start claiming progress. Quality have improved, but I think want a bit more before I start jumping up and down of joy. > There is more work to do, no doubt about it, but I can't see how > flaming on mailing lists helps. Agreed. > > Whomever has concrete ideas: I propose we move this discussion to the > ncc-services-wg list/group, that was created exactly for this purpose. Agreed! - kurtis - From kurtis at kurtis.pp.se Tue Aug 19 21:23:10 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 21:23:10 +0200 Subject: [ncc-services-wg] Re: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In-Reply-To: <004601c3610e$52ff3800$29e0a8c0@HATMADDER> Message-ID: <91E75D74-D27A-11D7-A889-000A95880ECC@kurtis.pp.se> > I have NO communication path to approach this notional 5% as I do not > have > access to a membership list, and I dislike spamming folks anyway. Not > all > members are on an open mailing list (AFAIK) - or rather not all those > who > are in a position to vote on behalf oif their company. The ncc-services WG was created in order to create a forum for these discussions. You have from what I remember in the past used the LIR WG mailinglist for arguing your view. What else should we do? I will be the first yo say I certainly do not think that RIPE NCC have been up to their primary task, and I must say I am still in doubts. However, I will also acknowledge that the membership have not really been paying much attention and doing their job either. In principle we are where we are because of our own fault. _WE_, the users and members of the RIPE NCC should be giving feedback to Axel and the rest of the NCC management as well as the board on where we think NCC needs to go and what should change. They can not second guess us. - kurtis - From kurtis at kurtis.pp.se Tue Aug 19 22:19:02 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 22:19:02 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: <3F3BB2F9.8080301@ripe.net> Message-ID: <5FAA9FFC-D282-11D7-A889-000A95880ECC@kurtis.pp.se> Shane, >> In France there is such a thing as unlisted phone numbers which >> remain private and unknown. Further, the RIPE DB is becoming the >> best spam list in the world. So yes, responsability lays with LIR, >> yes let's clean the DB, yes respect privacy. > > I think there are two sides to this issue. > > > One is what the RIPE NCC can and has done to increase the privacy of > people who have contact information in the Database. We have been > trying to increase the privacy protections in the Database over time: > > - person/role objects removed from public FTP site > - DB automatically rate limits access to person/role objects > - mntner/irt objects removed from public FTP site > - .DE person object deletion > - automatic cleanup of unreferenced person/role objects > > The Allocation Editor on the LIR Portal should allow LIRs to keep > their contact data up-to-date. > > We have talked with the Dutch Data Protection Authority about the > Database as well, to make sure that we don't run afoul of the EU > privacy directives. I think that issue is somewhat more problematic than that. I guess that what Katri is actually asking for is the Swedish data protection law. I am no expert on this law but from what I know / remember, the law requires the direct consent of the registered party as well as certain guarantees that the data is not passed on (within some limits). This means that the Swedish ISPs in order to register these customers actually needs written consent from the customer, as well as to solve the issue on passing that data on further by registering the data in the RIPE DB. Perhaps someone that knows the issue better could comment? Best regards, - kurtis - From kurtis at kurtis.pp.se Tue Aug 19 22:23:59 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 19 Aug 2003 22:23:59 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: Message-ID: <110B3923-D283-11D7-A889-000A95880ECC@kurtis.pp.se> >> thanks for the numbers. How about the rest of the information >> requested? > > You wanted some information on the background, types of PI requests > and other things. > > We don't keep statistics on the motivation for a request for PI > address space. In fact, we don't ask for it in most cases. We just > make sure that the requester is aware of the issues that come with > small blocks of address space and any possible alternatives to PI > address space. > > However, we do keep statistics on the stated use the address space > will be put to. However, the majority of PI assignments we make will > be used for more than one purpose. In these cases it is often > impossible to label an assignment with a single category. Instead, we > label it as "Miscellaneous". > > This year, the "Miscellaneous" category has been appropriate in about > 69% of assignments. Another 19% were for office LANs. We also had 4% > used for server hosting, 3% for broadband services, about 1% for P2P > links and about 1% for GPRS services. > From what I remember of what you said in Barcelona, the absolute numbers of PI space assigned is really low though, right? - kurtis - From leo at ripe.net Wed Aug 20 00:38:31 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 20 Aug 2003 00:38:31 +0200 Subject: [address-policy-wg] Draft agenda Address Policy Working Group RIPE 46 In-Reply-To: <110B3923-D283-11D7-A889-000A95880ECC@kurtis.pp.se> References: <110B3923-D283-11D7-A889-000A95880ECC@kurtis.pp.se> Message-ID: <20030819223830.GA9119@ripe.net> Hi, On Tue, Aug 19, 2003 at 10:23:59PM +0200, Kurt Erik Lindqvist wrote: [...] > From what I remember of what you said in Barcelona, the absolute > numbers of PI space assigned is really low though, right? We made 408 in the first half of this year. There are also some other stats in the summary I sent the list, at: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00030.html Regards, -- leo vegoda Registration Services Manager RIPE NCC From katri at swip.net Wed Aug 20 10:06:39 2003 From: katri at swip.net (Katri) Date: Wed, 20 Aug 2003 10:06:39 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: <5FAA9FFC-D282-11D7-A889-000A95880ECC@kurtis.pp.se> References: <3F3BB2F9.8080301@ripe.net> Message-ID: <5.1.0.14.0.20030820094623.00b34ad0@pop.swip.net> Hello, sorry for late response ;-) No the question in fact is that there should be no difference weather it is a Swedish law or e.g a Polish law that has the "restriction" of putting personal contact data in the RIPE db, I think that all counties have or will make some kind of laws agains data protection. I would like us to come up with a templates (-s) that could be useful in these cases. This template should clearly point out that there is a customer that is only documented at the actual ISP and not in the db. I understand that several isp:s allready have had these kind of issues over the years and due to data protection laws only have internal records over the customers, but I believe that the templates that have been created differ a lot. Is there a way to take out information about how many objects there is in the db that is only personal contact data without no referrence to a company name? Maybe we then could see which areas (countries) this concerns the most. (+ get a good clean up done in the db) Regards Katri that could be used in these cases. At 22:19 2003-08-19 +0200, you wrote: > Shane, > >>>In France there is such a thing as unlisted phone numbers which >>>remain private and unknown. Further, the RIPE DB is becoming the >>>best spam list in the world. So yes, responsability lays with LIR, >>>yes let's clean the DB, yes respect privacy. >> >>I think there are two sides to this issue. >> >> >>One is what the RIPE NCC can and has done to increase the privacy of >>people who have contact information in the Database. We have been trying >>to increase the privacy protections in the Database over time: >> >>- person/role objects removed from public FTP site >>- DB automatically rate limits access to person/role objects >>- mntner/irt objects removed from public FTP site >>- .DE person object deletion >>- automatic cleanup of unreferenced person/role objects >> >>The Allocation Editor on the LIR Portal should allow LIRs to keep their >>contact data up-to-date. >> >>We have talked with the Dutch Data Protection Authority about the >>Database as well, to make sure that we don't run afoul of the EU privacy >>directives. > > >I think that issue is somewhat more problematic than that. I guess that >what Katri is actually asking for is the Swedish data protection law. I am >no expert on this law but from what I know / remember, the law requires >the direct consent of the registered party as well as certain guarantees >that the data is not passed on (within some limits). This means that the >Swedish ISPs in order to register these customers actually needs written >consent from the customer, as well as to solve the issue on passing that >data on further by registering the data in the RIPE DB. > >Perhaps someone that knows the issue better could comment? > >Best regards, > >- kurtis - From katri at swip.net Wed Aug 20 10:30:03 2003 From: katri at swip.net (Katri) Date: Wed, 20 Aug 2003 10:30:03 +0200 Subject: [address-policy-wg] Fwd: selling ip:s? (kf) Message-ID: <5.1.0.14.0.20030820102954.00b874e0@pop.swip.net> >Hello, I would like rise the question about selling ip-addresses... > >Let me present two exampled: >1. ISP A has offeres adls that includes static 1 ip-address, but if the >customer needs more ip:s > they will apply for this and pay a sum of X krona per ip-adress they > receive. > ISP B also offeres adsl that inclued 1 ip-address, and when the > customer needs more ip:s > they will have to change the service in order to receive more ip:s, > since the adsl service is > only offered with 1 ip-address and approved from RIPE NCC to be done > in this way. > How should ISP B compare and offer the same amount of ip-addresses > without "getting > into trouble"? > >2. ISP A has a customer who has received /24 from which they share out >addresses > and their customers can receive more addresses for a sum of X krona. > > I understand that we are not allowed to sel our ip-addresses but what > about > our customers customer? Is there anything preventing this from > happening and > is there something documented? > >Regards Katri >Tele2/Swipnet IP Registry >Local Internet Registry >__________________________________________________________ > >Tele2/SWIPnet Tel: 08 5626 40 08 >Box 62 Fax: 08 5626 42 10 >164 94 Kista Email: ip at swip.net >SWIP-RIPE SWIPNET-LIR-MNT >__________________________________________________________ From Niall.oReilly at ucd.ie Wed Aug 20 12:48:36 2003 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 20 Aug 2003 11:48:36 +0100 Subject: [address-policy-wg] Transferring InterNIC space from ARIN Database to other RIR datab ases In-Reply-To: Message-ID: On Wednesday, Jul 30, 2003, at 22:42 Europe/Dublin, Hans Petter Holen wrote: > Hmm, we did form a special task force for this matter to work with the > RIPE NCC with the process etc. (References in Leos message) > > As chair of this working group I would really like to know what more we > can do to interact more closesly with the community - please feel free > to > suggest to the list or approach me personally with suggestions ! Hans Petter, Thanks for your encouraging words. I've been away for a couple of weeks and am still mining the e-mail mountain. During second half of July, I've had some off-list exchange with Leo, and found him really eager to be helpful. I still have some sense of the "blind man and elephant" problem, in both directions. As I'm not involved in a LIR, I missed the formation of the task force. In addition, I couldn't travel to Barcelona. In any case, a TF involving LIR-WG and RIPE-NCC is likely (as seems FWIS to be actually the case) to focus on managing the production line rather than on managing customer expectations. It's worth bearing in mind that ERX customers are likely, for the same historical reasons by which they have become ERX customers, to be involved directly with the RIR rather than via their ISP as LIR. [ Hmm, the emergence of the Address Policy WG seems to be just what I needed. ] It seems to me that a useful view of the ERX project and its progress would be a set of graphs derived from a table like the one below; needless to say, my numbers can't be related to reality except by co-incidence. Reporting Period (Month or Qtr) 2003.01 2003.02 ... Estimated work (contact count) 8000 8251 ... (estimate may evolve) Estimated work (network count) 215 216 ... Completed work (contact count) 0 57 ... Completed work (network count) 0 16 ... The graphic would show clearly, for two different measures of the work involved, both the estimated and (cumulative) completed work at each reporting instant. The gap between the estimated and completed work would show how much was left to be done. Hopefully, the curves would converge! I haven't been able to find such a simple overview in the material I've located on the web, or in the nice Member Update which Leo has kindly had sent to me. I think presentation of this kind of information would help customers anticipate ERX progress in the foreseeable, rather than indefinite, future. It would also be useful to know in what order the different /8 blocks are to be dealt with, what criteria have led to choosing this order, and how soon each /8 is expected to be finished, at least as planned at present. I expect that the plan may evolve in the light of experience, and that some blocks of space will prove more troublesome than others. There may be scope for taking advantage of the usual 80/20 result/effort ratio. I expect that the information I would like to see presented must already be in use to manage the project, and so should not require significant extra effort to prepare. It's probably a good idea for me to say that I'm just looking for information, not trying to paint anyone into a corner. [ As you can probably guess, I'm really only interested in 137.43/16, 8-) ] I hope these suggestions help. I expect to come to Amsterdam for the first week in September, and look forward to seeing some nice graphs! Best regards, Niall O'Reilly PS. FWIS: From where I sit. From andrei at ripe.net Wed Aug 20 14:14:39 2003 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 20 Aug 2003 14:14:39 +0200 Subject: [address-policy-wg] IP Addressing policy on personal contact info (kf) In-Reply-To: <5FAA9FFC-D282-11D7-A889-000A95880ECC@kurtis.pp.se> References: <5FAA9FFC-D282-11D7-A889-000A95880ECC@kurtis.pp.se> Message-ID: <3F43662F.2050500@ripe.net> Kurt Erik Lindqvist wrote: [...] >> We have talked with the Dutch Data Protection Authority about the >> Database as well, to make sure that we don't run afoul of the EU >> privacy directives. > > > > I think that issue is somewhat more problematic than that. I guess > that what Katri is actually asking for is the Swedish data protection > law. I am no expert on this law but from what I know / remember, the > law requires the direct consent of the registered party as well as > certain guarantees that the data is not passed on (within some > limits). This means that the Swedish ISPs in order to register these > customers actually needs written consent from the customer, as well > as to solve the issue on passing that data on further by registering > the data in the RIPE DB. > > Perhaps someone that knows the issue better could comment? > The lawyers told us that these registrations need to comply with the Dutch Data Protection Act which is derived from the EU Data Protection Directive. According to this Directive and the Dutch Data Protection Act storage and publication of personal data in a database is possible only (Article 7 EU Directive): a) with the data subject?s unambiguous consent, or b) if necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract, or c) if necessary for compliance with a legal obligation to which the controller is subject (controller is the party responsible for determining the purpose and means of the processing of personal data), or d) if processing is necessary in order to protect vital interests of the data subject, or e) if necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in a controller or in a third party to whom the data are disclosed, or f) if necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and interests and freedoms of the data subject which require protection under the EU Directive. They though that e) and f) may apply. Also, after discussing the case with the Dutch Data Protection Authority (and their main concern was .de unreferenced data at that moment), the conclusion was that though there are some issues, the problem should be significantly reduced after removal of .de contact data and other stale information that has no direct relationship to the NCC's business. > Best regards, > > - kurtis - Best regards, Andrei Robachevsky RIPE NCC From leo at ripe.net Wed Aug 20 20:11:00 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 20 Aug 2003 20:11:00 +0200 Subject: [address-policy-wg] Transferring InterNIC space from ARIN Database to other RIR datab ases In-Reply-To: References: Message-ID: <20030820181100.GI30418@ripe.net> Hi Niall, Thanks for your mail. You can also find a list of proposed dates for forthcoming transfers on our web site at: You'll also be glad to know that Wilfried has kindly given me a slot in the next DB WG session to make a presentation on the ERX project. I hope to be able to provide you with the information you want there. Regards, -- leo vegoda RIPE NCC Registration Services Manager From dr at cluenet.de Thu Aug 21 01:20:33 2003 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 21 Aug 2003 01:20:33 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030811140559.G67740@Space.Net>; from gert@space.net on Mon, Aug 11, 2003 at 02:05:59PM +0200 References: <20030811122954.D67740@Space.Net> <20030811140559.G67740@Space.Net> Message-ID: <20030821012033.A31199@homebase.cluenet.de> On Mon, Aug 11, 2003 at 02:05:59PM +0200, Gert Doering wrote: > That's what I thought people would do. But they don't. They want to > be "independent", and so they go for PI, instead for a suballocation > from one of their upstreams. > > (And they don't renumber, of course, but just keep the PI) Correct. > > Marcus Ruchti says that the majority of the ISPs will not announce PA space > > from another AS, does this include more specific announcements? > > I just disagree with that statement. PA-based multihoming is a valid > approach to solve certain classes of problems. If some ISPs refuse > to support this (because it creates more work for their NOC or > whatever reason...), the market place has alternatives... It's the end customer who refuses to use PA address space of one of his upstreams as when he terminates contract with him, he'll need to renumber. This is a commercial factor. Renumbering costs customers real money. As such, PA space ties the end customer somewhat into the PA-providing uplink. The second reason why I find this approach not too viable is that it would create a lot of inconsistant origin BGP announcements. I do understand that this is needed for anycast applications, but this should be limited to a number of "well-known" anycast services. On the other hand, this (and ONLY THIS) point is moot as soon as the end customer gets an ASN of his own and announces the PA more-specific himself. But this leaves still the commercial consideration discussed above. According to my experience, end customers multihome for two reasons: - technical resilience - commercial independence Multi-homing with PA subnets solves only the first problem space. Nowadays, customers are more and more (and more) looking to solve the second problem space as well (and for good reasons). We ISPs are here to solve customer problems - even if it means that we give up some means of customer retention, so we should aim to tackle the second problem space as well. I will respond to the four proposed policy changes in a seperate mail. Best regards, Daniel From dr at cluenet.de Thu Aug 21 02:42:05 2003 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 21 Aug 2003 02:42:05 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <+f6cKhCCWzN$EwbX@ripe.net>; from leo@ripe.net on Mon, Aug 11, 2003 at 08:19:46AM +0200 References: <+f6cKhCCWzN$EwbX@ripe.net> Message-ID: <20030821024204.B31199@homebase.cluenet.de> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: > Below is a summary of the recent discussions on the PI TF mailing list. As the pi-tf mailing list seems to have been closed (at least I'm unable to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess further discussion should take place here (which makes some sense). > 1. Reduce the minimum allocation size from /20 to /21 Agreed. > 2. Remove the requirement to show an immediate need for 25% of the > allocated address space (a /23 in this case) Agreed. > 3. No longer assign PI (Portable) address space to End Users Strongly disagreed. Upstream-independent address space is _needed_. This cannot be ignored. > 4. End Users requiring a portable address block could become an LIR > and receive a /21 allocation. An end-user can't be a LIR by definition. :-) Let's take a look at four entity categories: A) Commercial ISPs, assigning subnets to customers B) Enterprises (from very small companies to multinational heavyweights) C) non-commercial organisations (NCOs) being absolute end-users D) non-commercial organisations (NCOs) assigning subnets to org members Cat A is quite clear. They should become regular LIRs, receive an initial allocation under provisions of #1 and #2 above. RIPE NCC efforts are covered by LIR membership fees. Cat B should be able to get an IP block according to documented need plus some reserve (perhaps at least a /22 by default) without ability to sub-assign subnets. RIPE NCC efforts are primarily one-time and thus the requestor should pay a one-time fee for the request processing, plus a periodic, moderate maintenance fee to cover administrative and operational costs for their data in the RIPE systems like the RIPE DB. Usually, those kind of entities are nowadays typical PI requestors (getting IP space for free via a LIR), or Enterprise LIRs (paying significant yearly fees, but not requiring any cost-intensive RIPE NCC service like hostmaster support as no registry function is performed). Cat C+D are most interesting. The aim for those should be to keep cost as low as possible. Cat C would be typical PI requestors today, with no fees to be paid at all. IMHO, we should keep this cost neutrality for those kind of NCOs. Cat D is where the fun starts. Currently, Cat D NCOs would usually request larger PI blocks, and "silently" (without documentation in the RIPE DB due to the nature of PI assignments) sub-assign subnets to NCO members. As an example, imagine a "computer club" having built a city-wide "club WAN" by some creative means, being BGP multihomed to some ISPs, connecting club members with static IP subnets to this "club backbone". Naturally, the club would like to document those assignments in RIPE to provide sensible contact information for IP ranges, but isn't allowed due to the "end user" style of PI assignments (mnt-lower to RIPE NCC). NCOs like clubs usually can't afford to become LIRs, but would like to document such sub-assignments. I would suggest to treat them like Cat C, but: - Allocate a netblock of justified size, at least /21, like ISP LIRs - Allow assignments within this allocation for documentation reasons (NOT usage level _justification_) in RIPE DB. - require them to request their stuff via an established LIR like with Cat C and usualy PI requests today. - no fees Overall, in short: A) normal LIR status, with normal LIR payments to RIPE NCC B) end-user status, one-time fee plus moderate periodic maintenance fee C) non-commercial (totally) end-user status, no fees, request via a LIR D) non-commercial organisation able to document usage of IP blocks within their IP range, no fees, request via a LIR So, Cat A+D would receive PA allocations, and Cat B+C would receive PI assignments. Reading all that again, I might overcomplicate things. But then again, I don't simpler models being equally "fair". :-/ > Finally, it was noted that there is a requirement for globally > unique addresses that will not be routed on the Internet. This would fall under Cat B (if commercial) or Cat C (non-commercial). Please take above as a proposal for discussion. I'm highly interested in comments. Best regards, Daniel From slz at baycix.de Mon Aug 25 11:43:10 2003 From: slz at baycix.de (Sascha Lenz) Date: Mon, 25 Aug 2003 11:43:10 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: <5.1.0.14.2.20030821144547.03a36b60@mailhost.ripe.net>; from dominic@ripe.net on Thu, Aug 21, 2003 at 04:02:16PM +0200 References: <5.1.0.14.2.20030820145057.03db5e18@mailhost.ripe.net> <5.1.0.14.2.20030820145057.03db5e18@mailhost.ripe.net> <20030821033735.C31199@homebase.cluenet.de> <5.1.0.14.2.20030821144547.03a36b60@mailhost.ripe.net> Message-ID: <20030825114310.B13657@mama.baycix.de> 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 at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From chr at jay.net Mon Aug 25 14:24:02 2003 From: chr at jay.net (Christian Rasmussen) Date: Mon, 25 Aug 2003 14:24:02 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: <20030825114310.B13657@mama.baycix.de> Message-ID: 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 at jay.net Personal email: chr at 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 at ripe.net > [mailto:address-policy-wg-admin at ripe.net]On Behalf Of Sascha Lenz > Sent: 25. august 2003 11:43 > To: Dominic Spratley > Cc: ncc-services-wg at ripe.net; address-policy-wg at 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 at baycix.de = > = NOC BayCIX GmbH = > = http://www.noc.baycix.de/ * PGP public Key on demand * = > ================================================================== > ======== > From slz at baycix.de Tue Aug 26 10:22:20 2003 From: slz at baycix.de (Sascha Lenz) Date: Tue, 26 Aug 2003 10:22:20 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <20030821024204.B31199@homebase.cluenet.de>; from dr@cluenet.de on Thu, Aug 21, 2003 at 02:42:05AM +0200 References: <+f6cKhCCWzN$EwbX@ripe.net> <20030821024204.B31199@homebase.cluenet.de> Message-ID: <20030826102219.C13657@mama.baycix.de> Hay, On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: > On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: > > Below is a summary of the recent discussions on the PI TF mailing list. > > As the pi-tf mailing list seems to have been closed (at least I'm unable > to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess > further discussion should take place here (which makes some sense). Closed, yes. > > 1. Reduce the minimum allocation size from /20 to /21 > > Agreed. There shouldn't be much problems with that. > > 2. Remove the requirement to show an immediate need for 25% of the > > allocated address space (a /23 in this case) > > Agreed. That was a bad one anyways, for the reasons mentioned already. Such requirements only lead to faked requests and more work. We even had a customer who insisted on us faking some PA assignments for him so he can show a /22 for immediate use; of course he never wanted to use them in first place since he didn't want to renumber his customers twice. After we denied that, the customer left, but obviously found another LIR who had no problems with such things, at least he is LIR now for a while. > > 3. No longer assign PI (Portable) address space to End Users > > Strongly disagreed. Upstream-independent address space is _needed_. > This cannot be ignored. Oh my... the big PI vs. routing table size ect. discussion. I _really_ don't want to get into this. But in general, PI is needed - people, deal with it. (This goes for IPv6, too by the way... some day you all will notice). > > 4. End Users requiring a portable address block could become an LIR > > and receive a /21 allocation. > > An end-user can't be a LIR by definition. :-) Hrnjaaa... Enterprise-LIRs are End-Users (more or less). > Let's take a look at four entity categories: > > A) Commercial ISPs, assigning subnets to customers > B) Enterprises (from very small companies to multinational heavyweights) > C) non-commercial organisations (NCOs) being absolute end-users > D) non-commercial organisations (NCOs) assigning subnets to org members > > Cat A is quite clear. They should become regular LIRs, receive an > initial allocation under provisions of #1 and #2 above. RIPE NCC efforts > are covered by LIR membership fees. ACK. as always. > Cat B should be able to get an IP block according to documented need > plus some reserve (perhaps at least a /22 by default) without ability > to sub-assign subnets. RIPE NCC efforts are primarily one-time and > thus the requestor should pay a one-time fee for the request processing, > plus a periodic, moderate maintenance fee to cover administrative and > operational costs for their data in the RIPE systems like the RIPE DB. > Usually, those kind of entities are nowadays typical PI requestors > (getting IP space for free via a LIR), or Enterprise LIRs (paying > significant yearly fees, but not requiring any cost-intensive RIPE NCC > service like hostmaster support as no registry function is performed). basically, ACK. I'm just no fan of being denied to enter useful information in the database, if i want to. See below, in D)... Why shouldn't it be allowed for big companies to use LIR-PARTITIONED or hopefully soon sub-allocations ect? ...on the other hand, what company does keep their RIPE database objects up-to-date anyways? *bighsigh* There's Enterprise-LIR status, i don't know how many "big" companies get LIR and how many just request a PI-block though. The problem is, you talk about NCOs not being able to document their "sub-assignments" with PI space, but you deny even large companies to do so with your suggestion here. At least those big ones can get Enterprise-LIR up to now and then have the ability (and responsibility) to manage and document their address space within their company, documenting different contact persons, abuse addresses ect. per subsidiary and so on. > Cat C+D are most interesting. The aim for those should be to keep > cost as low as possible. Cat C would be typical PI requestors today, > with no fees to be paid at all. IMHO, we should keep this cost > neutrality for those kind of NCOs. Full-ACK. Since i'm personally involved in two (and a half) of this kind of non-commercial organisations, i can only confirm this. I'm not pleased with arguments like "you are small, you are not commercial, you have no customers - why do you need to be in the global routing table? just get a descent IP uplink if you want stable connectivity and a big ISP certainly doesn't go bankrupt either so no need to renumber sometime soon!"-talk one _always_ gets about this situation. I'm absolutely against an Internet in the future, where only big companies with much money and thousands of IP addresses are allowed to be completely independant and have full backup connectivity. (i.e., having their prefix(es) showing up in the DFZ). NOT to assign anymore PI-space and denying a cheap way to get PA Allocation blocks of routeable size for no/low fees would be a first step towards that. NOT having some kind of PI-space in the IPv6 world is, too (though, a bit different there, but that's another discussion). > Cat D is where the fun starts. > > Currently, Cat D NCOs would usually request larger PI blocks, and > "silently" (without documentation in the RIPE DB due to the nature of > PI assignments) sub-assign subnets to NCO members. As an example, > imagine a "computer club" having built a city-wide "club WAN" by > some creative means, being BGP multihomed to some ISPs, connecting > club members with static IP subnets to this "club backbone". > Naturally, the club would like to document those assignments in > RIPE to provide sensible contact information for IP ranges, but > isn't allowed due to the "end user" style of PI assignments > (mnt-lower to RIPE NCC). Thank you for describing what i constantly do because i'm forced to. The housing subnets for club-members are refered as one big "housing subnet" in the RIPE reuqest(s), but of course everyone gets a small subnet and a VLAN ... but i can't document it, because there's no sub-assigning or PI-Allocations (bad, bad...) Same goes for IPSEC-Tunnels ect. Though, the problem here seems to be that not enough of those situations with NCOs exist?! (if i'm wrong, show up people! :) ) ==> Probably this shouldn't be narrowed down to NCOs, but also include "very small ISPs", who want to provide adequate services but only have very few customers, and rather want to invest their money into infrastructure than in RIPE membership fees. Whatever, a local WLAN provider with some Hotspots and few point2point links for some offices of customers with permanent links ect. Another point may be that many are not-so-unhappy about not having the responsibility to deal with assignment and record- keeping activities. I'm not sure but i guess at least some NCOs/small ISPs are quite happy with PI space for that reason, too. (which is bad i mean if PI-space is abused for such reasons) > NCOs like clubs usually can't afford to become LIRs, but would > like to document such sub-assignments. I would suggest to treat > them like Cat C, but: > > - Allocate a netblock of justified size, at least /21, like ISP LIRs > - Allow assignments within this allocation for documentation reasons > (NOT usage level _justification_) in RIPE DB. > - require them to request their stuff via an established LIR like > with Cat C and usualy PI requests today. > - no fees sounds like a nice compromise. Another one would be an official introduction of PI-Allocations. For example for me, in all cases i don't need a /21, a /23 is enough, most likely forever. "ALLOCATED PI" status exists, why not use it? Of course that's no solution for the future, if i read it right, available PI-blocks are fading away fast. And with your suggestion, new requests might result in PA-allocation-blocks of routable-size, no PI anymore. But probably as additional feature for already existing situations like that with existing PI-Assignments? -> migrate to PI-Allocations on request? ...just an opinion since we already have many relatively small PI blocks out there now which are probably used like described here to a certain degree. > > Overall, in short: > > A) normal LIR status, with normal LIR payments to RIPE NCC > B) end-user status, one-time fee plus moderate periodic maintenance fee > C) non-commercial (totally) end-user status, no fees, request via a LIR > D) non-commercial organisation able to document usage of IP blocks within > their IP range, no fees, request via a LIR > > So, Cat A+D would receive PA allocations, and Cat B+C would receive > PI assignments. > > Reading all that again, I might overcomplicate things. But then again, > I don't simpler models being equally "fair". :-/ I put it a bit more general - Independant address space must be available for everone who has a good reason and knows what he/she is doing (that explicitiy does not mean "anyone" as in "anyone" :) ) - There should be possibilities to get address space and have the ability to assign address space without paying horrible RIPE membership fees and the need to fulfill minimum requirements if one is very small and/or a NCO Up to now, you can get PI-space from seperate PI-blocks, any size, but only assignments, no allocations, so documentation is impossible, this is bad for the reasons mentioned above. This was an intended situation, but i think it turned out badly. (More and more PI requests, no documentation of actual assignments within PI assignments...), so it should be changed. And obviously PI-blocks are soon gone. - Small(!) one time or per-year fees are OK, of course with reduced RIPE services, or none at all (-> handling via a LIR); NO FEES are recommended for special cases like NCOs or veeery small ISPs Or to make it easier, probably some reduced-price LIR status for those ("Status: Very Small < Small < Medium < Large" :) ) It's most likely safe to assume that those "small" organisations who really want to get into all the RIPE stuff probably have more self-interest in the things and mean less hassle than one or another "bigger" commercial LIR, so they don't really mean "more work" for the RIPE NCC. But that rather leads into the recent "RIPE-tasks and cost" discussion we had earlier this month. => in short - Daniel's proposal is quite nice so far Though, I wouldn't refuse some kind of "enry-level LIR status" either. Sounds easier for me. Nothing new to implement (not much at least) and no need for seperate PI blocks anymore.. > > Finally, it was noted that there is a requirement for globally > > unique addresses that will not be routed on the Internet. > > This would fall under Cat B (if commercial) or Cat C (non-commercial). I don't really see a difference about non-routed addresses either. If IPv4 space finally runs out, probably some more developers and ISPs start deploying IPv6 faster, that's only positive. Doesn't nescessarily mean to _waste_ IPv4 addresses, but i don't see a point in more and more conservation policies. (no more PI assignments... probably more restrictive policy for non-routed addresses ect.) > Please take above as a proposal for discussion. I'm highly interested in > comments. done. Sorry for possible confusion, this is a pre-morning-coffee-reply. I rather wonder why noone else replied yet? Does that mean "granted" and we can implement that by next week? :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From woeber at cc.univie.ac.at Tue Aug 26 13:09:27 2003 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 26 Aug 2003 13:09:27 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions Message-ID: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> >Hay, > >On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: >> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: >> > Below is a summary of the recent discussions on the PI TF mailing list. >> >> As the pi-tf mailing list seems to have been closed (at least I'm unable >> to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess >> further discussion should take place here (which makes some sense). > >Closed, yes. I don't think so, pls. see below. Wilfried. ______________________________________________________________________ From: Mally Mclane To: pi-tf at ripe.net Subject: [pi-tf] This list has moved to mailman Date: Tue, 26 Aug 2003 09:26:26 +0200 Dear Colleagues, We have moved this list to mailman, in an attempt to cut down on the spam that was entering it. The list will function exactly as before, and the archives will still be available in the same space. You can edit your personal options at: http://www.ripe.net/mailman/listinfo/pi-tf If you notice any oddities, please contact . Regards, Mally Mclane RIPE NCC - Operations -------------------------------------------------------------------------------- From leo at ripe.net Tue Aug 26 13:12:29 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 26 Aug 2003 13:12:29 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> References: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> Message-ID: Hi, "Wilfried Woeber, UniVie/ACOnet" wrote: >>Hay, >> >>On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: >>> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: >>> > Below is a summary of the recent discussions on the PI TF mailing list. >>> >>> As the pi-tf mailing list seems to have been closed (at least I'm unable >>> to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess >>> further discussion should take place here (which makes some sense). >> >>Closed, yes. > > I don't think so, pls. see below. We moved the mailing list to Mailman to help filter out spam. We won't close the list until we're asked to do so by the AP WG. Regards, -- leo vegoda RIPE NCC Registration Services Manager From mally at ripe.net Tue Aug 26 13:16:47 2003 From: mally at ripe.net (Mally Mclane) Date: Tue, 26 Aug 2003 13:16:47 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> References: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> Message-ID: <939449857.1061903807@ginger.singel.ripe.net> Hi, --On 26 August 2003 13:09 +0200 "Wilfried Woeber, UniVie/ACOnet" wrote: >>> >>> As the pi-tf mailing list seems to have been closed (at least I'm unable >>> to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess >>> further discussion should take place here (which makes some sense). >> >> Closed, yes. > > I don't think so, pls. see below. > Wilfried. > ______________________________________________________________________ > > From: Mally Mclane > To: pi-tf at ripe.net > Subject: [pi-tf] This list has moved to mailman > Date: Tue, 26 Aug 2003 09:26:26 +0200 Just to clarify, the pi-tf list until earlier this morning was a simple mail exploder. Thus, the alias 'pi-tf-request at ripe.net', will have bounced. However, in the current RIPE NCC setup, *-request at ripe.net will not work for any of our lists. All subscriptions/unsubscriptions must be done through the web interface for each public list, linked at: http://www.ripe.net/mailman/listinfo/ Public RIPE lists are archived and linked from: If you have further questions, please do not hesitate to contact . Regards, Mally Mclane RIPE NCC - Operations From slz at baycix.de Tue Aug 26 13:16:51 2003 From: slz at baycix.de (Sascha Lenz) Date: Tue, 26 Aug 2003 13:16:51 +0200 Subject: [address-policy-wg] Summary of the PI Task Force's recent discussions In-Reply-To: <00A24F5B.BE20F2AE.13@cc.univie.ac.at>; from woeber@cc.univie.ac.at on Tue, Aug 26, 2003 at 01:09:27PM +0200 References: <00A24F5B.BE20F2AE.13@cc.univie.ac.at> Message-ID: <20030826131651.B10106@mama.baycix.de> Hay, On Tue, Aug 26, 2003 at 01:09:27PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > >Hay, > > > >On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote: > >> On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote: > >> > Below is a summary of the recent discussions on the PI TF mailing list. > >> > >> As the pi-tf mailing list seems to have been closed (at least I'm unable > >> to subscribe - pi-tf-request at ripe.net bounces as unknown), I guess > >> further discussion should take place here (which makes some sense). > > > >Closed, yes. > > I don't think so, pls. see below. [...] I'm sorry, i was going to write something completely different anyways. ("Yes, further discussion should take place.") Impacts of a low caffein level. But as Daniel pointed out, "pi-tf-request at ripe.net bounces as unknown", but if this works again today (looks like), thanks for the information! -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From hpholen at tiscali.no Fri Aug 29 12:51:31 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 29 Aug 2003 12:51:31 +0200 (CEST) Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: <20030825114310.B13657@mama.baycix.de> Message-ID: > 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 From slz at baycix.de Thu Aug 28 13:18:59 2003 From: slz at baycix.de (Sascha Lenz) Date: Thu, 28 Aug 2003 13:18:59 +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 12:51:31PM +0200 References: <20030825114310.B13657@mama.baycix.de> Message-ID: <20030828131859.A13958@mama.baycix.de> 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 at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================== From hpholen at tiscali.no Fri Aug 29 14:00:03 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Fri, 29 Aug 2003 14:00:03 +0200 (CEST) Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: <20030828131859.A13958@mama.baycix.de> Message-ID: > > 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 From eamonn at ripe.net Thu Aug 28 12:54:38 2003 From: eamonn at ripe.net (Eamonn McGuinness) Date: Thu, 28 Aug 2003 12:54:38 +0200 Subject: [address-policy-wg] Fwd: selling ip:s? (kf) In-Reply-To: Your message of Wed, 20 Aug 2003 10:30:03 +0200. <5.1.0.14.0.20030820102954.00b874e0@pop.swip.net> References: <5.1.0.14.0.20030820102954.00b874e0@pop.swip.net> Message-ID: <200308281054.h7SAscWt023697@birch.ripe.net> Hi Katri, We have not seen any response to your question so let us try to give you an answer. Let us clear up the question of charging for IP address space first. If you read RIPE-152, "Charging by Local Internet Registries", Section 3, you will see that IP addresses and AS numbers cannot be "charged", "rented" or "sold" : http://www.ripe.net/docs/chargingbylirs.html [..] 3.Registries and Resources Two of the above services involve the assignment of finite resources to customers; these are domain name space and IPv4 address space. They are managed and assigned by registration agencies, respectively domain name registries and IP registries. By themselves, these resources have no intrinsic value; their worth is only realised in conjunction with the provision of Internet access. Thus, while registries may charge for their administrative and technical services, they may not charge for namespace or address space as such; no unit cost or price tag can be attached to a domain name or to an IP address, public or private. [..] Actually there is an agenda point about this document at next week's Address Policy Working Group. Now to the rest of the question. LIR's can offer multiple IP addresses to customers as long as there is justification from the customer that multiple IP addresses are required. If there is then ISP B can use their AW to evaluate and assign these requests. ISP A should not charge per IP address, rather the cost of administering the "package" the customer has bought. Ultimately the LIR is responsible for the users of their address space so assignments made to customers must *not* be sub-assigned. We refer to the latest supporting document: "A separate form must be completed on behalf of each customer's network or for the infrastructure of the Local Internet Registry (LIR). Do not include requests for more than one customer in one form." http://www.ripe.net/ripe/docs/iprequestsupport.html#intro and the latest draft policy document states: 10.0 Record Keeping "All documentation related to an IP address request and sub-allocation or assignment must be maintained by the LIR for future reference..." http://www.ripe.net/ripe/draft-documents/ipv4-policies.html#record Kind regards, Eamonn McGuinness RIPE NCC Hostmaster Team Leader Apparently the following was written: > >>Hello, I would like rise the question about selling ip-addresses... >> >>Let me present two exampled: >>1. ISP A has offeres adls that includes static 1 ip-address, but if the >>customer needs more ip:s >> they will apply for this and pay a sum of X krona per ip-adress they >> receive. >> ISP B also offeres adsl that inclued 1 ip-address, and when the >> customer needs more ip:s >> they will have to change the service in order to receive more ip:s, >> since the adsl service is >> only offered with 1 ip-address and approved from RIPE NCC to be done >> in this way. >> How should ISP B compare and offer the same amount of ip-addresses >> without "getting >> into trouble"? >> >>2. ISP A has a customer who has received /24 from which they share out >>addresses >> and their customers can receive more addresses for a sum of X krona. >> >> I understand that we are not allowed to sel our ip-addresses but what >> about >> our customers customer? Is there anything preventing this from >> happening and >> is there something documented? >> >>Regards Katri >>Tele2/Swipnet IP Registry >>Local Internet Registry >>__________________________________________________________ >> >>Tele2/SWIPnet Tel: 08 5626 40 08 >>Box 62 Fax: 08 5626 42 10 >>164 94 Kista Email: ip at swip.net >>SWIP-RIPE SWIPNET-LIR-MNT >>__________________________________________________________ From chr at jay.net Thu Aug 28 18:43:47 2003 From: chr at jay.net (Christian Rasmussen) Date: Thu, 28 Aug 2003 18:43:47 +0200 Subject: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal In-Reply-To: Message-ID: 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 at jay.net Personal email: chr at 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 at ripe.net > [mailto:address-policy-wg-admin at ripe.net]On Behalf Of Hans Petter Holen > Sent: 29. august 2003 12:52 > To: Sascha Lenz > Cc: address-policy-wg at 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 > > From daniel.karrenberg at ripe.net Sun Aug 31 15:58:22 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 31 Aug 2003 15:58:22 +0200 Subject: [address-policy-wg] WG Charter In-Reply-To: References: Message-ID: <20030831135822.GB1538@reifa.local.> On 11.08 20:47, Hans Petter Holen wrote: > > The Address Policy WG develops policies relating to the > management and registration of Internet resources > (currently IPv4, IPv6 and AS Numbers) by the RIPE NCC > and its LIRs within the RIPE NCC service region. It also > co-ordinates policies with the other RIR communities and > liaises with the IANA and ICANN on address policy issues. > The Address Policy WG meets three times a year at RIPE > meetings and has an open (publicly archived) mailing list. > Anyone with an interest in Internet numbering issues is > welcome to observe, participate and contribute to the WG. Nit: IPv4 and IPv6 *addresses* or shorter "Internet addresses". Suggestion: replace "Internet resources ....)" by "Internet addresses and routing idetifiers". One can always add other stuff if necessary. Nit: mentioning IANA is sufficient, no need to mention ICANN. Suggestion: replace "It also .... issues." with "The WG coordinates its work with the appropriate bodies of the other RIRs and the IANA." Daniel From plzak at arin.net Sun Aug 31 22:44:59 2003 From: plzak at arin.net (Ray Plzak) Date: Sun, 31 Aug 2003 16:44:59 -0400 Subject: [address-policy-wg] WG Charter In-Reply-To: <20030831135822.GB1538@reifa.local.> Message-ID: <003f01c37000$c0166570$178888c0@arin.net> Nits: 1. Should be Internet Number Resources 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. Ray > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Daniel > Karrenberg > Sent: Sunday, August 31, 2003 9:58 AM > To: Hans Petter Holen > Cc: Rob Blokzijl; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] WG Charter > > > On 11.08 20:47, Hans Petter Holen wrote: > > > > The Address Policy WG develops policies relating to the > > management and registration of Internet resources > > (currently IPv4, IPv6 and AS Numbers) by the RIPE NCC > > and its LIRs within the RIPE NCC service region. It also > > co-ordinates policies with the other RIR communities and > > liaises with the IANA and ICANN on address policy issues. > > The Address Policy WG meets three times a year at RIPE > > meetings and has an open (publicly archived) mailing list. > > Anyone with an interest in Internet numbering issues is > > welcome to observe, participate and contribute to the WG. > > Nit: IPv4 and IPv6 *addresses* or shorter "Internet addresses". > > Suggestion: replace "Internet resources ....)" by > "Internet addresses and routing idetifiers". One can > always add other stuff if necessary. > > Nit: mentioning IANA is sufficient, no need to mention ICANN. > > Suggestion: replace "It also .... issues." with > "The WG coordinates its work with the appropriate bodies > of the other RIRs and the IANA." > > Daniel > From daniel.karrenberg at ripe.net Sun Aug 31 23:33:57 2003 From: daniel.karrenberg at ripe.net ('Daniel Karrenberg') Date: Sun, 31 Aug 2003 23:33:57 +0200 Subject: [address-policy-wg] WG Charter In-Reply-To: <003f01c37000$c0166570$178888c0@arin.net> References: <20030831135822.GB1538@reifa.local.> <003f01c37000$c0166570$178888c0@arin.net> Message-ID: <20030831213357.GB803@dhcp-9-224.ripemtg.ripe.net> 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