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

Re: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by Opteamax GmbH 15 May '14

15 May '14

I fully support this proposal and I was requested by 3 additional LIRs that I assist in maintainment-works to also express their support for this proposal. BR Jens On 15.05.2014 11:05, Marco Schmidt wrote: > Dear colleagues, > > > The draft document for version 2.0 of the policy proposal 2014-01, > "Abandoning the Minimum Allocation Size for IPv4" has now been published, > along with an impact analysis conducted by the RIPE NCC. > > Some of the differences from version 1.0 include: > > - Adding the abandonment of Minimum Sub-Allocation Size concept > - Minor wording adjustments in the arguments supporting the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-01 > > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-01/draft > > > We encourage you to read the draft document text and send any comments > to <address-policy-wg(a)ripe.net> before 13 June 2014. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > > !DSPAM:637,537475b230748687177688! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo(a)opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989

2 3

Re: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by George Giannousopoulos 15 May '14

15 May '14

I support too. - George On Thu, May 15, 2014 at 11:05 AM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > > The draft document for version 2.0 of the policy proposal 2014-01, > "Abandoning the Minimum Allocation Size for IPv4" has now been published, > along with an impact analysis conducted by the RIPE NCC. > > Some of the differences from version 1.0 include: > > - Adding the abandonment of Minimum Sub-Allocation Size concept > - Minor wording adjustments in the arguments supporting the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-01 > > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-01/draft > > > We encourage you to read the draft document text and send any comments > to <address-policy-wg(a)ripe.net> before 13 June 2014. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > >

1 0

Re: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by Mailing List Account 15 May '14

15 May '14

All, On Thu, May 15, 2014 at 10:05:08AM +0200, Marco Schmidt wrote: >You can find the full proposal and the impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2014-01 >And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2014-01/draft Yes, I think I can sign up to this. Maybe, it is also a step towards removing the PI/PA separation. One question though, if the minimum (sub-)/allocation size is now /24, is the part regarding classless reverse delegation in the impact statement now obsolete? rgds, Sascha Luck

2 1

2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 15 May '14

15 May '14

Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-01, "Abandoning the Minimum Allocation Size for IPv4" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - Adding the abandonment of Minimum Sub-Allocation Size concept - Minor wording adjustments in the arguments supporting the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-01 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-01/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 13 June 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Roger Jørgensen 14 May '14

14 May '14

On Mon, May 5, 2014 at 3:17 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > > A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 3 June 2014. The idea is good. However - can we please stop introducing the term PI and PA into yet another document? The other problem is as mention in the working group today, do we really need to mention IPv6 there? If we should keep IPv6 there, I suggest something like this: "Allocations will only be made to LIRs if they have already received an IPv6 allocation or assignment" (old text : Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.) This just require them to have some sort of IPv6 registred to them, no difference between PI/PA, RIPE NCC or other regions... This is quite similar to what we had back in 6bone days, you first needed a connection to 6bone and some address space before you would get your own block. -- Roger Jorgensen | ROJO9-RIPE rogerj(a)gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger(a)jorgensen.no

1 0

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Piotr Strzyzewski 13 May '14

13 May '14

On Wed, Apr 30, 2014 at 03:28:17PM +0200, Marco Schmidt wrote: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 I support this proposal. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10
by Lu Heng 08 May '14

08 May '14

I personally believe we might no longer need to distinguish PI and PA--it might solve all the question all together. On Tue, May 6, 2014 at 4:49 AM, <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: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 2. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Tore Anderson) > 3. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 4. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Richard Hartmann) > 5. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 6. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Tore Anderson) > 7. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Carlos Friacas) > 8. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Erik Bais) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 May 2014 21:08:41 +0200 > From: Sander Steffann <sander(a)steffann.nl> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Jan Ingvoldstad <frettled(a)gmail.com> > Cc: Gert D?ring <gert(a)space.net>, "address-policy-wg(a)ripe.net Working > Group" <address-policy-wg(a)ripe.net> > Message-ID: <092F992E-EC5E-403D-90DC-CF8186258D89(a)steffann.nl> > Content-Type: text/plain; charset=us-ascii > > Hi Jan, > >>> Historically it was put in there as an encouragement for "last /8" LIRs >>> to "do something with IPv6"... >> >> I know that, but that's not quite what I meant. >> >> What I meant is that I don't see why the current requirement for IPv6 PA is there, but that the current document didn't already have IPv6 PI as a valid requirement. >> >> Not either-or. > > I first thought that the last /8 policy was written before IPv6 PI for LIRs became possible, so I checked: > - IPv6 PI for LIRS was 2009-08 (concluded in 2009) > - Last /8 was 2010-02 > > Seems I was wrong. IPv6 PI for LIRs did exist at the time that the last /8 policy was written. I think at the time we just didn't even consider LIRs that didn't want/need IPv6 PA space. > > Cheers, > Sander > > > > > ------------------------------ > > Message: 2 > Date: Mon, 05 May 2014 21:53:34 +0200 > From: Tore Anderson <tore(a)fud.no> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann <sander(a)steffann.nl>, Jan Ingvoldstad > <frettled(a)gmail.com> > Cc: Gert D?ring <gert(a)space.net>, "address-policy-wg(a)ripe.net Working > Group" <address-policy-wg(a)ripe.net> > Message-ID: <5367EC3E.5040209(a)fud.no> > Content-Type: text/plain; charset=ISO-8859-1 > > * Sander Steffann > >> I think at the time we just didn't even consider LIRs that didn't >> want/need IPv6 PA space. > > Right. But the summary of the proposal identifies the *actual* problem here: > > ?In order to qualify [for IPv6 PA], they need to request an IPv6 > allocation and subsequently return their existing PI assignment > (per ripe-589 section 7.1)? > > If that PI assignment is already in use, a requirement to renumber and > return it might be a showstopper for getting PA space. Renumbering is > *hard* - it is *a lot* of work. > > So while I don't think 2014-04 is harmful in any way and I don't have > any objections to it, I do find it quite puzzling that it does not try > to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 > were to pass, would remain just as ?downright deleterious to IPv6 > adoption? as before. > > Tore > > > > ------------------------------ > > Message: 3 > Date: Mon, 5 May 2014 22:02:36 +0200 > From: Sander Steffann <sander(a)steffann.nl> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Tore Anderson <tore(a)fud.no> > Cc: "address-policy-wg(a)ripe.net Working Group" > <address-policy-wg(a)ripe.net>, Gert D?ring <gert(a)space.net> > Message-ID: <4815E7AE-510E-4A78-81B9-AF4555D34ECF(a)steffann.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > >>> I think at the time we just didn't even consider LIRs that didn't >>> want/need IPv6 PA space. >> >> Right. But the summary of the proposal identifies the *actual* problem here: >> >> ?In order to qualify [for IPv6 PA], they need to request an IPv6 >> allocation and subsequently return their existing PI assignment >> (per ripe-589 section 7.1)? > > Yep, seen that. > >> If that PI assignment is already in use, a requirement to renumber and >> return it might be a showstopper for getting PA space. Renumbering is >> *hard* - it is *a lot* of work. > > Ack > >> So while I don't think 2014-04 is harmful in any way and I don't have >> any objections to it, I do find it quite puzzling that it does not try >> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >> were to pass, would remain just as ?downright deleterious to IPv6 >> adoption? as before. > > It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? > > Cheers, > Sander > > > > > ------------------------------ > > Message: 4 > Date: Mon, 5 May 2014 22:02:49 +0200 > From: Richard Hartmann <richih.mailinglist(a)gmail.com> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Tore Anderson <tore(a)fud.no> > Cc: Sander Steffann <sander(a)steffann.nl>, "address-policy-wg(a)ripe.net > Working Group" <address-policy-wg(a)ripe.net>, Gert D?ring > <gert(a)space.net> > Message-ID: > <CAD77+gQcWNcNdyKdwkTR1O3jdePZ-fabno9ncU6oWctgzxkE5A(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, May 5, 2014 at 9:53 PM, Tore Anderson <tore(a)fud.no> wrote: >> If that PI assignment is already in use, a requirement to renumber and >> return it might be a showstopper for getting PA space. Renumbering is >> *hard* - it is *a lot* of work. > > As the guy who renumbered a /17 in a few months: Yes. Oh my $deity... yes. > > >> So while I don't think 2014-04 is harmful in any way and I don't have >> any objections to it, I do find it quite puzzling that it does not try >> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >> were to pass, would remain just as ?downright deleterious to IPv6 >> adoption? as before. > > I would also support such a proposal or maybe even help spearhead it. ...Tore? > > > Richard > > > > ------------------------------ > > Message: 5 > Date: Mon, 5 May 2014 22:07:08 +0200 > From: Sander Steffann <sander(a)steffann.nl> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Richard Hartmann <richih.mailinglist(a)gmail.com>, Tore Anderson > <tore(a)fud.no>, Gert D?ring <gert(a)space.net> > Cc: "address-policy-wg(a)ripe.net Working Group" > <address-policy-wg(a)ripe.net> > Message-ID: <005C7559-A48E-4F8C-B858-BB18A58F7909(a)steffann.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > >>> So while I don't think 2014-04 is harmful in any way and I don't have >>> any objections to it, I do find it quite puzzling that it does not try >>> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >>> were to pass, would remain just as ?downright deleterious to IPv6 >>> adoption? as before. >> >> I would also support such a proposal or maybe even help spearhead it. ...Tore? > > /me feels an agenda item for section Y coming up... > > Cheers, > Sander > > > > > ------------------------------ > > Message: 6 > Date: Tue, 06 May 2014 07:13:54 +0200 > From: Tore Anderson <tore(a)fud.no> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann <sander(a)steffann.nl> > Cc: "address-policy-wg(a)ripe.net Working Group" > <address-policy-wg(a)ripe.net>, Gert D?ring <gert(a)space.net> > Message-ID: <53686F92.5060400(a)fud.no> > Content-Type: text/plain; charset=ISO-8859-1 > > * Sander Steffann > >> It is again a balance of address policy vs routing table >> conservation. I personally wouldn't have a problem with letting an >> LIR keep their PI space when they get their PA space. How does this >> working group feel about that? > > Me neither. I think is fine to *encourage* newly formed LIRs to return > IPv6 PI when they're requesting PA, but *requiring* it is a tad too > tough. If the end result is that the newly formed LIRs cannot provision > their End Users with IPv6 addresses because they cannot realistically > get PA space, we're doing something wrong... > > That said, this isn't my itch to scratch really (I already have all the > IPv6 I need)...so if you want to do a proposal, Richard, go right ahead! > I promised myself 2014 would be a proposal-free year...and besides I > won't be going to Warszawa either. :-/ > > Tore > > > > ------------------------------ > > Message: 7 > Date: Tue, 6 May 2014 07:22:49 +0100 (WEST) > From: Carlos Friacas <cfriacas(a)fccn.pt> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann <sander(a)steffann.nl> > Cc: "address-policy-wg(a)ripe.net Working Group" > <address-policy-wg(a)ripe.net> > Message-ID: <alpine.LRH.2.11.1405060721480.11281(a)gauntlet.id.fccn.pt> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 5 May 2014, Sander Steffann wrote: > > (...) >> >> It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? > > Should be allowed to keep the PI, i.e. avoiding renumbering at all cost. > > Cheers, > Carlos > >> Cheers, >> Sander >> >> > > > > ------------------------------ > > Message: 8 > Date: Tue, 6 May 2014 11:48:49 +0200 > From: "Erik Bais" <ebais(a)a2b-internet.com> > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: "'Sander Steffann'" <sander(a)steffann.nl>, "'Tore Anderson'" > <tore(a)fud.no> > Cc: address-policy-wg(a)ripe.net, 'Gert D?ring' <gert(a)space.net> > Message-ID: <005a01cf6910$67958880$36c09980$(a)a2b-internet.com> > Content-Type: text/plain; charset="Windows-1252" > > Hi, > >> > Right. But the summary of the proposal identifies the *actual* problem > here: >> > >> > ?In order to qualify [for IPv6 PA], they need to request an IPv6 >> > allocation and subsequently return their existing PI assignment >> > (per ripe-589 section 7.1)? > >> Yep, seen that. > > Why should an LIR have to return his PI space if they have valid reasons for > its use and are already using it ? > > I agree with Tore that to encourage a LIR to return a v6 PI assignments if > they can, but if it is in use and active, I would feel strongly against a > requirement to return the space and get a PA block. > > Having a v6 allocation doesn't guarantee the usage of v6 ... and if someone > went through the trouble in the past to actually get a v6 PI assignment and > later decides to become a LIR, they get a penalty and are required to return > the space !! > > Besides that and the issue that a v6 PI assignment doesn't 'qualify' for the > final /8 v4 allocation list, are in my opinion the 2 items that should be > fixed. > > As a suggestion to the authors for the policy text: > > Skip the distinction between v6 PA or PI in the policy text and rephrase it > to : > > b. New policy text > 5.1 Allocations made by the RIPE NCC to LIRs > [...] > Allocations will only be made to LIRs if they have already received v6 > resources from an upstream LIR or the RIPE NCC. > > And include a change to ripe-589 section 7.1 ( > http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments ) > > Original text: > 7.1 IPv6 Provider Independent (PI) Assignments for LIRs > LIRs can qualify for an IPv6 PI assignment for parts of their own > infrastructure that are not used for customer end sites. Where an LIR has an > IPv6 allocation, the LIR must demonstrate the unique routing requirements > for the PI assignment. > > The LIR must return the IPv6 PI assignment within a period of six months if > the original criteria on which the assignment was based are no longer valid. > > If an organisation already received a PI assignment before becoming an LIR, > the PI assignment should be returned upon receiving an IPv6 allocation if > there are no specific routing requirements to justify both. > > Updated text: > 7.1 IPv6 Provider Independent (PI) Assignments for LIRs > LIRs can qualify for an IPv6 PI assignment for parts of their own > infrastructure that are not used for customer end sites. Where an LIR has an > IPv6 allocation, the LIR must demonstrate the unique routing requirements > for the PI assignment. > > The LIR must return the IPv6 PI assignment within a period of six months if > the original criteria on which the assignment was based are no longer valid. > > If an organisation already received a PI assignment before becoming an LIR, > the PI assignment should be returned upon receiving an IPv6 allocation, if > the original criteria on which the assignment was based are no longer valid. > > Regards, > Erik Bais > > > > > > > > > End of address-policy-wg Digest, Vol 33, Issue 10 > ************************************************* -- -- Kind regards. Lu 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.

5 5

2014-04 new radical suggestions
by Aleksi Suhonen 07 May '14

07 May '14

Hi, While we were formulating the proposal 2014-04, we came up with a handful of other more radical alternatives too. We decided to leave them out of the initial proposal text, because of their controversial nature. We decided to instead present them to the discussion on the mailing list, which I'm doing now: OTHER RIRS The current policy for final /8 IPv4 assignments requires that the IPv6 address space is assigned by RIPE NCC. Assignments by other RIRs aren't accepted. Proposal 2014-04 does not change this oversight. I can see one snag, if IPv6 assignments from other RIRs were accepted: multi-national corporations would hoard "an automatic /22" from every RIR slightly more easily than the current policy allows. In that case I would also add policy text that would make sure that if the applicant already has a final /8 IPv4 assignment from some other RIR, they can't get one from RIPE. PROMOTE IPv6 USAGE Gert Doering wrote: > Historically it was put in there as an encouragement for "last /8" LIRs > to "do something with IPv6"... The something that the current policy encourages LIRs to do with IPv6: * register a block and forget about it To really promote IPv6 adoption, why not require final /8 applicants to demonstrate their IPv6 capability before being given the IPv4 address block? The simplest way I came up with would be to create a service mailbox under an IPv6 only sub-domain (e.g. hostmaster(a)v6only.ripe.net) and require that the applicants complete some steps of their process with this mailbox. This would verify that the applicant has access to IPv6 capable: * routing * DNS resolvers * authoritative DNS * SMTP servers ... and is not afraid to use them! Well, of course the applicant could be using someone else's mail system to complete those steps. I'm not sure if that matters. When the original policy was written, I guess the community felt that the global routing system was not ripe enough for these requirements. I would argue that the world should be ready now! There's only one RIR left that has more than 16 million IPv4 addresses in their free pool. There, that's two provocative radical suggestions for you, from -- Aleksi Suhonen / Axu TM Oy You say "potato", I say "closest-exit."

4 3

Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by George Giannousopoulos 05 May '14

05 May '14

Hi, I support the proposal. I'll agree with the previous about the distinction between PI and PA. In my mind both were valid in order to get the last /22.. Regards, George On Mon, May 5, 2014 at 4:17 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > > A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 3 June 2014. > > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > >

1 0

Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Richard Hartmann 05 May '14

05 May '14

+1 for the reasons listed in the proposal. Richard

1 0

Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Elvis Daniel Velea 05 May '14

05 May '14

Hi, I support this policy proposal. That being said, I do not understand why is this policy proposal making a difference between IPv6 PA and IPv6 PI assignments. I would say that someone can request the last /22 if they have an IPv6 block registered on their name - be it an allocation (ALLOCATED-BY-RIR), a sub-allocation (ALLOCATED-BY-LIR), using an aggregated block (AGGREGATED-BY-LIR) or an IPv6 PI or PA assignment. Regards, Elvis On 05/05/14 15:17, Marco Schmidt wrote: > Dear colleagues, > > > A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 3 June 2014. > > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

1 0

Re: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03
by lir＠elisa.fi 05 May '14

05 May '14

+1 I support this proposal. Rgds, Ray From: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Elvis Daniel Velea Sent: 5. toukokuuta 2014 14:06 To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 Hi, you have my support for this policy change proposal. While the current policy was/is working fine, the RIPE NCC has no tools to actually enforce and/or verify the multihoming of an AS Number once it is issued. cheers, elvis On 05/05/14 12:58, Sander Steffann wrote: Hi Johan, Yes, apologies for voting in the wrong place. Then again, isn't a fake vote the strongest sign of support? I genuinely feel this proposal would strongly benefit the community, and it is one of those "why has this not been written before"-moments for me. Thank you for your very useful message. While the common '+1' messages are useful to determine the difference between 'nobody cares enough to comment' and 'people think this is a useful proposal', actually having comments that show the reasons and/or feelings for supporting a proposal are much much more valuable. Thanks for the welcome. I hope I can contribute. You seem to have started well :) Welcome! Cheers, Sander APWG co-chair -- ************************************************************ Raymond Jetten Phone: +358 3 41024 139 Senior System Specialist Fax: +358 3 41024 199 Elisa Oyj / Network Management Mobile: +358 45 6700 139 Hermiankatu 3A raymond.jetten(a)elisa.fi FIN-33720, TAMPERE http://www.elisa.fi ************************************************************

2 1

2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Marco Schmidt 05 May '14

05 May '14

Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 3 June 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Support of https://www.ripe.net/ripe/policies/proposals/2014-03
by Johan Boger 05 May '14

05 May '14

Dear Colleagues, I hereby vote YES on the proposal linked at https://www.ripe.net/ripe/policies/proposals/2014-03 Best Regards, -- Johan Boger, Project Manager (AS48285) e: johan(a)robtex.com w: http://www.robtex.com l: cy.robtex

6 6

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Tore Anderson 05 May '14

05 May '14

* Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-03 Makes sense to me. Tore

1 0

Fwd: Updates to RIPE-500: Policy Development in RIPE
by Sander Steffann 04 May '14

04 May '14

Hello WG, Work is being done on ripe-500, the Policy Development Process (PDP). As the PDP is quite important to the Address _Policy_ Working Group this is probably of interest to you. Hans Petter Holen, our RIPE Deputy Chair, has posted the proposed new revision on the RIPE list. For those of you who are not subscribed to the RIPE list: here is a copy of his message. If you want to comment on this proposed new text please do so on the RIPE list. Sincerely, Sander APWG Co-chair Begin doorgestuurd bericht: > Van: Hans Petter Holen <hph(a)oslo.net> > Onderwerp: Updates to RIPE-500: Policy Development in RIPE > Datum: 4 mei 2014 13:55:55 CEST > Aan: ripe-list(a)ripe.net > > Dear colleagues, > The Working-group chairs have for some time been discussing how to improve the Policy Development Process as described in RIPE-500. A small task force with Brian Nisbet as the coordinator and Ondrej Filip, Nick Hilliard and Hans Petter Holen as members has worked out the final details in the text. > > The wg-chairs have reached consensus on the attached proposal. > > The main change in the PDP is to allow the Working-group Chairs of the working-group developing the policy to declare consensus. > > This allows for a more timely conclusion of the PDP, but also allows for the Working-group chairs collectively to act as an appeals body. > > I am circulating the new text now for community review and the intent is to put this in place at the coming RIPE meeting. > > > Yours Sincerely, > > Hans Petter Holen > RIPE Deputy Chair > >

1 0

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by James Blessing 01 May '14

01 May '14

On 30 April 2014 14:28, Marco Schmidt <mschmidt(a)ripe.net> wrote: > https://www.ripe.net/ripe/policies/proposals/2014-03 > Other than the use cases suggested in the document (which could be achieved using private ASNs) is there a reason for this that I'm missing? With other discussions about recovering non globally routed ASNs this just seem odd J -- James Blessing 07989 039 476

5 4

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Fredy Kuenzler 01 May '14

01 May '14

Am 30.04.2014 15:28, schrieb Marco Schmidt: > A proposed change to RIPE Document ripe-525, "Autonomous System (AS) > Number Assignment Policies" is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 I support this proposal. However I suggest a small change in the text: "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing or private AS Number." should be "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing AS Number." Since we arrived in the 32bit-ASN century, private ASN should not matter anymore, i.e. noone should be forced to use private ASN permanently. Re hoarding: If someone thinks hoarding of AS206832 to AS207363 is useful, so be it... -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/

1 0

Re: [address-policy-wg] [policy-announce] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Richard Hartmann 01 May '14

01 May '14

Support. Richard Sent by mobile; excuse my brevity.

1 0

2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer)
by Marco Schmidt 01 May '14

01 May '14

Dear colleagues, The Discussion Period for the proposal 2014-02, "Allow IPv4 PI transfer" has been extended until 23 May 2014. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 30 Apr '14

30 Apr '14

Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 29 May 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE 67 Address Policy WG Draft Minutes
by Marco Schmidt 30 Apr '14

30 Apr '14

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 67 have now been published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-67 Please let us know any corrections or amendments. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

IEEE TrustCom Deadline is Approaching: May 5, 2014
by Sandra Sendra 25 Apr '14

25 Apr '14

[Please accept our apologies if you receive multiple copies of this email] *********************** CFP ******************************* The 13th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-14) http://www.greenorbs.org/TrustCom2014/ 24-26 September 2014, Beijing, China Important Dates Workshop Proposal: May 5, 2014 Submission Deadline: 11:59PM (UTC/GMT+8 hours) May 5, 2014 (This is the firm deadline) Authors Notification: June 26, 2014 Final Manuscript Due: July 20, 2014 Publications Accepted and presented papers will be included in the IEEE CPS Proceedings. Distinguished papers presented at the conference, after further revision, will be published in special issues of the following high quality international journals (pending). - Computers & Security - Elsevier (Impact factor=0.868) - Concurrency and Computation: Practice and Experience - Wiley (Impact factor=0.636) - Security and Communication Networks - Wiley (Impact factor=0.414) - Future Generation Computer Systems - Elsevier (Impact factor=1.978) - Multimedia Tools and Applications - Springer (Impact factor=0.617) - Journal of Internet Technology (Impact factor=0.508) - Journal of Computer and System Sciences - Elsevier (Impact factor=1.157) Topics Trust Track - Trust semantics, metrics and models - Trusted computing platform - Trusted network computing - Trusted operating systems - Trusted software and applications - Trust in social networks - Trust in e-commerce and e-government - Trust in mobile and wireless communications - Risk and reputation management - Survivable computer systems/networks - Miscellaneous trust issues Security Track - Network security - Computer security - Database security - Web applications security - Security policy, model and architecture - Security in social networks - Security in parallel and distributed systems - Security in mobile and wireless communications - Security in grid/cloud/pervasive computing - Authentication, authorization and accounting - Miscellaneous security issues Privacy Track - Privacy in Web-based applications and services - Privacy in database systems - Privacy in parallel and distributed systems - Privacy in grid/cloud/pervasive computing - Privacy in mobile and wireless communications - Privacy in e-commerce and e-government - Privacy in network deployment and management - Privacy and trust - Privacy and security - Privacy and anonymity - Miscellaneous privacy issues Organisation Committee General Chairs: Jiaguang Sun, Tsinghua University, China Ivan Stojmenovic, University of Ottawa, Canada Program Chair: Yunhao Liu, Tsinghua University, China Publicity Chairs: Sandra Sendra Compte, Polytechnic University of Valencia, Spain Haojin Zhu, Shanghai Jiao Tong University, China Xiaodong Lin, University of Ontario Institute of Technology, Canada Workshop Chairs: Yang Xiang, Deakin University, Australia Kouichi Sakurai, Kyushu University, Japan Publication Chair: Jemal Abawajy, Deakin University, Australia Steering and Program Committees: Please see http://www.greenorbs.org/TrustCom2014/

1 0

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Wilfried Woeber 25 Apr '14

25 Apr '14

A couple of observations, fwiw, and no, I'm not going to assess the role of brokers :-) In general, let me start with the statement that I support all ideas to get rid of the different shapes and colours of address blocks. And that actually includes Legacy, as they are simply PI, just a tad older... How to deal with moving address space from a PI assignment to a different party? Well, I can see 2 *substantially* different scenarios: 1) the current holder of the address block doesn't need *all of it* any longer (and wants to get money from an interested party, but that's a side issue). 2) the current holder of the address block doesn't need *any* of the addresses any longer and wants to transfer the full block, in one chunk or in smaller pieces. Nr. 1 is pretty easy, and possible already or really soon now: convert the PI block to PA, thus become an LIR, and proceed according to the rules. Nr. 2 is more tricky. First of all, there was a good reason, why the resource was tightly bound to the requester. That background and assumption is also part of the basis for the low annual fee of €50,- per resource. Now, as soon as the original criteria are no longer in place, the resource MUST be returned. A PI holder offering the *full block* to an interested party (for money or for free) obviously matches that provision. The resource needs to get returned to the pool. So, why would we want to bend into this direction or that direction to create a special case for Nr. 2 to circumvent the existing policy? Just because some money is seen on the horizon? Which gets me to the point of *not* supporting this proposal! Wilfried.

7 8

2014-01 Draft Document and Impact Analysis will be produced (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 22 Apr '14

22 Apr '14

Dear colleagues, The discussion period for the proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-01 Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0