From tore.anderson at redpill-linpro.com Thu Nov 1 08:24:59 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 01 Nov 2012 08:24:59 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> Message-ID: <509223CB.6070509@redpill-linpro.com> Good morning Alex, >> Quoting from 2012-05's impact analysis: >> >> ?It is worth mentioning that the RIPE NCC is willing to publish >> details on resource transfers and a report has not been requested >> so far. Only one transfer has been recorded in the RIPE NCC >> service region recently, and this is why no details on resource >> transfers have been published so far.? * Alex Le Heux > However, given this proposal and the discussion around it, we would > prefer to wait until it reaches a conclusion before publishing. Okay. This surprises me a bit, though. The impact analysis seems to me to state, essentially, ?we are willing to publish the requested information without a clear policy mandate from the community?. However, your response seems to suggest the exact opposite, i.e., ?we are NOT willing to publish the requested information without a policy clear mandate from the community?. I don't believe anyone is proposing to *forbid* you from publishing information on transfers, the way I see it, the question is simply whether or not the community needs to compel you (through policy) to publish it, or not. In my opinion, it would be much more preferable to not have to take the policy route, since the terser and concise the policy text is, the better it is. The community shouldn't need to micro-manage the NCC through policy - it would be better and more efficient if we could instead work directly with you to get what we want. But now I am not so sure on whether or not the added policy text is required after all. Do you see any outcome of this proposal's discussion that would cause you to not publish the requested information after all? > We already publish various files that reflect the state of the RIPE > registry: > > ftp://ftp.ripe.net/pub/stats/ripencc/ > ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt > ftp://ftp.ripe.net/ripe/dbase/split/ > > Comparing different versions of these files will show any transfers > that were done under the transfer policy. It would however also show > the results of the various types of mergers, acquisitions and > divestments that also happen on a regular basis. I am aware of these files, and have been digging through them already in search of the transfer in question. The problem with them, as you point out, is that it is difficult to tell a "pure" transfer apart from other types of business transactions. Looking back to mid-June, the most likely candidates I find are: 1) 109.109.144.0/20 (uk.layershift -> uk.gemsoft, 2012-06-19) 2) 91.145.32.0/19 (se.helsingenet -> se.hnet-ovan, 2012-08-29) 3) 82.164.192.0/18 (no.telenor -> no.eab, 2012-10-17) 4) 82.196.28.0/22 (fr.inetwork -> fr.edxnetwork, 2012-10-30) #4 can't be the one the Impact Analysis refers to as it is too recent, and all the others seems to be related in other ways (e.g., same ASN for the route objects). If I were to make a guess, I'd put my money on #3, as the recipient LIRs in #1 and #2 hold only the single transferred resource, making me suspect those transactions are due to the origin LIRs' organisations splitting in two. However, all the allocations mentioned above are listed with the original date of allocation in both alloclist.txt and delegated-ripencc-extended. I could not find a single transaction where the date changed to the present day (except those blocks that went through the "reserved" state, which I guess means returned to the NCC and re-allocated normally). So while I won't ask you to confirm whether or not any of the above transactions are indeed the transfer the Impact Analysis refers to, I was wondering if you could tell whether or not the date of the allocation will remain unchanged as a result of a transfer? > I hope this answers your questions for now. Not really. I ended up with more questions than I had to begin with. ;-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From mueller at syr.edu Sat Nov 3 18:00:37 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Nov 2012 17:00:37 +0000 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <508F98A7.6030102@redpill-linpro.com> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Tore Anderson > I'd like > this information in order to try to confirm my belief that this > information is possible to extract from the stats files already > available on the FTP. [Milton L Mueller] If you need this information to confirm your "belief" that this info can be extracted from existing stats file, a reasonable person would conclude that maybe we should make the information available in the format suggested by 2012-05. > Also, if there has been more transfers since the impact analysis was > written, I'd like to see their details, as well. If possible, I would > prefer to see a daily updated (and easy to parse) text file with all the > transfers and their details being made available on the FTP. [Milton L Mueller] In other words, you want to see everything that 2012-05 would allow anyone to see. A reasonable person would interpret this as support for 2012-05. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From mueller at syr.edu Sat Nov 3 18:06:57 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Nov 2012 17:06:57 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> Message-ID: <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> For example, on stock market no one publish who sold and who bought shares. I think for safety reason. [Milton L Mueller] One can pick a dozen other resources, ranging from acquisitions of companies to real estate transactions, where buyer and seller are documented. Second, even with stock exchanges, trades made by ?insiders? are all documented, by name. Third, ?safety reasons? dictate that resources held in rem are best recorded in a public exchange, so that it is more difficult to deceive anyone in the public as to who is the rightful owner of resources. What you need to do to make your argument convincing and meaningful, Alexey, is to explain what harm is done by publishing this information. Tell me what ?safety? issues for example are raised by people knowing that a transaction took place? For analyse enought anonymous statistical information about transfers. -- Alexey Ivanov LeaderTelecom 29.10.2012 20:27 - Emilio Madaio ???????(?): Dear Colleagues, The draft document for the version 2.0 of the proposal 2012-05 has been published. The impact analysis that was conducted for this proposal has also been published. The main changes in the new version are: -use of a bullet point layout for the proposal text; -anonymous reports of non-approved transfers. You can find the full proposal and impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 12 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Sat Nov 3 19:45:02 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 3 Nov 2012 18:45:02 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> Message-ID: <855077AC3D7A7147A7570370CA01ECD227A66E@SUEX10-mbx-10.ad.syr.edu> Dmitry This has been discussed before; there are no new privacy issues raised by this proposal. First, privacy issues pertain to ?natural persons? not to the organizational entities (legal persons) that typically hold and trade address blocks. Second, and more fundamentally, recording transactions in the way suggested by 2012-05 does not alter anyone?s privacy status whether they are a natural person or legal person. The possession of an address block both before and after the transaction will be recorded in the Whois. We are simply making the information about the functioning of the transfer market easier to see, compile and analyze. Again, you talk about the ?high price? of the proposed policy but provide no specifics. Please tell me who would be harmed by having a transaction directly publicized in the way proposed, how they would be harmed. Until you do so I cannot take your arguments seriously. From: Dmitry Burkov [mailto:dvburk at gmail.com] Sent: Saturday, November 03, 2012 1:28 PM To: Milton L Mueller Cc: LeaderTelecom Ltd.; address-policy-wg at ripe.net; policy-announce at ripe.net Subject: Re: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] Milton, When in result your position can become so close to B.Flame dreams I can't agree with you. Sorry - you reminded me last discussions on Whois and last years talks about lea's expectations to minimize their spendings and to get centralized DBs with personal data on each Internet user or as it named in our country - personal authorization in Internet . Of course - you current talks seems are so far from this- but what's can be behind? I hope that you can understand that there are two side of one medal and the price of free market approach can be so high for us? Dima PS Sorry - it was not directly about disclosure info on transfers - it is a part of some of more general issues where this market is just a small part Sent from my iPhone On 03.11.2012, at 21:06, Milton L Mueller > wrote: For example, on stock market no one publish who sold and who bought shares. I think for safety reason. [Milton L Mueller] One can pick a dozen other resources, ranging from acquisitions of companies to real estate transactions, where buyer and seller are documented. Second, even with stock exchanges, trades made by ?insiders? are all documented, by name. Third, ?safety reasons? dictate that resources held in rem are best recorded in a public exchange, so that it is more difficult to deceive anyone in the public as to who is the rightful owner of resources. What you need to do to make your argument convincing and meaningful, Alexey, is to explain what harm is done by publishing this information. Tell me what ?safety? issues for example are raised by people knowing that a transaction took place? For analyse enought anonymous statistical information about transfers. -- Alexey Ivanov LeaderTelecom 29.10.2012 20:27 - Emilio Madaio ???????(?): Dear Colleagues, The draft document for the version 2.0 of the proposal 2012-05 has been published. The impact analysis that was conducted for this proposal has also been published. The main changes in the new version are: -use of a bullet point layout for the proposal text; -anonymous reports of non-approved transfers. You can find the full proposal and impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 12 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-ripe at c4inet.net Sat Nov 3 21:11:27 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sat, 3 Nov 2012 20:11:27 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <855077AC3D7A7147A7570370CA01ECD227A66E@SUEX10-mbx-10.ad.syr.edu> References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <855077AC3D7A7147A7570370CA01ECD227A66E@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20121103201127.GA12350@cilantro.c4inet.net> On Sat, Nov 03, 2012 at 06:45:02PM +0000, Milton L Mueller wrote: >raised by this proposal. First, privacy issues pertain to ???natural >persons??? not to the organizational entities (legal persons) that >typically hold and trade address blocks. IP resources are held by both legal and natural persons. In the case of natural persons, privacy implication certainly exist (yes, this is the case with already available registry data, too). >Second, and more fundamentally, recording transactions in the way >suggested by 2012-05 does not alter anyone???s privacy status whether >they are a natural person or legal person. The possession of an address >block both before and after the transaction will be recorded in the >Whois. We are simply making the information about the functioning of >the transfer market easier to see, compile and analyze. In my opinion, while whois is a useful and necessary resource, access to that data needs to be better controlled. IP resource holders are in the pretty unique position to have nearly all their business relationships published in a database, access to which is basically uncontrolled. Also, referring to recent debate on which RIR services should be free and which should require payment, this sort of data collation service should not be provided free to all comers, paid for by the membership. On the contrary, it should not only require payment (commensurate with the effort of the RIR) but also an agreement specifying exactly the purposes for which the data may be used. Regards, Sascha Luck From tore.anderson at redpill-linpro.com Sun Nov 4 10:03:49 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 04 Nov 2012 10:03:49 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> Message-ID: <50962F75.6060605@redpill-linpro.com> * Milton L Mueller > If you need this information to confirm your "belief" that this info > can be extracted from existing stats file, a reasonable person would > conclude that maybe we should make the information available in the > format suggested by 2012-05. The format suggested by 2012-05 is fine by me. I would prefer something that is easily parsed by a script, for example something inspired by the delegated-ripencc-extended format: ; network|length|date|sourceLIR|destinationLIR 192.0.2.0|256|20121104|no.anderson|us.mueller > In other words, you want to see everything that 2012-05 would allow anyone to see. Yes, I do strongly support the notion that the above information should be made available to the community by the NCC. > A reasonable person would interpret this as support for 2012-05. As noted above, I do indeed support 2012-05's goal of making this information available to the community. However, my earlier objection to the proposal is only relating to how this is accomplished, and whether or not is is really necessary to add even more text to an already excessively long and complicated policy document. The way I see it, if the NCC publishes the information voluntarily, compelling them through policy anyway amounts to redundant micromanagement. The NCC's impact analysis seemed to address this concern, by saying, essentially: ?We are willing to publish the details requested, somebody just have to ask us first?. So I asked. To my surprise, I got a negative answer. In light of that, it would seem that we do need to compel the NCC to publish the information after all. Hence, I do support 2012-05. That said, if the NCC at a later point in the PDP starts publishing the information voluntarily, I withdraw my support of the proposal and instead object to it, on the grounds that it will be redundant and only serve to further bloat the policy text. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From dvburk at gmail.com Sat Nov 3 18:28:25 2012 From: dvburk at gmail.com (Dmitry Burkov) Date: Sat, 3 Nov 2012 21:28:25 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> Message-ID: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> Milton, When in result your position can become so close to B.Flame dreams I can't agree with you. Sorry - you reminded me last discussions on Whois and last years talks about lea's expectations to minimize their spendings and to get centralized DBs with personal data on each Internet user or as it named in our country - personal authorization in Internet . Of course - you current talks seems are so far from this- but what's can be behind? I hope that you can understand that there are two side of one medal and the price of free market approach can be so high for us? Dima PS Sorry - it was not directly about disclosure info on transfers - it is a part of some of more general issues where this market is just a small part Sent from my iPhone On 03.11.2012, at 21:06, Milton L Mueller wrote: > > > For example, on stock market no one publish who sold and who bought shares. I think for safety reason. > [Milton L Mueller] > One can pick a dozen other resources, ranging from acquisitions of companies to real estate transactions, where buyer and seller are documented. > Second, even with stock exchanges, trades made by ?insiders? are all documented, by name. > Third, ?safety reasons? dictate that resources held in rem are best recorded in a public exchange, so that it is more difficult to deceive anyone in the public as to who is the rightful owner of resources. > > What you need to do to make your argument convincing and meaningful, Alexey, is to explain what harm is done by publishing this information. > Tell me what ?safety? issues for example are raised by people knowing that a transaction took place? > > For analyse enought anonymous statistical information about transfers. > > -- > Alexey Ivanov > LeaderTelecom > > 29.10.2012 20:27 - Emilio Madaio ???????(?): > > > Dear Colleagues, > > The draft document for the version 2.0 of the proposal 2012-05 has > been published. The impact analysis that was conducted for this > proposal has also been published. > > > The main changes in the new version are: > > -use of a bullet point layout for the proposal text; > -anonymous reports of non-approved transfers. > > > You can find the full proposal and impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-05 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-05/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 12 November 2012. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon Nov 5 12:32:26 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 05 Nov 2012 11:32:26 +0000 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <50962F75.6060605@redpill-linpro.com> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> <50962F75.6060605@redpill-linpro.com> Message-ID: <5097A3CA.60607@inex.ie> On 04/11/2012 09:03, Tore Anderson wrote: > In light of that, it would seem that we do need to compel the NCC to > publish the information after all. Hence, I do support 2012-05. > > That said, if the NCC at a later point in the PDP starts publishing the > information voluntarily, I withdraw my support of the proposal and > instead object to it, on the grounds that it will be redundant and only > serve to further bloat the policy text. If the RIPE NCC feels that it's a matter of their interpretation as to whether they publish this information or not, then there is a clear requirement for having an explicit policy. I support this policy. Nick From ingrid at ripe.net Mon Nov 5 14:59:17 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 05 Nov 2012 14:59:17 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <509223CB.6070509@redpill-linpro.com> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> Message-ID: <5097C635.5090707@ripe.net> Dear Tore, Apologies for the late reply. >> However, given this proposal and the discussion around it, we would >> prefer to wait until it reaches a conclusion before publishing. > Okay. This surprises me a bit, though. The impact analysis seems to me > to state, essentially, ?we are willing to publish the requested > information without a clear policy mandate from the community?. > > However, your response seems to suggest the exact opposite, i.e., ?we > are NOT willing to publish the requested information without a policy > clear mandate from the community?. > > I don't believe anyone is proposing to *forbid* you from publishing > information on transfers, the way I see it, the question is simply > whether or not the community needs to compel you (through policy) to > publish it, or not. In my opinion, it would be much more preferable to > not have to take the policy route, since the terser and concise the > policy text is, the better it is. The community shouldn't need to > micro-manage the NCC through policy - it would be better and more > efficient if we could instead work directly with you to get what we want. > > But now I am not so sure on whether or not the added policy text is > required after all. Do you see any outcome of this proposal's discussion > that would cause you to not publish the requested information after all? Publishing the names of the few organisations that were involved in a transfer, in an ad-hoc manner on a public mailing list, seems premature since the discussion has not yet reached a conclusion, and some opposition has been voiced. As indicated in the impact analysis, the RIPE NCC can publish information regarding transfers on ftp.ripe.net with or without a policy but would inform the community and membership in advance. However, now that there is an ongoing policy proposal, we should wait for the outcome of that discussion before making any decision. [...] > > However, all the allocations mentioned above are listed with the > original date of allocation in both alloclist.txt and > delegated-ripencc-extended. I could not find a single transaction where > the date changed to the present day (except those blocks that went > through the "reserved" state, which I guess means returned to the NCC > and re-allocated normally). So while I won't ask you to confirm whether > or not any of the above transactions are indeed the transfer the Impact > Analysis refers to, I was wondering if you could tell whether or not the > date of the allocation will remain unchanged as a result of a transfer? > We have not updated the allocation date of the transfers that we have done so far. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC From emadaio at ripe.net Mon Nov 5 15:21:32 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 05 Nov 2012 15:21:32 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Last Call for Comments on Draft Document for Reverse Delegation Policy ripe-302 Message-ID: <5097CB6C.3080702@ripe.net> Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC published for community review the draft policy document ripe-302, "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region". Information on the Cosmetic Surgery Project and the draft policy document are available at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents The Last Call for Comments has ended. After the feedback received, a new draft (3.0) of the policy document is online and ready for community comments. The highlights of the changes in response of the community's request include: -use of the hyphen for "sub-domain". The Address Policy Working Group co-chairs decided to extend the Last Call period until 19 November 2012 to allow the community more time to give their feedback. We encourage you to read this new version. Please send any comments to address-policy-wg at ripe.net by 19 November 2012. Best Regards Emilio Madaio Policy Development Officer RIPE NCC From frettled at gmail.com Mon Nov 5 15:25:28 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 5 Nov 2012 15:25:28 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <5097C635.5090707@ripe.net> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> Message-ID: On Mon, Nov 5, 2012 at 2:59 PM, Ingrid Wijte wrote: > As indicated in the impact analysis, the RIPE NCC can publish information > regarding transfers on ftp.ripe.net with or without a policy but would > inform the community and membership in advance. However, now that there is > an ongoing policy proposal, we should wait for the outcome of that > discussion before making any decision. > So, in essence, you will not voluntarily publish this information unless you are compelled to do so? This seems slightly kafkaesque to me. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nihb at tdc.dk Mon Nov 5 15:22:24 2012 From: nihb at tdc.dk (Nina Hjorth Bargisen) Date: Mon, 5 Nov 2012 15:22:24 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: References: <508fe53b.c9cf0e0a.7c00.7f5dSMTPIN_ADDED@mx.google.com> Message-ID: <20121105142224.GB48701@freesbee.wheel.dk> I support this proposal. I see no need to discuss assignment vs allocation periods since the depletion prevents further allocations. I see this proposal as a way to bring back sense in the assignments that the LIRs are able to make from the address space they currently hold. Rgds Nina Bargisen TDC dk.teledanmark On 31.10.2012 15:50:21 +0200, George Giannousopoulos wrote: > Hello all, > > I agree that the three months limitation has to go.. > However, I also believe that the period for allocations and assignments > should be equal > > Best regards > > > On Tue, Oct 30, 2012 at 4:28 PM, Emilio Madaio wrote: > > > > > Dear Colleagues, > > > > > > The draft document for the version 2.0 of the policy proposal > > 2010-06,"Revert 'Run Out Fairly'" has been published. The impact > > analysis that was conducted for this proposal has also been published. > > > > The changes in the version 2.0 are in the Title, Summary and > > Rationale. They are purely editorial and reflect that the depletion is > > no longer a future event. > > > > > > > > You can find the full proposal at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > > > and the draft document at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-06/draft > > > > We encourage you to read the draft document text and send any comments > > to address-policy-wg at ripe.net before 27 November 2012. > > > > Regards > > > > Emilio Madaio > > Policy Development Officer > > RIPE NCC > > > > > > From tore.anderson at redpill-linpro.com Mon Nov 5 20:18:09 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 05 Nov 2012 20:18:09 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: References: <508fe53b.c9cf0e0a.7c00.7f5dSMTPIN_ADDED@mx.google.com> Message-ID: <509810F1.2050002@redpill-linpro.com> Hi George, * George Giannousopoulos > I agree that the three months limitation has to go.. > However, I also believe that the period for allocations and assignments > should be equal The period for allocation is only relevant for transfers nowadays, as the NCC does not issue needs-based allocations any longer. With that in mind, I'd like to point out that there is another active proposal - 2012-03 - that seeks to increase the transfer allocation period to 24 months, which is the same as the NCC's interpretation (according to the Impact Analysis) of what the new assignment period would be, if this proposal (2012-06) passes. http://www.ripe.net/ripe/policies/proposals/2012-03 In other words, it would seem that you can get both the things you want, by supporting both 2012-06 and 2012-03. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From info at leadertelecom.ru Tue Nov 6 08:52:12 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 6 Nov 2012 11:52:12 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> References: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> Message-ID: <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> Dear?Milton, > What you need to do to make your argument convincing and meaningful, Alexey, is to explain > what harm is done by publishing this information.? > Tell me what ?safety? issues for example are raised by people knowing that a transaction took place?? For Russia better don't open financial information about transfers, while criminal element will know who just received big amount of money and can e target for raiders. I think that we have to protect companies if we don't need to publish unnecessary information. Milton, why you will publish this information? What you will get from this statistic?? --? Alexey Ivanov 03.11.2012 21:32 - Dmitry Burkov ???????(?): ? Milton,? When in result your position can become so close to B.Flame dreams I can't agree with you. ? Sorry - you reminded me last discussions on Whois and last years talks about lea's expectations to minimize their spendings and to get centralized DBs with personal data on each Internet user or as it named in our country - ?personal authorization in Internet . ? Of course - you current talks seems are so far from this- ?but what's can be behind? I hope that you can understand that there are two side of one medal and the price of free market approach can be so high for us? ? Dima PS ? Sorry - it was not directly about disclosure info on transfers - it is a part of some of more general issues where this market is just a small part Sent from my iPhone On 03.11.2012, at 21:06, Milton L Mueller <[1]mueller at syr.edu> wrote: ? For example, on stock market no one publish who sold and who bought shares. I think for safety reason.? [Milton L Mueller] One can pick a dozen other resources, ranging from acquisitions of companies to real estate transactions, where buyer and seller are documented. Second, even with stock exchanges, trades made by ?insiders? are all documented, by name. Third, ?safety reasons? dictate that resources held in rem are best recorded in a public exchange, so that it is more difficult to deceive anyone in the public as to who is the rightful owner of resources. ? What you need to do to make your argument convincing and meaningful, Alexey, is to explain what harm is done by publishing this information. Tell me what ?safety? issues for example are raised by people knowing that a transaction took place? ? For analyse enought anonymous statistical information about transfers. --? Alexey Ivanov LeaderTelecom 29.10.2012 20:27 - Emilio Madaio ???????(?): Dear Colleagues, The draft document for the version 2.0 of the proposal 2012-05 has been published. The impact analysis that was conducted for this proposal has also been published. The main changes in the new version are: -use of a bullet point layout for the proposal text; -anonymous reports of non-approved transfers. You can find the full proposal and impact analysis at: ????[2]https://www.ripe.net/ripe/policies/proposals/2012-05 ???? and the draft document at: ????[3]https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to [4]address-policy-wg at ripe.net before 12 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC [1] mailto:mueller at syr.edu [2] https://www.ripe.net/ripe/policies/proposals/2012-05 [3] https://www.ripe.net/ripe/policies/proposals/2012-05/draft [4] mailto:address-policy-wg at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Tue Nov 6 09:59:45 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 06 Nov 2012 09:59:45 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> References: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> Message-ID: <5098D181.1050209@redpill-linpro.com> * LeaderTelecom Ltd. > For Russia better don't open financial information about transfers, > while criminal element will know who just received big amount of > money and can e target for raiders. I think that we have to protect > companies if we don't need to publish unnecessary information. Alexey, The proposal does not seek to have any financial information relating to transfers published. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From info at leadertelecom.ru Tue Nov 6 10:03:19 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 6 Nov 2012 13:03:19 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <5098D181.1050209@redpill-linpro.com> References: <5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> Message-ID: <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> Dear?Tore, 1 IP address transfers for 10-20USD. Just multiple count of IP x 15 USD. -- Alexey 06.11.2012 13:00 - Tore Anderson ???????(?): * LeaderTelecom Ltd. > For Russia better don't open financial information about transfers, > while criminal element will know who just received big amount of > money and can e target for raiders. I think that we have to protect > companies if we don't need to publish unnecessary information. Alexey, The proposal does not seek to have any financial information relating to transfers published. -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com [1] http://www.redpill-linpro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Tue Nov 6 10:34:04 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 06 Nov 2012 10:34:04 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> References: <5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> Message-ID: <5098D98C.40100@redpill-linpro.com> * LeaderTelecom Ltd. > 1 IP address transfers for 10-20USD. Just multiple count of IP x 15 USD. The size of the monetary compensation (if any) is likely to be confidential between the parties. There's no IPv4 stock exchange where everyone can can see the buying and selling prices. As there has been only very few transactions in the RIPE region to date, I don't think you can so easily conclude that US$15 is the market price everyone will end up paying. The proposal only seeks to document a transfer has happened, not any prices paid (it is doubtful that the NCC is privy to this information in any case). This is in keeping with the "Registration" goal of the internet registry system (see ripe-553 section 3.0). It is in any case already possible to determine that there has been an IPv4 address transaction between two LIRs by, as Alex Le Heux pointed out earlier, comparing different versions of the files available on ftp.ripe.net. It's more cumbersome than the reading neat list requested by this proposal, but it's certainly something the Russian mafia has enough technical talent to do, if they want to. (It took me something like 10 minutes.) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From info at leadertelecom.ru Tue Nov 6 10:40:04 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 6 Nov 2012 13:40:04 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <5098D98C.40100@redpill-linpro.com> References: <5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> Message-ID: <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> Dear Tore, > It is in any case already possible to determine that there has been an > IPv4 address transaction between two LIRs by, as Alex Le Heux pointed > out earlier, comparing different versions of the files available on >?[1]ftp://ftp.ripe.net. It's more cumbersome than the reading neat list requested > by this proposal, but it's certainly something the Russian mafia has > enough technical talent to do, if they want to. (It took me something > like 10 minutes.) It is too difficult to analyse, while you need to do it systematically and it can be just changes names of company or transfer. ? --? Alexey 06.11.2012 13:34 - Tore Anderson ???????(?): * LeaderTelecom Ltd. > 1 IP address transfers for 10-20USD. Just multiple count of IP x 15 USD. The size of the monetary compensation (if any) is likely to be confidential between the parties. There's no IPv4 stock exchange where everyone can can see the buying and selling prices. As there has been only very few transactions in the RIPE region to date, I don't think you can so easily conclude that US$15 is the market price everyone will end up paying. The proposal only seeks to document a transfer has happened, not any prices paid (it is doubtful that the NCC is privy to this information in any case). This is in keeping with the "Registration" goal of the internet registry system (see ripe-553 section 3.0). It is in any case already possible to determine that there has been an IPv4 address transaction between two LIRs by, as Alex Le Heux pointed out earlier, comparing different versions of the files available on [2]ftp://ftp.ripe.net. It's more cumbersome than the reading neat list requested by this proposal, but it's certainly something the Russian mafia has enough technical talent to do, if they want to. (It took me something like 10 minutes.) -- Tore Anderson Redpill Linpro AS - [3]http://www.redpill-linpro.com [1] ftp://ftp.ripe.net [2] ftp://ftp.ripe.net [3] http://www.redpill-linpro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Tue Nov 6 10:59:46 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 09:59:46 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> References: <5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> Message-ID: <5098DF92.8000709@inex.ie> On 06/11/2012 09:40, LeaderTelecom Ltd. wrote: > It is too difficult to analyse, while you need to do it systematically and > it can be just changes names of company or transfer. No, it takes 10-15 lines of perl. It's ridiculously simple to analyse and as Tore said, it takes no more than a couple of minutes to write. In fact, I've just written some perl to analyse this. Usage is: % v4-transfer.pl < alloclist.txt This will tell you how much address space has been allocated to each LIR. If you do this daily and run the "diff" command, or feed this into a database, you can see exactly who has lost or gained address space. Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: v4-transfer.pl Type: text/x-perl-script Size: 325 bytes Desc: not available URL: From dez at otenet.gr Tue Nov 6 11:20:24 2012 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Tue, 06 Nov 2012 12:20:24 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 Message-ID: <5098E468.1010708@otenet.gr> *Sander Steffann*wrote/@ Wed Oct 3 15:17:43 CEST 2012/: Hello Marcin, >/ I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? / You can find the status here:http://www.ripe.net/ripe/policies/proposals/2012-04 The policy proposal is in the review phase and under discussion until the 8th of October. Sander Steffann APWG co-chair I'm a little lost too. Are we waiting until RIPE66 or was there supposed to be an update on that? regards, Yannis -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Tue Nov 6 11:46:38 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 10:46:38 +0000 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <5098E468.1010708@otenet.gr> References: <5098E468.1010708@otenet.gr> Message-ID: <5098EA8E.6080306@inex.ie> On 06/11/2012 10:20, Yannis Nikolopoulos wrote: > *Sander Steffann*wrote/@ > Wed Oct 3 15:17:43 CEST 2012/: > > Hello Marcin, > >> / I'am lost a little bit, what is the current status of policy, that >> would allow single /24 PI IPv4 assignment from the last /8 ??? > / > You can find the status here: http://www.ripe.net/ripe/policies/proposals/2012-04 > The policy proposal is in the review phase and under discussion until the 8th of October. > > Sander Steffann > APWG co-chair > > I'm a little lost too. Are we waiting until RIPE66 or was there supposed to > be an update on that? Yannis, It was clear from the discussion at RIPE65 that there was no consensus in favour of the existing proposal. As author of the proposal, I intend to leave the proposal sit for a short period (maybe a couple of months) before resuming work on it. I think as a community, we need the benefit of some hindsight in terms of figuring out what's best in terms of overall policy. Nick From info at leadertelecom.ru Tue Nov 6 13:03:51 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 6 Nov 2012 16:03:51 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <5098DF92.8000709@inex.ie> References: <5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> Message-ID: <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Dear?Nick, How are you going to know did company changed name or IPs were transfered? -- Alexey 06.11.2012 14:00 - Nick Hilliard ???????(?): On 06/11/2012 09:40, LeaderTelecom Ltd. wrote: > It is too difficult to analyse, while you need to do it systematically and > it can be just changes names of company or transfer. No, it takes 10-15 lines of perl.??It's ridiculously simple to analyse and as Tore said, it takes no more than a couple of minutes to write. In fact, I've just written some perl to analyse this.??Usage is: % v4-transfer.pl < alloclist.txt This will tell you how much address space has been allocated to each LIR. If you do this daily and run the "diff" command, or feed this into a database, you can see exactly who has lost or gained address space. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Tue Nov 6 13:17:21 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 6 Nov 2012 13:17:21 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> References: <5098D98C.40100@redpill-linpro.com> <5098D181.1050209@redpill-linpro.com> <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <5098DF92.8000709@inex.ie> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Message-ID: On Tue, Nov 6, 2012 at 1:03 PM, LeaderTelecom Ltd. wrote: > Dear Nick, > > How are you going to know did company changed name or IPs were transfered? > If I understand the service agreement correctly, a name change also requires a new service agreement for the LIR in question. As you yourself can see from alloclist.txt, there is only the name identifying the organisation. As I understand the proposal, there would not be any new information added, so we still will not be able to see whether a LIR merely changed names or there was more going on, except when something is transfered from one existing LIR to another existing LIR. What is being requested is not a matter of getting information that we are not already getting, it is a matter of providing the same information in a more transparent manner. But that is, again, as I understand it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Tue Nov 6 13:27:07 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 06 Nov 2012 13:27:07 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> References: <5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Message-ID: <5099021B.1030705@redpill-linpro.com> * LeaderTelecom Ltd. > How are you going to know did company changed name or IPs were > transfered? Based on your earlier argument, shouldn't the question instead be: How will the Russian mafia know? I'm neither Russian nor a wiseguy, but really - I cannot bring myself to believe that they would have any problem whatsoever figuring out whether an LIR has changed its name or not before proceeding with shaking it down. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From info at leadertelecom.ru Tue Nov 6 13:32:59 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 6 Nov 2012 16:32:59 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <5099021B.1030705@redpill-linpro.com> References: <5099021B.1030705@redpill-linpro.com><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Message-ID: <1352205178.877006.24663188.256146.2@otrs.hostingconsult.ru> Dear?Tore, In general it is possible to find any information about any company. The more difficult information about transfers - then more safe for ISP.? But anyway - if this information will be open - what you can find? Why you are intrested in this information? If you need any summary statistic - I think RIPE will publish it anyway - we (as community) can tell that we need. In this case you don't need to check each transfer. Tore, what do you think? -- Alexey Ivanov ? 06.11.2012 16:27 - Tore Anderson ???????(?): * LeaderTelecom Ltd. > How are you going to know did company changed name or IPs were > transfered? Based on your earlier argument, shouldn't the question instead be: How will the Russian mafia know? I'm neither Russian nor a wiseguy, but really - I cannot bring myself to believe that they would have any problem whatsoever figuring out whether an LIR has changed its name or not before proceeding with shaking it down. -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com/ [1] http://www.redpill-linpro.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Tue Nov 6 13:41:40 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 12:41:40 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> References: <5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Message-ID: <50990584.5050503@inex.ie> On 06/11/2012 12:03, LeaderTelecom Ltd. wrote: > How are you going to know did company changed name or IPs were transfered? Alexey, the LIR ID stays the same, regardless of the legal name of the company. You've said that your concern is that other people will know which IP addresses have been transferred. The code I included shows which LIR ID loses or gains IP addresses, and according to what you said earlier: > criminal element will know who just received big amount of money and can > be target for raiders. ... the code I posted will identify exactly which LIR have recently lost or gained IP addresses, because you can look up the LIR details here: https://www.ripe.net/membership/indices/ So you can use my code to see exactly which LIR has lost IP addresses or gained them. It's really easy to track this. Here's a database schema for holding the information: CREATE TABLE `ipv4quantities` ( `id` int unsigned NOT NULL, `regid` varchar(255) NOT NULL, `numberofaddresses` int unsigned NOT NULL default 0, `thedate` date NOT NULL, PRIMARY KEY (`id`) ); Will I write another couple of lines of code and hook up v4-transfer.pl into this database schema? And another 10 lines of code to provide a web front end? If you want, I'll write another couple of lines on top of that, with another two database tables, and that can be used to provide a complete historical list of exactly what addresses are held by any LIR, along with sortable columns so you can see what IP address space was transferred, and when. But it turns out that most of this is unnecessary, because it's already being done here: https://stat.ripe.net/ In other words the information proposed in this policy is already available in multiple formats from multiple areas of the RIPE NCC web site / database / ftp site, and extracting this information is simple enough for a school child to do. Let me repeat: ######################################################################## ## ## ## Getting this information is so simple that even a child can do it. ## ## ## ######################################################################## Please drop your objection. It's completely ridiculous. Nick From ggiannou at gmail.com Tue Nov 6 17:10:22 2012 From: ggiannou at gmail.com (George Giannousopoulos) Date: Tue, 6 Nov 2012 18:10:22 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <5098EA8E.6080306@inex.ie> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> Message-ID: Nick, I'm not sure that leaving the policy sit is a good idea We already have customers asking for PI space and all we can tell them is to wait. Seeing the "Awaiting Decision from Working Group Chair" on the proposal page, we hoped for a decision soon. Should we advice them to become LIRs instead of waiting for a policy change? George On Tue, Nov 6, 2012 at 12:46 PM, Nick Hilliard wrote: > On 06/11/2012 10:20, Yannis Nikolopoulos wrote: > > *Sander Steffann*wrote ?Subject=Re:%20%5Baddress-policy-wg%5D%20Status%20of%20/24%20PI%20IPv4%20from%20last%20/8&In-Reply-To=%3CA3853826-7A62-4EE4-94D6-EBF1A6F5AE88% > 40steffann.nl%3E>/@ > > Wed Oct 3 15:17:43 CEST 2012/: > > > > Hello Marcin, > > > >> / I'am lost a little bit, what is the current status of policy, that > >> would allow single /24 PI IPv4 assignment from the last /8 ??? > > / > > You can find the status here: > http://www.ripe.net/ripe/policies/proposals/2012-04 > > The policy proposal is in the review phase and under discussion until > the 8th of October. > > > > Sander Steffann > > APWG co-chair > > > > I'm a little lost too. Are we waiting until RIPE66 or was there supposed > to > > be an update on that? > > Yannis, > > It was clear from the discussion at RIPE65 that there was no consensus in > favour of the existing proposal. As author of the proposal, I intend to > leave the proposal sit for a short period (maybe a couple of months) before > resuming work on it. I think as a community, we need the benefit of some > hindsight in terms of figuring out what's best in terms of overall policy. > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Nov 6 17:12:11 2012 From: gert at space.net (Gert Doering) Date: Tue, 6 Nov 2012 17:12:11 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> Message-ID: <20121106161211.GS13776@Space.Net> Hi, On Tue, Nov 06, 2012 at 06:10:22PM +0200, George Giannousopoulos wrote: > I'm not sure that leaving the policy sit is a good idea > We already have customers asking for PI space and all we can tell them is > to wait. > > Seeing the "Awaiting Decision from Working Group Chair" on the proposal > page, we hoped for a decision soon. > Should we advice them to become LIRs instead of waiting for a policy change? IPv6 comes to mind. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tore.anderson at redpill-linpro.com Tue Nov 6 17:32:51 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 06 Nov 2012 17:32:51 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> Message-ID: <50993BB3.3090605@redpill-linpro.com> * George Giannousopoulos > I'm not sure that leaving the policy sit is a good idea > We already have customers asking for PI space and all we can tell > them is to wait. > > Seeing the "Awaiting Decision from Working Group Chair" on the > proposal page, we hoped for a decision soon. > Should we advice them to become LIRs instead of waiting for a policy > change? Yes. 2012-03 won't pass soon, and there is no guarantee that it ever will. Judging by the discussion it stirred up at the last RIPE meeting, I believe it has rather slim chances of reaching consensus. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From nick at inex.ie Tue Nov 6 17:48:40 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 16:48:40 +0000 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <50993BB3.3090605@redpill-linpro.com> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> Message-ID: <50993F68.1000308@inex.ie> On 06/11/2012 16:32, Tore Anderson wrote: > 2012-03[*] won't pass soon, and there is no guarantee that it ever will. > Judging by the discussion it stirred up at the last RIPE meeting, I > believe it has rather slim chances of reaching consensus. I don't think it's all doom and gloom, btw. The comments both on the mailing list and at the APWG session fell into a couple of different categories: - yes - no, but would support after 185.0.0.0/8 is exhausted - no, but would support if potential abuse could be reduced - no, under no circumstances What's clear is that there is no consensus on the current proposal. But I think that it may be possible to satisfy many of the concerns of the people who objected if the proposal were modified to e.g. reduce the possibility of potential abusers, or maybe make it applicable only to reclaimed address space and not 185.0.0.0/8. Nick [*] 2012-04 From sander at steffann.nl Tue Nov 6 18:27:16 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 6 Nov 2012 18:27:16 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352205178.877006.24663188.256146.2@otrs.hostingconsult.ru> References: <5099021B.1030705@redpill-linpro.com><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352205178.877006.24663188.256146.2@otrs.hostingconsult.ru> Message-ID: <7431C876-13F8-4E40-B103-9F01280551C0@steffann.nl> Hi, > In general it is possible to find any information about any company. The more difficult information about transfers - then more safe for ISP. Hmmmm. This sounds like a case of security-by-obscurity to me... Sander From jan at go6.si Tue Nov 6 18:51:09 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 06 Nov 2012 18:51:09 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> Message-ID: <50994E0D.9000604@go6.si> On 11/6/12 5:10 PM, George Giannousopoulos wrote: > We already have customers asking for PI space and all we can tell them > is to wait. tell them "no" or put them in endless wait loop ;) if/when policy changes, take them out of the loop. reality.press Cheers, Jan From farmer at umn.edu Tue Nov 6 18:52:20 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 06 Nov 2012 11:52:20 -0600 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <50993F68.1000308@inex.ie> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> Message-ID: <50994E54.4030703@umn.edu> On 11/6/12 10:48 , Nick Hilliard wrote: > On 06/11/2012 16:32, Tore Anderson wrote: >> 2012-03[*] won't pass soon, and there is no guarantee that it ever will. >> Judging by the discussion it stirred up at the last RIPE meeting, I >> believe it has rather slim chances of reaching consensus. > > I don't think it's all doom and gloom, btw. The comments both on the > mailing list and at the APWG session fell into a couple of different > categories: > > - yes > - no, but would support after 185.0.0.0/8 is exhausted > - no, but would support if potential abuse could be reduced > - no, under no circumstances > > What's clear is that there is no consensus on the current proposal. But I > think that it may be possible to satisfy many of the concerns of the people > who objected if the proposal were modified to e.g. reduce the possibility > of potential abusers, or maybe make it applicable only to reclaimed address > space and not 185.0.0.0/8. As currently written GPP-IPv4-2011 (AKA RIPE-2011-01) says "The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space." So it may be some time before reclaimed address are available to be issued as PI, if you follow the suggested approach. I'm not completely familiar with the nuances of RIPE's policies, but is it possible for organizations that want PI to get it from the transfer market under RIPE's current policies? If not then that probably needs to be fixed ASAP, they probably shouldn't be shutout of both the last /8 and the transfer market. This was brought up in the discussion of 2012-02, but I don't know if it has been resolved to allow PI through transfers, and in particular inter-RIR transfers. I have no opinion on this policy, as I do not receive resources within the RIPE region. But, I will say I think it is important for end user organizations in the RIPE region to have a viable way to get IPv4 resources, be it from the last /8 or via transfers. I think it is highly problematic if there isn't some mechanism that provides for continued PI resource availability. Thanks -- ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================= From nick at inex.ie Tue Nov 6 18:53:45 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 17:53:45 +0000 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <50994E54.4030703@umn.edu> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> Message-ID: <50994EA9.1070305@inex.ie> On 06/11/2012 17:52, David Farmer wrote: > I think it is highly problematic if there isn't some mechanism that > provides for continued PI resource availability. I agree. Nick From tore.anderson at redpill-linpro.com Tue Nov 6 19:35:06 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 06 Nov 2012 19:35:06 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <50993F68.1000308@inex.ie> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> Message-ID: <5099585A.4070701@redpill-linpro.com> * Nick Hilliard > On 06/11/2012 16:32, Tore Anderson wrote: >> 2012-03[*] won't pass soon, and there is no guarantee that it ever will. >> Judging by the discussion it stirred up at the last RIPE meeting, I >> believe it has rather slim chances of reaching consensus. > > I don't think it's all doom and gloom, btw. True. I didn't mean to suggest that this propsal, if amended, could not reach consensus at some point in the future. My main message was that telling one's customers to sit around and wait for that to happen is really bad advice, unless it comes with a big fat warning that the waiting period may be very long, possibly even infinite. If the customer absolutely must acquire multihomable IPv4 address space, becoming an LIR is currently the only way that is certain to succeed in a reasonable time frame. That's what I tell my customers, anyway. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From nick at inex.ie Tue Nov 6 20:05:07 2012 From: nick at inex.ie (Nick Hilliard) Date: Tue, 06 Nov 2012 19:05:07 +0000 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <5099585A.4070701@redpill-linpro.com> References: <5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <5099585A.4070701@redpill-linpro.com> Message-ID: <50995F63.4050308@inex.ie> On 06/11/2012 18:35, Tore Anderson wrote: > True. I didn't mean to suggest that this propsal, if amended, could not > reach consensus at some point in the future. My main message was that > telling one's customers to sit around and wait for that to happen is > really bad advice, unless it comes with a big fat warning that the > waiting period may be very long, possibly even infinite. There's no "may" about it. The waiting period _will_ be long. 2012-04 will have to go back to initial discussion phase, and the journey from there to policy takes a minimum of 19 weeks. That's assuming it's all plain sailing. Nick From lists-ripe at c4inet.net Tue Nov 6 21:53:07 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 6 Nov 2012 20:53:07 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <7431C876-13F8-4E40-B103-9F01280551C0@steffann.nl> References: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352205178.877006.24663188.256146.2@otrs.hostingconsult.ru> <7431C876-13F8-4E40-B103-9F01280551C0@steffann.nl> Message-ID: <20121106205307.GA26837@cilantro.c4inet.net> On Tue, Nov 06, 2012 at 06:27:16PM +0100, Sander Steffann wrote: >Hmmmm. This sounds like a case of security-by-obscurity to me... It is. Security-by-obscurity is not as useless as it is often portrayed. As Gen. Westmoreland said: "If you can see it, you can hit it. If you can hit it, you can kill it". The reverse is also true: If you don't know it is there, you *can't* hit it... I reckon, if the ripedb was proposed today there is no way it would find consensus - it *is* dangerous these days to have to lay open, to absolutely everyone with a web browser, all your business relationships. Perhaps a re-think of exactly who can see how much of your data is way past due. Another question is, whether this discussion doesn't actually belong in the Services WG... Regards, Sascha Luck From info at leadertelecom.ru Wed Nov 7 09:29:55 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 12:29:55 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <50994EA9.1070305@inex.ie> References: <50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> Message-ID: <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> Forget about PIv4. It is deprecated and we don't need it for now. --? Alexey Ivanov 06.11.2012 21:54 - Nick Hilliard ???????(?): On 06/11/2012 17:52, David Farmer wrote: > I think it is highly problematic if there isn't some mechanism that > provides for continued PI resource availability. I agree. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 11:23:59 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 10:23:59 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> References: <50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> Message-ID: <509A36BF.1050003@inex.ie> On 07/11/2012 08:29, LeaderTelecom Ltd. wrote: > Forget about PIv4. It is deprecated and we don't need it for now. You may not need it, but there are a lot of other end users in the RIPE service area who disagree and feel that they need it very badly. Nick From info at leadertelecom.ru Wed Nov 7 11:38:12 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 14:38:12 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A36BF.1050003@inex.ie> References: <509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> Message-ID: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> Why not continue give PA-addresses in this case? Many customers need them too. We have to be consistent: 1. Continue distribute last /8 for PA & PI. OR 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 IPs from last /8). I think second option is more optimal, while some defficit and increasing prices for IPv4 allow customers run IPv6 faster.? p.s. Who will PI-addresses? Why they can't rent them or start use IPv6? --? Alexey Ivanov 07.11.2012 14:24 - Nick Hilliard ???????(?): On 07/11/2012 08:29, LeaderTelecom Ltd. wrote: > Forget about PIv4. It is deprecated and we don't need it for now. You may not need it, but there are a lot of other end users in the RIPE service area who disagree and feel that they need it very badly. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 12:29:07 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 11:29:07 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> References: <509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> Message-ID: <509A4603.8050105@inex.ie> On 07/11/2012 10:38, LeaderTelecom Ltd. wrote: > Why not continue give PA-addresses in this case? Many customers need them too. Because you can't multihome PA addresses. > We have to be consistent: > 1. Continue distribute last /8 for PA & PI. > OR > 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 > IPs from last /8). > > I think second option is more optimal, while some defficit and increasing > prices for IPv4 allow customers run IPv6 faster. > > p.s. Who will PI-addresses? Why they can't rent them or start use IPv6? They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment. Nick From jan at go6.si Wed Nov 7 12:36:02 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 07 Nov 2012 12:36:02 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A4603.8050105@inex.ie> References: <509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> Message-ID: <509A47A2.2040002@go6.si> On 11/7/12 12:29 PM, Nick Hilliard wrote: >> p.s. Who will PI-addresses? Why they can't rent them or start use >> IPv6? > > They can't rent them because the renting market has not yet > developed, and they can't use ipv6 because it's not usable at the > moment. So, they are stuck (all of a sudden, what a surprise). Another option is to start working on IPv6 solutions so the whole thing becomes usable for them - whatever that might be and whatever efforts that may include ;) At some point this really needs to end. Cheers, Jan From jan at go6.si Wed Nov 7 12:53:27 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 07 Nov 2012 12:53:27 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... Message-ID: <509A4BB7.4020607@go6.si> Dear AP-WG ;) Some time ago we come to a consensus to change the IPv6 initial allocation rules and extend the initial allocation size from /32 to whatever between /32 and /29 without additional justification needed. One of the reasons to do that was a reserved space of /29 for each previously allocated /32 and general thinking was "let them use that space that no one else will probably ever use it as it is reserved for holder of /32 at the start of that /29" So far so good, many of you requested the extension to /29 and most of you got it with no issues. But not all of you. We encountered LIRs that are operators and in the past they bought other small operators and joined for example 3 LIRs under one and now they have 3 x /32 (of course with that /29 as reserved space). When those LIRs asked for extension to /29 they received a response from IPRAs, that they can extend to /29 *in total* as written in the policy. The policy says: "LIRs that hold one or more IPv6 allocations are able to request extension of these allocations up to a *total* of a /29 without providing further documentation." So an LIR can extend as many allocations as they want, as long as they never end up with more than a /29 *total* 3x/32 can be extended into 1x/30 + 2x/31 = /29 Alternatively, one /32 can be returned, then both remaining /32s can be extended to a /30. When we were preparing the policy change proposal we did not read that word *total* through the "multiple LIR/32" eyes and I feel that we should somehow correct this. New suggested text would be: "LIRs that hold one or more IPv6 allocations are able to request extension of *each* these allocations up to a /29 without providing further documentation." With this email I would like to check if community thinks we should go that route and draft the policy change proposal? Is this something that nobody cares and should not be fixed? Is this a threat to someone? Anyone sees any danger in going forward with this small change? Thank you very much, Jan Zorz From nick at inex.ie Wed Nov 7 13:03:36 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 12:03:36 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A47A2.2040002@go6.si> References: <509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> Message-ID: <509A4E18.9070008@inex.ie> On 07/11/2012 11:36, Jan Zorz @ go6.si wrote: > So, they are stuck (all of a sudden, what a surprise). > > Another option is to start working on IPv6 solutions so the whole thing > becomes usable for them - whatever that might be and whatever efforts that > may include ;) > > At some point this really needs to end. I agree but we haven't reached that point yet, and as long as these two graphs: https://www.inex.ie/noncms/img/inex-lan1-ipv6-20121107.png https://www.inex.ie/noncms/img/inex-lan1-ipv4-20121107.png ... differ from each other by a factor of 1000, it's unrealistic to say that: - ipv6 is a viable alternative to IPv4 right now - ipv4 is deprecated / legacy / historic / whatever I know that you're not saying this, but other people on this mailing list are. Don't get me wrong either: I'd love to see much more ipv6 penetration and wider deployment, but we are where we are and we need to deal with policies which are relevant to people today. Incidentally, if you strip out the top 10% of the v6 talkers from those graphs above, the ipv6 graph drops by two orders of magnitude. :-| Nick From gert at space.net Wed Nov 7 13:13:38 2012 From: gert at space.net (Gert Doering) Date: Wed, 7 Nov 2012 13:13:38 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A4E18.9070008@inex.ie> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> Message-ID: <20121107121338.GA13776@Space.Net> Hi, On Wed, Nov 07, 2012 at 12:03:36PM +0000, Nick Hilliard wrote: > On 07/11/2012 11:36, Jan Zorz @ go6.si wrote: > > So, they are stuck (all of a sudden, what a surprise). > > > > Another option is to start working on IPv6 solutions so the whole thing > > becomes usable for them - whatever that might be and whatever efforts that > > may include ;) > > > > At some point this really needs to end. > > I agree but we haven't reached that point yet, and as long as these two graphs: > > https://www.inex.ie/noncms/img/inex-lan1-ipv6-20121107.png > https://www.inex.ie/noncms/img/inex-lan1-ipv4-20121107.png > > ... differ from each other by a factor of 1000, it's unrealistic to say that: > > - ipv6 is a viable alternative to IPv4 right now > - ipv4 is deprecated / legacy / historic / whatever Actually, looking at traffic graphs is misleading at best. These show whether big telcos that have sat on their huge IPv6 allocations for a long time finally get around to IPv6-enable their customers (or continue stalling), but do not really say anything about the *usability* of IPv6 for Joe Average User. Since the context of this discussion is "WE MUST HAVE IPv4 PI!!!", this statement might need some adjustment to "there is no IPv4 PI, can we do something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"... These seem much more relevant questions to me than "can we look around in the decks below the water line for additional deck chairs?". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nick at inex.ie Wed Nov 7 13:22:42 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 12:22:42 +0000 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509A4BB7.4020607@go6.si> References: <509A4BB7.4020607@go6.si> Message-ID: <509A5292.3080801@inex.ie> On 07/11/2012 11:53, Jan Zorz @ go6.si wrote: > Is this something that nobody cares and should not be fixed? Is this a > threat to someone? Anyone sees any danger in going forward with this small > change? To give some background data on this, I figure this affects 55 LIRs out of 4587 which have ipv6 allocations. Of these, 44 LIRs have exactly 2 x 32. The distribution for the rest is: > /32 /32 /30 /27 > /32 /32 /32 > /32 /32 /32 > /32 /32 /32 > /32 /32 /32 /32 > /32 /32 /32 /32 > /32 /32 /32 /32 > /32 /32 /32 /32 > /32 /32 /32 /32 /32 > /32 /32 /32 /32 /32 > /32 /32 /32 /32 /32 /32 /32 /32 /32 /30 Nick From nick at inex.ie Wed Nov 7 13:54:13 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 12:54:13 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107121338.GA13776@Space.Net> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> Message-ID: <509A59F5.5080500@inex.ie> On 07/11/2012 12:13, Gert Doering wrote: > Actually, looking at traffic graphs is misleading at best. These show > whether big telcos that have sat on their huge IPv6 allocations for > a long time finally get around to IPv6-enable their customers (or > continue stalling), but do not really say anything about the *usability* > of IPv6 for Joe Average User. Usability is one thing: in general where native ipv6 is provided, it mostly works fine and most problems aren't related to the access layer. But as you correctly point out, it's simply not available for most end users. > Since the context of this discussion is "WE MUST HAVE IPv4 PI!!!", this Please don't be dismissive about this discussion. There is a serious issue here relating to availability of a resource which provides significant benefit to many people and organisations in the RIPE service region. > statement might need some adjustment to "there is no IPv4 PI, can we do > something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or > "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"... > > These seem much more relevant questions to me than "can we look around > in the decks below the water line for additional deck chairs?". It's less of a deck-chair discussion and more of a discussion about life-boat seats - the relevant point being that there is a small quantity of seats left and the crew/operators have bagged the lot for themselves, leaving the passengers stranded on a sinking ship. Now one way or another that ship will sink and we all know it, but in the interim it is unreasonable to expect that end users who want PI are going to be happy about the situation. Nick From gert at space.net Wed Nov 7 13:58:47 2012 From: gert at space.net (Gert Doering) Date: Wed, 7 Nov 2012 13:58:47 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A59F5.5080500@inex.ie> References: <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> Message-ID: <20121107125847.GC13776@Space.Net> Hi, On Wed, Nov 07, 2012 at 12:54:13PM +0000, Nick Hilliard wrote: > Now one way or another that ship will sink and we all know it, but in the > interim it is unreasonable to expect that end users who want PI are going > to be happy about the situation. Anybody who relies on availability of "more IPv4 addresses" for their future business planning is going to be quite unhappy. Should that be a reason to discuss IPv4, or discuss alternatives? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From lir at elisa.fi Wed Nov 7 14:18:38 2012 From: lir at elisa.fi (lir at elisa.fi) Date: Wed, 7 Nov 2012 15:18:38 +0200 (EET) Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509A4BB7.4020607@go6.si> References: <509A4BB7.4020607@go6.si> Message-ID: Hi, I fully support this (proposal), in some cases it may make the routing table a little bit smaller... Rgds Ray On Wed, 7 Nov 2012, Jan Zorz @ go6.si wrote: > Date: Wed, 07 Nov 2012 12:53:27 +0100 > From: "Jan Zorz @ go6.si" > To: "address-policy-wg at ripe.net" > Subject: [address-policy-wg] Another small IPv6 allocation policy change > proposal (sanity check email)... > > Dear AP-WG ;) > > Some time ago we come to a consensus to change the IPv6 initial allocation > rules and extend the initial allocation size from /32 to whatever between /32 > and /29 without additional justification needed. > > One of the reasons to do that was a reserved space of /29 for each previously > allocated /32 and general thinking was "let them use that space that no one > else will probably ever use it as it is reserved for holder of /32 at the > start of that /29" > > So far so good, many of you requested the extension to /29 and most of you > got it with no issues. But not all of you. > > We encountered LIRs that are operators and in the past they bought other > small operators and joined for example 3 LIRs under one and now they have 3 x > /32 (of course with that /29 as reserved space). > > When those LIRs asked for extension to /29 they received a response from > IPRAs, that they can extend to /29 *in total* as written in the policy. > > The policy says: > > "LIRs that hold one or more IPv6 allocations are able to request extension of > these allocations up to a *total* of a /29 without providing further > documentation." > > So an LIR can extend as many allocations as they want, as long as they never > end up with more than a /29 *total* > > 3x/32 can be extended into 1x/30 + 2x/31 = /29 > > Alternatively, one /32 can be returned, then both remaining /32s can be > extended to a /30. > > When we were preparing the policy change proposal we did not read that word > *total* through the "multiple LIR/32" eyes and I feel that we should somehow > correct this. > > New suggested text would be: > > "LIRs that hold one or more IPv6 allocations are able to request > extension of *each* these allocations up to a /29 without providing further > documentation." > > With this email I would like to check if community thinks we should go that > route and draft the policy change proposal? > > Is this something that nobody cares and should not be fixed? Is this a threat > to someone? Anyone sees any danger in going forward with this small change? > > Thank you very much, Jan Zorz > > > -- ************************************************************ Raymond Jetten ??? Phone: +358 3 41024 139 Senior System Specialist Fax: +358 3 41024 199 Elisa Oyj / Network Management Mobile: +358 45 6700 139 Hermiankatu 3A?? ?????????? raymond.jetten at elisa.fi FIN-33720, TAMPERE????????? http://www.elisa.fi ************************************************************ From ingrid at ripe.net Wed Nov 7 14:29:53 2012 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 07 Nov 2012 14:29:53 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> Message-ID: <509A6251.9030509@ripe.net> Dear Jan, Just to clarify our position a bit here. We are willing and able to publish the information. But the fact remains that there is now a policy proposal being discussed in the community that specifically deals with making this information publicly available. It doesn't make much sense for us to go ahead and publish the information in a different format before we know the outcome of the policy proposal. Regards, Ingrid Wijte Registration Services Assistant manager RIPE NCC On 11/5/12 3:25 PM, Jan Ingvoldstad wrote: > On Mon, Nov 5, 2012 at 2:59 PM, Ingrid Wijte > wrote: > > As indicated in the impact analysis, the RIPE NCC can publish > information regarding transfers on ftp.ripe.net > with or without a policy but would inform > the community and membership in advance. However, now that there > is an ongoing policy proposal, we should wait for the outcome of > that discussion before making any decision. > > > So, in essence, you will not voluntarily publish this information > unless you are compelled to do so? > > This seems slightly kafkaesque to me. > > -- > Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Wed Nov 7 14:34:06 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 17:34:06 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A4603.8050105@inex.ie> References: <509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> Message-ID: <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> > > Why not continue give PA-addresses in this case? Many customers need them too. > Because you can't multihome PA addresses. /24 PA works excelent for?multihome. I have a lot examples. > They can't rent them because the renting market has not yet developed, and > they can't use ipv6 because it's not usable at the moment. Just send me contacts and I'll help them. I mean IPv4 PA. It is not a problem at all. --? Alexey Ivanov 07.11.2012 15:29 - Nick Hilliard ???????(?): On 07/11/2012 10:38, LeaderTelecom Ltd. wrote: > Why not continue give PA-addresses in this case? Many customers need them too. Because you can't multihome PA addresses. > We have to be consistent: > 1. Continue distribute last /8 for PA & PI. > OR > 2. Don't distribute last /8 for PA & PI (except LIR which didn't get 1024 > IPs from last /8). > > I think second option is more optimal, while some defficit and increasing > prices for IPv4 allow customers run IPv6 faster. > > p.s. Who will PI-addresses? Why they can't rent them or start use IPv6? They can't rent them because the renting market has not yet developed, and they can't use ipv6 because it's not usable at the moment. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 14:35:33 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 13:35:33 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107125847.GC13776@Space.Net> References: <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> Message-ID: <509A63A5.30602@inex.ie> On 07/11/2012 12:58, Gert Doering wrote: > Anybody who relies on availability of "more IPv4 addresses" for their > future business planning is going to be quite unhappy. The same argument was made in the US in the late 1800s after the land rushes ended and the last bits of unassigned land were taken. After all, if there was no more land available, how could the economy survive and grow? But this isn't the point. The point is that there is a modest stash of resources available right now, and that PI requesters are being turned away. Down the road, everyone will be in the same boat: namely that if IPv4 addresses are needed, they will need to be acquired on the market. We're not there yet, though. Nick From gert at space.net Wed Nov 7 14:45:13 2012 From: gert at space.net (Gert Doering) Date: Wed, 7 Nov 2012 14:45:13 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A63A5.30602@inex.ie> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> Message-ID: <20121107134513.GD13776@Space.Net> Hi, On Wed, Nov 07, 2012 at 01:35:33PM +0000, Nick Hilliard wrote: > On 07/11/2012 12:58, Gert Doering wrote: > > Anybody who relies on availability of "more IPv4 addresses" for their > > future business planning is going to be quite unhappy. > > The same argument was made in the US in the late 1800s after the land > rushes ended and the last bits of unassigned land were taken. After all, > if there was no more land available, how could the economy survive and grow? By using IPv6. Unlike the landrush in the US we *do* have an alternative, and do not need to find ways to make IPv4 last forever. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nick at inex.ie Wed Nov 7 14:45:55 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 13:45:55 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> References: <509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> Message-ID: <509A6613.2000606@inex.ie> On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > /24 PA works excelent for multihome. I have a lot examples. I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent. Nick From nick at inex.ie Wed Nov 7 14:51:14 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 13:51:14 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107134513.GD13776@Space.Net> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> Message-ID: <509A6752.6000906@inex.ie> On 07/11/2012 13:45, Gert Doering wrote: > By using IPv6. > > Unlike the landrush in the US we *do* have an alternative, and do not need > to find ways to make IPv4 last forever. ... which brings us straight back to my posting of 13:03:36 CET today. I'm not going to argue another loop of this particular circle. Nick From info at leadertelecom.ru Wed Nov 7 14:53:55 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 17:53:55 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A6613.2000606@inex.ie> References: <509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> Message-ID: <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> Nick, > > /24 PA works excelent for multihome. I have a lot examples. > I'm sure it does, until the day that the end user gets into contractual > problems with the PA LIR and wants to move transit provider, but can't do > so easily because they lose the addresses.??PI == provider independent. We allow to use our PA space with any?transit provider. So customers will be provider independent. -- Alexey Ivanov 07.11.2012 17:46 - Nick Hilliard ???????(?): On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > /24 PA works excelent for multihome. I have a lot examples. I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses.??PI == provider independent. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From poty at iiat.ru Wed Nov 7 14:57:56 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 7 Nov 2012 17:57:56 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 Message-ID: Nick, while there is no IP addresses some alternative is better than no alternative at all. You plan for the "may future" and forget about "need now". I don't see any problem with changing PA LIR in case of problems with old one (PI=small block), changing the transit provider for PI also need some DB work, new agreements with new providers and so on. The job has to be done and in modern situation there is no way out of this culprit. For the shining and undoubtful future - the only way is IPv6. Vladislav Potapov -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nick Hilliard Sent: Wednesday, November 07, 2012 5:46 PM To: LeaderTelecom Ltd. Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > /24 PA works excelent for multihome. I have a lot examples. I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses. PI == provider independent. Nick From jim at rfc1035.com Wed Nov 7 15:00:06 2012 From: jim at rfc1035.com (Jim Reid) Date: Wed, 7 Nov 2012 14:00:06 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A6752.6000906@inex.ie> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509A6752.6000906@inex.ie> Message-ID: <5D95489A-7632-43A4-8231-3E0A0FF4AE5E@rfc1035.com> On 7 Nov 2012, at 13:51, Nick Hilliard wrote: > I'm not going to argue another loop of this particular circle. That's a pity. It may be helpful to keep this "debate" burbling along until there's no more IPv4 left or the heat death of the universe. Whichever comes first. :-) We all agree that everyone will be unhappy once v4 runs out. But not everyone will be unhappy to the same extent or at the same time. They will be unhappy though. IMO, it looks like those wanting PI space are the first to be unhappy. They will not be the last. From nick at inex.ie Wed Nov 7 15:05:16 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 14:05:16 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> References: <509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> Message-ID: <509A6A9C.4050504@inex.ie> On 07/11/2012 13:53, LeaderTelecom Ltd. wrote: > We allow to use our PA space with any transit provider. So customers will > be provider independent. So what happens when your customer leaves or gets into a dispute with you? Is the PA assignment your IP address or theirs? If it's yours when they leave you, then it's not provider independent. This is the way that most LIRs operate: PA assignments are valid as long as the end user is a customer of the provider. Once they move to another provider and stop taking services from you, then the address assignment is no longer theirs. This is what provider independent means. Anyone can multihome a /24 from an allocated block, but it will still remain part of a PA allocation. Nick From info at leadertelecom.ru Wed Nov 7 15:32:43 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 18:32:43 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A6A9C.4050504@inex.ie> References: <509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> Message-ID: <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> Dear Nick, > > We allow to use our PA space with any transit provider. So customers will > > be provider independent. > So what happens when your customer leaves or gets into a dispute with you? > Is the PA assignment your IP address or theirs? This is our PA. But why they will leave us if they have agreement only for PA-space (without IP-transit)? I see only 2 cases - price or customer don't need IPs and return back. > If it's yours when they leave you, then it's not provider independent. This > is the way that most LIRs operate: PA assignments are valid as long as the > end user is a customer of the provider.??Once they move to another provider > and stop taking services from you, then the address assignment is no longer > theirs. > This is what provider independent means.??Anyone can multihome a /24 from > an allocated block, but it will still remain part of a PA allocation. If customer will not pay to sponsoring LIR - RIPE will request IPs back too.? I think using PA space is good option for now. And ASAP start use IPv6. --? Alexey Ivanov ? 07.11.2012 18:06 - Nick Hilliard ???????(?): On 07/11/2012 13:53, LeaderTelecom Ltd. wrote: > We allow to use our PA space with any transit provider. So customers will > be provider independent. So what happens when your customer leaves or gets into a dispute with you? Is the PA assignment your IP address or theirs? If it's yours when they leave you, then it's not provider independent. This is the way that most LIRs operate: PA assignments are valid as long as the end user is a customer of the provider.??Once they move to another provider and stop taking services from you, then the address assignment is no longer theirs. This is what provider independent means.??Anyone can multihome a /24 from an allocated block, but it will still remain part of a PA allocation. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 15:39:31 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 14:39:31 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107141848.GJ3433@hydra.ck.polsl.pl> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <509A6613.2000606@inex.ie> <20121107141848.GJ3433@hydra.ck.polsl.pl> Message-ID: <509A72A3.6040602@inex.ie> On 07/11/2012 14:18, Piotr Strzyzewski wrote: > But your original point was: "Because you can't multihome PA addresses." > Yes, you can. ;-) > > Please make your mind about your arguments. You can, with the implicit agreement of the LIR who holds the allocation and the explicit agreement of a third party provider. If either choose not to play agree, then your multihoming plans either won't work (third party disagrees) or can be screwed up (LIR disagrees). Either way, it's not provider independent in any meaningful way and can lead to serious business harm if there is a breakdown in any of the arrangements. Nick From sander at steffann.nl Wed Nov 7 15:45:15 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 7 Nov 2012 15:45:15 +0100 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <20121106205307.GA26837@cilantro.c4inet.net> References: <92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352205178.877006.24663188.256146.2@otrs.hostingconsult.ru> <7431C876-13F8-4E40-B103-9F01280551C0@steffann.nl> <20121106205307.GA26837@cilantro.c4inet.net> Message-ID: Hi, > Another question is, whether this discussion doesn't actually belong in > the Services WG... That is a valid question. Sander From Piotr.Strzyzewski at polsl.pl Wed Nov 7 15:18:48 2012 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 7 Nov 2012 15:18:48 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A6613.2000606@inex.ie> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <509A6613.2000606@inex.ie> Message-ID: <20121107141848.GJ3433@hydra.ck.polsl.pl> On Wed, Nov 07, 2012 at 01:45:55PM +0000, Nick Hilliard wrote: > On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > > /24 PA works excelent for multihome. I have a lot examples. > > I'm sure it does, until the day that the end user gets into contractual > problems with the PA LIR and wants to move transit provider, but can't do > so easily because they lose the addresses. PI == provider independent. But your original point was: "Because you can't multihome PA addresses." Yes, you can. ;-) Please make your mind about your arguments. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From tore.anderson at redpill-linpro.com Wed Nov 7 15:49:01 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 07 Nov 2012 15:49:01 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <509A6251.9030509@ripe.net> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> <509A6251.9030509@ripe.net> Message-ID: <509A74DD.8040809@redpill-linpro.com> * Ingrid Wijte > Just to clarify our position a bit here. We are willing and able to > publish the information. But the fact remains that there is now a > policy proposal being discussed in the community that specifically > deals with making this information publicly available. It doesn't > make much sense for us to go ahead and publish the information in a > different format before we know the outcome of the policy proposal. Hi, I would like the list of transfers to be made public, but I would at the same time prefer that this proposal did *not* pass, because if you are willing to publish the information anyway, there's really no need to add more policy text - we have enough text in the policy as it is. However, now I'm faced with a dilemma. If I (and others) object to this proposal so that it ends up not passing, I worry that the NCC would then opt *not* to publish the information - considering that the community would then have just rejected a proposal that told you to do so, it would not be all that surprising if you interpret that as the message from the community is ?don't make this information public?. However, if you will go ahead and publish information after this proposal is finished - even if it failed! - you might as well go ahead and do it right now, since you'll end up publishing no matter what. I hope that made sense to you... However, if it is the determination of the format/syntax of the published data that is the only thing that's stopping you from publishing right now, then I have a suggestion: Make a mock transfer list based on your current understanding of the proposal, and then maybe, if the proposer agrees it will give him the information he want to see made public, he could withdraw the proposal in exchange for you starting to publishing the real list immediately afterwards. This ought to keep everyone happy: - Proposer and the rest of the community gets access to all the information we want, and much faster than if we had to wait for the PDP to complete - No addition of extraneous text to the policy document - No need for micro management of the NCC Does this sound like a reasonable path forward? (this question is meant both for the proposer and the NCC) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Piotr.Strzyzewski at polsl.pl Wed Nov 7 15:49:20 2012 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 7 Nov 2012 15:49:20 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A72A3.6040602@inex.ie> References: <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <509A6613.2000606@inex.ie> <20121107141848.GJ3433@hydra.ck.polsl.pl> <509A72A3.6040602@inex.ie> Message-ID: <20121107144920.GK3433@hydra.ck.polsl.pl> On Wed, Nov 07, 2012 at 02:39:31PM +0000, Nick Hilliard wrote: > On 07/11/2012 14:18, Piotr Strzyzewski wrote: > > But your original point was: "Because you can't multihome PA addresses." > > Yes, you can. ;-) > > > > Please make your mind about your arguments. > > You can, with the implicit agreement of the LIR who holds the allocation > and the explicit agreement of a third party provider. If either choose not > to play agree, then your multihoming plans either won't work (third party > disagrees) or can be screwed up (LIR disagrees). Either way, it's not > provider independent in any meaningful way and can lead to serious business > harm if there is a breakdown in any of the arrangements. So, your point should be: "Because you can't always multihome PA addresses in the easy way.". ;-) Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From nick at inex.ie Wed Nov 7 15:57:40 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 14:57:40 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> References: <509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> Message-ID: <509A76E4.8040105@inex.ie> On 07/11/2012 14:32, LeaderTelecom Ltd. wrote: > I think using PA space is good option for now. It's good if you're happy to build your business with sticky tape, chewing gum and string. Nick From sander at steffann.nl Wed Nov 7 16:15:46 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 7 Nov 2012 16:15:46 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107121338.GA13776@Space.Net> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> Message-ID: Hi, > this statement might need some adjustment to "there is no IPv4 PI, can we do something else?", like "can we use IPv6 PI plus double-IPv4-PA?" or "can we use IPv6 PI plus our ISP's friendly NAT64 translator?"... I think these are the only options that can survive in the medium to long term. At some point in time the final /8 will also be depleted and then everybody will be unhappy. We should start moving in such a direction *now*. Geoff Huston showed us years ago: we were meant to deploy IPv6 before the IPv4 pool ran out. We postponed deployment until we did run out. If we keep postponing solutions that don't rely on IPv4 address space then we will remain in the situation we are in now and the pain will become worse and worse. We have been making policies for specific cases (we now have PA form the final /8, we have IXP space from that /8, we are discussing PI from that /8 now). Maybe we need to take a step back and look at the big picture first. I personally think that it would be very bad if ISPs don't have any IPv4 space for things like central NAT64 boxes or similar services for example. We have the current final /8 policy for that now, but lets look a few steps ahead... - Sander From poty at iiat.ru Wed Nov 7 16:21:22 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 7 Nov 2012 19:21:22 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 Message-ID: If you have PI you should have agreement with your sponsoring LIR (or RIPE NCC) and with several providers (taking into consideration multihoming). If all of them (wrongly assumed as "either" by you) choose not to play agree, then your multihoming plans won't work. What's the difference then with assigned PA block? Alexey Ivanov tried to say that there are several LIRs that are not providers and their MAIN business is provide numbers (IPs, ASns...). They are of the same reliability as sponsoring LIRs and won't leave you without their service, because they want your money. More than that - there MANY providers, LIRs, carriers... which gives you enormous possibilities to change any of the party without any problem. No business harm at all. Regards, Vladislav Potapov -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Nick Hilliard Sent: Wednesday, November 07, 2012 6:40 PM To: Piotr Strzyzewski Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 On 07/11/2012 14:18, Piotr Strzyzewski wrote: > But your original point was: "Because you can't multihome PA addresses." > Yes, you can. ;-) > > Please make your mind about your arguments. You can, with the implicit agreement of the LIR who holds the allocation and the explicit agreement of a third party provider. If either choose not to play agree, then your multihoming plans either won't work (third party disagrees) or can be screwed up (LIR disagrees). Either way, it's not provider independent in any meaningful way and can lead to serious business harm if there is a breakdown in any of the arrangements. Nick From richih.mailinglist at gmail.com Wed Nov 7 16:41:51 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 7 Nov 2012 16:41:51 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107134513.GD13776@Space.Net> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> Message-ID: On Wed, Nov 7, 2012 at 2:45 PM, Gert Doering wrote: > Unlike the landrush in the US we *do* have an alternative, and do not need > to find ways to make IPv4 last forever. If anything, allowing IPv4 PI at this stage will speed up IPv4 exhaustion, not slow it down. I don't see this as trying to make it last longer; the reverse is true. There are valid business cases to be made today that include getting IPv4 as long as it's available. Yes, unless they include IPv6 in their business plans they are going to get hurt Real Soon Now (tm), but that's outside of the scope of this argument. The _only_ thing we should be discussing in this particular context is "should we still hand out IPv4 PI as long as IPv4 is still available or should we hand out IPv4 PA, only?" Possible answers include: * Stop handing out IPv4 PI once we reach the last /8 * Stop handing out IPv4 PI once we reach the last /x (12? 16?) * Hand out IPv4 PI from a designated /x in the last /8, stop once that's empty * Hand out IPv4 PI from returned space, only. Don't hand out PI from the last /8 And I am sure there are others. It's painfully obvious that the argument that IPv6 is the way of the future is correct. It's also obvious, to me, that this fact is detached from the question of how the remaining bits and pieces of IPv4 should be used up. To put it differently: Why does anyone who considers IPv4 legacy care about how it's used up? -- Richard From info at leadertelecom.ru Wed Nov 7 17:10:49 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 20:10:49 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A76E4.8040105@inex.ie> References: <509A76E4.8040105@inex.ie><509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> Message-ID: <1352304648.11815.0956534354.257473.2@otrs.hostingconsult.ru> > > I think using PA space is good option for now. > It's good if you're happy to build your business with sticky tape, chewing > gum and string. Nick, Insternet based on?trust. Do you sign legal agreement with each peer? I think, no. --? Alexey Ivanov 07.11.2012 18:58 - Nick Hilliard ???????(?): On 07/11/2012 14:32, LeaderTelecom Ltd. wrote: > I think using PA space is good option for now. It's good if you're happy to build your business with sticky tape, chewing gum and string. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Wed Nov 7 17:58:06 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 20:58:06 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <50990584.5050503@inex.ie> References: <50990584.5050503@inex.ie><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> Message-ID: <1352307485.436678.63211411.256146.2@otrs.hostingconsult.ru> Nick, Your information based on?assumption that you work with clean information. Could you tell LIR for this Allocated PA network? [1]https://apps.db.ripe.net/search/query.html?searchtext=192.115.112.0&search%3AdoSearch=Search#resultsAnchor [2]https://apps.db.ripe.net/whois/lookup/ripe/inetnum/192.33.111.0-192.33.111.255.html I see more than 500 networks with type?"Allocated PA" doesn't have LIR. So you will not see transfers for this networks if this information will be not published. Of course it is possible to make "diff" for changes, but it will be not 100% correct information about transfers. --? Alexey Ivanov 06.11.2012 16:42 - Nick Hilliard ???????(?): On 06/11/2012 12:03, LeaderTelecom Ltd. wrote: > How are you going to know did company changed name or IPs were transfered? Alexey, the LIR ID stays the same, regardless of the legal name of the company. You've said that your concern is that other people will know which IP addresses have been transferred.??The code I included shows which LIR ID loses or gains IP addresses, and according to what you said earlier: > criminal element will know who just received big amount of money and can > be target for raiders. ... the code I posted will identify exactly which LIR have recently lost or gained IP addresses, because you can look up the LIR details here: [3]https://www.ripe.net/membership/indices/ So you can use my code to see exactly which LIR has lost IP addresses or gained them. It's really easy to track this.??Here's a database schema for holding the information: CREATE TABLE `ipv4quantities` ( ??`id` int unsigned NOT NULL, ??`regid` varchar(255) NOT NULL, ??`numberofaddresses` int unsigned NOT NULL default 0, ??`thedate` date NOT NULL, ??PRIMARY KEY??(`id`) ); Will I write another couple of lines of code and hook up v4-transfer.pl into this database schema???And another 10 lines of code to provide a web front end? If you want, I'll write another couple of lines on top of that, with another two database tables, and that can be used to provide a complete historical list of exactly what addresses are held by any LIR, along with sortable columns so you can see what IP address space was transferred, and when.??But it turns out that most of this is unnecessary, because it's already being done here: [4]https://stat.ripe.net/ In other words the information proposed in this policy is already available in multiple formats from multiple areas of the RIPE NCC web site / database / ftp site, and extracting this information is simple enough for a school child to do. Let me repeat: ######################################################################## ##????????????????????????????????????????????????????????????????????## ## Getting this information is so simple that even a child can do it. ## ##????????????????????????????????????????????????????????????????????## ######################################################################## Please drop your objection.??It's completely ridiculous. Nick ? [1] https://apps.db.ripe.net/search/query.html?searchtext=192.115.112.0&search%3AdoSearch=Search#resultsAnchor [2] https://apps.db.ripe.net/whois/lookup/ripe/inetnum/192.33.111.0-192.33.111.255.html [3] https://www.ripe.net/membership/indices/ [4] https://stat.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 18:06:27 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 17:06:27 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352307485.436678.63211411.256146.2@otrs.hostingconsult.ru> References: <50990584.5050503@inex.ie><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352307485.436678.63211411.256146.2@otrs.hostingconsult.ru> Message-ID: <509A9513.9040701@inex.ie> On 07/11/2012 16:58, LeaderTelecom Ltd. wrote: > Could you tell LIR for this Allocated PA network? > > https://apps.db.ripe.net/search/query.html?searchtext=192.115.112.0&search%3AdoSearch=Search#resultsAnchor > > https://apps.db.ripe.net/whois/lookup/ripe/inetnum/192.33.111.0-192.33.111.255.html Neither of those networks are allocated PA. They're ERX space. Nick From info at leadertelecom.ru Wed Nov 7 18:08:46 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 21:08:46 +0400 Subject: [address-policy-wg] [Ticket#2012110701002726] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <509A74DD.8040809@redpill-linpro.com> References: <509A74DD.8040809@redpill-linpro.com><20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> <509A6251.9030509@ripe.net> Message-ID: <1352308125.618333.253521129.257753.2@otrs.hostingconsult.ru> Tore, Lets?imagine that information about transfers published on FTP. Which?benefits will have community?? Put in Excel and make graph of transfers per month in count of IPs and numbers of transfers? I think this information anyway will be published in RIPE reports. I don't see other benefits. --? Alexey Ivanov 07.11.2012 18:50 - Tore Anderson ???????(?): * Ingrid Wijte > Just to clarify our position a bit here. We are willing and able to > publish the information. But the fact remains that there is now a > policy proposal being discussed in the community that specifically > deals with making this information publicly available. It doesn't > make much sense for us to go ahead and publish the information in a > different format before we know the outcome of the policy proposal. Hi, I would like the list of transfers to be made public, but I would at the same time prefer that this proposal did *not* pass, because if you are willing to publish the information anyway, there's really no need to add more policy text - we have enough text in the policy as it is. However, now I'm faced with a dilemma. If I (and others) object to this proposal so that it ends up not passing, I worry that the NCC would then opt *not* to publish the information - considering that the community would then have just rejected a proposal that told you to do so, it would not be all that surprising if you interpret that as the message from the community is ?don't make this information public?. However, if you will go ahead and publish information after this proposal is finished - even if it failed! - you might as well go ahead and do it right now, since you'll end up publishing no matter what. I hope that made sense to you... However, if it is the determination of the format/syntax of the published data that is the only thing that's stopping you from publishing right now, then I have a suggestion: Make a mock transfer list based on your current understanding of the proposal, and then maybe, if the proposer agrees it will give him the information he want to see made public, he could withdraw the proposal in exchange for you starting to publishing the real list immediately afterwards. This ought to keep everyone happy: - Proposer and the rest of the community gets access to all the information we want, and much faster than if we had to wait for the PDP to complete - No addition of extraneous text to the policy document - No need for micro management of the NCC Does this sound like a reasonable path forward? (this question is meant both for the proposer and the NCC) -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com ? [1] http://www.redpill-linpro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Wed Nov 7 18:13:22 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 7 Nov 2012 21:13:22 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <509A9513.9040701@inex.ie> References: <509A9513.9040701@inex.ie><50990584.5050503@inex.ie><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352307485.436678.63211411.256146.2@otrs.hostingconsult.ru> Message-ID: <1352308401.497643.582875174.256146.2@otrs.hostingconsult.ru> Nick, How did you find it? If networks has status "ALLOCATED PA", but doesn't have "org" - then it is?ERX? Or you see any other?attribute? Example:? inetnum: ? ? ? ?192.33.111.0 - 192.33.111.255 netname: ? ? ? ?THENET descr: ? ? ? ? ?TheNet - Internet Services AG descr: ? ? ? ? ?Bern, Switzerland country: ? ? ? ?CH admin-c: ? ? ? ?JR11-RIPE tech-c: ? ? ? ? YS135-RIPE status: ? ? ? ? ALLOCATED PA notify: ? ? ? ? helpdesk at thenet.ch mnt-by: ? ? ? ? THENET-MN changed: ? ? ? ?support at thenet.ch 19990128 source: ? ? ? ? RIPE --? Alexey Ivanov 07.11.2012 21:07 - Nick Hilliard ???????(?): On 07/11/2012 16:58, LeaderTelecom Ltd. wrote: > Could you tell LIR for this Allocated PA network? > > [1]https://apps.db.ripe.net/search/query.html?searchtext=192.115.112.0&search%[..] > > [2]https://apps.db.ripe.net/whois/lookup/ripe/inetnum/192.33.111.0-192.33.111.[..] Neither of those networks are allocated PA.??They're ERX space. Nick [1] https://apps.db.ripe.net/search/query.html?searchtext=192.115.112.0&search%3AdoSearch=Search#resultsAnchor [2] https://apps.db.ripe.net/whois/lookup/ripe/inetnum/192.33.111.0-192.33.111.255.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Nov 7 18:18:30 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 17:18:30 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352308401.497643.582875174.256146.2@otrs.hostingconsult.ru> References: <509A9513.9040701@inex.ie><50990584.5050503@inex.ie><5098DF92.8000709@inex.ie><5098D98C.40100@redpill-linpro.com><5098D181.1050209@redpill-linpro.com><92C9A0FB-900E-411F-BA0F-8B852FD55CD1@burkov.aha.ru> <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <855077AC3D7A7147A7570370CA01ECD227A626@SUEX10-mbx-10.ad.syr.edu> <1352188332.207118.986944674.256146.2@otrs.hostingconsult.ru> <1352192598.465506.982199773.256146.2@otrs.hostingconsult.ru> <1352194803.664850.127905032.256146.2@otrs.hostingconsult.ru> <1352203430.135834.721537128.256146.2@otrs.hostingconsult.ru> <1352307485.436678.63211411.256146.2@otrs.hostingconsult.ru> <1352308401.497643.582875174.256146.2@otrs.hostingconsult.ru> Message-ID: <509A97E6.4070406@inex.ie> On 07/11/2012 17:13, LeaderTelecom Ltd. wrote: > How did you find it? If networks has status "ALLOCATED PA", but doesn't > have "org" - then it is ERX? Or you see any other attribute? It isn't in alloclist.txt: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt Also, all the 192.0.0.0/8 is InterNIC assigned space. Nick From nick at inex.ie Wed Nov 7 18:23:39 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 17:23:39 +0000 Subject: [address-policy-wg] [Ticket#2012110701002726] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1352308125.618333.253521129.257753.2@otrs.hostingconsult.ru> References: <509A74DD.8040809@redpill-linpro.com><20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> <509A6251.9030509@ripe.net> <1352308125.618333.253521129.257753.2@otrs.hostingconsult.ru> Message-ID: <509A991B.4010605@inex.ie> On 07/11/2012 17:08, LeaderTelecom Ltd. wrote: > Put in Excel and make graph of transfers per month in count of IPs and > numbers of transfers? I think this information anyway will be published in > RIPE reports. I don't see other benefits. Cross-posting from from ietf at ietf.org earlier on today: > ?Sunlight Is the Best Disinfectant? > > ?Sunlight is the best disinfectant,? a well-known quote from U.S. Supreme > Court Justice Louis Brandeis, refers to the benefits of openness and > transparency. I invoke this quote often as executive director of the > NYSSCPA, to illustrate that the most credible and respected > organizations operate in an atmosphere of avowed openness. We should not > only accept criticism and suggestions, we should embrace them. If > questions from constituents, the public, or the media make leaders or > other responsible parties obfuscate, the questions are usually valid and > the answers are not. People who feel uncomfortable under the bright > light of scrutiny and criticism often have something to hide. ref: http://www.nysscpa.org/cpajournal/2003/1203/nv/nv2.htm The same principal of openness and clarity have served the RIPE community extremely well since it began, and I see no reason abandon them at the point. Openness will help to ensure a fair and reasonable market. Nick From nick at inex.ie Wed Nov 7 18:26:54 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 07 Nov 2012 17:26:54 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352304648.11815.0956534354.257473.2@otrs.hostingconsult.ru> References: <509A76E4.8040105@inex.ie><509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> <1352304648.11815.0956534354.257473.2@otrs.hostingconsult.ru> Message-ID: <509A99DE.4040200@inex.ie> On 07/11/2012 16:10, LeaderTelecom Ltd. wrote: > Nick, Insternet based on trust. Do you sign legal agreement with each peer? > I think, no. No, but I do for each address space provider and transit provider. You can live if a peer session drops because it's not critical to business. The same is not true for either transit or address space service. Nick From gert at space.net Wed Nov 7 19:17:03 2012 From: gert at space.net (Gert Doering) Date: Wed, 7 Nov 2012 19:17:03 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> Message-ID: <20121107181703.GE13776@Space.Net> Hi, On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: > To put it differently: Why does anyone who considers IPv4 legacy care > about how it's used up? Well, I *do* care about the way we use the community's resources in policy building. If everybody gets exhausted doing a new round of IPv4 PI policy every time the "we do IPv4 PI only until happens, and then no more!" mark is reached, other policy proposals do not get the attention they deserve. (By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From niels=apwg at bakker.net Wed Nov 7 19:51:43 2012 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Wed, 7 Nov 2012 19:51:43 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <5097A3CA.60607@inex.ie> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> <50962F75.6060605@redpill-linpro.com> <5097A3CA.60607@inex.ie> Message-ID: <20121107185143.GC11613@burnout.tpb.net> * nick at inex.ie (Nick Hilliard) [Mon 05 Nov 2012, 12:32 CET]: >I support this policy. Seconded. -- Niels. -- From jan at go6.si Wed Nov 7 20:23:09 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 07 Nov 2012 20:23:09 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107121338.GA13776@Space.Net> References: <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> Message-ID: <509AB51D.3000905@go6.si> On 11/7/12 1:13 PM, Gert Doering wrote: > These seem much more relevant questions to me than "can we look around > in the decks below the water line for additional deck chairs?". +10 Cheers, Jan From marcin at leon.pl Wed Nov 7 20:25:15 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 07 Nov 2012 20:25:15 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107134513.GD13776@Space.Net> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> Message-ID: <509AB59B.6050908@leon.pl> > By using IPv6. > > Unlike the landrush in the US we *do* have an alternative, and do not need > to find ways to make IPv4 last forever. > > Gert Doering > -- NetMaster Yeap... but... We are an ISP fucusing on individuals (most) and business (minority, but growing). Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever). Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to put them in production. 2 years at least I suppose.. Now, imagine that there is a lot of ISPs like us with the same problem, however, very often lager scale... (I suppose that Juniper and others are at the same stage). Regards, Marcin From marcin at leon.pl Wed Nov 7 20:27:27 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 07 Nov 2012 20:27:27 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> References: <509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> Message-ID: <509AB61F.3010802@leon.pl> On 2012-11-07 14:53, LeaderTelecom Ltd. wrote: > Nick, > > > > /24 PA works excelent for multihome. I have a lot examples. > > > I'm sure it does, until the day that the end user gets into contractual > > problems with the PA LIR and wants to move transit provider, but > can't do > > so easily because they lose the addresses. PI == provider independent. > > We allow to use our PA space with any transit provider. So customers > will be provider independent. Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses. Regards, Marcin > > -- > Alexey Ivanov > > 07.11.2012 17:46 - Nick Hilliard ???????(?): > On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > > /24 PA works excelent for multihome. I have a lot examples. > > I'm sure it does, until the day that the end user gets into contractual > problems with the PA LIR and wants to move transit provider, but can't do > so easily because they lose the addresses. PI == provider independent. > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Wed Nov 7 20:35:15 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 07 Nov 2012 20:35:15 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB59B.6050908@leon.pl> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509AB59B.6050908@leon.pl> Message-ID: <509AB7F3.1040301@go6.si> On 11/7/12 8:25 PM, Marcin Kuczera wrote: > Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet > implemented this access method for IPv6.. > They have it on roadmap, but it will take a while for first releases and > much more before they will be stable enough to > put them in production. Not true. Cisco ASR1k and Ericsson Redback works very well with IPv6/IPv4 for access. Tested at least for PPPoE/A users. Cheers, Jan From erik at bais.name Wed Nov 7 20:37:19 2012 From: erik at bais.name (Erik Bais) Date: Wed, 7 Nov 2012 20:37:19 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB61F.3010802@leon.pl> References: <509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <509AB61F.3010802@leon.pl> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D590B@EXVS002.netsourcing.lan> Hi Marcin, > Without beeing yours customer for transit ? > If yes, I suppose that you charge them for using your PA addresses. I?m pretty sure he is not doing it for free. And with the current market, providing transit to a customer doesn?t mean that they can blindly request additional IP?s without any additional financial contractual agreement I presume. There are already some ISP?s that charge for additional IP addresses on a service. And I would expect that this would become more the standard than the exception . . . Charge extra for IPv4 addresses, provide v6 for free. Regards, Erik Bais From jan at go6.si Wed Nov 7 20:38:43 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 07 Nov 2012 20:38:43 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509A76E4.8040105@inex.ie> References: <509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> <509A76E4.8040105@inex.ie> Message-ID: <509AB8C3.4010302@go6.si> On 11/7/12 3:57 PM, Nick Hilliard wrote: > On 07/11/2012 14:32, LeaderTelecom Ltd. wrote: >> I think using PA space is good option for now. > > It's good if you're happy to build your business with sticky tape, chewing > gum and string. Well, the big part of IETF was quite busy with standardizing "sticky tape, chewing gum and string" for the last decade probably. I'm sure vendors will soon come out with new&shiny tools on their equipment to easily get around this small issue. They are brilliant at doing that (and of course charging for additional license somehow) :) Cheers, Jan From hamed at skydsl.ir Wed Nov 7 20:56:24 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Wed, 7 Nov 2012 23:26:24 +0330 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB59B.6050908@leon.pl> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509AB59B.6050908@leon.pl> Message-ID: > Yeap... but... > > We are an ISP fucusing on individuals (most) and business (minority, but > growing). > Because of nature of our business, we decided to have central BRAS and > large L2 (in future MPLS) network. > So, most of our subscribers are connected via "ethernet all the way", > native DHCP (no PPPoWhatever). > > Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented > this access method for IPv6.. > They have it on roadmap, but it will take a while for first releases and > much more before they will be stable enough to > put them in production. > 2 years at least I suppose.. > > Now, imagine that there is a lot of ISPs like us with the same problem, > however, very often lager scale... > > (I suppose that Juniper and others are at the same stage). > > Regards, > Marcin > We have a same problem in one of our ADSL2+ zone :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From Remco.vanMook at eu.equinix.com Wed Nov 7 20:22:17 2012 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 7 Nov 2012 19:22:17 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107181703.GE13776@Space.Net> Message-ID: Hi Gert, I see what you're saying here. At the same time, I think any policy allowing PIv4 from the final /8 would have such a profound impact on what the current final /8 policy is trying to achieve that we should probably review the final /8 policy in its entirety. Yes, I'm fully aware how much pain and effort would go into that. But if we don't we might as well take away the fences and let everyone have a few more glorious weeks of cheap IPv4 resources. Best Remco (No hats) ----- Original Message ----- From: Gert Doering [mailto:gert at space.net] Sent: Wednesday, November 07, 2012 06:17 PM To: Richard Hartmann Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 Hi, On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: > To put it differently: Why does anyone who considers IPv4 legacy care > about how it's used up? Well, I *do* care about the way we use the community's resources in policy building. If everybody gets exhausted doing a new round of IPv4 PI policy every time the "we do IPv4 PI only until happens, and then no more!" mark is reached, other policy proposals do not get the attention they deserve. (By which I'd ask you to please stay away from a PI policy that will do things like "but only in the first /9 of the last /8, not in the second /9" - *iff* the community decides to bring back IPv4 PI, then let's do it for good and for all the remaining space. Doing it for "but not for the last /x" is exactly what we have now - let's not do *that* again). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From dez at otenet.gr Wed Nov 7 21:17:10 2012 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Wed, 07 Nov 2012 22:17:10 +0200 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107181703.GE13776@Space.Net> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> Message-ID: <509AC1C6.6000605@otenet.gr> Hello Gert, On 11/07/2012 08:17 PM, Gert Doering wrote: > Hi, > > On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: >> To put it differently: Why does anyone who considers IPv4 legacy care >> about how it's used up? > Well, I *do* care about the way we use the community's resources in > policy building. I'm confused. We should all care about the way the community's resources are used. That's the whole point of this discussion (and this group). What we're now seeing, is new LIRs that never wanted to become LIRs in the first place and just wanted a /24 of PI space. They have no (real) alternative though if they want to multihome (as an LIR/ISP I'm with Nick on this one). How's that fair on them, considering registration and handling fees? As far as IPv6 goes, most of us or on the same boat, no need to state the obvious. As Richard said, the question here is whether we should hand out PI from the last /8 or not. regards, Yannis From marcin at leon.pl Wed Nov 7 21:37:47 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 07 Nov 2012 21:37:47 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB7F3.1040301@go6.si> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509AB59B.6050908@leon.pl> <509AB7F3.1040301@go6.si> Message-ID: <509AC69B.8020803@leon.pl> On 2012-11-07 20:35, Jan Zorz @ go6.si wrote: > On 11/7/12 8:25 PM, Marcin Kuczera wrote: >> Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet >> implemented this access method for IPv6.. >> They have it on roadmap, but it will take a while for first releases and >> much more before they will be stable enough to >> put them in production. > > Not true. Cisco ASR1k and Ericsson Redback works very well with > IPv6/IPv4 for access. Tested at least for PPPoE/A users. Jan, please - read it once again, I wrote that - I don't care abut PPPoE/A, *NO PPP* I need NATIVE ETHERNET - in RedBack the call it CLIPS - any hints about that ? Regards, Marcin From marcin at leon.pl Wed Nov 7 21:40:59 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 07 Nov 2012 21:40:59 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB8C3.4010302@go6.si> References: <509A6A9C.4050504@inex.ie><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> <1352298762.343139.298371829.257473.2@otrs.hostingconsult.ru> <509A76E4.8040105@inex.ie> <509AB8C3.4010302@go6.si> Message-ID: <509AC75B.1030406@leon.pl> On 2012-11-07 20:38, Jan Zorz @ go6.si wrote: > On 11/7/12 3:57 PM, Nick Hilliard wrote: >> On 07/11/2012 14:32, LeaderTelecom Ltd. wrote: >>> I think using PA space is good option for now. >> >> It's good if you're happy to build your business with sticky tape, >> chewing >> gum and string. > > Well, the big part of IETF was quite busy with standardizing "sticky > tape, chewing gum and string" for the last decade probably. > > I'm sure vendors will soon come out with new&shiny tools on their > equipment to easily get around this small issue. They are brilliant at > doing that (and of course charging for additional license somehow) :) > Oh yeah, tha't what I also feel. Vendors will find solutions to keep IPv4 forever... Recently I saw a lot of CarrierGrade NAT presentations on conference schedules... Regards, Marcin From info at leadertelecom.ru Wed Nov 7 21:54:26 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Thu, 8 Nov 2012 00:54:26 +0400 Subject: [address-policy-wg] [Ticket#2012110701002726] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <509A991B.4010605@inex.ie> References: <509A991B.4010605@inex.ie><509A74DD.8040809@redpill-linpro.com><20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> <509223CB.6070509@redpill-linpro.com> <5097C635.5090707@ripe.net> <509A6251.9030509@ripe.net> <1352308125.618333.253521129.257753.2@otrs.hostingconsult.ru> Message-ID: <1352321665.618896.158769313.257753.2@otrs.hostingconsult.ru> Dear Nick, Beautiful words. ?I?respect your opinion. I think it is possible to find so great words about privacy. It is important to have balance between privacy and openness. My collegues from Greece told that they have very limited information in whois by privacy reason. In different countries is different opinion about privacy and opennes while we have different mentality. I don't see?benefits for community in publishing list of transfer. --? Alexey 07.11.2012 21:24 - Nick Hilliard ???????(?): On 07/11/2012 17:08, LeaderTelecom Ltd. wrote: > Put in Excel and make graph of transfers per month in count of IPs and > numbers of transfers? I think this information anyway will be published in > RIPE reports. I don't see other benefits. Cross-posting from from ietf at ietf.org earlier on today: > ?Sunlight Is the Best Disinfectant? > > ?Sunlight is the best disinfectant,? a well-known quote from U.S. Supreme > Court Justice Louis Brandeis, refers to the benefits of openness and > transparency. I invoke this quote often as executive director of the > NYSSCPA, to illustrate that the most credible and respected > organizations operate in an atmosphere of avowed openness. We should not > only accept criticism and suggestions, we should embrace them. If > questions from constituents, the public, or the media make leaders or > other responsible parties obfuscate, the questions are usually valid and > the answers are not. People who feel uncomfortable under the bright > light of scrutiny and criticism often have something to hide. ref: [1]http://www.nysscpa.org/cpajournal/2003/1203/nv/nv2.htm The same principal of openness and clarity have served the RIPE community extremely well since it began, and I see no reason abandon them at the point.??Openness will help to ensure a fair and reasonable market. Nick ? [1] http://www.nysscpa.org/cpajournal/2003/1203/nv/nv2.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Nov 7 21:59:09 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 7 Nov 2012 21:59:09 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB59B.6050908@leon.pl> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509AB59B.6050908@leon.pl> Message-ID: <767FDF20-2897-40FC-ACCB-1757897E4E82@steffann.nl> Hi, > Yeap... but... > > We are an ISP fucusing on individuals (most) and business (minority, but growing). > Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. > So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever). > > Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. > They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to > put them in production. > 2 years at least I suppose.. I know multiple networks like that. The one that ran out of public IPv4 space is now doing NAT444 with 100.64.0.0/10 combined with 6rd. It's certainly not pretty, but it is easy to convert an existing 'ethernet all the way' network to this by adding a set of central NAT boxes and a set of 6rd border relays. The existing IPv4 infrastructure doesn't have to change. You do need to supply 6rd capable CPEs to customers, but those are available from many vendors these days. - Sander From info at leadertelecom.ru Wed Nov 7 22:01:02 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Thu, 8 Nov 2012 01:01:02 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AB61F.3010802@leon.pl> References: <509AB61F.3010802@leon.pl><509A6613.2000606@inex.ie><509A4603.8050105@inex.ie><509A36BF.1050003@inex.ie><50994EA9.1070305@inex.ie><5098E468.1010708@otenet.gr> <5098EA8E.6080306@inex.ie> <50993BB3.3090605@redpill-linpro.com> <50993F68.1000308@inex.ie> <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <1352295245.732136.562873421.257473.2@otrs.hostingconsult.ru> <1352296434.960333.988942077.257473.2@otrs.hostingconsult.ru> Message-ID: <1352322061.412815.99417694.257473.2@otrs.hostingconsult.ru> Dear?Marcin, > Without beeing yours customer for transit ? > If yes, I suppose that you charge them for using your PA addresses. Correct. We just registry. Most of our customers uses PI-addresses. But for now PA-addresses instead of PI is a good option. -- Alexey Ivanov 07.11.2012 23:28 - Marcin Kuczera ???????(?): On 2012-11-07 14:53, LeaderTelecom Ltd. wrote: Nick, > > /24 PA works excelent for multihome. I have a lot examples. > I'm sure it does, until the day that the end user gets into contractual > problems with the PA LIR and wants to move transit provider, but can't do > so easily because they lose the addresses.??PI == provider independent. We allow to use our PA space with any?transit provider. So customers will be provider independent. Without beeing yours customer for transit ? If yes, I suppose that you charge them for using your PA addresses. Regards, Marcin -- Alexey Ivanov 07.11.2012 17:46 - Nick Hilliard ???????(?): On 07/11/2012 13:34, LeaderTelecom Ltd. wrote: > /24 PA works excelent for multihome. I have a lot examples. I'm sure it does, until the day that the end user gets into contractual problems with the PA LIR and wants to move transit provider, but can't do so easily because they lose the addresses.??PI == provider independent. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at leon.pl Wed Nov 7 22:16:42 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 07 Nov 2012 22:16:42 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <767FDF20-2897-40FC-ACCB-1757897E4E82@steffann.nl> References: <50994E54.4030703@umn.edu> <1352276994.317347.143611797.257473.2@otrs.hostingconsult.ru> <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <509AB59B.6050908@leon.pl> <767FDF20-2897-40FC-ACCB-1757897E4E82@steffann.nl> Message-ID: <509ACFBA.7020008@leon.pl> On 2012-11-07 21:59, Sander Steffann wrote: > Hi, > >> Yeap... but... >> >> We are an ISP fucusing on individuals (most) and business (minority, but growing). >> Because of nature of our business, we decided to have central BRAS and large L2 (in future MPLS) network. >> So, most of our subscribers are connected via "ethernet all the way", native DHCP (no PPPoWhatever). >> >> Both - Cisco/Ericsson(RedBack) - for their BRASes have not yet implemented this access method for IPv6.. >> They have it on roadmap, but it will take a while for first releases and much more before they will be stable enough to >> put them in production. >> 2 years at least I suppose.. > I know multiple networks like that. The one that ran out of public IPv4 space is now doing NAT444 with 100.64.0.0/10 combined with 6rd. It's certainly not pretty, but it is easy to convert an existing 'ethernet all the way' network to this by adding a set of central NAT boxes and a set of 6rd border relays. The existing IPv4 infrastructure doesn't have to change. You do need to supply 6rd capable CPEs to customers, but those are available from many vendors these days. > > - Sander > > Sure, but it is still "chewing gum and co.." solution. Quite expasive spearmint... We have no problem with IPv4, but others do. I'am not complaining about that IPv4 is out, rather that vendors have their bussines plans about IPv6... Regards, Marcin From farmer at umn.edu Wed Nov 7 22:56:14 2012 From: farmer at umn.edu (David Farmer) Date: Wed, 07 Nov 2012 15:56:14 -0600 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AC1C6.6000605@otenet.gr> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> Message-ID: <509AD8FE.6010304@umn.edu> On 11/7/12 14:17 , Yannis Nikolopoulos wrote: > Hello Gert, > > As Richard said, the question here is whether we should > hand out PI from the last /8 or not. I think there is another viable option; *Allow IPv4 PI from the transfer market But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me. If the RIPE community doesn't want to make IPv4 PI assignments out of its last /8, I think that is defensible. If someone wants something out of the last /8, making them become an LIR seems reasonable as well. However, saying there is no such thing as IPv4 PI any longer is not reasonable when there is a viable transfer market available as a source of addresses. The whole point of creating a IPv4 transfer market was to encourage getting unused or underutilized IPv4 addresses in to the hands of those that need them. End users need for IPv4 PI is just as important and valid of a use for IPv4 as ISP need for IPv4. Shutting IPv4 PI out of the last /8 is one thing, shutting IPv4 PI out of the transfer market is another and doesn't seem justified. -- ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================= From info at leadertelecom.ru Wed Nov 7 23:02:08 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Thu, 8 Nov 2012 02:02:08 +0400 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AD8FE.6010304@umn.edu> References: <509AD8FE.6010304@umn.edu><1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> Message-ID: <1352325727.397817.196039249.257473.2@otrs.hostingconsult.ru> >?*Allow IPv4 PI from the transfer market Very good idea! --? Alexey Ivanov ? 08.11.2012 01:57 - David Farmer ???????(?): On 11/7/12 14:17 , Yannis Nikolopoulos wrote: > Hello Gert, > > As Richard said, the question here is whether we should > hand out PI from the last /8 or not. I think there is another viable option; *Allow IPv4 PI from the transfer market But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy.??If, I'm wrong about this please correct me. If the RIPE community doesn't want to make IPv4 PI assignments out of its last /8, I think that is defensible.??If someone wants something out of the last /8, making them become an LIR seems reasonable as well. However, saying there is no such thing as IPv4 PI any longer is not reasonable when there is a viable transfer market available as a source of addresses. The whole point of creating a IPv4 transfer market was to encourage getting unused or underutilized IPv4 addresses in to the hands of those that need them.??End users need for IPv4 PI is just as important and valid of a use for IPv4 as ISP need for IPv4.??Shutting IPv4 PI out of the last /8 is one thing, shutting IPv4 PI out of the transfer market is another and doesn't seem justified. -- ================================================= David Farmer????????????????Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE??????Phone: 1-612-626-0815 Minneapolis, MN 55414-3029?? Cell: 1-612-812-9952 ================================================= ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefine at aramin.net Wed Nov 7 23:12:26 2012 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Wed, 07 Nov 2012 23:12:26 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <1352325727.397817.196039249.257473.2@otrs.hostingconsult.ru> References: <509AD8FE.6010304@umn.edu><1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> <1352325727.397817.196039249.257473.2@otrs.hostingconsult.ru> Message-ID: <509ADCCA.2090005@aramin.net> W dniu 07.11.2012 23:02, LeaderTelecom Ltd. pisze: > > *Allow IPv4 PI from the transfer market > > Very good idea! allow transfer between operators and allow convert from pa space to pi space. and - all will be happy :) > > -- > Alexey Ivanov > > 08.11.2012 01:57 - David Farmer ???????(?): > On 11/7/12 14:17 , Yannis Nikolopoulos wrote: > > Hello Gert, > > > > As Richard said, the question here is whether we should > > hand out PI from the last /8 or not. > > I think there is another viable option; > > *Allow IPv4 PI from the transfer market > > But, I by my read of RIPE policy this isn't allow, or its not clear to > me that it is allowed when I read the policy. If, I'm wrong about this > please correct me. > > If the RIPE community doesn't want to make IPv4 PI assignments out of > its last /8, I think that is defensible. If someone wants something out > of the last /8, making them become an LIR seems reasonable as well. > However, saying there is no such thing as IPv4 PI any longer is not > reasonable when there is a viable transfer market available as a source > of addresses. > > The whole point of creating a IPv4 transfer market was to encourage > getting unused or underutilized IPv4 addresses in to the hands of those > that need them. End users need for IPv4 PI is just as important and > valid of a use for IPv4 as ISP need for IPv4. Shutting IPv4 PI out of > the last /8 is one thing, shutting IPv4 PI out of the transfer market is > another and doesn't seem justified. > > > -- > ================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================= > -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Nov 7 23:25:11 2012 From: farmer at umn.edu (David Farmer) Date: Wed, 07 Nov 2012 16:25:11 -0600 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509ADCCA.2090005@aramin.net> References: <509AD8FE.6010304@umn.edu><1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> <1352325727.397817.196039249.257473.2@otrs.hostingconsult.ru> <509ADCCA.2090005@aramin.net> Message-ID: <509ADFC7.9060301@umn.edu> On 11/7/12 16:12 , Andrzej Dopiera?a wrote: > W dniu 07.11.2012 23:02, LeaderTelecom Ltd. pisze: >> > *Allow IPv4 PI from the transfer market >> >> Very good idea! > allow transfer between operators and allow convert from pa space to pi > space. and - all will be happy :) That depends how the financial transactions are going to work, as a end user I wouldn't give an operator any money unless they had the addresses already. If the users PI need is being used to justify the operator receiving the transfer then will RIPE approve the transfer? I'm not saying it can't work, but I don't think it is as simple as you say. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From sander at steffann.nl Thu Nov 8 00:32:07 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 8 Nov 2012 00:32:07 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AD8FE.6010304@umn.edu> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> <509AD8FE.6010304@umn.edu> Message-ID: Hi, > I think there is another viable option; > > *Allow IPv4 PI from the transfer market > > But, I by my read of RIPE policy this isn't allow, or its not clear to me that it is allowed when I read the policy. If, I'm wrong about this please correct me. No, you are right. The *current* policy doesn't allow IPv4 PI address transfers. Policies can change of course. That's what this list is for :-) Thanks, Sander From swmike at swm.pp.se Thu Nov 8 04:48:10 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 8 Nov 2012 04:48:10 +0100 (CET) Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121107181703.GE13776@Space.Net> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> Message-ID: On Wed, 7 Nov 2012, Gert Doering wrote: > If everybody gets exhausted doing a new round of IPv4 PI policy every > time the "we do IPv4 PI only until happens, and then no more!" mark > is reached, other policy proposals do not get the attention they > deserve. I agree totally. This seems to happen all the time, people just want to solve the problems of today and care little about the longer term. I'm exhausted by this, so I would like to see a policy that handles all of the space. Also, since people seem to be motivated to get IPv4 space and don't care about IPv6, let's just put a price on IPv4 which is now a scarce resource. I would like RIPE to stop doing justification handling for IPv4. Just stop. It's wasted time for everybody. People have IPv4 addresses, they won't get substantially more, people will game the system to not have to return them. Let people trade them as they want, and new PI (/24) or PA (/22) space costs the equivalent per-IPv4 address cost as getting a new LIR, getting the /22, and paying the fees. This would mean a /24 PI out of the remaining pool costs 1/4 of the /22 LIR cost (which would mean what, around 750 EUR per year) ? Just take the money, keep down on administration, and use the excess money to fund community development projects (R&D, FOSS etc). > (By which I'd ask you to please stay away from a PI policy that will do > things like "but only in the first /9 of the last /8, not in the second > /9" - *iff* the community decides to bring back IPv4 PI, then let's do > it for good and for all the remaining space. Doing it for "but not for > the last /x" is exactly what we have now - let's not do *that* again). I totally agree. -- Mikael Abrahamsson email: swmike at swm.pp.se From tore.anderson at redpill-linpro.com Thu Nov 8 08:43:15 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 08 Nov 2012 08:43:15 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509A4BB7.4020607@go6.si> References: <509A4BB7.4020607@go6.si> Message-ID: <509B6293.9080500@redpill-linpro.com> * Jan Zorz @ go6.si > We encountered LIRs that are operators and in the past they bought other > small operators and joined for example 3 LIRs under one and now they > have 3 x /32 (of course with that /29 as reserved space). > > When those LIRs asked for extension to /29 they received a response from > IPRAs, that they can extend to /29 *in total* as written in the policy. I assume you mean "that LIR" (i.e., the single consolidated LIR) here? As I understand it, if the three LIRs had individually requested their /29 extension *before* being merged into one single LIR, they would have gotten them, and I don't believe that they would have had to give two of them back after the merger either. So they accidentally painted themselves into a policy corner by doing things in the wrong order. I would be happy to support such a proposal on the grounds that the order of things should not matter in this way. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson at redpill-linpro.com Thu Nov 8 08:54:10 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 08 Nov 2012 08:54:10 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> Message-ID: <509B6522.1090707@redpill-linpro.com> * Mikael Abrahamsson > I would like RIPE to stop doing justification handling for IPv4. Just > stop. It's wasted time for everybody. For what it's worth, I agree fully, and I've already prepared a proposal that does exactly this. It's awaiting review by the WG chairs before being formally submitted. If you or anyone else would like to (p)review it to see if it is in a shape you could support, or even help co-author it, that would be much appreciated. >> (By which I'd ask you to please stay away from a PI policy that will >> do things like "but only in the first /9 of the last /8, not in the >> second /9" - *iff* the community decides to bring back IPv4 PI, then >> let's do it for good and for all the remaining space. Doing it for >> "but not for the last /x" is exactly what we have now - let's not do >> *that* again). > > I totally agree. Partially to this end, my proposal also takes the opportunity to clean up the last /8 policy - making it "the everything policy" - by merging it into or replacing the main policy sections. (It does not seek to actually change the mechanics of the last /8 policy though, only to do some cosmetic reconstructive surgery. This means the two "last /16" reservations for IXPs and unforeseen circumstances remain.) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From corebug at corebug.net Thu Nov 8 10:07:43 2012 From: corebug at corebug.net (=?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KLRg9GA0L7QstC10YY=?=) Date: Thu, 8 Nov 2012 11:07:43 +0200 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509B6522.1090707@redpill-linpro.com> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509B6522.1090707@redpill-linpro.com> Message-ID: Hello there people! I've read this list for quite a long time now and finally achieved the point when i would like to ask: how do we start voting process, or, say, create a new policy proposal regarding the prohibition of PI/PA space exchange between operators? I strongly agree with my colleagues from LeaderTelecom: the transfers definitely will occur, no matter whether RIPE NCC wants them to or not, but if we create a policy that allows such transfers in a "legal" (from RIPE's perspective) way, than those at least will become organized. If by now policy does not change - i'm very much sure that lots of origin ASNs will travel to new geographic locations :) -- ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP NOC Lead @Service Outsourcing company +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv From jan at go6.si Thu Nov 8 10:10:32 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 08 Nov 2012 10:10:32 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509B6293.9080500@redpill-linpro.com> References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> Message-ID: <509B7708.1020209@go6.si> On 11/8/12 8:43 AM, Tore Anderson wrote: > * Jan Zorz @ go6.si > >> We encountered LIRs that are operators and in the past they bought other >> small operators and joined for example 3 LIRs under one and now they >> have 3 x /32 (of course with that /29 as reserved space). >> >> When those LIRs asked for extension to /29 they received a response from >> IPRAs, that they can extend to /29 *in total* as written in the policy. > > I assume you mean "that LIR" (i.e., the single consolidated LIR) here? Tore, hi Well, there are probably many consolidated LIRs here. I personally know of few of them. Nick showed some numbers (thnx) - but I would suggest to ask RIPE-NCC staff for the "consolidated-LIRs-with-multiple-/32" numbers - what is this number we are talking about. > > As I understand it, if the three LIRs had individually requested their > /29 extension *before* being merged into one single LIR, they would have > gotten them, and I don't believe that they would have had to give two of > them back after the merger either. So they accidentally painted > themselves into a policy corner by doing things in the wrong order. > > I would be happy to support such a proposal on the grounds that the > order of things should not matter in this way. Good point, agree. We ran into small procedural inconvenience that should be fixed imho. Cheers, Jan From tore.anderson at redpill-linpro.com Thu Nov 8 10:17:36 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 08 Nov 2012 10:17:36 +0100 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509B6522.1090707@redpill-linpro.com> Message-ID: <509B78B0.2000708@redpill-linpro.com> Hi Vitaliy, * ??????? ??????? > I've read this list for quite a long time now and finally achieved the > point when i would like to ask: how do we start voting process, or, > say, create a new policy proposal regarding the prohibition of PI/PA > space exchange between operators? Transfer of PA space is already allowed under current policy. There's no explicit *prohibition* of transfer of PI space, there's simply no policy that regulates it. My guess it's simply not there because there was no need for it in the past. > I strongly agree with my colleagues from LeaderTelecom: the transfers > definitely will occur, no matter whether RIPE NCC wants them to or > not, The RIPE NCC does not have any preference in the matter. The RIPE NCC simply does what the RIPE Community (that's you and me!) tells it to do. > but if we create a policy that allows such transfers That's precisely what you would have to do in order to allow for transfer of PI space. I'd suggest you review the following pages, which document the RIPE Policy Development Process: http://www.ripe.net/ripe/policies http://www.ripe.net/ripe/docs/ripe-500 http://www.ripe.net/ripe/policies/policy-development-process-glossary Next, write up a proposal and submit it. Then the Address Policy WG can discuss it to determine whether or not there is consensus for it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Remco.vanMook at eu.equinix.com Thu Nov 8 11:33:51 2012 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 8 Nov 2012 10:33:51 +0000 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509B78B0.2000708@redpill-linpro.com> Message-ID: Hi Tore, To clarify: the original proposed transfer policy had no limitations included whatsoever. We ended up with all the limitations in there as a compromise to get any transfer policy reaching consensus at all within the RIPE NCC service region, being the first region in the world with a transfer policy in place back in the day. As other regions have now adopted transfer policies as well, the one in hte RIPE NCC resion is now by far the most restrictive, and I would encourage anyone to do a proposal to remove some or all of the limitations in current policy. Best Remco (one of the authors of the current transfer policy) On 08-11-12 10:17, "Tore Anderson" wrote: >Hi Vitaliy, > >* ??????? ??????? > >> I've read this list for quite a long time now and finally achieved the >> point when i would like to ask: how do we start voting process, or, >> say, create a new policy proposal regarding the prohibition of PI/PA >> space exchange between operators? > >Transfer of PA space is already allowed under current policy. > >There's no explicit *prohibition* of transfer of PI space, there's >simply no policy that regulates it. My guess it's simply not there >because there was no need for it in the past. > >> I strongly agree with my colleagues from LeaderTelecom: the transfers >> definitely will occur, no matter whether RIPE NCC wants them to or >> not, > >The RIPE NCC does not have any preference in the matter. The RIPE NCC >simply does what the RIPE Community (that's you and me!) tells it to do. > >> but if we create a policy that allows such transfers > >That's precisely what you would have to do in order to allow for >transfer of PI space. I'd suggest you review the following pages, which >document the RIPE Policy Development Process: > >http://www.ripe.net/ripe/policies >http://www.ripe.net/ripe/docs/ripe-500 >http://www.ripe.net/ripe/policies/policy-development-process-glossary > >Next, write up a proposal and submit it. Then the Address Policy WG can >discuss it to determine whether or not there is consensus for it. > >Best regards, >-- >Tore Anderson >Redpill Linpro AS - http://www.redpill-linpro.com > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From mueller at syr.edu Thu Nov 8 12:45:28 2012 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 8 Nov 2012 11:45:28 +0000 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <50962F75.6060605@redpill-linpro.com> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> <50962F75.6060605@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD227BE19@SUEX10-mbx-10.ad.syr.edu> Sorry for the slow response, am I an Internet Governance Forum where there is no internet access. > -----Original Message----- > The NCC's impact analysis seemed to address this concern, by saying, > essentially: just have to ask us first>. > > So I asked. To my surprise, I got a negative answer. > > In light of that, it would seem that we do need to compel the NCC to > publish the information after all. Hence, I do support 2012-05. > > That said, if the NCC at a later point in the PDP starts publishing the > information voluntarily, I withdraw my support of the proposal and > instead object to it, on the grounds that it will be redundant and only > serve to further bloat the policy text. > [Milton L Mueller] Your point is logical. I just hope the proposal passes before the NCC changes its mind again! From tore.anderson at redpill-linpro.com Thu Nov 8 14:21:26 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 08 Nov 2012 14:21:26 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD227BE19@SUEX10-mbx-10.ad.syr.edu> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227A601@SUEX10-mbx-10.ad.syr.edu> <50962F75.6060605@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD227BE19@SUEX10-mbx-10.ad.syr.edu> Message-ID: <509BB1D6.7030609@redpill-linpro.com> * Milton L Mueller >> In light of that, it would seem that we do need to compel the NCC >> to publish the information after all. Hence, I do support 2012-05. >> >> That said, if the NCC at a later point in the PDP starts publishing >> the information voluntarily, I withdraw my support of the proposal >> and instead object to it, on the grounds that it will be redundant >> and only serve to further bloat the policy text. >> > [Milton L Mueller] Your point is logical. I just hope the proposal > passes before the NCC changes its mind again! I got a clarification of the NCC's position off-list, which I might as summarise here: They are in willing to publish voluntarily, but since there's now a proposal being discussed, they would like to wait - if it turns out that the proposal falls through ***due to the community consensus being that the information should NOT be made public***, then they would change their position on voluntary publication, which does make sense. So when the WG chairs declares there is consensus for the proposal (or it fails for any other reason than "this info shouldn't be public") we should IMHO ask the NCC to voluntarily publish again, and skip the actual amending of the policy text. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From bgp2 at linuxadmin.org Thu Nov 8 16:00:04 2012 From: bgp2 at linuxadmin.org (Greg) Date: Thu, 08 Nov 2012 10:00:04 -0500 Subject: [address-policy-wg] [Ticket#2012110601002595] Status of /24 PI IPv4 from last /8 In-Reply-To: <509AC1C6.6000605@otenet.gr> References: <1352284691.42716.7545652888.257473.2@otrs.hostingconsult.ru> <509A4603.8050105@inex.ie> <509A47A2.2040002@go6.si> <509A4E18.9070008@inex.ie> <20121107121338.GA13776@Space.Net> <509A59F5.5080500@inex.ie> <20121107125847.GC13776@Space.Net> <509A63A5.30602@inex.ie> <20121107134513.GD13776@Space.Net> <20121107181703.GE13776@Space.Net> <509AC1C6.6000605@otenet.gr> Message-ID: <951664d2a5d7e8b7066f868fc3383543@utraffic.com> Hello. Absolutely right.... Applying for LIR status just for multi-homing where /24 PI space is more than enough is a waste of much bigger IPv4 space, but then again more money for some ..... :> Greg On 2012-11-07 15:17, Yannis Nikolopoulos wrote: > Hello Gert, > > On 11/07/2012 08:17 PM, Gert Doering wrote: >> Hi, >> >> On Wed, Nov 07, 2012 at 04:41:51PM +0100, Richard Hartmann wrote: >>> To put it differently: Why does anyone who considers IPv4 legacy >>> care >>> about how it's used up? >> Well, I *do* care about the way we use the community's resources in >> policy building. > > I'm confused. We should all care about the way the community's > resources are used. That's the whole point of this discussion (and > this group). What we're now seeing, is new LIRs that never wanted to > become LIRs in the first place and just wanted a /24 of PI space. > They > have no (real) alternative though if they want to multihome (as an > LIR/ISP I'm with Nick on this one). How's that fair on them, > considering registration and handling fees? > > As far as IPv6 goes, most of us or on the same boat, no need to state > the obvious. As Richard said, the question here is whether we should > hand out PI from the last /8 or not. > > regards, > Yannis From ggiannou at gmail.com Fri Nov 9 10:00:41 2012 From: ggiannou at gmail.com (George Giannousopoulos) Date: Fri, 9 Nov 2012 11:00:41 +0200 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509B7708.1020209@go6.si> References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> <509B7708.1020209@go6.si> Message-ID: Hi all, Although it may not affect so many LIRs, it has to be fixed Otherwise the reserved and not allocated space between the initial /32 and the /29 will be wasted, since no one will be eligible to claim it. I agree too. George On Thu, Nov 8, 2012 at 11:10 AM, Jan Zorz @ go6.si wrote: > On 11/8/12 8:43 AM, Tore Anderson wrote: > >> * Jan Zorz @ go6.si >> >> We encountered LIRs that are operators and in the past they bought other >>> small operators and joined for example 3 LIRs under one and now they >>> have 3 x /32 (of course with that /29 as reserved space). >>> >>> When those LIRs asked for extension to /29 they received a response from >>> IPRAs, that they can extend to /29 *in total* as written in the policy. >>> >> >> I assume you mean "that LIR" (i.e., the single consolidated LIR) here? >> > > Tore, hi > > Well, there are probably many consolidated LIRs here. I personally know of > few of them. Nick showed some numbers (thnx) - but I would suggest to ask > RIPE-NCC staff for the "consolidated-LIRs-with-**multiple-/32" numbers - > what is this number we are talking about. > > > >> As I understand it, if the three LIRs had individually requested their >> /29 extension *before* being merged into one single LIR, they would have >> gotten them, and I don't believe that they would have had to give two of >> them back after the merger either. So they accidentally painted >> themselves into a policy corner by doing things in the wrong order. >> >> I would be happy to support such a proposal on the grounds that the >> order of things should not matter in this way. >> > > Good point, agree. We ran into small procedural inconvenience that should > be fixed imho. > > Cheers, Jan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Fri Nov 9 11:35:47 2012 From: andrea at ripe.net (Andrea Cima) Date: Fri, 09 Nov 2012 11:35:47 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509B7708.1020209@go6.si> References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> <509B7708.1020209@go6.si> Message-ID: <509CDC83.3030204@ripe.net> Hi Jan, On 11/8/12 10:10 AM, Jan Zorz @ go6.si wrote: > On 11/8/12 8:43 AM, Tore Anderson wrote: >> * Jan Zorz @ go6.si >> >>> We encountered LIRs that are operators and in the past they bought >>> other >>> small operators and joined for example 3 LIRs under one and now they >>> have 3 x /32 (of course with that /29 as reserved space). >>> >>> When those LIRs asked for extension to /29 they received a response >>> from >>> IPRAs, that they can extend to /29 *in total* as written in the policy. >> >> I assume you mean "that LIR" (i.e., the single consolidated LIR) here? > > Tore, hi > > Well, there are probably many consolidated LIRs here. I personally > know of few of them. Nick showed some numbers (thnx) - but I would > suggest to ask RIPE-NCC staff for the > "consolidated-LIRs-with-multiple-/32" numbers - what is this number we > are talking about. > In total there are 64 LIRs with more than one IPv6 allocation. Of them, - 52 LIRs have 2 IPv6 allocations each, - 5 LIRs have 4 IPv6 allocations each, - 4 LIRs have 3 IPv6 allocations each, - 2 LIRs have 5 IPv6 allocations each, - 1 LIR has 10 IPv6 allocations. This data is also publicly available at: ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt Like has been mentioned on the mailing list, this is the result of mergers and acquisitions over time. I hope this helps Andrea Cima RIPE NCC >> >> As I understand it, if the three LIRs had individually requested their >> /29 extension *before* being merged into one single LIR, they would have >> gotten them, and I don't believe that they would have had to give two of >> them back after the merger either. So they accidentally painted >> themselves into a policy corner by doing things in the wrong order. >> >> I would be happy to support such a proposal on the grounds that the >> order of things should not matter in this way. > > Good point, agree. We ran into small procedural inconvenience that > should be fixed imho. > > Cheers, Jan > > From jan at go6.si Fri Nov 9 12:30:45 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 09 Nov 2012 12:30:45 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509CDC83.3030204@ripe.net> References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> <509B7708.1020209@go6.si> <509CDC83.3030204@ripe.net> Message-ID: <509CE965.7010003@go6.si> On 11/9/12 11:35 AM, Andrea Cima wrote: > In total there are 64 LIRs with more than one IPv6 allocation. > > Of them, > - 52 LIRs have 2 IPv6 allocations each, > - 5 LIRs have 4 IPv6 allocations each, > - 4 LIRs have 3 IPv6 allocations each, > - 2 LIRs have 5 IPv6 allocations each, > - 1 LIR has 10 IPv6 allocations. > > This data is also publicly available at: > ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt > > Like has been mentioned on the mailing list, this is the result of > mergers and acquisitions over time. Andrea, thank you for this info... So far I heard from this WG that we should fix this little issue. Any suggestion from the chairs? Cheers, Jan From sander at steffann.nl Fri Nov 9 13:10:16 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 9 Nov 2012 13:10:16 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509CE965.7010003@go6.si> References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> <509B7708.1020209@go6.si> <509CDC83.3030204@ripe.net> <509CE965.7010003@go6.si> Message-ID: Hi Jan, > Andrea, thank you for this info... > > So far I heard from this WG that we should fix this little issue. Any suggestion from the chairs? There seems to be support for this, and I haven't seen any objections. I think it's time for you to start writing a policy proposal text that we can discuss here. Emilio: can you contact Jan and help to get this started? Thanks! Sander From emadaio at ripe.net Fri Nov 9 13:15:48 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 09 Nov 2012 13:15:48 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: References: <509A4BB7.4020607@go6.si> <509B6293.9080500@redpill-linpro.com> <509B7708.1020209@go6.si> <509CDC83.3030204@ripe.net> <509CE965.7010003@go6.si> Message-ID: <509CF3F4.4070108@ripe.net> Hi Sander, I will contact Jan and help the process of creating a policy proposal. Thanks to all the WG for the participation in the mailing list and the clear feedback so far. Regards Emilio On 11/9/12 1:10 PM, Sander Steffann wrote: > Hi Jan, > >> Andrea, thank you for this info... >> >> So far I heard from this WG that we should fix this little issue. Any suggestion from the chairs? > > > There seems to be support for this, and I haven't seen any objections. I think it's time for you to start writing a policy proposal text that we can discuss here. Emilio: can you contact Jan and help to get this started? > > Thanks! > Sander > From gert at space.net Fri Nov 9 13:49:51 2012 From: gert at space.net (Gert Doering) Date: Fri, 9 Nov 2012 13:49:51 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <509A4BB7.4020607@go6.si> References: <509A4BB7.4020607@go6.si> Message-ID: <20121109124951.GC13776@Space.Net> Hi, On Wed, Nov 07, 2012 at 12:53:27PM +0100, Jan Zorz @ go6.si wrote: > When those LIRs asked for extension to /29 they received a response from > IPRAs, that they can extend to /29 *in total* as written in the policy. > > The policy says: > > "LIRs that hold one or more IPv6 allocations are able to request > extension of these allocations up to a *total* of a /29 without > providing further documentation." Actually, I think the IPRAs are reading something in there that has not been the intention by the WG (and it should be obvious from the discussions that it wasn't, because the case "what about a LIR that has more than one /32?" was never discussed) For non-native speakers (like me), the sentence above is perfectly fine to be interpreted as "... extensions of *any of these* allocations up to a total of /29..." and not "... up to a total of a /29 across all IPv6 stock the LIR has". We've been there with the "80% utilization" in IPv4, where the IPRA interpretation was more strict than what the WG intended, and it seems that this is another of these cases... Anyway, to give clear guidance to the NCC, I think having Jan and Emilio draft new text, have this be cross-checked by the NCC for interpretation leeway, and then formally accept it via the PDP, is the right way forward. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sandrabrown at ipv4marketgroup.com Fri Nov 9 14:21:54 2012 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Fri, 09 Nov 2012 06:21:54 -0700 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published(Transparency in Address Block Transfers) Message-ID: <20121109062154.ec289651d84890fcbef5f195936e1217.33fbb1e0fd.wbe@email17.secureserver.net> An HTML attachment was scrubbed... URL: From sandrabrown at ipv4marketgroup.com Fri Nov 9 14:23:22 2012 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Fri, 09 Nov 2012 06:23:22 -0700 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published(Transparency in Address Block Transfers) Message-ID: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> As a broker in the IPv4 space, I support 2012-05 100%. We need transparency in transaction pricing. Otherwise there will continue to be black markets and unscrupulous operators. I view my job as finding buyers to match sellers and finding sellers to match buyer needs. Just as in stock markets, commodity markets, and housing markets, IPv4 markets require open pricing. Only then will most people give this market legitimacy and most of the devious behaviour go away. Further, other RIR policies need to morph to support open-ness. For example, RIR's should not reclaim unused IP's now that they have value. Global barriers to trade (think inter-RIR transfers) have to come down so that prices in one part of the world are not different from other parts. Although this is a little off-topic, the use of needs justification is a huge barrier to honest and open trade (as per Milton's workshop in Baku earlier this week). Companies are doing some very creative things to avoid the RIR justification process and as a result the registries are getting less accurate, and the RIR's spout community credos rather than really look at the problem. The good news is these problems should be gone in 50 years when IPv4 is finally replaced by IPv6! Sandra Brown President IPv4 Market Group sandrabrown at ipv4marketgroup.com 716-348-6768 www.ipv4marketgroup.com From andreas at schachtner.eu Fri Nov 9 14:51:54 2012 From: andreas at schachtner.eu (Andreas Schachtner) Date: Fri, 9 Nov 2012 14:51:54 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <20121109124951.GC13776@Space.Net> References: <509A4BB7.4020607@go6.si> <20121109124951.GC13776@Space.Net> Message-ID: <20121109145154.5270efa3@foohome> Am Fri, 9 Nov 2012 13:49:51 +0100 schrieb Gert Doering : ... > Actually, I think the IPRAs are reading something in there that has > not been the intention by the WG (and it should be obvious from the > discussions that it wasn't, because the case "what about a LIR that > has more than one /32?" was never discussed) > > For non-native speakers (like me), the sentence above is perfectly > fine to be interpreted as "... extensions of *any of these* > allocations up to a total of /29..." and not "... up to a total of > a /29 across all IPv6 stock the LIR has". From an old programmers paradigm "be liberate on what you receive and strict what you send" I would interpret the policy like the NCC (to be on the safe side). Under business and policy aspects, your reasoning absolutely makes sense to me. +1 for your suggestion. Andreas -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund From jim at rfc1035.com Fri Nov 9 15:20:00 2012 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Nov 2012 14:20:00 +0000 Subject: [address-policy-wg] openness in RIR policies In-Reply-To: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> References: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> Message-ID: <9E1B29AC-95E9-4764-821A-714037B20B56@rfc1035.com> On 9 Nov 2012, at 13:23, sandrabrown at ipv4marketgroup.com wrote: > Further, other RIR policies need to morph to support open-ness. Please explain. In what way do RIR policies not support openness or transparency. Or are not open and transparent enough? Feel free to submit proposals which improve these principles. > For example, RIR's should not reclaim unused IP's now that they have value. This has nothing to do with openness or RIR policies. I think you're mistaken too. First off, it's IP addresses, not "IPs". Second, current policy says LIRs are supposed to return unused resources to their RIR when they no longer need/use them. Can you provide an example where an RIR has reclaimed unused addresses from an LIR? [Some address space has of course been recovered by the RIRs and IANA. However to the best of my knowledge that's pretty much been unused legacy space that had been given to organisations that no longer exist.] An RIR has no way of knowing definitively if an LIR is using its address space or not unless the LIR confirms that. Finally, whatever action an RIR takes over an LIR's unused address space is decided by RIR policy, not whether those addresses "have value". For some definition of "have value". AFAICT nobody's suggesting a policy change so RIRs can reclaim addresses (and re-sell them?) now that a market in v4 space is emerging. Now whether an LIR will hand back its unused space or not is an entirely different matter from RIR policy or its openness. Perhaps those LIRs will want to trade their unused space. Perhaps not. That's largely a matter for them and their consciences. From presiden at ukraine.su Fri Nov 9 16:03:17 2012 From: presiden at ukraine.su (Max Tulyev) Date: Fri, 9 Nov 2012 17:03:17 +0200 Subject: [address-policy-wg] openness in RIR policies In-Reply-To: <9E1B29AC-95E9-4764-821A-714037B20B56@rfc1035.com> References: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> <9E1B29AC-95E9-4764-821A-714037B20B56@rfc1035.com> Message-ID: <25F52741-3531-4F76-936E-C98731931739@ukraine.su> The problem is that these "just numbers" became to have a real value, and this value grows fast. This is a real life, whatever you want it or not. If the policies will remain same as from time it has no values - it will lead to the dark crime market. I do not want this way to be real, but it becoming true now. So we need to adjust policies with that real life situation. I support Sandra. On 9. 11. 2012, at 16:20, Jim Reid wrote: > On 9 Nov 2012, at 13:23, sandrabrown at ipv4marketgroup.com wrote: > >> Further, other RIR policies need to morph to support open-ness. > > Please explain. In what way do RIR policies not support openness or transparency. Or are not open and transparent enough? Feel free to submit proposals which improve these principles. > >> For example, RIR's should not reclaim unused IP's now that they have value. > > This has nothing to do with openness or RIR policies. I think you're mistaken too. > > First off, it's IP addresses, not "IPs". Second, current policy says LIRs are supposed to return unused resources to their RIR when they no longer need/use them. Can you provide an example where an RIR has reclaimed unused addresses from an LIR? [Some address space has of course been recovered by the RIRs and IANA. However to the best of my knowledge that's pretty much been unused legacy space that had been given to organisations that no longer exist.] An RIR has no way of knowing definitively if an LIR is using its address space or not unless the LIR confirms that. Finally, whatever action an RIR takes over an LIR's unused address space is decided by RIR policy, not whether those addresses "have value". For some definition of "have value". AFAICT nobody's suggesting a policy change so RIRs can reclaim addresses (and re-sell them?) now that a market in v4 space is emerging. > > Now whether an LIR will hand back its unused space or not is an entirely different matter from RIR policy or its openness. Perhaps those LIRs will want to trade their unused space. Perhaps not. That's largely a matter for them and their consciences. > > From nigel at titley.com Mon Nov 12 18:52:56 2012 From: nigel at titley.com (Nigel Titley) Date: Mon, 12 Nov 2012 17:52:56 +0000 Subject: [address-policy-wg] openness in RIR policies In-Reply-To: <25F52741-3531-4F76-936E-C98731931739@ukraine.su> References: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> <9E1B29AC-95E9-4764-821A-714037B20B56@rfc1035.com> <25F52741-3531-4F76-936E-C98731931739@ukraine.su> Message-ID: <50A13778.8060701@titley.com> On 09/11/2012 15:03, Max Tulyev wrote: > The problem is that these "just numbers" became to have a real value, and this value grows fast. > This is a real life, whatever you want it or not. > If the policies will remain same as from time it has no values - it will lead to the dark crime market. I do not want this way to be real, but it becoming true now. > So we need to adjust policies with that real life situation. I support Sandra. > I don't think that anything Jim said contradicts you. Jim took issue with a couple of throwaway remarks: "Other RIR policies need to morph to support open-ness (sic)" "RIRs should not reclaim unused IP's (sic) now that they have value" neither of which she appeared to justify. Nigel From nigel at titley.com Mon Nov 12 18:46:25 2012 From: nigel at titley.com (Nigel Titley) Date: Mon, 12 Nov 2012 17:46:25 +0000 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published(Transparency in Address Block Transfers) In-Reply-To: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> References: <20121109062322.ec289651d84890fcbef5f195936e1217.820f92dffd.wbe@email17.secureserver.net> Message-ID: <50A135F1.4090309@titley.com> On 09/11/2012 13:23, sandrabrown at ipv4marketgroup.com wrote: > As a broker in the IPv4 space, I support 2012-05 100%. We need > transparency in transaction pricing. Otherwise there will continue to > be black markets and unscrupulous operators. I view my job as finding > buyers to match sellers and finding sellers to match buyer needs. Just > as in stock markets, commodity markets, and housing markets, IPv4 > markets require open pricing. Only then will most people give this > market legitimacy and most of the devious behaviour go away. > As I read it, 2012-05 does nothing to increase transparency in transaction pricing. The RIPE NCC will not be involved in the commercial discussions around a transfer and will in general have no idea of whether money changed hands at all. Nigel From maildanrl at gmail.com Fri Nov 23 17:15:31 2012 From: maildanrl at gmail.com (Dan Luedtke) Date: Fri, 23 Nov 2012 17:15:31 +0100 Subject: [address-policy-wg] Another small IPv6 allocation policy change proposal (sanity check email)... In-Reply-To: <20121109145154.5270efa3@foohome> References: <509A4BB7.4020607@go6.si> <20121109124951.GC13776@Space.Net> <20121109145154.5270efa3@foohome> Message-ID: I support this proposal and as non-native speaker I would never have read it other than "you can extend all /32 you have". I think thats a perfect example of how careful one schould be reading/writing proposals, especial us non-native guys. Greetings Dan From emadaio at ripe.net Mon Nov 26 15:41:01 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 26 Nov 2012 15:41:01 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document Published (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: Dear Colleagues, The draft document for the proposal described in 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-02 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 24 December 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Mon Nov 26 16:22:33 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 26 Nov 2012 16:22:33 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) Message-ID: Dear Colleagues, The draft document for the proposal described in 2012-03, "Intra-RIR Transfer Policy Proposal", has been published. The impact analysis that was conducted for this proposal has also been published You can find the full proposa and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-03 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 24 December 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From tore.anderson at redpill-linpro.com Mon Nov 26 22:27:37 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 26 Nov 2012 22:27:37 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <20121126152257.EBC67C3DEB@mailhub.linpro.no> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> Message-ID: <50B3DEC9.6040406@redpill-linpro.com> * Emilio Madaio > The draft document for the proposal described in 2012-03, "Intra-RIR > Transfer Policy Proposal", has been published. The impact analysis > that was conducted for this proposal has also been published > > You can find the full proposa and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-03 On this page, it would appear that the phrase ?Within the RIPE NCC service region,? is to be added at the beginning of the second paragraph in section 5.5. > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-03/draft However, that phrase is not found in the ?new text? box on this page. That must be an omission? As a general feedback to the draft document page, not specific to 2012-03, I find it preferable if the ?original text? and ?new text? boxes are made as small as absolutely possible. If the paragraphs that aren't touched by the proposal are kept outside of those boxes, it is much easier to spot the actual changes made, than it is if you include the entire original and new section side-by-side (as is the case with 2012-03's draft document). Taking it one step further, it would be even better if those paragraphs that have only change by a small amount (i.e., aren't completely rewritten) have the actual changes highlighted, e.g., using strikethrough for deleted text, and coloured text for added text (such as the "Within the RIPE NCC service region" added by this proposal). The changes indicated in sections 6.0 and 6.3 at https://www.ripe.net/ripe/policies/proposals/2009-03/draft are two examples I like. In any case, I support this policy proposal. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From frettled at gmail.com Tue Nov 27 00:33:02 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 27 Nov 2012 00:33:02 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <50B3DEC9.6040406@redpill-linpro.com> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> <50B3DEC9.6040406@redpill-linpro.com> Message-ID: On Mon, Nov 26, 2012 at 10:27 PM, Tore Anderson < tore.anderson at redpill-linpro.com> wrote: > As a general feedback to the draft document page, not specific to > 2012-03, I find it preferable if the ?original text? and ?new text? > boxes are made as small as absolutely possible. If the paragraphs that > aren't touched by the proposal are kept outside of those boxes, it is > much easier to spot the actual changes made, than it is if you include > the entire original and new section side-by-side (as is the case with > 2012-03's draft document). > > Taking it one step further, it would be even better if those paragraphs > that have only change by a small amount (i.e., aren't completely > rewritten) have the actual changes highlighted, e.g., using > strikethrough for deleted text, and coloured text for added text (such > as the "Within the RIPE NCC service region" added by this proposal). > > The changes indicated in sections 6.0 and 6.3 at > https://www.ripe.net/ripe/policies/proposals/2009-03/draft are two > examples I like. > Yes, that is far more helpful than other proposals I have taken the time to read, and makes it far easier to consider whether this is something I need to be concerned about or not, and to which extent. Clear indications of changes is vital for the decision process. In some document difference tracking views, there will be coloured differences, red for removed text, green for added, yellow for modified, and so on, plus markers such as arrows or plus/minus signs to indicate the differences for those who for some reason cannot discern the colours. But we digress, my apologies for going forward with that. > In any case, I support this policy proposal. > > After spending a bit more time than I felt was necessary for such small textual changes, I support it as well ? I _think_ I know what the changes mean. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Tue Nov 27 02:34:29 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 27 Nov 2012 02:34:29 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <50B3DEC9.6040406@redpill-linpro.com> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> <50B3DEC9.6040406@redpill-linpro.com> Message-ID: I agree with this proposal. That being said... On Mon, Nov 26, 2012 at 10:27 PM, Tore Anderson < tore.anderson at redpill-linpro.com> wrote: > As a general feedback to the draft document page, not specific to > 2012-03, I find it preferable if the ?original text? and ?new text? > boxes are made as small as absolutely possible. [...] Agreed. I have tried to raise this general point with RIPE repeatedly in the past with very little success. Maybe we could garner enough support for this now :) The documents we are dealing with are almost exclusively plain text. This is the _perfect_ use case for version control systems. Not relying on one, both internally and externally, seems archaic and error-prone, to me. Released documents would be in master, allowing anyone to clone a full copy for their convenience while _knowing_ that it is a complete and up-to-date copy. PDPs would be maintained in branches, updates to a PDP would be done by means of commits in the respective branches. If a PDP is successful, it's merged back into master. If not, it either lives on as a stale branch or gets moved into a special archive directory before being merged back into master. This would: * Keep diffs at the bare minimum in size * Allow everyone to display changes in the way they like best * Provide a single, canonical, up-to-date reference of all valid documents * Allow anyone to use their favorite text handling tool to view documents and changes * Ensure complete logging of all changes * Introduce more accountability * Allow statistical and other analysis * Enable anyone to find out when a particular line last changed within seconds (think `git blame`) * Allow proposals to be sent to RIPE by means of a patch, reducing mistakes and overhead on all sides * Propel this process forward into the 90ies of the last century ;) Personally, I would like to use git as the tool for this job, but any reasonably recent VCS under a FLOSS license would be better than the status quo. I would also be glad to help RIPE implement such a system and migrate to it. Depending on the amount of feedback this receives, it may be prudent to move this discussion somewhere else. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Tue Nov 27 11:45:27 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 27 Nov 2012 11:45:27 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <50B3DEC9.6040406@redpill-linpro.com> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> <50B3DEC9.6040406@redpill-linpro.com> Message-ID: <50B499C7.6030205@ripe.net> Dear Tore, all, Thank you for the notification. The draft policy text has been corrected. The execution of the PDP is always improving. If the RIPE community has input and ideas on the matter, like the ones recently expressed, please do not hesitate to email . I'll gladly collect your feedback to take action upon it. Best Regards Emilio On 11/26/12 10:27 PM, Tore Anderson wrote: > * Emilio Madaio > >> The draft document for the proposal described in 2012-03, "Intra-RIR >> Transfer Policy Proposal", has been published. The impact analysis >> that was conducted for this proposal has also been published >> >> You can find the full proposa and the impact analysis at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-03 > > On this page, it would appear that the phrase ?Within the RIPE NCC > service region,? is to be added at the beginning of the second paragraph > in section 5.5. > >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-03/draft > > However, that phrase is not found in the ?new text? box on this page. > That must be an omission? > > As a general feedback to the draft document page, not specific to > 2012-03, I find it preferable if the ?original text? and ?new text? > boxes are made as small as absolutely possible. If the paragraphs that > aren't touched by the proposal are kept outside of those boxes, it is > much easier to spot the actual changes made, than it is if you include > the entire original and new section side-by-side (as is the case with > 2012-03's draft document). > > Taking it one step further, it would be even better if those paragraphs > that have only change by a small amount (i.e., aren't completely > rewritten) have the actual changes highlighted, e.g., using > strikethrough for deleted text, and coloured text for added text (such > as the "Within the RIPE NCC service region" added by this proposal). > > The changes indicated in sections 6.0 and 6.3 at > https://www.ripe.net/ripe/policies/proposals/2009-03/draft are two > examples I like. > > In any case, I support this policy proposal. > > Best regards, > From richih.mailinglist at gmail.com Tue Nov 27 12:06:12 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 27 Nov 2012 12:06:12 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <50B499C7.6030205@ripe.net> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> <50B3DEC9.6040406@redpill-linpro.com> <50B499C7.6030205@ripe.net> Message-ID: On Tue, Nov 27, 2012 at 11:45 AM, Emilio Madaio wrote: > Thank you for the notification. The draft policy text has been > corrected. > Could you adapt the side-by-side version [1] as well please? The actual diff is more or less trivial as seen in the attachment. It's needlessly complicated to see the actual difference at a glance. > I'll gladly collect your feedback to take action upon it. > How does this process work, exactly? As implied by my initial email, I already tried to help improve this process in the past? Is there a phase of public review of options or similar? Are issues that may block adoption of new techniques documented publicly? Other than suggesting a change, what can the community do to influence or help with this process? Thanks, Richard [1] https://www.ripe.net/ripe/policies/proposals/2012-03/draft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 1639 bytes Desc: not available URL: From mike at IPTrading.com Tue Nov 27 18:40:15 2012 From: mike at IPTrading.com (Mike Burns) Date: Tue, 27 Nov 2012 12:40:15 -0500 Subject: [address-policy-wg] 2012-03 New Draft Document Published(Intra-RIR Transfer Policy Proposal) In-Reply-To: <50B3DEC9.6040406@redpill-linpro.com> References: <20121126152257.EBC67C3DEB@mailhub.linpro.no> <50B3DEC9.6040406@redpill-linpro.com> Message-ID: <645F7402A8EB4E46995673432E321A7F@MPC> Last month I brokered a sale of legacy ARIN space to a customer in the APNIC region using the Inter-RIR transfer policies in place in both regions. As we know, ARIN has the lion's share of IPv4 space, and this proposal would open the door to this source of address space for buyers in Europe. For sellers of RIPE space, this proposal provides another market or two to sell into. I believe a viable global transfer market in IPv4 addresses will assist in what appears to be a lengthy transition to IPv6 by making available underutilized address space and equalizing transition pressure around the world. I support the proposal. Regards, Mike Burns IPTrading.com -----Original Message----- From: Tore Anderson Sent: Monday, November 26, 2012 4:27 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2012-03 New Draft Document Published(Intra-RIR Transfer Policy Proposal) * Emilio Madaio > The draft document for the proposal described in 2012-03, "Intra-RIR > Transfer Policy Proposal", has been published. The impact analysis > that was conducted for this proposal has also been published > > You can find the full proposa and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-03 On this page, it would appear that the phrase ?Within the RIPE NCC service region,? is to be added at the beginning of the second paragraph in section 5.5. > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-03/draft However, that phrase is not found in the ?new text? box on this page. That must be an omission? As a general feedback to the draft document page, not specific to 2012-03, I find it preferable if the ?original text? and ?new text? boxes are made as small as absolutely possible. If the paragraphs that aren't touched by the proposal are kept outside of those boxes, it is much easier to spot the actual changes made, than it is if you include the entire original and new section side-by-side (as is the case with 2012-03's draft document). Taking it one step further, it would be even better if those paragraphs that have only change by a small amount (i.e., aren't completely rewritten) have the actual changes highlighted, e.g., using strikethrough for deleted text, and coloured text for added text (such as the "Within the RIPE NCC service region" added by this proposal). The changes indicated in sections 6.0 and 6.3 at https://www.ripe.net/ripe/policies/proposals/2009-03/draft are two examples I like. In any case, I support this policy proposal. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/