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

Is the final /8 the correct term ? - semi off track to the 2013-03 discussion..
by Erik Bais 28 Jul '13

28 Jul '13

Hi, Ive heard the phrase the final /8 in several discussions but I want to ask people what their idea is about the pool that is currently still left If you think that the pool which we have left is only the final /8 that we are working into currently (185.x.y.z) I think that the assumption is incorrect. There is still space left at IANA and once the first RIR reaches below their /9 mark of their final /8 from my understanding it is , that also that space is going to be allocated to the RIRs . Also there will be reclaimed space from 2007-01 and closing LIRs (forced or by people their own decision) and also that space all goes back into the same pool. So you might need quite a couple of new entities to finish the pool as it is. . . Ive seen people say, why not open 20 new entities, setup a new LIR in each .. and you have 20 /22s Yes it is possible.. However Ive noticed, there is little support to close this gap.. or the gap to be able to merge those 20 LIRs .. or the option to be able to merge any LIRs that already have their final /8 /22 provided. Yes there will be people who play the system.. and with the bottom in sight, do we want to close all possible loopholes ? If we decide, no we dont want to close the loopholes, stop mentioning it in the discussion as a possible threat, because we already decided it is what it is and we are not going to close the gap. There will be some people that will just open a second LIR or perhaps even 8, there will be people who go to the IPv4 market and seek their v4 fix there The more people will request space from the current pool, with their own benefit in mind without any regard for the actual intention of the policy (provide an option for new companies into the market) it is too bad. If we are happy with the policy in place or dont see/feel the need to change, it is to me a clear consensus on how it is potentially abused. If there is no consensus and people do feel the requirement to adjust it, lets see what goes faster Getting a new policy in place or the depletion of the pool as it is currently Just my 2 cent. Erik

4 4

Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published(No Need - Post-Depletion Reality Adjustment and Clean up)(Tore Anderson)
by sandrabrown＠ipv4marketgroup.com 25 Jul '13

25 Jul '13

Dear Tore, Thank you for inviting me to speak. >>I feel this statement is somewhat disingenuous. The "odd RIR out" here is really ARIN, who is the only one to have a inter-RIR transfer policy that has a needs-based requirement that is also applied to the other region involved in the transfer. I agree 100% that ARIN is the "Odd RIR Out". Only ARIN pushes for needs assessments and other silliness on transfers, and I agree 100% that companies will not be silly about spending good money on IPv4 addresses that may become worthless. >>That said, there has been an inter-RIR proposal (2012-02) on the table for a while now, but the community does not seem to want or care much about it. I think that this is important to keep that in mind when deciding on how much weight to give this argument against 2013-03. Yes, 2012-02 was on the table, but has now been withdrawn, pending the outcome of 2013-03. If, and hopefully when, 2013-03 is implemented, then my intention is to put in place a new inter-RIR proposal for the RIPE community, at a time the community feels is appropriate, which allows for transfer of **legacy** IP's currently in the ARIN registry. As you probably know, legacy IP's were issued to resource holders prior to the creation of ARIN in 1997, and thus legacy holders can request RIPE to register their IP's, if the RIPE community agrees, rather than ARIN, as the registry. Then the inter-RIR transfer of legacy IP's from ARIN to RIPE can proceed regardless of needs justification, as the legacy IP's would be in the RIPE registry rather than the ARIN registry. We would have to discuss the mechanics as it might better be regarded as an inter-RIR transfer from a legacy ARIN registry element to a RIPE LIR. This is much like the ERX transfers of the past, but to a purchasing LIR. >>I'm not at all principally opposed to inter-RIR transfers, so if the author of 2012-02 would add a "need compatibility clause" to the proposed inter-RIR policy, I would have nothing against that. In other words, if it would be possible to make the need evaluation a voluntary thing that you only had to do if transferring addresses from the ARIN region - fine. Then those 5 LIRs, and those 5 only, could subject themselves to whatever demands the ARIN community might have, while the rest of us would be free of the IPv4 bureaucracy. Win-win. No, the author of 2012-02 is strongly opposed to needs justification so I would not be interested in adding needs compatibility to inter-RIR transfers. I would much rather focus on legacy IP's for inter-RIR transfers, intra-RIR transfers within RIPE, and will support any discussion within the community to bring modern economics to ARIN. Best Regards, and Thanks for the Invitation, Sandra Brown

3 2

Re: [address-policy-wg] address-policy-wg Digest, Vol 23, Issue 15
by Lu Heng 24 Jul '13

24 Jul '13

Hi Should the technical side of resouce training being done by ripe ncc training rather than policy? I am not against put basic principal there though. On Jul 24, 2013 5:27 PM, <address-policy-wg-request(a)ripe.net> wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > 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 > > You can reach the person managing the list at > address-policy-wg-owner(a)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: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Tore Anderson) > 3. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Filiz Yilmaz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jul 2013 12:53:18 +0200 > From: Filiz Yilmaz <koalafil(a)gmail.com> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment > and > Clean up) > To: Tore Anderson <tore(a)fud.no> > Cc: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> > Message-ID: <FFF81C24-3E2F-4E44-8837-32D44B8B841D(a)gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hello Tore, > > While I am curious for Michele's response to your mail too, here is my > bit, as I feel I agree with him in terms of principles. > > First of all, I am not totally against your proposal; it cleans up the > policy text reflecting today's circumstances to some extent and it makes a > long document way more readable. > This is also why I am writing back because I've read the draft policy > document from the beginning to the end. > > My observation is that the new document proposed is not exactly a > "registration" policy document. > It more looked to me like a description of how address space management is > done within RIPE NCC region "by the RIPE NCC". > > If I am not missing anything crucial, the main points described are: > > - The language is English, > - How big an allocation can be, > - That there is no PI anymore to be assigned directly from the NCC pools > to End users (except for the IXPs) so all resources will only goto LIRs > - And these blocks can be transferred between LIRs. > > The only bit about registration I see in the new text is section 4.0 > Registration Requirements and it does not go more than saying details > should be recorded in the database. > > So it does not contain any substantial information for registration or > address management on the LIR's side. > > This is interesting as now with this proposed policy any End user's chance > to get any IPv4 address space will be through an LIR and hope that these > LIRs are responsible and know what they are doing. I would like to see some > guidelines or at least principles mentioned in this document so the LIRs > know their responsibility in terms of fair address management as well as > the End Users so they know what to expect from these LIRs. This is what I > would be expecting from a transparent documentation of a set of policies > and principles that are still in place. > > We may not have too many specific policies to set for the few left-over > resources but I would like to believe we still have "principles" towards > the responsible management of these resources. > > In that sense Michele has a point and I argue that LIRs need to be guided > for "good address management" even without the "conservation" principle as > the top priority in the new IP world. This is missing in the proposed > policy text for it to be considered as a helpful "registration" policy in > my opinion. > > In practice, I can set up a new LIR now and ask for a new allocation and I > may be someone who does not have any previous RIPE or RIPE NCC experience. > If all I have is this document, I am not sure if it tells me enough about > my responsibilities, while I will be a critical token in the EU address > management and registration system by just becoming an LIR. > > > My other concern is in regards to the transfers. As neatly put by the NCC > Board in the Impact Analysis: > > --- > As mentioned in previous sections, the policy proposal would negatively > affect the ability of LIRs to engage in inter-RIR transfers, as the RIPE > NCC?s service region would be the only one without a needs-based > requirement for transfers. > Implementation of the policy could expose LIRs to legal challenges under > EU competition law. > --- > > > I think singling out the RIPE NCC region in the world of transfers may not > be the best idea at this stage. > > Kind regards > Filiz Yilmaz > > > > > On 24 Jul 2013, at 10:52, Tore Anderson <tore(a)fud.no> wrote: > > > * Michele Neylon - Blacknight > > > >> As previously stated, I do NOT support the "no need" policy and > >> cannot support this document. > >> > >> IP addresses are a finite resource, as we all know, and obliging > >> people to provide some level of justification makes sense. > >> > >> The argument for "conservation" may no longer be valid, but there > >> will always be a compelling argument in favour of good resource > >> management, which I believe the policy covers. > >> > >> RIPE should not remove the requirement to provide justification. > > > > Hi Michele, > > > > I doubt you'll find anyone in the working group who is against good > > resource management. I am convinced that the proposed policy is not in > > conflict with good resource management, otherwise I would never have > > proposed it. While I can obviously only speak with certainty for myself, > > I assume that the people who support the proposal feel the same way. > > > > While it appears you believe that the proposal will bring about poor > > resource management, your message neglected to explain why or how. This > > makes it rather difficult for me to try to alleviate your concerns. > > > > As Gert also pointed out recently, the main reason I believe that IPv4 > > would continue to be consumed responsibly under the proposed policy, is > > that the LIRs in the region are painfully aware that there is no more > > IPv4 to be had from the RIPE NCC. Should an LIR anyway decide to go on a > > "spending spree" with its remaining inventory, it would only end up > > hurting itself by expediting its own depletion date. The community will > > not be impacted - without a Common, there can be no Tragedy. > > > > Best regards, > > Tore Anderson > > > >

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 23, Issue 5
by Lu 17 Jul '13

17 Jul '13

I support it as it would greatly reduce our work load. This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. 在 2013-7-12，12:00，address-policy-wg-request@ripe.net 写道： > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > 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 > > You can reach the person managing the list at > address-policy-wg-owner(a)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: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Randy Bush) > 2. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Elvis Daniel Velea) > 3. Re: 2013-03 New Draft Document and Impact Analysis Published > (No Need - Post-Depletion Reality Adjustment and Clean up) > (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Jul 2013 14:19:50 -1000 > From: Randy Bush <randy(a)psg.com> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: Tore Anderson <tore(a)fud.no> > Cc: RIPE address policy WG <address-policy-wg(a)ripe.net> > Message-ID: <m2bo681vfd.wl%randy(a)psg.com> > Content-Type: text/plain; charset=US-ASCII > > tore, > > you did not succeed in making the proposal unappealing. so i still > support it. > > randy > > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Jul 2013 03:01:55 +0200 > From: Elvis Daniel Velea <elvis(a)velea.eu> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: Randy Bush <randy(a)psg.com> > Cc: Tore Anderson <tore(a)fud.no>, RIPE address policy WG > <address-policy-wg(a)ripe.net> > Message-ID: <-1730481542746753856@unknownmsgid> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I also support it. > > Regards, > Elvis > > Excuse the briefness of this mail, it was sent from a mobile device. > > On 12 jul. 2013, at 02:20, Randy Bush <randy(a)psg.com> wrote: > >> tore, >> >> you did not succeed in making the proposal unappealing. so i still >> support it. >> >> randy > > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Jul 2013 09:55:13 +0200 > From: Jan Ingvoldstad <frettled(a)gmail.com> > Subject: Re: [address-policy-wg] 2013-03 New Draft Document and Impact > Analysis Published (No Need - Post-Depletion Reality Adjustment and > Clean up) > To: RIPE Address Policy WG <address-policy-wg(a)ripe.net> > Message-ID: > <CAEffzkzNTbrBYRRW+x2xObqcro-CK=tmKUj4r-_i_dRVu5JciA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, Jul 4, 2013 at 1:48 AM, Tore Anderson <tore(a)fud.no> wrote: > >> Hi again, >> >> I was asked off-list if I could provide a unified diff showing the >> changes between version 1.0 and 2.0 of the proposed policy text. >> Attached! > > > Excellent, that made it much easier to see the changes. > > I support this version. > -- > Jan >

1 0

RIPE 66 Address Policy WG Meeting Draft Minutes
by Emilio Madaio 16 Jul '13

16 Jul '13

Dear Colleagues, The draft minutes of Address Policy Working Group sessions from RIPE 61 are now available at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-66 Best Regards Emilio Madaio Policy Development Officer RIPE NCC

1 1

regid: rspn.ir
by Mehdi Sabour 15 Jul '13

15 Jul '13

Dear Colleague, I've faced a problem and I want to address it to you; I hope you can help me. One of my customers called "Sapco" has 193.105.2.0/24 range of IP address, It has already established BGP protocol with us and ITC (You can find its diagram in attachment). Everything with this Range IP is ok but when Sapco's clients want to browse Google's website, google.br (Belgium) opens instead of google.com. I registered its IPs in Google' support (https://support.google.com/websearch/contact/ip), unfortunately the problem hasn't solved yet. I've checked these IPs in all websites, in all of them 193.105.2.0/24 registered Iran country but I and ITC don't know what the problem is. I hope you can help me, if you face this kind of problem. Best Regards. --- Mehdi Sabour NOC Manager Technical Division Respina Networks & Beyond T: +98 21 84 23 00 00 F: +98 21 88 19 10 83 www.respina.net<http://www.respina.net/> ________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of RESPINA. Finally, the recipient should check this email and any attachments for the presence of viruses. RESPINA accepts no liability for any damage caused by any virus transmitted by this email. ________________________________

2 1

Guidance Requested: Reassigning Referenced ASNs
by Sonderegger Olaf ABRAXAS INFORMATIK AG 01 Jul '13

01 Jul '13

Hi all Based on Randy's proposal: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail. So: 1. Inform owner about its wrong objects (only once). 2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month. 3. Re-assign AS numbers after two month. Best regards, Olaf Sonderegger

11 12

Re: [address-policy-wg] PA/PI unification PI Address Space
by Gert Doering 01 Jul '13

01 Jul '13

Hi, (subject changed and in-reply-to: removed, to make it clear that this is really a different thread) On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > It would be nice if Address Policy WG could continue with the > idea about removing status "Provider Aggregatable" (PA) and "Provider > Independent" (PI). Are there any plans? For IPv4, let's wait until Tore's proposal has come to a conclusion, as it's very hard to do two large-scale changes to the same text at the same time. For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

4 6

Guidance Requested: Reassigning Referenced ASNs
by Andrea Cima 01 Jul '13

01 Jul '13

[Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC

12 21

Re: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
by Andreas Schachtner 27 Jun '13

27 Jun '13

Sanity checking upon submitting to the DB could prevent this. My 2c, Andreas Schachtner Send via mobile device. Please excuse brevity, typos and the funny spelling checker in particular. Gert Doering <gert(a)space.net> schrieb: >Hi, > >On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote: >> Actually I don't really understand the problem. If the ASN is >> back in the pool, this reads for me "it shall no longer appear in >> the routing table". This includes for me that any object referencing >> this ASN is illegal by definition. So these illegal objects may not >> exist and *must* be removed asap from the DB. After removing all >> illegal objects, they should stay in some "grace-period" - let's >> say 3 month - and then there should be no problem reallocating the >> asn. > >The database currently has no mechanics to prevent someone from entering >an import/export line that says: > > aut-num: AS100000 > remarks: have fun with Jens > export: to AS5539 announce AS48200 > >which is exactly that sort of reference that would currently keep the >NCC from reallocating AS48200 (assuming that one were free). > >Auto-cleaning the route: objects still referencing AS48200 is fairly >easy, but auto-cleaning export/import policies and AS-SET objects is >harder, especially as people might have the aut-num: object in question >on file, just change stuff locally, and then re-send it when they have >changes, overriding the cleaned-up object in the database... > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

4 6

Guidance Requested: Changing the Status of PI Address Space
by Sonderegger Olaf ABRAXAS INFORMATIK AG 27 Jun '13

27 Jun '13

Hi all My question is: Why RIPE NCC should go one step back instead one step forward? I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. Ref 1: http://ripe62.ripe.net/presentations/148-wg.pdf<http://ripe62.ripe.net/presentations/148-wg.pdf%20/> Ref 2: http://ripe63.ripe.net/presentations/143-wg3.pdf I think, I could accept request as our first step in direction of removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Best regards, Olaf Sonderegger

4 4

Re: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
by Michele Neylon :: Blacknight 26 Jun '13

26 Jun '13

+1 seems sane On 25 Jun 2013, at 16:51, Randy Bush <randy(a)psg.com> wrote: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. > > randy > Mr Michele Neylon Blacknight Solutions ♞ Hosting & Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

1 0

Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 26 Jun '13

26 Jun '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". A draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… The Address Policy Working Group Co-Chairs decided to extend the review period until 9 July 2013 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at <address-policy-wg at ripe.net>. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC

4 4

2013-02 Proposal Accepted (Removal of requirement for certification of reallocated IPv4 addresses)
by Emilio Madaio 21 Jun '13

21 Jun '13

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-02 The updated RIPE Policy document is ripe-592 and is available at: https://www.ripe.net/ripe/docs/ripe-592 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Resource Certification for non-RIPE NCC Members
by Erik Bais 20 Jun '13

20 Jun '13

Dear community members of the AP WG and the NCC Services WG, As you may have seen, Ive created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders) Currently we are in the phase: Discussion Open for discussion And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy. For those that are not subscribed to the NCC Services mail-list -=> http://www.ripe.net/mailman/listinfo/ncc-services-wg/ During the creation of the policy I made a small error in the intention to limit the policy to entities in the RIPE NCC service region and the policy currently states: The Internet resources reside within the RIPE NCC service region Ill update this in the review phase. Im not sure yet if we need to skip that part entirely or change it to the actual intention. Your input and stated support on the NCC Services WG mail list would be highly appreciated. Kind regards, Erik Bais Link to the policy proposal: https://www.ripe.net/ripe/policies/proposals/2013-04

10 13

the interpretation of "transfer" - somewhat related to 2012-07
by Wilfried Woeber 12 Jun '13

12 Jun '13

Quoting Andrea's comment of today regarding "authoritative" RIR: <quote> Legacy resources issued to organisations within the RIPE region have been transferred to the RIPE region during the ERX project. Legacy resources that have not been transferred at that time, have been issued and registered to organisations in other RIR regions. RIPE policy has no authority over legacy resources registered in other RIR regions. For this reason, in order to transfer those resources to the RIPE registry (and register them with a RIPE NCC LIR), there needs to be a transfer policy that would allow transfers between the RIPE NCC and the RIR that has the authority over those resources. </quote> First of all, I appreciate the NCC's cautious approach to moving things around without a clear consensus and guidance on preocedures! Two comments for discussion or clarification: ° until now I always read policies or policy proposals regarding a "transfer" of addresses from userA to userB. With either both of them sharing the same assignment to an authoritative RIR (intra-region xfr) or relating to different authoritative RIRs (inter-region xfr). The comment as quoted above indicates a different, or rather an additional interpretation and applicability: the transfer of address *registration* data pertaining to some (the very same!) userX from one authoritative RIR to a different one. I am not sure that the community did or does have that interpetation in mind? ° the "good old ERX" project, back then, was based on simple clerical inputs, a procedural agreement amongst the RIRs, and with no formal policy background, IIRC. Thus I do not really understand, why we would need a formal "policy" regarding inter-regeion transfers, as long as the registration subject remains the same. I may have missed some things, of course. Wilfried.

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 22, Issue 5
by ACCESS 11 Jun '13

11 Jun '13

Вторник, 11 июня 2013, 12:00 +02:00 от address-policy-wg-request(a)ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > 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 > > You can reach the person managing the list at > address-policy-wg-owner(a)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: Resource Certification for non-RIPE NCC Members (Peter Koch) > 2. Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a > per-allocation vs per-LIR basis" implemented (Kjell Leknes) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jun 2013 17:20:30 +0200 > From: Peter Koch < pk(a)DENIC.DE > > Subject: Re: [address-policy-wg] Resource Certification for non-RIPE > NCC Members > To: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 20130610152030.GK14598(a)x28.adm.denic.de > > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: > > > Whether we need a formal "policy" or just an agreement (amongst the members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > > For now using the framework of the PDP maybe useful and appropriate. > > I respectfully suggest it is not. The current modus operandi for RPKI > in the NCC service region is not only not based on a policy created > by the PDP, it exists despite a policy proposal for that very subject > having failed. Whether or not that creates a schism might be interesting > to discuss, but is not relevant for the case at hand. What counts here is > that the absence of policy is not an 'omission' or accident. > > So far I have seen support for 2013-04 based on symmetry or equality of > PA, PI and other (former) special cases. While this might have merit > operationally, it cannot support a parallel policy just because there's > nothing to draw the parallel to. This point of order has not been addressed > so far (and there are multiple solutions to this situation). > > Therefore I formally object to 2013-04 being elevated into the next PDP phase. > > -Peter > > ------------------------------ > > Message: 2 > Date: Tue, 11 Jun 2013 08:43:29 +0200 > From: Kjell Leknes < kjell(a)ripe.net > > Subject: [address-policy-wg] Policy Proposal 2012-10 "Extension of > IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented > To: "address-policy-wg(a)ripe.net" < address-policy-wg(a)ripe.net >, > "policy-announce(a)ripe.net" < policy-announce(a)ripe.net > > Message-ID: < 11E136AE-2A9A-4798-9F2E-D57CF49672D8(a)ripe.net > > Content-Type: text/plain; charset="us-ascii" > > [Apologies for duplicate emails] > > Dear colleagues, > > We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. > > The full policy proposal can be found at: > http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] > > The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: > http://www.ripe.net/ripe/docs/ripe-589 [Open URL] > > You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net > > If you have any questions, please contact ncc(a)ripe.net > > Regards, > > Kjell Leknes > Registration Services > RIPE NCC >

1 0

Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
by Kjell Leknes 11 Jun '13

11 Jun '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net If you have any questions, please contact ncc(a)ripe.net Regards, Kjell Leknes Registration Services RIPE NCC

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 22, Issue 2
by ACCESS 08 Jun '13

08 Jun '13

Суббота, 8 июня 2013, 12:00 +02:00 от address-policy-wg-request(a)ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > 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 > > You can reach the person managing the list at > address-policy-wg-owner(a)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: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Wilfried Woeber) > 2. Re: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Erik Bais) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 07 Jun 2013 15:32:31 +0200 > From: Wilfried Woeber < Woeber(a)CC.UniVie.ac.at > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: Erik Bais < ebais(a)a2b-internet.com > > Cc: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 51B1E0EF.7010303(a)CC.UniVie.ac.at > > Content-Type: text/plain; charset=windows-1252 > > Hi Erik, Community, > > a couple of general comments before potentially going into details on the > Services WG. > > Whether we need a formal "policy" or just an agreement (amongst the members > of the NCC) to a Service Description and a review of the CPS as maintained > by the NCC is a sideline issue, imho. > > For now using the framework of the PDP maybe useful and appropriate. > > I concur with other comments already, that - at the moment - there is, and > probably shouldn't be - a different colour related to PA, PI, ERX, v4, v6, > you name it. So, whatever we come up with should be "the same", technically. > > Looking at the proposed text for discussion, I sense a mindset of "the NCC is > the sole source of the Certificates". This may be reasonable for those paries, > which do have a direct Service Contract with the NCC (Direct End User, Legacy). > > For all the others, there is - or structurally, will be - a managed foodchain > and Hierarchy. > > This may be > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > In the end we SHOULD, imo, structure the service definition *and* the > implementation to be congruent to this structe. I.e. the LIRs SHOULD be the > parties issuing the certificates for those resources which are held by their > users/customers, and for which there is a contract. > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > structure for cert.creation, and "verification" by the NCC, would become > messy. We (my team) DO have real life experience, that such a disjunct and > artificial mechanism is a pain, and a source for inconsistencies. > > And, last but not least, in order to potentially, in the (near?) future, > overcome the "single point of failure thing" (that we are creating now by > building a "proper" tree structure!), removing any and all notion of the > Service Region would have my *strong* support. Not just because it will be > difficult to find a proper definition of "reside within", but more so because > it would open the chance to actually acquire certificates from more than one > "root", aka CA. > > These multiple roots/CAs could either (preferably?) be the set of RIRs, but > other parties as well. This would take away most of my worries and reservation > related to the proliferation of the RPKI. > > Sorry for the long text ;-) > Wilfried. > > Erik Bais wrote: > > > Dear community members of the AP ? WG and the NCC Services WG, > > > > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to > > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > > / Legacy space and PI space holders) > > > > Currently we are in the phase: Discussion ? Open for discussion > > > > And I would like to invite you to the service wg mail list for your support > > for this policy and a discussion on wording of the policy. > > For those that are not subscribed to the NCC Services mail-list -=> > > http://www.ripe.net/mailman/listinfo/ncc-services-wg/ > > > > During the creation of the policy I made a small error in the intention to > > limit the policy to entities in the RIPE NCC service region and the policy > > currently states: > > > > ? The Internet resources reside within the RIPE NCC service region > > > > I?ll update this in the review phase. I?m not sure yet if we need to skip > > that part entirely or change it to the actual intention. > > > > Your input and stated support on the NCC Services WG mail list would be > > highly appreciated. > > > > Kind regards, > > Erik Bais > > > > Link to the policy proposal: > > https://www.ripe.net/ripe/policies/proposals/2013-04 > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Jun 2013 18:37:38 +0200 > From: "Erik Bais" < ebais(a)a2b-internet.com > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: < Woeber(a)CC.UniVie.ac.at > > Cc: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 007801ce639d$529eb0b0$f7dc1210$(a)a2b-internet.com > > Content-Type: text/plain; charset="Windows-1252" > > Hi Wilfried, > > First of all, let me say thanks for the feedback. > > > Whether we need a formal "policy" or just an agreement (amongst the > members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > For now using the framework of the PDP maybe useful and appropriate. > > So do I. > > > Looking at the proposed text for discussion, I sense a mindset of "the NCC > is > > the sole source of the Certificates". This may be reasonable for those > paries, > > which do have a direct Service Contract with the NCC (Direct End User, > Legacy). > > > For all the others, there is - or structurally, will be - a managed > foodchain > > and Hierarchy. > > > This may be > > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > > In the end we SHOULD, imo, structure the service definition *and* the > > implementation to be congruent to this structe. I.e. the LIRs SHOULD be > the > > parties issuing the certificates for those resources which are held by > their > > users/customers, and for which there is a contract. > > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > > structure for cert.creation, and "verification" by the NCC, would become > > messy. We (my team) DO have real life experience, that such a disjunct and > > artificial mechanism is a pain, and a source for inconsistencies. > > The proposal was specifically written without a structure on how the NCC > should implement the system towards the PI or Legacy resource holders. > In my opinion that is a complete different discussion than a decision on IF > we want resource certification for resources of non-RIPE NCC members. > > I understand that it might be tempting to state how we want to have it > implemented or even move into the area where we ask ourselves the question, > who is going to pay for this and how? > However in order to keep the discussion as simple as possible and not to > force the discussion or proposal about how to do the implementation into a > certain direction or to hand-cuff the NCC on how they operate the systems, > it was specifically written without how / who / SHOULD or structure. It is > simply a question to allow non-RIPE NCC members their resources to be > certified. > > I'm sure that there will be questions after this, about what the better > structure would be (option 1,2,3), implications etc etc. > > > And, last but not least, in order to potentially, in the (near?) future, > > overcome the "single point of failure thing" (that we are creating now by > > building a "proper" tree structure!), removing any and all notion of the > > Service Region would have my *strong* support. Not just because it will be > > difficult to find a proper definition of "reside within", but more so > because > > it would open the chance to actually acquire certificates from more than > one > > "root", aka CA. > > The specific sentence has been adjusted as it was provided based on input > during the discussion phase to: > > -the Internet resources are registered in the RIPE registry. > > As certification is very closely related to the registration of resources, I > would like to limit it to the RIPE registry for now. > > I can see your point on a more global view and desire, however I would > prefer to take small steps here. > Let's get this in place for the resources in the RIPE registry. If we have > this step taken, we can always adjust the specifics if we need/want to move > to a more distributed model. > Currently it is my goal to have this sorted for the resources in the RIPE > registry. > > > These multiple roots/CAs could either (preferably?) be the set of RIRs, > but > > other parties as well. This would take away most of my worries and > reservation > > related to the proliferation of the RPKI. > > As stated earlier, I'm not going, in the current discussion, going to move > away from the as-is situation. > There is a current implementation and it is missing most of the resources. > > Yes I see how a more distributed environment might be better, however it is > beyond the scope of this proposal. > Any discussion on a distributed model is in vain imho if we exclude the > current group for which this proposal is created. > > > Sorry for the long text ;-) > > Wilfried. > > Thanks for the input and I hope to have answered your questions. > > Regards & have a nice weekend, > Erik Bais > > End of address-policy-wg Digest, Vol 22, Issue 2 > ************************************************ ACCE$$ Отправлено из мобильной Почты Mail.Ru

1 0

Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects
by Emilio Madaio 28 May '13

28 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we’re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

3 2

Final RIPE 65 APWG Session Minutes
by Emilio Madaio 21 May '13

21 May '13

Dear colleagues, The draft minutes of the RIPE 65 Address Policy Working Group session were approved by the Working Group during the session at RIPE 66. The final minutes are online at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-65 Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Update to RFC2050
by Hans Petter Holen 14 May '13

14 May '13

(I tried do search trough the archives and found this only deep within the 2013-03 discussion.) The ASO Address Council was made aware of - and had a short discussion with one of the author on - the topic of the proposed update to RFC 2050. The current version of the draft is at http://www.ietf.org/id/draft-housley-rfc2050bis-01.txt Below is the messages I have found on the topic on the ARIN ppml which explains the background of the work in progress. Personally I think this is a long overdue cleanup of RFC2050 - and the Address Policy working-group should perhaps spend some time on follwing the development of the document to get the workings right. Hans Petter > *From:* John Curran <jcurran(a)arin.net <mailto:jcurran@arin.net>> > *Date:* March 17, 2013, 2:57:17 PM PDT > *To:* CJ Aronson <cja(a)daydream.com <mailto:cja@daydream.com>> > *Cc:* "arin-ppml(a)arin.net <mailto:arin-ppml@arin.net>" > <arin-ppml(a)arin.net <mailto:arin-ppml@arin.net>> > *Subject:* *Re: [arin-ppml] Update to RFC2050* > > On Mar 17, 2013, at 4:57 PM, CJ Aronson <cja(a)daydream.com > <mailto:cja@daydream.com>> wrote: > >> There is a current IETF draft to update RFC205. Since that RFC is >> near and dear to all of us I thought folks might want the link. >> >> http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt > > Thanks Cathy! Let me add some more background - > > We've known for quite some time that RFC 2050 (describing the > structure of > the Internet Registry system and its initial policies back in days of > Jon Postel) > has become rather outdated with time, and yet we did not want it to be > made > "historic" without a successor document (due to the various references > in the > Internet community) > > What was needed is a revised document reflecting just the high-level > principles > and agreements for the Internet address registry system. As an > informational > document, such an updated statement of current state of affairs could > serve as > a useful successor and replacement for RFC 2050. I will note that the > last time > such an effort was attempted within the IETF (circa 2003), there was some > confusion over whether the goal was documenting "as is" versus "as it > should > be", and ultimately did not reach productive conclusion. > > So, a few of us (Russ Housley, myself, Geoff Huston, and David Conrad) > took > it upon ourselves to draft a suitable replacement document, and we > have now > completed the task. We also took the time to have the draft reviewed > by the > execs from the other RIRs, folks in the IAB, IESG, and ISOC, as well > as list > of folks who have had strong involvement in the Registry System over the > years (Scott Bradner, Randy Bush, etc.) The resulting document should be > an accurate representation of the current "as is" state of the > Internet Number > Registry System as far as we can determine, including having references > to the agreements defining the structure and primary relationships. > > The document is available here: > > <http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt> > > The announcement of the draft has been posted to the "ietf" > mailing list for > further discussion (and more information on the "ietf" list is > available here: > <https://www.ietf.org/mailman/listinfo/ietf>) > > Thanks! > /John > > John Curran > President and CEO > ARIN > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML(a)arin.net > <mailto:ARIN-PPML@arin.net>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info(a)arin.net <mailto:info@arin.net> if you experience > any issues.

1 0

2012-10 Proposal Accepted (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis)
by Marco Schmidt 14 May '13

14 May '13

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-552, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-10 The updated RIPE document is ripe-589 and is available at: https://www.ripe.net/ripe/docs/ripe-589 Thank you for your input. An announcement regarding the implementation will follow. Kind Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

DRAFT Mintues from the APWG Meeting at RIPE 65
by Emilio Madaio 13 May '13

13 May '13

Dear Colleagues, the draft minutes from the APWG sessions at the recent RIPE 65 meeting have been now published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-65 Please let us know if there is anything that needs to be corrected or amended. Best Regards Emilio Madaio Policy Development Officer RIPE NCC

2 1

Cosmetic Surgery Project: new revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 13 May '13

13 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0