August 2015 - address-policy-wg

2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 07 Nov '15

07 Nov '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - AS Numbers can now be assigned for any need that cannot be satisfied with an existing AS Number - The RIPE NCC's need evaluation has been removed - A limit of 1,000 AS Numbers per organisation has been added - There is now a requirement that 16-bit AS Numbers be multihomed after nine months - The requirement that the routing policy must be new and unique has been removed - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-03 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-03/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 22 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

16 41

2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4
by Job Snijders 15 Oct '15

15 Oct '15

Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job

8 15

2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by Marco Schmidt 02 Oct '15

02 Oct '15

Dear colleagues, A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 14 September. Regards Marco Schmidt Policy Development Officer RIPE NCC

12 24

2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 29 Sep '15

29 Sep '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

9 19

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