From mschmidt at ripe.net Tue Nov 15 14:50:34 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 15 Nov 2016 14:50:34 +0100 Subject: [address-policy-wg] 2016-03 Policy Proposal Withdrawn (Locking Down the Final /8 Policy) Message-ID: Dear colleagues, The proposal 2016-03, "Locking Down the Final /8 Policy" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposer decided to abandon the proposal as he felt that the ongoing discussion was damaging the RIPE community?s reputation. As nobody stepped forward to take over the authorship this proposal, the proposal was withdrawn. Regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From Ondrej.Caletka at cesnet.cz Wed Nov 16 15:29:31 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Wed, 16 Nov 2016 15:29:31 +0100 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: <20161023100613.71c7a30e@envy.e1.y.home> References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <20161023100613.71c7a30e@envy.e1.y.home> Message-ID: Dne 23.10.2016 v 10:06 Tore Anderson napsal(a): > Hi Kai, > > * Kai 'wusel' Siering > >> > (Which, btw, means there's no difference between PA and PI here. >> > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent >> > interpretation. Eeks.) >> > >> > [...] >>> > > And 3rd party usage of IPv6 PI addresses is currently not allowed. >> > >> > Well, if reading the policy that way, neither is it for non-PI space? > I think you're right. An assignment is an assignment. > > If the policy currently disallows using assignments (PI or PA) for > things like wireless networks for guests, then I'd say that 2016-04 > doesn't go far enough. +1 My opinion is that 2016-04 goes completely wrong way because it makes the exception "longer than /64 is not an assignment" valid only for PI, not for PA addresses. So if we agree that any device getting an address is getting an assignment, which has to be registered properly in the database, this problem is same for PI and PA addresses. The only legitimate solution that is available exclusively for PA holders is the special status AGGREGATED-BY-LIR with an assignment size of 128. But I guess this is not the intention of this special status. I've searched through the RIPE DB and found just 31 such assignments. This is certainly not on par with how many Wi-Fi networks used by third parties are out there. And this is not only about Wi-Fi networks. All the VPS providers I know have just one block assigned to themselves from which they delegate one or more IP address per customer-controlled VPS. I think it would be better to clarify the 2.6 section of ripe-655 to explicitly state what is not an assignment. Using a prefix length of "longer than /64" seem to be a good criteria, although it makes me little bit scared of possibly wrong interpretation by some non-LIR ISPs who would start delegating very long prefixes to avoid the need of becoming LIR. Cheers, Ond?ej Caletka CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5600 bytes Desc: Elektronicky podpis S/MIME URL: From wusel+ml at uu.org Thu Nov 17 02:43:52 2016 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Thu, 17 Nov 2016 02:43:52 +0100 Subject: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification) In-Reply-To: References: <8eae7879-d1a4-60f3-3a4d-12331e12cb0e@wirem.net> <8660okg2up.fsf@naartjie.uucp> <51B5F978-07F2-497E-80CF-00C968DE2A2B@a2b-internet.com> <743adb0c-2ce5-5071-800c-250f054c6582@uu.org> <29784B88-3C9C-49E4-A1CC-2E1615F0FE9A@steffann.nl> <17f978d5-224e-2cb7-fc0a-e4e9729d8630@uu.org> <20161023100613.71c7a30e@envy.e1.y.home> Message-ID: <89b550f8-a00b-b75d-cf87-e229e246033a@uu.org> Hi, am 16.11.2016 um 15:29 schrieb Ond?ej Caletka: > Dne 23.10.2016 v 10:06 Tore Anderson napsal(a): >> Hi Kai, >> >> * Kai 'wusel' Siering >> >>>> (Which, btw, means there's no difference between PA and PI here. >>>> Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent >>>> interpretation. Eeks.) >>>> >>>> [...] >>>>>> And 3rd party usage of IPv6 PI addresses is currently not allowed. >>>> Well, if reading the policy that way, neither is it for non-PI space? >> I think you're right. An assignment is an assignment. >> >> If the policy currently disallows using assignments (PI or PA) for >> things like wireless networks for guests, then I'd say that 2016-04 >> doesn't go far enough. > +1 > > My opinion is that 2016-04 goes completely wrong way because it makes > the exception "longer than /64 is not an assignment" valid only for PI, > not for PA addresses. > > So if we agree that any device getting an address is getting an > assignment, which has to be registered properly in the database, this > problem is same for PI and PA addresses. > > [?] > And this is not only about Wi-Fi networks. All the VPS providers I know > have just one block assigned to themselves from which they delegate one > or more IP address per customer-controlled VPS. > > I think it would be better to clarify the 2.6 section of ripe-655 to > explicitly state what is not an assignment. Using a prefix length of > "longer than /64" seem to be a good criteria, although it makes me > little bit scared of possibly wrong interpretation by some non-LIR ISPs > who would start delegating very long prefixes to avoid the need of > becoming LIR. I don't agree on "any device getting an address is getting an assignment" in the first place. Let's refer to ripe-655's definition: > 2.6. Assign > > To ?assign? means to delegate address space to an ISP or End User for > specific use within the Internet infrastructure they operate. > Assignments must only be made for specific purposes documented by specific > organisations and are not to be sub-assigned to other parties. From my point of view, the sentence is really clear already, and shouln'tbe able to be interpreted in the way it currently seems to be ;) An assignment is a bureaucratic act, executed by an organisation (IR) in favor of another organisation (non-IR). An assignment is considered to exist for a prolonged duration and as such to be documentedin the RIPE Database. Nothing of that happens when mechanisms like SLAAC or DHCPv6 suggest, to a requesting device, which IPv6 Prefix is being used/which IPv6 address itshould use. So, what ?are not to be sub-assigned to other parties? (2.6) and especially?cannot be further assigned to other organisations? (7) are trying toprevent in the first place? Sander gave the context: > [?] > Then IPv4 NAT came along, and most residential ISPs started to not assign addresses to customers at all anymore: they only got the interconnect and were expected to NAT using the interconnect's address. That made it possible for ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed the loophole for (IIRC) two reasons: > - it was considered unfair that some ISPs used cheap PI addresses while others paid for running the NCC (this included hosters using PI space as well as access ISPs) > - the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6 > > This of course forced all ISPs to use PA space, but situations where the "ISP" vs "End user" boundary wasn't the classical one had problems. This was discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf starting at slide 9, it took me a lot of effort trying to find that one, I couldn't imagine it already being 5 years ago) and because of that an effort was started to stop distributing different "colours" of address space and unify PA and PI. > > Unfortunately that effort failed because it turned out to cause too many complications (see https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf), which is why we are at the current policy and interpretation as presented 5 years ago: > > > - No DSL > > - No Cable > > - VPN > > - No co-location > > - No virtual servers > > - No SSL hosting > > > > No buts and no exceptions > > And that's where we are today, and what this policy proposal is trying to change. If above reflects the (agreed on?) ?current policy and interpretation?, as ripe-655 _is_ the document that specifies the ?IPv6 Address Allocation and Assignment Policy?, it must be added there in a proper and consistent way in the first place.(Althoughnot being allowed to use IPv6 PI inhouse for virtual servers would be ridiculous at best: Green IT? Only over RIPE's dead body.) I really think the whole of ripe-655 should be reworked, especially as the published policy and the ?lived? interpretation are totally out of sync. ?To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled ?Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region?? means: anyone who is willing to sign the funny document with an LIR is eligible to receive IPv6 PI space, period. This, obviously, is in clear contrast to RIPE NCC's execution of ripe-655 and in contrast of the goals stated: ?In IPv6 address policy, the goal of aggregation is considered to be the most important.? Oddly enough, RIPE NCC would rather assign PI in 3x /48 instead of /47 + /48 or, pragmatically, an /46 (with e. g. the fourth /48 put in an allocated state ?for future use? or whatever). To put it all in a nutshell, thingsareseverely out of sync here. On the other hand: hasn't reality already overtaken policy already? Considering [1], this shouln't have worked? > wusel at ysabell:~$ sudo traceroute -A -T -6 space.net > traceroute to space.net (2001:608:2:88::1), 30 hops max, 80 byte packets > 1 gw-gt.uu.org (2a07:a907:50c:1000:219:99ff:fe5b:cc93) [AS206946] 6.072 ms 6.073 ms 9.125 ms > [?] > 8 www.space.net (2001:608:2:88::1) [AS5539] 68.685 ms 66.751 ms 66.750 ms I'm using a /48 PA I 'purchased' from an UK LIR and ?GRE-tunnel? it home. There's no connection routing-wise between me and the LIR (um, well, I do announce my /48 from a VM there over their upstream, but there's nearly ever any traffic coming in), but getting it announced to the right upstreams (HE, NTT), things ?just worked?. Curiosity took over, so ... Well, the same applies to a /47 APNIC-PA: > root at gw-gt:~# traceroute -A -T -6 facebook.com -s 2402:9e80:21:1::1 > traceroute to facebook.com (2a03:2880:f100:83:face:b00c:0:25de), 30 hops max, 80 byte packets > 1 de3-gut1.as206946.net (2a07:a907:50c:f700::1) [AS206946] 30.946 ms 30.898 ms 31.433 ms > [?] > 15 edge-star-mini6-shv-01-mia1.facebook.com (2a03:2880:f100:83:face:b00c:0:25de) [AS32934] 151.048 ms 150.789 ms 148.580 ms IPv6 PA seems to be pay-as-you-go already. As you need to pay for v6 PI as well (actually more than for v6 PA, at least in my case), what's the point of IPv6 PI anyway? (Don't get me wrong, I'm a happy camper with my personal stuff on v4 ERX/PI, never needed to touch my setup, regardless of what ISP was used for the upstream connectivity, in the last 20 years. I wanted the same for v6, but as PA was much more easy to get, I started playing with that.) To sum things up: - Policy actually encourages people to ask for PI space - NCC is not really acting by policy letters - PA is freely routable these days As an related topic,who is actually enforcing ?5.5 Registration?? Out of 2003::/19, at least 2003:c9:cb00::/48 is heavily used (with /64s and /56s assigned to the same end user for 14+ days), but there's no assignment at all in the RIPE DB. Obviously LIRs have a card blance ignoring ripe-655 post-allocation :-( Or is the RIPE NCC so busy scrutinizing PI requests that they don't have time to check on LIRs behaviour? Something is really wierd here. Regards, -kai [1] https://www.space.net/~gert/RIPE/ipv6-filters.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgori at wirem.net Fri Nov 18 14:45:06 2016 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 18 Nov 2016 14:45:06 +0100 Subject: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) In-Reply-To: <6e5847d9-9d7e-c2d6-a18c-03ac75ccd825@wirem.net> References: <20161021.124501.1230279093156300597.he@uninett.no> <20161021105707.GJ93886@cilantro.c4inet.net> <20161021.131732.1966246577534839196.he@uninett.no> <20161021114248.GK93886@cilantro.c4inet.net> <1477168411.1086952.764187681.770B05F2@webmail.messagingengine.com> <013301d22d47$5e8d6b60$1ba84220$@a2b-internet.com> <6e5847d9-9d7e-c2d6-a18c-03ac75ccd825@wirem.net> Message-ID: Hi all, I want to withdrawn my neutral position on this policy saying I support 2015-04 'cause my feeling is to support anything goes against speculation and not using last IP space to grow the internet. thank you Erik for your work on it kind regards Riccardo Il 24/10/2016 11:54, Riccardo Gori ha scritto: > > Hi Erik, > > > Il 23/10/2016 18:06, Erik Bais ha scritto: >> I?ll entertain your question here, although the question isn?t in relation to the policy proposal, but more about how transfers work .. >> >> If a company splits? it is actually very simple ? you setup a second LIR .. ( Provided that we are talking about RIPE PA space.. ) ? >> >> And you transfer the space out that needs to go to the business that is split off, to the new LIR ? >> The new entity / LIR would also receive a free /22 IPv4 and have the right to a /29 IPv6 and request an AS number, if they like, in the process ? >> >> And also get 2 free access tickets to the next RIPE meeting ? and may send employees to a new LIR training. >> >> In case you are talking about RIPE PI space .. it is even easier .. >> You decide who the sponsoring LIR is going to be for the new entity.. ( the split off business.. ) Sign an End-User Agreement with the Sponsoring LIR of choice .. >> Initiate a transfer to split the original prefix into multiple smaller prefixes.. and divide them between the 2 companies.. >> >> Send a signed Transfer agreement document and a copy of the End-User Agreement to the RIPE NCC or upload it through the portal ? >> The new entity doesn?t have any additional rights to an extra /22 or other stuff or free tickets or trainings. >> >> Similar as with Legacy space .. only a Confirmation of Transfer to the RIPE NCC Service Region ( no RIPE NCC or Sponsoring LIR contract required even .. ) >> >> I?m not saying that there might be corner cases out there that one might bump into however I think that with all the different versions that we worked on, we addressed the ones that are common in normal business practices. >> >> The policy proposal doesn?t limit companies from doing M&A?s ? and if you would read point 2.2, it clearly points that out in the text.. >> >> The text states : >> >>> Scarce resources, which are understood as those resources that are allocated or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs), >>> cannot be transferred for 24 months from the date the resource was received by the resource holder. >>> This restriction also applies if the resource was received due to a change in the organisation?s business (such as a merger or acquisition). >>> This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. >> So it doesn't prevent future M&A's .. as that is not possible to restrict and not the intention ... >> The intention is to avoid speculation by hoarding and combining LIR's and transferring IP space out. > > I wanted to see this stated in the summary proposal as a goal. > I confess this proposal see me almost neutral but what I don't like is > that the summary proposal has as primary goal collect transfer > policies in one document > but we are mosltly discussing possibile abuses of M&A procedures. > This policy technically forces business process to take place (this > makes this policy similar to 2016-03) as example to keep an LIR opened > while the company has been acquired. > In my point of view is not a good idea to force business processes for > reasons already expresses by others: future inconsistence of database, > possible back market behind > and so on.... > Please consider me neutral today i have to think a little bit more > about it and maybe need some chat with you. > > Said this, text of 2015-04 is wonderfully clean now and is very clear. > Thank you for you work Erik. > Now I need to go get the plane to get there ;-) > see you in Madrid. > > regards > Riccardo >> Regards, >> Erik Bais >> >> --- >> >> >> Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Ciprian Nica >> Verzonden: zaterdag 22 oktober 2016 22:39 >> Aan: Radu-Adrian FEURDEANripe-wgs at radu-adrian.feurdean.net >> CC: RIPE Address Policy WG List >> Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies) >> >> That's a good point, what would happen when a business splits ? I think there are many situations that need to be discussed and if we want to do something good we'd need to cover all situations. And yes, there is definitely the need for better policies in order for NCC to do exactly what the community wants and not leave room for interpretation. >> >> Ciprian >> >> On Sat, Oct 22, 2016 at 11:33 PM, Radu-Adrian FEURDEAN wrote: >> On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote: >> >>> RIPE NCC recognises that and puts M&A firmly outside policy. >>> Where it should remain unless the desire is that every transfer >>> application or M&A notification start with filing suit against >>> the NCC. >> On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single >> legal entity, it would make some sense that the M&A procedure (the one >> outside the policy scope) is limited to only changing the name of the >> LIR. >> Of course that would mean that all movements of IP addresses between >> LIRs, even those related to mergers, acquisition, restructuring, >> consolidation, ..... would fall under transfer policy. Could someone >> detail what would be the problem in this case (except a limited amount >> of money of up to 4200 EUR). >> Unfortunately this is not where we are, and it doesn't look like it's >> where is going. >> >> As for RIPE NCC handling completely on its own the M&A process this is >> exactly what allowed abuse to happen in the first place (and will still >> do, even with 2015-01, 2015-04 and 2016-03). And how about a business >> split - this doesn't feel like handled by the M&A procedure. >> >> -- >> Radu-Adrian FEURDEAN >> >> >> > > -- > Ing. Riccardo Gori > e-mail:rgori at wirem.net > Mobile: +39 339 8925947 > Mobile: +34 602 009 437 > Profile:https://it.linkedin.com/in/riccardo-gori-74201943 > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying toinfo at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- -- Riccardo Gori -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 41774 bytes Desc: not available URL: From tecnico at alojalia.com Thu Nov 24 01:07:18 2016 From: tecnico at alojalia.com (ANGEL MARTINEZ SANCHEZ) Date: Thu, 24 Nov 2016 01:07:18 +0100 Subject: [address-policy-wg] Migration Datacenter Message-ID: Hello, We are going to migrate from our actually datacenter to another one. We have /22 IPs block and not have AS number, our datacenter announce them. Our plan is as follows: - We already add new route objects before migration and will remove old after migration. - At dawn on Sunday, November 27 about 3:00 AM, we will shut down all our servers from the current data center. - At that point we will delete the current route ASXXXX in RIPE DB from inetnum XXX.XXX.XX.0/22 and only the route object corresponding to new datacenter will remain. - We will contact new datacenter to activate our IP block on their router and configure the requested gateway. - We will dismantle the entire rack from old datacenter and move it to the new datacenter where we will start up all our servers again. We need to know if the procedure is correct and very important, the time it takes to propagate the new route of our IP block since we delete the current ASXXXXX and the new ASXXXX is activated by new datacenter. We also need to know if we depend on any action by the current data center to complete this procedure. For example, if they have to remove our block from their AS or their router and that would happen in case they refused to do so on the date indicated for the migration. Thanks and regards. Angel Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ebais at a2b-internet.com Thu Nov 24 13:43:07 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 24 Nov 2016 13:43:07 +0100 Subject: [address-policy-wg] Migration Datacenter In-Reply-To: References: Message-ID: <022d01d24650$4ecc1010$ec643030$@a2b-internet.com> Hi Angel, Typically the route objects are being used to create daily filters at certain upstream / backbone providers.. As long as you delete the old RIPE Route object (let's say 12 hrs before the migration ) and create a new one for the new transit provider to allow them to notify their transit provider to update their filters and announce the new route.. you should be ok. You could also ... ( during the migration ) ask the new transit provider to announce in /24's, so that if the old provider hasn't stopped their announcement yet, you can still use the IP's in your new location. As a more specific route has preference above a larger announcement. And once the old provider stopped the announcement of the /22, you can start to announce the /22 on the new location and stop with the /24's to be announced. ( Aggregation back to a /22 is nice to do.. ) Good luck on the migration. Kind regards, Erik Bais A2B Internet -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens ANGEL MARTINEZ SANCHEZ Verzonden: donderdag 24 november 2016 1:07 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] Migration Datacenter Hello, We are going to migrate from our actually datacenter to another one. We have /22 IPs block and not have AS number, our datacenter announce them. Our plan is as follows: - We already add new route objects before migration and will remove old after migration. - At dawn on Sunday, November 27 about 3:00 AM, we will shut down all our servers from the current data center. - At that point we will delete the current route ASXXXX in RIPE DB from inetnum XXX.XXX.XX.0/22 and only the route object corresponding to new datacenter will remain. - We will contact new datacenter to activate our IP block on their router and configure the requested gateway. - We will dismantle the entire rack from old datacenter and move it to the new datacenter where we will start up all our servers again. We need to know if the procedure is correct and very important, the time it takes to propagate the new route of our IP block since we delete the current ASXXXXX and the new ASXXXX is activated by new datacenter. We also need to know if we depend on any action by the current data center to complete this procedure. For example, if they have to remove our block from their AS or their router and that would happen in case they refused to do so on the date indicated for the migration. Thanks and regards. Angel Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mschmidt at ripe.net Thu Nov 24 14:20:19 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 24 Nov 2016 14:20:19 +0100 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Message-ID: Dear colleagues, A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" is now available for discussion. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 We encourage you to review this proposal and send your comments to before 23 December 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From athina.fragkouli at ripe.net Thu Nov 24 17:18:33 2016 From: athina.fragkouli at ripe.net (Athina Fragkouli) Date: Thu, 24 Nov 2016 17:18:33 +0100 Subject: [address-policy-wg] RIPE Accountability Task Force Message-ID: <92c4a6af-bbcd-a353-3d57-4ba711fb2eec@ripe.net> Dear colleagues, At RIPE 73 there was support for a review of the RIPE community's accountability, by looking at its current procedures, documentation and structures. An Accountability Task Force has been established to carry out this work and will have its first meeting in the coming weeks, after which a charter and additional information will be published. A mailing list will also be created for the Task Force?s discussions and the archives will be publicly available. You can find the accountability presentation at RIPE 73 here: https://ripe73.ripe.net/archives/video/1248/ If you have feedback or would like to join the Task Force, please send an email to . Kind regards, Athina Fragkouli Head of Legal RIPE NCC From Mathew.Newton643 at mod.gov.uk Thu Nov 24 19:08:58 2016 From: Mathew.Newton643 at mod.gov.uk (Newton, Mathew C1 (ISS Des-Arch33-Arch)) Date: Thu, 24 Nov 2016 18:08:58 +0000 Subject: [address-policy-wg] [policy-announce] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: <60822c70-48bf-3eca-b6a4-7ae4e2717275@ripe.net> References: <60822c70-48bf-3eca-b6a4-7ae4e2717275@ripe.net> Message-ID: Dear WG, On 24 November 2016 13:16, Marco Schmidt wrote: > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" > is now available for discussion. > > The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. I am pleased to see the arrival of this policy proposal as whilst the additional assessment criteria introduced by proposal 2015-03 allowed the legitimate requirements of a broader range of organisations to be satisfied it was of benefit only to those that had not previously received address space (and/or those in a position to return/exchange it). These same requirements do however exist equally for many other organisations who should not be discriminated against simply because they happened to have received their initial allocation under the previous assessment criteria. The proposed policy serves to remove this discrimination and provide the same benefits to all, notwithstanding the unavoidable practical difficulty of providing contiguous address space to organisations who may find themselves 'landlocked' by allocations already made to other organisations. In light of the above I fully support the adoption and implementation of the proposed policy. Regards, Mathew From bruecknerc at gmail.com Thu Nov 24 21:04:00 2016 From: bruecknerc at gmail.com (=?utf-8?Q?Carsten_Br=C3=BCckner?=) Date: Thu, 24 Nov 2016 21:04:00 +0100 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: References: Message-ID: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> Hello WG, I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. But I have a question to the proposed paragraph in 5.2.3: "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation " paragraph 2 (b)? Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? Regards, Carsten > Am 24.11.2016 um 14:20 schrieb Marco Schmidt : > > Dear colleagues, > > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" > is now available for discussion. > > The goal of this proposal is to match the subsequent IPv6 allocation requirements > with the initial allocation requirements. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-05 > > We encourage you to review this proposal and send your comments to > before 23 December 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Nov 24 21:39:58 2016 From: jordi.palet at consulintel.es (Jordi Palet Martinez) Date: Thu, 24 Nov 2016 21:39:58 +0100 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> References: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> Message-ID: Hi Carsten, Thanks for your support. Regarding your question, yes the idea is to follow the same criteria as for the initial allocation. Do you think the text is not clear and requieres some clarification ? Regards, Jordi > El 24 nov 2016, a las 21:04, Carsten Br?ckner escribi?: > > Hello WG, > > I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. > > But I have a question to the proposed paragraph in 5.2.3: > "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? > > Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? > Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? > > Regards, > Carsten > > >> Am 24.11.2016 um 14:20 schrieb Marco Schmidt : >> >> Dear colleagues, >> >> A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" >> is now available for discussion. >> >> The goal of this proposal is to match the subsequent IPv6 allocation requirements >> with the initial allocation requirements. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2016-05 >> >> We encourage you to review this proposal and send your comments to >> before 23 December 2016. >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvia.hagen at sunny.ch Thu Nov 24 21:59:00 2016 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Thu, 24 Nov 2016 20:59:00 +0000 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: References: Message-ID: Dear WG I support this policy. It seems natural to me that for allocation of subsequent space the same rules apply like for the initial allocation. It also helps organizations, that have received their space before the updated initial allocation policy can receive space based on the same criteria. Silvia Hagen Chair Swiss IPv6 Council -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 24. November 2016 14:20 An: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Dear colleagues, A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" is now available for discussion. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 We encourage you to review this proposal and send your comments to > before 23 December 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Nov 24 22:23:16 2016 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 24 Nov 2016 22:23:16 +0100 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: References: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> Message-ID: <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> Hi Carsten, After reading several times our proposal, I think I got your point and I guess you?re right. The actual text may be interpreted to limit the subsequent allocation to be based only on the planned longevity, but not the other possibilities. I think it can be reworded as: ?If an organisation needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. (number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation). The allocation made will be based on those requirements.? If we want to get the subsequent allocation ?automatically synchronized? with the initial one, we should omit the text in ?()?. I think is the right way to do so, if in the future the initial allocation text is changed again, most probably, there are many chances that we avoid to rewrite the text of the subsequent allocation. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Jordi Palet Martinez Responder a: Fecha: jueves, 24 de noviembre de 2016, 21:39 Para: CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Hi Carsten, Thanks for your support. Regarding your question, yes the idea is to follow the same criteria as for the initial allocation. Do you think the text is not clear and requieres some clarification ? Regards, Jordi El 24 nov 2016, a las 21:04, Carsten Br?ckner escribi?: Hello WG, I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. But I have a question to the proposed paragraph in 5.2.3: "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? Regards, Carsten Am 24.11.2016 um 14:20 schrieb Marco Schmidt : Dear colleagues, A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" is now available for discussion. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 We encourage you to review this proposal and send your comments to before 23 December 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bruecknerc at gmail.com Thu Nov 24 22:29:33 2016 From: bruecknerc at gmail.com (=?utf-8?Q?Carsten_Br=C3=BCckner?=) Date: Thu, 24 Nov 2016 22:29:33 +0100 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> References: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> Message-ID: Hi Jordi, Perfect! Full Support :-) Regards, Carsten > Am 24.11.2016 um 22:23 schrieb JORDI PALET MARTINEZ : > > Hi Carsten, > > After reading several times our proposal, I think I got your point and I guess you?re right. > > The actual text may be interpreted to limit the subsequent allocation to be based only on the planned longevity, but not the other possibilities. > > I think it can be reworded as: > > ?If an organisation needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. (number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation). The allocation made will be based on those requirements.? > > If we want to get the subsequent allocation ?automatically synchronized? with the initial one, we should omit the text in ?()?. I think is the right way to do so, if in the future the initial allocation text is changed again, most probably, there are many chances that we avoid to rewrite the text of the subsequent allocation. > > Saludos, > Jordi > > > -----Mensaje original----- > De: address-policy-wg en nombre de Jordi Palet Martinez > Responder a: > Fecha: jueves, 24 de noviembre de 2016, 21:39 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) > > Hi Carsten, > > Thanks for your support. > > Regarding your question, yes the idea is to follow the same criteria as for the initial allocation. Do you think the text is not clear and requieres some clarification ? > > Regards, > Jordi > > > El 24 nov 2016, a las 21:04, Carsten Br?ckner escribi?: > > > > Hello WG, > > I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. > > But I have a question to the proposed paragraph in 5.2.3: > "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? > > Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? > Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? > > Regards, > Carsten > > > > > > Am 24.11.2016 um 14:20 schrieb Marco Schmidt : > > Dear colleagues, > > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" > is now available for discussion. > > The goal of this proposal is to match the subsequent IPv6 allocation requirements > with the initial allocation requirements. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-05 > > We encourage you to review this proposal and send your comments to > before 23 December 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From cobuerger at gmail.com Fri Nov 25 11:04:13 2016 From: cobuerger at gmail.com (constanze buerger) Date: Fri, 25 Nov 2016 11:04:13 +0100 Subject: [address-policy-wg] address-policy-wg Digest, Vol 63, Issue 6 In-Reply-To: References: Message-ID: +1 for the proposal Am 24.11.2016 22:29 schrieb : > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ripe.net/ > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2016-05 New Policy Proposal (Synchronising the Initial > and Subsequent IPv6 Allocation Policies) (Silvia Hagen) > 2. Re: 2016-05 New Policy Proposal (Synchronising the Initial > and Subsequent IPv6 Allocation Policies) (JORDI PALET MARTINEZ) > 3. Re: 2016-05 New Policy Proposal (Synchronising the Initial > and Subsequent IPv6 Allocation Policies) (Carsten Br?ckner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Nov 2016 20:59:00 +0000 > From: Silvia Hagen > To: Marco Schmidt , "address-policy-wg at ripe.net" > > Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal > (Synchronising the Initial and Subsequent IPv6 Allocation Policies) > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Dear WG > > > > I support this policy. It seems natural to me that for allocation of > subsequent space the same rules apply like for the initial allocation. It > also helps organizations, that have received their space before the updated > initial allocation policy can receive space based on the same criteria. > > > > Silvia Hagen > > Chair Swiss IPv6 Council > > > > -----Urspr?ngliche Nachricht----- > Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im > Auftrag von Marco Schmidt > Gesendet: Donnerstag, 24. November 2016 14:20 > An: address-policy-wg at ripe.net > Betreff: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising > the Initial and Subsequent IPv6 Allocation Policies) > > > > Dear colleagues, > > > > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and > Subsequent IPv6 Allocation Policies" > > is now available for discussion. > > > > The goal of this proposal is to match the subsequent IPv6 allocation > requirements with the initial allocation requirements. > > > > You can find the full proposal at: > > > > https://www.ripe.net/participate/policies/proposals/2016-05 > > > > We encourage you to review this proposal and send your comments to < > address-policy-wg at ripe.net> before 23 > December 2016. > > > > Regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: wg/attachments/20161124/9704a2bc/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 24 Nov 2016 22:23:16 +0100 > From: JORDI PALET MARTINEZ > To: "address-policy-wg at ripe.net" > Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal > (Synchronising the Initial and Subsequent IPv6 Allocation Policies) > Message-ID: <559CA103-A7B4-449B-A8F6-B30CA92FBA66 at consulintel.es> > Content-Type: text/plain; charset="UTF-8" > > Hi Carsten, > > After reading several times our proposal, I think I got your point and I > guess you?re right. > > The actual text may be interpreted to limit the subsequent allocation to > be based only on the planned longevity, but not the other possibilities. > > I think it can be reworded as: > > ?If an organisation needs more address space, it must provide > documentation justifying its new requirements, as described in section > 5.1.2. (number of users, the extent of the organisation's infrastructure, > the hierarchical and geographical structuring of the organisation, the > segmentation of infrastructure for security and the planned longevity of > the allocation). The allocation made will be based on those requirements.? > > If we want to get the subsequent allocation ?automatically synchronized? > with the initial one, we should omit the text in ?()?. I think is the right > way to do so, if in the future the initial allocation text is changed > again, most probably, there are many chances that we avoid to rewrite the > text of the subsequent allocation. > > Saludos, > Jordi > > > -----Mensaje original----- > De: address-policy-wg en nombre de > Jordi Palet Martinez > Responder a: > Fecha: jueves, 24 de noviembre de 2016, 21:39 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising > the Initial and Subsequent IPv6 Allocation Policies) > > Hi Carsten, > > Thanks for your support. > > Regarding your question, yes the idea is to follow the same criteria > as for the initial allocation. Do you think the text is not clear and > requieres some clarification ? > > Regards, > Jordi > > > El 24 nov 2016, a las 21:04, Carsten Br?ckner > escribi?: > > > > Hello WG, > > I support this proposal. It will help current LIRs the receive of a > suitable (large) subsequent IPv6 address space according to their specific > needs. At the same time, it will give them the opportunity to set up a > senseful IPv6 Adressplan with respect to the Goals of IPv6 address space > management (Chapter 3 - ripe-655). Overall it will support the further IPv6 > Deployment in large organizations. > > But I have a question to the proposed paragraph in 5.2.3: > "If an organization needs more address space, it must provide > documentation justifying its requirements for the planned longevity of the > allocation. The allocation made will be based on this requirement.? > > Does that mean ?planned longevity? in sense of " > https://www.ripe.net/manage-ips-and-asns/ipv6/request- > ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? > Is this wording correct for the main goal of the proposal to > synchronize, with respect to the allocation size? > > Regards, > Carsten > > > > > > Am 24.11.2016 um 14:20 schrieb Marco Schmidt : > > Dear colleagues, > > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and > Subsequent IPv6 Allocation Policies" > is now available for discussion. > > The goal of this proposal is to match the subsequent IPv6 allocation > requirements > with the initial allocation requirements. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-05 > > We encourage you to review this proposal and send your comments to > before 23 December 2016. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 24 Nov 2016 22:29:33 +0100 > From: Carsten Br?ckner > To: jordi.palet at consulintel.es > Cc: "address-policy-wg at ripe.net" > Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal > (Synchronising the Initial and Subsequent IPv6 Allocation Policies) > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi Jordi, > Perfect! Full Support :-) > Regards, > Carsten > > > Am 24.11.2016 um 22:23 schrieb JORDI PALET MARTINEZ < > jordi.palet at consulintel.es>: > > > > Hi Carsten, > > > > After reading several times our proposal, I think I got your point and I > guess you?re right. > > > > The actual text may be interpreted to limit the subsequent allocation to > be based only on the planned longevity, but not the other possibilities. > > > > I think it can be reworded as: > > > > ?If an organisation needs more address space, it must provide > documentation justifying its new requirements, as described in section > 5.1.2. (number of users, the extent of the organisation's infrastructure, > the hierarchical and geographical structuring of the organisation, the > segmentation of infrastructure for security and the planned longevity of > the allocation). The allocation made will be based on those requirements.? > > > > If we want to get the subsequent allocation ?automatically synchronized? > with the initial one, we should omit the text in ?()?. I think is the right > way to do so, if in the future the initial allocation text is changed > again, most probably, there are many chances that we avoid to rewrite the > text of the subsequent allocation. > > > > Saludos, > > Jordi > > > > > > -----Mensaje original----- > > De: address-policy-wg en nombre de > Jordi Palet Martinez > > Responder a: > > Fecha: jueves, 24 de noviembre de 2016, 21:39 > > Para: > > CC: "address-policy-wg at ripe.net" > > Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal > (Synchronising the Initial and Subsequent IPv6 Allocation Policies) > > > > Hi Carsten, > > > > Thanks for your support. > > > > Regarding your question, yes the idea is to follow the same criteria > as for the initial allocation. Do you think the text is not clear and > requieres some clarification ? > > > > Regards, > > Jordi > > > > > > El 24 nov 2016, a las 21:04, Carsten Br?ckner > escribi?: > > > > > > > > Hello WG, > > > > I support this proposal. It will help current LIRs the receive of a > suitable (large) subsequent IPv6 address space according to their specific > needs. At the same time, it will give them the opportunity to set up a > senseful IPv6 Adressplan with respect to the Goals of IPv6 address space > management (Chapter 3 - ripe-655). Overall it will support the further IPv6 > Deployment in large organizations. > > > > But I have a question to the proposed paragraph in 5.2.3: > > "If an organization needs more address space, it must provide > documentation justifying its requirements for the planned longevity of the > allocation. The allocation made will be based on this requirement.? > > > > Does that mean ?planned longevity? in sense of " > https://www.ripe.net/manage-ips-and-asns/ipv6/request- > ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? > > Is this wording correct for the main goal of the proposal to > synchronize, with respect to the allocation size? > > > > Regards, > > Carsten > > > > > > > > > > > > Am 24.11.2016 um 14:20 schrieb Marco Schmidt : > > > > Dear colleagues, > > > > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and > Subsequent IPv6 Allocation Policies" > > is now available for discussion. > > > > The goal of this proposal is to match the subsequent IPv6 allocation > requirements > > with the initial allocation requirements. > > > > You can find the full proposal at: > > > > https://www.ripe.net/participate/policies/proposals/2016-05 > > > > We encourage you to review this proposal and send your comments to > > before 23 December 2016. > > > > Regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > > > > > > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > > > > > > > End of address-policy-wg Digest, Vol 63, Issue 6 > ************************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Dickinson at sky.uk Fri Nov 25 13:14:22 2016 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Fri, 25 Nov 2016 12:14:22 +0000 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> References: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE61749EFC@WPMBX010.bskyb.com> I support this proposal - and also the "automatic synchronisation" wording below. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of JORDI PALET MARTINEZ Sent: 24 November 2016 21:23 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Hi Carsten, After reading several times our proposal, I think I got your point and I guess you?re right. The actual text may be interpreted to limit the subsequent allocation to be based only on the planned longevity, but not the other possibilities. I think it can be reworded as: ?If an organisation needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. (number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation). The allocation made will be based on those requirements.? If we want to get the subsequent allocation ?automatically synchronized? with the initial one, we should omit the text in ?()?. I think is the right way to do so, if in the future the initial allocation text is changed again, most probably, there are many chances that we avoid to rewrite the text of the subsequent allocation. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Jordi Palet Martinez Responder a: Fecha: jueves, 24 de noviembre de 2016, 21:39 Para: CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Hi Carsten, Thanks for your support. Regarding your question, yes the idea is to follow the same criteria as for the initial allocation. Do you think the text is not clear and requieres some clarification ? Regards, Jordi El 24 nov 2016, a las 21:04, Carsten Br?ckner escribi?: Hello WG, I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. But I have a question to the proposed paragraph in 5.2.3: "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? Regards, Carsten Am 24.11.2016 um 14:20 schrieb Marco Schmidt : Dear colleagues, A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" is now available for discussion. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 We encourage you to review this proposal and send your comments to before 23 December 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From ripe-wgs.cs at schiefner.de Fri Nov 25 14:48:09 2016 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 25 Nov 2016 14:48:09 +0100 Subject: [address-policy-wg] If on digest mode, please edit your Subject line ! In-Reply-To: References: Message-ID: <0c87b4ed-c1fb-341a-83e3-ec9d8b6bc74c@schiefner.de> Constanze, all - I'd be much grateful if folks here (and on any other list they are subscribed to, too) would actually follow the following recommendation: On 25.11.2016 11:04, constanze buerger wrote: > [...] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." - which is part of any and all digests they are getting. Thank you very much - kind regards, Carsten From sander at steffann.nl Sun Nov 27 16:54:29 2016 From: sander at steffann.nl (Sander Steffann) Date: Sun, 27 Nov 2016 16:54:29 +0100 Subject: [address-policy-wg] Proceeding with proposal 2016-04 (IPv6 PI Sub-assignment clarification) Message-ID: <72460AB1-34ED-47C2-9CCD-6D2734102015@steffann.nl> Hello working group, The end of the discussion phase of proposal 2016-04 (IPv6 PI Sub-assignment clarification) has been reached. At this point in the PDP the proposer, in agreement with the working group chairs, decides whether to move forward. The chairs have determined that we have general consensus that the use-cases described in the proposal are valid ways to use PI space and the policy should reflect that. However there has been discussion on the exact way to fix the policy. The proposer has told us that he wants to continue with the current proposal and continue to the review phase. We decided to agree with this and go to review phase. The RIPE NCC will make an impact analysis and based on that we can continue the discussion on the list, review the proposal and where necessary adjust the exact wording of the proposal. Cheers, Sander & Gert Your working group chairs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Krengel at citkomm.de Tue Nov 29 13:22:21 2016 From: Krengel at citkomm.de (Krengel Martin) Date: Tue, 29 Nov 2016 12:22:21 +0000 Subject: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE61749EFC@WPMBX010.bskyb.com> References: <3A8594CB-DD61-4FB0-97A5-41F1390045A9@gmail.com> <559CA103-A7B4-449B-A8F6-B30CA92FBA66@consulintel.es> <9B3BFE0A18160E40BAF1950414D10FAE61749EFC@WPMBX010.bskyb.com> Message-ID: I support the proposal, based on the same reasons outlined by Silvia, and also the link for the "automatic synchronisation" Best regards Martin -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Dickinson, Ian Sent: Friday, November 25, 2016 1:14 PM To: jordi.palet at consulintel.es; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) I support this proposal - and also the "automatic synchronisation" wording below. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of JORDI PALET MARTINEZ Sent: 24 November 2016 21:23 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Hi Carsten, After reading several times our proposal, I think I got your point and I guess you?re right. The actual text may be interpreted to limit the subsequent allocation to be based only on the planned longevity, but not the other possibilities. I think it can be reworded as: ?If an organisation needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. (number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation). The allocation made will be based on those requirements.? If we want to get the subsequent allocation ?automatically synchronized? with the initial one, we should omit the text in ?()?. I think is the right way to do so, if in the future the initial allocation text is changed again, most probably, there are many chances that we avoid to rewrite the text of the subsequent allocation. Saludos, Jordi -----Mensaje original----- De: address-policy-wg en nombre de Jordi Palet Martinez Responder a: Fecha: jueves, 24 de noviembre de 2016, 21:39 Para: CC: "address-policy-wg at ripe.net" Asunto: Re: [address-policy-wg] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Hi Carsten, Thanks for your support. Regarding your question, yes the idea is to follow the same criteria as for the initial allocation. Do you think the text is not clear and requieres some clarification ? Regards, Jordi El 24 nov 2016, a las 21:04, Carsten Br?ckner escribi?: Hello WG, I support this proposal. It will help current LIRs the receive of a suitable (large) subsequent IPv6 address space according to their specific needs. At the same time, it will give them the opportunity to set up a senseful IPv6 Adressplan with respect to the Goals of IPv6 address space management (Chapter 3 - ripe-655). Overall it will support the further IPv6 Deployment in large organizations. But I have a question to the proposed paragraph in 5.2.3: "If an organization needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation made will be based on this requirement.? Does that mean ?planned longevity? in sense of "https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-initial-ipv6-allocation" paragraph 2 (b)? Is this wording correct for the main goal of the proposal to synchronize, with respect to the allocation size? Regards, Carsten Am 24.11.2016 um 14:20 schrieb Marco Schmidt : Dear colleagues, A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" is now available for discussion. The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 We encourage you to review this proposal and send your comments to before 23 December 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4882 bytes Desc: not available URL: