From ripedenis at gmail.com Wed Jan 5 14:20:43 2022 From: ripedenis at gmail.com (denis walker) Date: Wed, 5 Jan 2022 14:20:43 +0100 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems In-Reply-To: <1A7843A0-A746-4D97-9437-A25D1191E8E1@bais.name> References: <1A7843A0-A746-4D97-9437-A25D1191E8E1@bais.name> Message-ID: Colleagues Thanks Erik for the detailed reply. I have made many comments inline below. For those who don't like to read long emails I have summarised my main points first. ripe-682 RIPE Resource Transfer Policies needs updating. These are my suggestions: 1/ Policies must be self contained and consistent. 2/ There must be a definition of the most important terms within the policy. 3/ There must be a clear definition of what a 'transfer' is. 4/ There must be a clear definition of what a 'consolidation' is. 5/ The section 'Transfer Restrictions' should become 'Restrictions' and make it clear these restrictions apply to both transfers and consolidations. 6/ The section 'Transfer Statistics' should become 'Statistics'. Lists of all Transfers and Consolidations will be published. An open and transparent industry should make all changes to resource holdership clear. 7/ For Mergers & Acquisitions (M&A), transfer of authority, responsibility and liability for the transferred resources should move to the receiving party when the national company registry officially deregisters the legal entity currently holding the resources. There should be no period where no legal entity is responsible and liable for address space or other resources. 8/ There must be strict time periods for informing the RIPE NCC that a M&A has taken place and for finalising all paperwork and signing of new contracts following a M&A. For example: a/ The RIPE NCC must be informed of a M&A within 4 weeks of the deregistration of a company currently holding resources. b/ All paperwork and signing of new contracts must be finalised within 6 months of the date of the deregistration of the previous resource holding company 9/ Failure to comply with these time periods, without justifiable reasoning beyond the control of the member concerned, should allow the RIPE NCC to close the relevant LIRs and deregister the resources. 10/ These new conditions should be back dated to 1 Jan 2021. An amnesty can be allowed for all M&As not yet notified to the RIPE NCC provided such M&As are reported to the RIPE NCC within 4 weeks of this policy change being approved. ripe-733 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region also needs updating. These are my suggestions: 1/ "On application for IPv4 resources LIRs will receive IPv4 addresses according to the following" should become 'On application for IPv4 resources Members will receive IPv4 addresses according to the following' 2/ The following conditions should include: Groups of Members linked through complex structures of subsidiary companies, or companies connected through common directorships, are considered as a single Member for the purpose of these allocations. 3/ Those Members who bypass the intent of the waiting list by setting up complex webs of multiple (shell) companies should be required to return, to the RIPE NCC, the allocations previously allocated to them . 4/ These new conditions should be back dated to 1 Jan 2021. These suggestions are controversial and will be heavily opposed, especially by those few who have benefitted significantly from the waiting list policy. But let me remind you all that ripe-733 says: "Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks." Note "fairly" and "operating networks". Also policy proposal 2019-02 says: "The goal of this policy proposal is to keep providing newcomers with a minimal amount of IPv4 space from the RIR for as long as possible." "By extending the availability of IPv4 addresses to newcomers, the RIPE community demonstrates goodwill with regards competition laws and regulations." The way the policy has been applied throughout 2021, I have seen little sign of 'goodwill'. more comments inline below... On Thu, 23 Dec 2021 at 22:46, Erik Bais wrote: > > Hi Denis, > > As the writer of the last transfer policy document, I can put some light in this for you .. ( I hope.. ) > > The reason for wording like 'a legitmate resource holder' is to include all kind of number resources that holders might have. > Being it .. legacy, PI assignments or PA Allocations. Or .. a holder of an AS number. That makes sense except it is the wrong word. A legal or COMMS review by the NCC should pick up things like this. Legitimate means correct or valid. What you meant was 'a holder of any type of resource'. > > On your statement you cannot transfer a resource unless it is allocated.. would exclude PI assignments .. or Legacy space .. which can also be transferred. Agreed but I was using that statement to illustrate how one policy may depend on another policy. > > There are some documents on the RIPE NCC website that are not policies, but operational procedures, as you already found out .. or how I would state, explanations by interpretation of the RIPE NCC. > Like : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region > > The way consolidations of resources between LIR's within a member org work, is written and executed by a procedure of the RIPE NCC, not by definition of the transfer policy. > That comes originally from the M&A operational procedure that wasn't written down on the public website, but was possible under/by the Dutch legal framework. > And when this became pubic knowledge later, explained on the NCC website and even later, adjusted after executive board direction to keep LIR's open for 24 months. > ( Yes it was possible in the beginning of the so-called 'final /8 policy' to open a new LIR, request a /22 and merge it back into the initial lir and close the LIR directly.. ) This is a can of worms all on it's own. Consolidation is not defined in any policy. RIPE NCC procedural documents are supposed to explain or interpret policies. Consolidation is only referenced in a procedural document. So the RIPE NCC is not interpreting what consolidation means, they are defining it. That should be done by policy. > > That was seen as a loop-hole .. against the intent of the transfer restriction of the policy and that was the reasoning this was introduced by EB decision. > > Currently there some operational differences on how 'consolidation' or m&a's are processed within the RIPE NCC and how that expected when the paperwork that is requested by the RIPE NCC and one might expect. > If you do a M&A or consolidation, it was (originally) the case that it was required to also sign a Transfer Agreement ( https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfer-agreement-template ) The reasoning behind this practise (as I've been informed by legal from the RIPE NCC ) is to indemnify the RIPE NCC for legal actions .. > which in a fact is a bit weird, because the NCC is not a party in the Transfer agreement, but only the executor of an agreement between 2 parties. > But in this case the RIPE NCC benefits of legal exclusion on their operation.. But that is a complete different can of worms to discuss. And it actually puts the RIPE NCC in the path of legal action, instead of excluding it as a party. > > Currently if you do a transfer resources between LIR's of the same member organisation, you are only requested to upload a chamber of commerce document via the website and no other forms are needed anymore. This is consolidation that is not defined in any policy as a transfer. > > With a M&A, there are notary documents required ... which typically specifies that the number resources are also changing from organisation A to org. B. > Those are explained in detail on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/required-documents-for-registry-updates > And you can see that also the transfer agreement is requested .. even if this is officially NOT a transfer .. but somehow it has been impossible for the RIPE NCC to create a specific template for M&A's ... > The only reason for this that I can think of is .. the same legal indemnification that I mentioned earlier .. making the RIPE NCC also here a third party beneficiary to an agreement that it doesn't sign itself. ( looks weird to me .. ) > > So if you Merge a shell company with 20 LIR's to a company .. with let's say .. 3 LIR's .. you need to select the target LIR .. > However .. as the LIR holdership is restricted via the 24 month transfer restriction due to the earlier decision by the board, this isn't executed .. and all LIR's will end up in the target company if the resource wasn't allocated longer than 24 months ago. ( Again .. that isn't how the policy was designed or written .. as M&A's should be possible by transfer policy. ( https://www.ripe.net/participate/policies/proposals/2015-04/?version=4#transferrestrictions ) This is another can of worms. The policy is so vague here that almost anything is allowed. The policy makes no clear distinction between transfer of a resource or transfer or an LIR holding a resource. Applying this policy literally, with a merger, you can transfer the 'resources' (not LIRs holding resources) to (an LIR within) the receiving company. So consolidation (which is not defined by any policy) can occur as part of a merger, regardless of any transfer restrictions. This may not be the intent, but it is what this policy says (or doesn't say). So if the policies are the 'law' consolidate as you like with mergers. > And with this long read .. I come to a close of the statement by itself .. > I don't think that the transfer policy by itself is incorrect .. ( but I could be biased ..) ... > That the RIPE NCC operates the transfers slightly to its own interpretation I can understand .. and even with the above mentioned topics, I think they do this very good... > There is always room for improvement .. and we pick our battles. I would disagree here. I think the policy is a very long way away from the intent. cheers denis co-chair DB-WG > Regards, > Erik Bais > > > > ?On 22/12/2021, 16:01, "address-policy-wg on behalf of denis walker" wrote: > > Colleagues > > The Transfer Policy ripe-682 is so vague you can drive a train through > the holes in it. I have some questions that I hope someone can answer > before Christmas as I would like to propose an amendment to this > policy in the new year. > > "Any legitimate resource holder is allowed to transfer" > What does 'legitimate' mean in this context? It is not defined in this > policy document. It is no use referring to a dictionary or even some > other policy document. It needs to be defined in this policy. If it > has no specific meaning in the context of this policy, then the word > should be removed. > > My understanding of a 'policy document' is that it is self contained > and consistent. None of the terms: > -RIPE NCC Member > -LIR > -Resource holder > are defined anywhere in the Transfer Policy or ripe-733, IPv4 > Allocation... A policy may be dependent on another policy being in > place. You cannot transfer a resource unless it has been allocated. > You cannot allocate a resource unless there is a RIPE NCC Member and > an LIR. But you should not have to backtrack through a whole sequence > of documents to find out what a term in this policy means. This policy > can only work if people understand 'commonly accepted' definitions of > these terms. But that is open to interpretation and mis-understanding. > That could make legal enforcement of, for example, restrictions more > difficult to apply. > > [As a side issue I have just quickly read through a whole series of > documents and forms on becoming a RIPE NCC Member and getting > resources. In every document/form I found: > -Legal errors > -English grammar errors > -Procedural errors > -Webpage errors > The whole process is a complete mess and needs a serious Legal/Comms review.] > > I found the definition of a Member in one document but nowhere have I > found any definition of LIR. These terms are so fundamental to all > these policies, to not define them leaves a massive hole in their > meaning and authority. These terms seem to be so interchangeable from > one paragraph to the next. In some places the wrong term is used. > > ripe-733 says allocations are made to LIRs > ripe-682 says allocations are transferred to members > ripe-682 says transfer restrictions apply to resource holders > > Then we have this document > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers > which talks about 'hodership', another term not defined. > > Then we have this document > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region > that conflicts with the Transfer Policy. > It also refers to Members as organisations, again without any actual definition. > > The above document says: > "Exception: For transfers between multiple LIR accounts belonging to > the same organisation, also referred to as consolidations, the 24 > months restriction will only apply once after the resources were > received from the RIPE NCC or from another organisation." > > This is NOT what the Transfer Policy says. The policy makes no mention > anywhere of consolidation. The only definition we have of a transfer > in any POLICY is this one line: > "Allocated resources may only be transferred to another RIPE NCC member." > This does not even make sense. A Member cannot 'hold' a resource. > Resources are held by Member LIRs. So if a resource is transferred to > a Member with 5 LIRs, which one receives it? Does it matter? Is it > whichever LIR the Member writes on the transfer request form? > > Now a consolidation is not a transfer. In the policy a transfer is > defined as moving a resource to 'another Member'. So consolidating a > resource by moving it from one LIR to another LIR of the same Member > is by policy definition, not a transfer. So consolidation is not > subject to Transfer Restrictions because it is not a transfer. > > So all the shell companies that have been set up this year to hoover > up the last /24s can now be merged with their parent company and then > all the /24s can be consolidated into one LIR. The other LIRs can then > be closed. Nothing in this policy document says a /24 allocation must > remain for 24 months with the LIR that it was allocated to. It says it > cannot be transferred, but mergers are allowed and consolidation is > not a transfer. > > This is even confirmed in a procedural document ripe-758, Transfer of > Internet Number Resources... (which doesn't appear to be policy) > "Internet number resources that are subject to transfer restrictions > imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that > are transferred due to a change in a member's business structure, must > either remain registered with the original LIR account or be > registered with a new LIR account." > > So merging a shell company with 20 LIRs, each with a /24, with the > parent company with a single LIR, allows those 20 /24s to be > registered with the single LIR of the parent company and closure of > the 20 LIRs. > > Also ripe-758 introduces yet another term, parties, without any > definition or clarity. > > This whole transfer process is totally confused with contradictory, > inconsistent and poorly written documents and policies. > > cheers > denis > co-chair DB-WG > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > From leo at vegoda.org Thu Jan 6 15:59:30 2022 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 6 Jan 2022 06:59:30 -0800 Subject: [address-policy-wg] RIPE 83 Minutes Message-ID: Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 83. The page also links to recorded content and supporting materials. Please write to this list or inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-83-address-policy-working-group-minutes Kind regards, Leo Vegoda for the Address Policy WG co-chairs From randy at psg.com Tue Jan 25 18:33:40 2022 From: randy at psg.com (Randy Bush) Date: Tue, 25 Jan 2022 09:33:40 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies Message-ID: ok, i did it again, tried to fit a square peg in a round hole. while the immediate problem is past, thanks to the ncc reg folk, i fear that we could benefit from thinking a bit more about $subject. for a research experiment, we wanted eight or a dozen routable, i.e. /24, prefixes which we would announce from various places in the topology. each /24 would have one pingable address, let's assume .42. because this is ops based research, we have to o go through the ncc bureaucrazy o actually deploy and test o run the measurements for a few months o do the analysis o possibly tune or vary the experiment o write the paper and submit it o wait three months for the accept/reject o if rejected, retune and submit to a different venue o the reviewers may ask for us to re-run to get fresh data for publication o whine whine this takes six to twelve months. if you are familiar with $subject, you will sense there are two problems here. 587 is designed for a much shorter time window, and it kind of assumes more that 1:256 utilisation. you can imagine that my request to registration services generated a bit of discussion :). as our social environment has become less tolerant, reg services understandably wants simple rules they can follow and which clearly justify their actions. and geeks such as i just want our mtv :). i suspect we may be able to wordsmith conditions to deal with the time length issue. but i suspect that codification of guidelines covering the needs & justifications for research experiments, folk qualifying strange devices, and those doing other weird things will not be so easy. i am considering a policy proposal in this space; but want to learn what others see and think, and to see if it is worth the time and effort. and can we please keep discussion focused on temporary address space assignments? thanks. randy From randy at psg.com Wed Jan 26 16:52:16 2022 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jan 2022 07:52:16 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: two additional good ideas contributed by an anonymous donor: - requests should differentiate whether the need is for a block or whether scattered (routable?) addgress space would do. e.g. a meeting might prefer a block, a routing experiment separate /24s - the address space MUST be returned to the NCC as clean or cleaner than when it was loaned out randy From leo at vegoda.org Wed Jan 26 17:03:16 2022 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 26 Jan 2022 08:03:16 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: Hi Randy, On Wed, Jan 26, 2022 at 7:52 AM Randy Bush wrote: [...] > - the address space MUST be returned to the NCC as clean or cleaner > than when it was loaned out This is a nice idea. Do you have a practical proposal for implementation? Thanks, Leo From randy at psg.com Wed Jan 26 17:29:01 2022 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jan 2022 08:29:01 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: mornin' leo >> - the address space MUST be returned to the NCC as clean or cleaner >> than when it was loaned out > > This is a nice idea. Do you have a practical proposal for > implementation? depends on if/how you mess it up. and if you can not describe this to the ncc reg folk, they should not give you the space. camper saying" if you pack it in, pack it out randy From gert at space.net Wed Jan 26 18:32:22 2022 From: gert at space.net (Gert Doering) Date: Wed, 26 Jan 2022 18:32:22 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: Hi, On Tue, Jan 25, 2022 at 09:33:40AM -0800, Randy Bush wrote: > ok, i did it again, tried to fit a square peg in a round hole. while > the immediate problem is past, thanks to the ncc reg folk, i fear that > we could benefit from thinking a bit more about $subject. > > for a research experiment, we wanted eight or a dozen routable, i.e. > /24, prefixes which we would announce from various places in the > topology. each /24 would have one pingable address, let's assume .42. This is a tough nut. I can totally see what you do, and understand what space you need, and for which times. OTOH, I can totally see the NCC being worried about people claiming "experiments! and I need a review!" and running their ISP for a year on temporary space - and with the argument "I want a dozen routable /24s", you can get quite some ISP work done. [..] > i am considering a policy proposal in this space; but want to learn what > others see and think, and to see if it is worth the time and effort. I want research and conferences and all these things to be possible, with temporary address space, and policies to be fairly liberal for "those good things". The NCC needs checklist-able items to say "this is okay" and "that is way too much space, you do not need a /16 for 6 months to run a conference with 1000 attendees for a week. How to codify this? Dunno. Marco, Angela - what's your take on this ("feedback from RS" time)? Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From randy at psg.com Wed Jan 26 18:35:04 2022 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jan 2022 09:35:04 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: >> for a research experiment, we wanted eight or a dozen routable, i.e. >> /24, prefixes which we would announce from various places in the >> topology. each /24 would have one pingable address, let's assume .42. > > This is a tough nut. > > I can totally see what you do, and understand what space you need, and > for which times. > > OTOH, I can totally see the NCC being worried about people claiming > "experiments! and I need a review!" and running their ISP for a year > on temporary space - and with the argument "I want a dozen routable > /24s", you can get quite some ISP work done. the current policy requires description, documentation, ... already. this point merely adds to the spec to allow the ncc to issue frags if a block is not needed. > have you enabled IPv6 on something today...? nope randy From v-Damian.Michalak at lionbridge.com Thu Jan 27 15:02:15 2022 From: v-Damian.Michalak at lionbridge.com (Michalak, Damian) Date: Thu, 27 Jan 2022 14:02:15 +0000 Subject: [address-policy-wg] IPv6 - Using RIPE acquired prefix in other regions Message-ID: Hi there, I'm quite confused and would appreciate your help - let's say I acquired /32 IPv6 prefix from RIPE NCC. I work for a company with a global footprint with locations at various regions (including ones covered by APNIC and ARIN). I create a subnet plan that assigns /48 to each location with the company. So each /48 falls into the /32 assigned by RIPE. Now let's take as an example a location in the USA. I have this location connected using Direct Internet Access link from one of the providers. BGP is established. Question: can I advertise the /48 subnet (that falls into the /32 assigned by RIPE) from the location that in theory falls into ARIN regulatory domain? I cannot find an answer on that anywhere, and I'd like to make sure that I don't have to acquire additional prefixes from other RIRs. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Thu Jan 27 15:10:00 2022 From: nick at foobar.org (Nick Hilliard) Date: Thu, 27 Jan 2022 14:10:00 +0000 Subject: [address-policy-wg] IPv6 - Using RIPE acquired prefix in other regions In-Reply-To: References: Message-ID: <3338fe8d-4c29-4eaf-44a2-9dc2780bbbed@foobar.org> How and where you choose to announce subnets of a legitimately registered address block on the internet is up to you. There is no such thing as "ARIN regulatory domain". RIRs are registration bodies, not regulatory bodies. Nick Michalak, Damian wrote on 27/01/2022 14:02: > Question: can I advertise the /48 subnet (that falls into the /32 > assigned by RIPE) from the location that in theory falls into ARIN > regulatory domain? > From v-Damian.Michalak at lionbridge.com Thu Jan 27 15:13:59 2022 From: v-Damian.Michalak at lionbridge.com (Michalak, Damian) Date: Thu, 27 Jan 2022 14:13:59 +0000 Subject: [address-policy-wg] IPv6 - Using RIPE acquired prefix in other regions In-Reply-To: <3338fe8d-4c29-4eaf-44a2-9dc2780bbbed@foobar.org> References: <3338fe8d-4c29-4eaf-44a2-9dc2780bbbed@foobar.org> Message-ID: Thanks Nick, much appreciated! -----Original Message----- From: Nick Hilliard Sent: 27 January 2022 15:10 To: Michalak, Damian Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 - Using RIPE acquired prefix in other regions How and where you choose to announce subnets of a legitimately registered address block on the internet is up to you. There is no such thing as "ARIN regulatory domain". RIRs are registration bodies, not regulatory bodies. Nick Michalak, Damian wrote on 27/01/2022 14:02: > Question: can I advertise the /48 subnet (that falls into the /32 > assigned by RIPE) from the location that in theory falls into ARIN > regulatory domain? > From adallara at ripe.net Thu Jan 27 15:44:51 2022 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 27 Jan 2022 15:44:51 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Hi Gert, Randy and Leo, Thank you for dedicating attention and time to ripe-587, as this policy became more topical since the IPv4 run-out. The requests for temporary assignments are always evaluated by the RIPE NCC on a case-by-case basis, and the current text of the policy presents some challenging aspects for the approval. Requests related to conferences and events generally include a documentation that can easily show the utilisation of the addresses and the time of the assignment. Sometimes there is some time pressure due to last-minute submissions and there were few occasions when organisers would have preferred more than the policy limit of two months, but overall this part of the policy is sufficiently clear for the RIPE NCC. The requests for research and testing are posing challenges for the approval against the required address utilisation (50%) stated in the policy, when this cannot be reached due to the nature of the research/experiment/test. We also receive requests where the temporary assignment purpose appears to be part of a standard network setup as the test/experiment/research is motivated with the need of configuring and testing a protocol or a feature that is new to the requester's network while being already widely used in other ones. Many of these requests come from the requester's interpretation of the policy. While the policy cannot cover all cases, a review of the technical requirements, time limits and address utilisation would be beneficial to facilitate the RIPE NCC?s assessment of different requests. Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 26/01/2022 18:32, Gert Doering wrote: > Hi, > > On Tue, Jan 25, 2022 at 09:33:40AM -0800, Randy Bush wrote: >> ok, i did it again, tried to fit a square peg in a round hole. while >> the immediate problem is past, thanks to the ncc reg folk, i fear that >> we could benefit from thinking a bit more about $subject. >> >> for a research experiment, we wanted eight or a dozen routable, i.e. >> /24, prefixes which we would announce from various places in the >> topology. each /24 would have one pingable address, let's assume .42. > This is a tough nut. > > I can totally see what you do, and understand what space you need, and > for which times. > > OTOH, I can totally see the NCC being worried about people claiming > "experiments! and I need a review!" and running their ISP for a year > on temporary space - and with the argument "I want a dozen routable > /24s", you can get quite some ISP work done. > > [..] >> i am considering a policy proposal in this space; but want to learn what >> others see and think, and to see if it is worth the time and effort. > I want research and conferences and all these things to be possible, > with temporary address space, and policies to be fairly liberal for > "those good things". > > The NCC needs checklist-able items to say "this is okay" and "that is > way too much space, you do not need a /16 for 6 months to run a > conference with 1000 attendees for a week. > > How to codify this? Dunno. > > Marco, Angela - what's your take on this ("feedback from RS" time)? > > Gert Doering > From jordi.palet at consulintel.es Thu Jan 27 16:44:40 2022 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 27 Jan 2022 16:44:40 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> References: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Message-ID: I'm not convinced that we should "today", provide IPv4 temporary assignments, neither for conferences or experiments. A conference can perfectly survive today with a single IPv4 public address (or very few of them) from the ISP providing the link (even if running BGP), using 464XLAT, so the participants get dual-stack in the same way they are used to (private IPv4 addresses) and they also have global IPv6 addresses. This can be made with pure open source in a VM (if the provider doesn't have a NAT64, it can be also in the VM, in addition to the CLAT support, both using Jool, or other choices), etc. It is very well proven. Now, regarding to experiments, I don't think we should keep doing IPv4 experiments anymore and in the case it is really needed, I think it should be possible to obtain the required addresses from the DCs where the experiment will be co-located. So, in short, I think if work is done, it makes more sense to send this policy to "historic", at least deprecating the IPv4 part. I'm happy to work on that with a proposal, which seems to be very simple to do. Regards, Jordi @jordipalet ?El 27/1/22 15:45, "address-policy-wg en nombre de Angela Dall'Ara" escribi?: Hi Gert, Randy and Leo, Thank you for dedicating attention and time to ripe-587, as this policy became more topical since the IPv4 run-out. The requests for temporary assignments are always evaluated by the RIPE NCC on a case-by-case basis, and the current text of the policy presents some challenging aspects for the approval. Requests related to conferences and events generally include a documentation that can easily show the utilisation of the addresses and the time of the assignment. Sometimes there is some time pressure due to last-minute submissions and there were few occasions when organisers would have preferred more than the policy limit of two months, but overall this part of the policy is sufficiently clear for the RIPE NCC. The requests for research and testing are posing challenges for the approval against the required address utilisation (50%) stated in the policy, when this cannot be reached due to the nature of the research/experiment/test. We also receive requests where the temporary assignment purpose appears to be part of a standard network setup as the test/experiment/research is motivated with the need of configuring and testing a protocol or a feature that is new to the requester's network while being already widely used in other ones. Many of these requests come from the requester's interpretation of the policy. While the policy cannot cover all cases, a review of the technical requirements, time limits and address utilisation would be beneficial to facilitate the RIPE NCC?s assessment of different requests. Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 26/01/2022 18:32, Gert Doering wrote: > Hi, > > On Tue, Jan 25, 2022 at 09:33:40AM -0800, Randy Bush wrote: >> ok, i did it again, tried to fit a square peg in a round hole. while >> the immediate problem is past, thanks to the ncc reg folk, i fear that >> we could benefit from thinking a bit more about $subject. >> >> for a research experiment, we wanted eight or a dozen routable, i.e. >> /24, prefixes which we would announce from various places in the >> topology. each /24 would have one pingable address, let's assume .42. > This is a tough nut. > > I can totally see what you do, and understand what space you need, and > for which times. > > OTOH, I can totally see the NCC being worried about people claiming > "experiments! and I need a review!" and running their ISP for a year > on temporary space - and with the argument "I want a dozen routable > /24s", you can get quite some ISP work done. > > [..] >> i am considering a policy proposal in this space; but want to learn what >> others see and think, and to see if it is worth the time and effort. > I want research and conferences and all these things to be possible, > with temporary address space, and policies to be fairly liberal for > "those good things". > > The NCC needs checklist-able items to say "this is okay" and "that is > way too much space, you do not need a /16 for 6 months to run a > conference with 1000 attendees for a week. > > How to codify this? Dunno. > > Marco, Angela - what's your take on this ("feedback from RS" time)? > > Gert Doering > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gert at space.net Thu Jan 27 18:19:01 2022 From: gert at space.net (Gert Doering) Date: Thu, 27 Jan 2022 18:19:01 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Message-ID: Hi, On Thu, Jan 27, 2022 at 04:44:40PM +0100, JORDI PALET MARTINEZ via address-policy-wg wrote: > So, in short, I think if work is done, it makes more sense to send this policy to "historic", at least deprecating the IPv4 part. > > I'm happy to work on that with a proposal, which seems to be very simple to do. Given that there seem to be people that actually get work done in their research, using IPv4 because not all vantage points have IPv6 yet, and that the existance of this policy seems to do little harm, I'd strongly object to such a proposal. This is not the place and time to go on an anti-IPv4 crusade. Gert Doering -- SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sander at steffann.nl Thu Jan 27 18:29:32 2022 From: sander at steffann.nl (Sander Steffann) Date: Thu, 27 Jan 2022 18:29:32 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Message-ID: > Given that there seem to be people that actually get work done in their > research, using IPv4 because not all vantage points have IPv6 yet, and > that the existance of this policy seems to do little harm, I'd strongly > object to such a proposal. > > This is not the place and time to go on an anti-IPv4 crusade. +many Cheers, Sander From jim at rfc1035.com Thu Jan 27 18:39:21 2022 From: jim at rfc1035.com (Jim Reid) Date: Thu, 27 Jan 2022 17:39:21 +0000 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Message-ID: <56F33580-3E74-436C-BC39-29799272F76A@rfc1035.com> > On 27 Jan 2022, at 17:19, Gert Doering wrote: > > I'd strongly object to such a proposal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 528 bytes Desc: Message signed with OpenPGP URL: From dfk at ripe.net Fri Jan 28 12:20:58 2022 From: dfk at ripe.net (Daniel Karrenberg) Date: Fri, 28 Jan 2022 12:20:58 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: I have the strong suspicion that this is another example of trying to codify special/corner cases. Doing this takes disproportionate amounts of energy and causes an ever increasing amount of undesired side effects. How about giving the RIPE NCC discretion to make sensible decisions about the corner case ?scientific experiment? after getting advice from a panel of scientists? Or delegating the decisions to such a panel? This way we could avoid spending energy on codification and avoid the undesired side effects. We would just need to find a couple of credible people to review the requests. I expect this to be less work than codification and re-codification ? Daniel From abscoco at gmail.com Fri Jan 28 12:47:46 2022 From: abscoco at gmail.com (Sylvain Baya) Date: Fri, 28 Jan 2022 12:47:46 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: <3963a1a4-6783-b06f-2fa9-d041ea28d346@ripe.net> Message-ID: Dear apWG members, Hope this email finds you in good health. Please see my comments below, inline... Le jeudi 27 janvier 2022, JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg at ripe.net> a ?crit : > I'm not convinced that we should "today", provide IPv4 temporary > assignments, neither for conferences or experiments. > > Hi Jordi, Thanks for your email, brother! ...imho, maybe you should, if you consider a Tech conference where you try to teach your attendees how to build a transitional network based on the 464XLAT approach... ;-) > A conference can perfectly survive today with a single IPv4 public address > (or very few of them) from the ISP providing the link (even if running > BGP), using 464XLAT, so the participants get dual-stack in the same way > they are used to (private IPv4 addresses) and they also have global IPv6 > addresses. > ...sure, but please see the usecase presented above. > > This can be made with pure open source in a VM (if the provider doesn't > have a NAT64, it can be also in the VM, in addition to the CLAT support, > both using Jool, or other choices), etc. It is very well proven. > > Jordi, maybe this is a good case for a BCOP? :-/ > Now, regarding to experiments, I don't think we should keep doing IPv4 > experiments anymore and in the case it is really needed, I think it should > be possible to obtain the required addresses from the DCs where the > experiment will be co-located. > > ...i'm understanding the above as: *we* should not keep *supporting* IPv4 experiments anymore within this RIR. That's not a PoV i actually want to support, brother. > So, in short, I think if work is done, it makes more sense to send this > policy to "historic", at least deprecating the IPv4 part. > > ...imho, the RIPE-587 appears to be really useful... It covers almost all the situations which may occur in regard to temporary INRs. Sure, there are things/aspects to improve but i'm not sure to understand why the specific request for experiment shared by Randy can not be handled through it :-/ Please, someone to explain it to me :'-( ~?~ " For longer term projects and research purposes, the number resources may be issued on a temporary basis for a period of up to six calendar months, or one month longer than the expected life of the project/research/experiment, whichever is shorter. In the case where an End User requires number resources for research purposes, and where the research project details are made public upon registration of the number resources by the RIPE NCC, and where the End User commits to making public the results of their research project free of charge and free from disclosure constraints, then the requested number resources may be issued for a period of up to one calendar year. At the RIPE NCC's discretion renewal of the registration of the resources may be possible in exceptional circumstances on receipt of a new request that details continuation of the End User's requirements during the extended period. Should this request be denied by the RIPE NCC, an appeal may be made using the RIPE NCC Conflict Arbitration " https://www.ripe.net/publications/docs/ripe-587#:~:text=For%20longer%20term,NCC%20Conflict%20Arbitration ~?~ > I'm happy to work on that with a proposal, which seems to be very simple > to do. > > If there is interesting details to improve i'm also a taker. Given that it recalls me that i promised to work on the similar DPP (Draft Policy Proposal) within the AfriNIC's service region :-) Blessed new year 2022! ...one year less, under the era of LORD's Grace! Shalom, --sb. > Regards, > Jordi > @jordipalet > > > > ?El 27/1/22 15:45, "address-policy-wg en nombre de Angela Dall'Ara" < > address-policy-wg-bounces at ripe.net en nombre de adallara at ripe.net> > escribi?: > > Hi Gert, Randy and Leo, > > Thank you for dedicating attention and time to ripe-587, as this > policy > became more topical since the IPv4 run-out. > > The requests for temporary assignments are always evaluated by the > RIPE > NCC on a case-by-case basis, and the current text of the policy > presents > some challenging aspects for the approval. > > Requests related to conferences and events generally include a > documentation that can easily show the utilisation of the addresses > and > the time of the assignment. Sometimes there is some time pressure due > to > last-minute submissions and there were few occasions when organisers > would have preferred more than the policy limit of two months, but > overall this part of the policy is sufficiently clear for the RIPE NCC. > > The requests for research and testing are posing challenges for the > approval against the required address utilisation (50%) stated in the > policy, when this cannot be reached due to the nature of the > research/experiment/test. > > We also receive requests where the temporary assignment purpose > appears > to be part of a standard network setup as the test/experiment/research > is motivated with the need of configuring and testing a protocol or a > feature that is new to the requester's network while being already > widely used in other ones. Many of these requests come from the > requester's interpretation of the policy. > > While the policy cannot cover all cases, a review of the technical > requirements, time limits and address utilisation would be beneficial > to > facilitate the RIPE NCC?s assessment of different requests. > > Kind regards, > Angela > > -- > Angela Dall'Ara > RIPE NCC Policy Officer > > > > On 26/01/2022 18:32, Gert Doering wrote: > > Hi, > > [...] > > > -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]| Subscribe to Mailing List: __ #?LASAINTEBIBLE?|#?Romains15?:33?Que LE ?#?DIEU? de ?#?Paix? soit avec vous tous! ?#?Amen?!? ?#?MaPri?re? est que tu naisses de nouveau. #Chr?tiennement? ?Comme une biche soupire apr?s des courants d?eau, ainsi mon ?me soupire apr?s TOI, ? DIEU!?(#Psaumes42:2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Jan 28 12:59:34 2022 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 28 Jan 2022 12:59:34 +0100 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: <9DC2DAB1-9651-43BC-A24C-76D4AAD239DF@consulintel.es> That look to me as a good approach. That will be a good way to handle "really needed" IPv4 experiments, which I don't think are relevant anymore, but I'm happy to support if there are good and needed cases considering the good of the overall community. The negative part is the overhead of the panel selection, etc. In any case, I'm still for not having temporary delegations of IPv4 for conference, I don't think there is a excuse for that today. May be the NCC can tell us, in the last 10 years or so, how many IPv4 temporary assignments have been provided for both, conferences, experiments, and "other" cases (if there have been)? Regards, Jordi @jordipalet ?El 28/1/22 12:21, "address-policy-wg en nombre de Daniel Karrenberg" escribi?: I have the strong suspicion that this is another example of trying to codify special/corner cases. Doing this takes disproportionate amounts of energy and causes an ever increasing amount of undesired side effects. How about giving the RIPE NCC discretion to make sensible decisions about the corner case ?scientific experiment? after getting advice from a panel of scientists? Or delegating the decisions to such a panel? This way we could avoid spending energy on codification and avoid the undesired side effects. We would just need to find a couple of credible people to review the requests. I expect this to be less work than codification and re-codification ? Daniel -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From leo at vegoda.org Fri Jan 28 15:28:44 2022 From: leo at vegoda.org (Leo Vegoda) Date: Fri, 28 Jan 2022 06:28:44 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: On Fri, Jan 28, 2022 at 3:21 AM Daniel Karrenberg wrote: [...] > How about giving the RIPE NCC discretion to make sensible decisions > about the corner case ?scientific experiment? after getting advice > from a panel of scientists? > Or delegating the decisions to such a panel? Something similar to Expert Review? https://datatracker.ietf.org/doc/html/rfc8126#section-4.5 Regards, Leo From erik at bais.name Fri Jan 28 15:51:04 2022 From: erik at bais.name (Erik Bais) Date: Fri, 28 Jan 2022 14:51:04 +0000 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: <4F2A6644-F711-40CE-A3AF-30D938272386@bais.name> Hi Randy, I think that the time for the temp assignment to be made, stretched to 1 year or more, will become an issue for the NCC to work with. It is my personal view / feeling, that not many requests are done to the NCC for longer periods than specified in the policy.. And this looks like fixing policy for a corner case. Not only of the point that Gert made, but also because it will make the life of the IPRA's must harder with the time that we add.. As we can also expect more requests to be made, if the policy would be changed ... As this is for research .. have you considered working with other research networks that hold large amount of numbers because they were NIR's before RIPE was setup ? Like Surf in The Netherlands for instance .. or Janet in the UK.. or alike .. If they are presented with a proper documented research request .. they will consider those requests and they are not bound by policy restrictions that we are discussing here. It could fix your specific case .. and that is why these orgs are actually doing what they are doing .. Regards, Erik Bais ?On 25/01/2022, 18:34, "address-policy-wg on behalf of Randy Bush" wrote: ok, i did it again, tried to fit a square peg in a round hole. while the immediate problem is past, thanks to the ncc reg folk, i fear that we could benefit from thinking a bit more about $subject. for a research experiment, we wanted eight or a dozen routable, i.e. /24, prefixes which we would announce from various places in the topology. each /24 would have one pingable address, let's assume .42. because this is ops based research, we have to o go through the ncc bureaucrazy o actually deploy and test o run the measurements for a few months o do the analysis o possibly tune or vary the experiment o write the paper and submit it o wait three months for the accept/reject o if rejected, retune and submit to a different venue o the reviewers may ask for us to re-run to get fresh data for publication o whine whine this takes six to twelve months. if you are familiar with $subject, you will sense there are two problems here. 587 is designed for a much shorter time window, and it kind of assumes more that 1:256 utilisation. you can imagine that my request to registration services generated a bit of discussion :). as our social environment has become less tolerant, reg services understandably wants simple rules they can follow and which clearly justify their actions. and geeks such as i just want our mtv :). i suspect we may be able to wordsmith conditions to deal with the time length issue. but i suspect that codification of guidelines covering the needs & justifications for research experiments, folk qualifying strange devices, and those doing other weird things will not be so easy. i am considering a policy proposal in this space; but want to learn what others see and think, and to see if it is worth the time and effort. and can we please keep discussion focused on temporary address space assignments? thanks. randy -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From jim at rfc1035.com Fri Jan 28 16:04:33 2022 From: jim at rfc1035.com (Jim Reid) Date: Fri, 28 Jan 2022 15:04:33 +0000 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: References: Message-ID: <3B276A32-C18D-4924-848C-B3B3851AA52B@rfc1035.com> > On 28 Jan 2022, at 11:20, Daniel Karrenberg wrote: > > How about giving the RIPE NCC discretion to make sensible decisions about the corner case ?scientific experiment? after getting advice from a panel of scientists? > Or delegating the decisions to such a panel? This would be a pragmatic, common sense solution. However I fear it would open up a new rat-hole for yet more shed-painting. Says me mixing my metaphors... There would be endless discussion on how this panel of experts gets chosen and who?s eligible or not, how they?re accountable (and to whom), who gets to choose, what the appeals process should be and how that?s invoked, etc, etc. Which brings us back to the point you made yesterday Daniel: huge amounts of effort for very little reward. I hope a pragmatic, common sense solution can be found. If not, I think we should just freeze the current policy on v4 and reject any further proposals unless there is a unanimous community consensus to reopen that can of worms. IMO v4 is done. Get over it. From randy at psg.com Fri Jan 28 17:31:09 2022 From: randy at psg.com (Randy Bush) Date: Fri, 28 Jan 2022 08:31:09 -0800 Subject: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies In-Reply-To: <4F2A6644-F711-40CE-A3AF-30D938272386@bais.name> References: <4F2A6644-F711-40CE-A3AF-30D938272386@bais.name> Message-ID: erik, > I think that the time for the temp assignment to be made, stretched to > 1 year or more, will become an issue for the NCC to work with. the current policy allows the ncc to go up to a year > Not only of the point that Gert made, but also because it will make > the life of the IPRA's must harder with the time that we add.. actually, it is the reg folk who raised these issues to me > As we can also expect more requests to be made, if the policy would be > changed ... this statement might benefit from some explanation > As this is for research .. have you considered working with other > research networks that hold large amount of numbers because they were > NIR's before RIPE was setup ? i can not speak for other researchers. but when my work can be done with existing allocations we use them, of course. we have done this a lot. in the particular case i hit, the nature of the experiment required space directly delegated from the ncc. randy From v-Damian.Michalak at lionbridge.com Mon Jan 31 17:10:14 2022 From: v-Damian.Michalak at lionbridge.com (Michalak, Damian) Date: Mon, 31 Jan 2022 16:10:14 +0000 Subject: [address-policy-wg] IPv6 - Geolocation concerns Message-ID: Hi there, This is a follow-up question to the older thread ("IPv6 - Using RIPE acquired prefix in other regions") Situation: I have acquired /32 IPv6 prefix from RIPE NCC. Prefix is registered for country: DE. I'm going to create /48 subnets and advertise them from various locations all around the globe. Question: Do I have to be concerned about geo-location issues? For example someone in US opening Google and getting Google.de? If so - what's the best way to address this? P.S. That's certainly a concern in IPv4 - I do advertise in US a subnet of a bigger supernet (registered in Poland) and Apple.com thinks I'm in Poland. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Mon Jan 31 17:23:58 2022 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 31 Jan 2022 08:23:58 -0800 Subject: [address-policy-wg] IPv6 - Geolocation concerns In-Reply-To: References: Message-ID: <67733A8C-B0AB-48F4-85A4-BCC56A76EBD0@semihuman.com> Generally speaking, the best way to deal with geolocation issues when subdelegating is to make sure that you create INET6NUM objects for your various subnets that include, at minimum, the country from which you expect to advertise them from. WHOIS serves as ground-floor data for most geo databases, so absent other signal, that?s a very good first step. -C > On Jan 31, 2022, at 8:10 AM, Michalak, Damian wrote: > > Hi there, > > This is a follow-up question to the older thread (?IPv6 - Using RIPE acquired prefix in other regions?) > > Situation: > I have acquired /32 IPv6 prefix from RIPE NCC. Prefix is registered for country: DE. > I?m going to create /48 subnets and advertise them from various locations all around the globe. > > Question: > Do I have to be concerned about geo-location issues? For example someone in US opening Google and getting Google.de ? > If so ? what?s the best way to address this? > > P.S. That?s certainly a concern in IPv4 ? I do advertise in US a subnet of a bigger supernet (registered in Poland) and Apple.com thinks I?m in Poland. > > Thanks > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: