- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by George Michaelson 03 Sep '15

03 Sep '15

Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details. Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms. On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one. I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers. -George On 3 September 2015 at 14:38, Nick Hilliard <nick(a)inex.ie> wrote: > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > Mind, if yelling loudly is how you get policy made in the RIPE > > community, rest assured I can yell VERY loudly. I can, in fact, > > even automate the yelling if need be. > > please don't: rfc7282 works much better. > > Nick > >

2 1

Update on Inter-RIR Transfer Implementation
by Marco Schmidt 01 Sep '15

01 Sep '15

Dear colleagues, We wanted to update you on our implementation of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". We have made good progress so far on what has been one of the most substantial policy changes ever implemented by the RIPE NCC. Most of the updates to our internal processes and software have been finalised, as have the processes that require interaction with the other RIRs. During the implementation we encountered some additional complexity in the transfer process. To compensate for this, we are developing additional software automation to ensure the quality of registration data is maintained. We now therefore expect the implementation to be finished before the end of September. The policy implementation status has been updated accordingly, and you can find this here: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-impleme… We will send another announcement once the implementation has been completed. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE IPv4 Allocation Policy
by SBS - Support 31 Aug '15

31 Aug '15

Dear RIPE Address Policy Group, The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified. Regards, Walter This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.

10 15

2015-03 Last Call for Comments (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 31 Aug '15

31 Aug '15

Dear colleagues, The proposal described in 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 29 September 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of the Working Group for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 29 September 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Help Re: address-policy-wg Digest, Vol 48, Issue 17
by 8lb. 7zin 19 Aug '15

19 Aug '15

‏في الثلاثاء، ١٨ أغسطس، ٢٠١٥, <address-policy-wg-request(a)ripe.net> كتب: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net <javascript:;> > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net <javascript:;> > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net <javascript:;> > > 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: 2015-04 New Policy Proposal (RIPE Resource Transfer > Policies) (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Aug 2015 18:26:30 +0200 > From: Jan Ingvoldstad <frettled(a)gmail.com <javascript:;>> > To: Address Policy Working Group <address-policy-wg(a)ripe.net > <javascript:;>> > Subject: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE > Resource Transfer Policies) > Message-ID: > < > CAEffzkzzpKA1aqUtUzESDJpLggLbOUdfMhaETmStDcRddPmUjg(a)mail.gmail.com > <javascript:;>> > Content-Type: text/plain; charset="utf-8" > > On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < > james.blessing(a)despres.co.uk <javascript:;>> wrote: > > > On 14 August 2015 at 10:54, Marco Schmidt <mschmidt(a)ripe.net > <javascript:;>> wrote: > > > > > https://www.ripe.net/participate/policies/proposals/2015-04 > > > > Thanks for putting in the time and effort, Erik! > > Couple of questions/comments... > > > > From 1.0 > > > > Shouldn't the scope be explicit as to what is/isn't included > > > > I agree that this would help. > > >From 2.1 > > > > "Transfers can be on a permanent or non-permanent basis." > > > > How is this going to be recorded and managed within the context of > > reflecting it being a non-permanent transfer? > > > > Wouldn't that be up to the RIPE NCC? > > >From 2.2 > > > > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit > > ASNs)" > > > > Rather than "such as" this needs to be a definitive list of what is > > classed as a restricted resource > > > > I concur, but I don't think it should be listed in the same document. > > My first thought is that this list should be maintained by the RIPE NCC. > > Keeping that list in a separate document means changing fewer documents > when policy changes, or reality reaches a pre-set limit set in policy. > > That separate list should reference the policy documents enabling the > restrictions. > > >From 3.1 > > > > Again a list of conditions or references to policies that impose > > restrictions needed > > > > I'm a bit confused both by the point and by your response to it, maybe I'm > just tired, but I think both could be clearer. :) > > >From 4.0 > > > > M&A process is mentioned, should there be other references to this? > > Especially as M&A (as I understand it) allows 2.2 to be overridden > > > > "The document proposes to include the transfer restrictions to mergers and > acquisitions. This is done to make the policy more in line with the > intention of the transfer policy restrictions when proposed." > > General > > > > - As this is about transfers should this also cover returning > > resources to ripe NCC so all types of transfers be included > > > > I'm not sure that this would be useful, but 2015-04 could 1) include a > reference to the policy for that, and 2) make it even clearer that this is > a document for transfers between resource holders. > > I don't think it's useful to consider the RIR a resource holder in this > context. > > - broadly support the unification of transfer policy into a single > > document, just things bits are missing or muddy > > > > Agreed, but the document is largely clarifying more than muddying, IMHO. > -- > Jan >

1 0

Fwd: 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by ripe＠europeiptv.net 16 Aug '15

16 Aug '15

Hello, The allocations made before the date of this announcement, should be governed by the old politics. is not serious things apply retroactively. On exhaustion, RIPE Why is not like other RIRs? Because RIPE accepts LIRs outside the region? without having a registered company and physical address in the RIPE Region? Other ARIN RIR as it met. Regards. David

8 12

Fwd: Suggestions on a new asn assignment policy
by Nick Hilliard 14 Aug '15

14 Aug '15

AP-WG, I've included below an email which was sent to the authors of 2014-03 as a followup to this email (dated Sat May 16 01:40:13 CEST 2015): > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-May/009982.h… Saku, Job and I discussed these ideas but the discussions didn't come to anything. The suggestions below don't fix everything with ASN assignment because 100% solutions don't work. However they provide a practical and workable mechanism which trivially deals with the vast majority of cases, and provides a known working mechanism for creating a run-out pool for ASN16, all based on policy principals which are either in place for other resources, or else which have been tried and tested in practice. I'm planning to write this up as a formal policy proposal in the next short while, as an alternative to 2014-03. If anyone has suggestions or tweaks, please feel free to bring them up. Nick -------- Forwarded Message -------- Subject: Suggestions on a new asn assignment policy Date: Sat, 16 May 2015 00:43:18 +0100 From: Nick Hilliard <nick(a)foobar.org> To: Job Snijders <job(a)instituut.net>, Saku Ytti <saku(a)ytti.fi> CC: AP WG Chairs <apwg-chairs(a)ripe.net> Saku, Job, WG Chairs, re: my email to ap-wg of a couple of moment ago, here are some ideas I've been mulling over: - if an end user wants a single ASN32 and they don't already have one, they should get it on the basis of entitlement. - if an end user wants more than one ASN32, they should get it on the basis of a needs-based policy. - if an end user wants one or more ASN16s, they should get it on the basis of an needs-based policy, unless the remaining pool of ASN16s has reached a certain threshold - regardless of the requirement, end users may only receive one ASN16 from the remaining pool, and this should be assigned on the basis of a needs-based policy. The needs criteria can be collated by both operator input and by taking a look at historical assignment reasons: the ripe ncc have 25 years of experience in assigning ASNs and have a large database of reasons that end-users have put forward on their application forms. But we already have a pretty good idea of what this list should include. Basing a new policy along the lines of these principals will provide the following: - no requirement for charging - trivially deals with the most common case, namely assignment of a single asn32 - a runout policy for asn16s which both has well-understood limitations and will probably be palatable to the ripe community, as it's proposed on a similar basis to the last /8 + will be subject to 24m rule. - no practical way of asn32 resource exhaustion because each application will be individually evaluated by an IPRA (either on the basis of 2007-01 for end-user authentication or else on the basis of needs evaluation once that authentication has been completed). - continuation of existing ASN16 policy until a hard limit is hit, after which a run-out policy will apply - conceptually very similar to ipv4 / ipv6 policy. - hopefully an end to lies on asn application forms for asn32s I don't know what you guys feel about these suggestions, but I think they could be used to create something a good deal better than what we have right now. If you want to use these suggestions to form 2014-03 v3.0, you are welcome to do so, but I would ask you kindly to acknowledge my input as appropriate. Alternatively, if either or both of you have got tired of 2014-03, I would be happy to take up the baton and run with something along the lines of the above. Nick

5 12

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 13 Aug '15

13 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #address-policy channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

19 25

2015-02 Proposal Accepted and Implemented (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 10 Aug '15

10 Aug '15

Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-641, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. This policy change removes the requirement that LIRs return their IPv6 Provider Independent (PI) assignment when requesting an IPv6 allocation if there are no specific routing requirements to justify both. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 The new RIPE Document is called ripe-650 and is available at: https://www.ripe.net/publications/docs/ripe-650 This proposal is implemented with immediate effect. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2015-02 Last Call for Comments (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 06 Aug '15

06 Aug '15

Dear colleagues, The proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 6 August 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 6 August 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

2 1