From gert at space.net  Mon May  2 09:12:03 2016
From: gert at space.net (Gert Doering)
Date: Mon, 2 May 2016 09:12:03 +0200
Subject: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy
 Proposals - April Update
In-Reply-To: <52493449.20160430122949@itns.md>
References: <572318CF.6020601@ripe.net> <194432980.20160429113800@itns.md>
 <7d770256-c3ee-f43d-009f-c1fe8337167e@wirem.net>
 <52493449.20160430122949@itns.md>
Message-ID: <20160502071203.GD56633@Space.Net>

Hi,

On Sat, Apr 30, 2016 at 12:29:49PM +0300, Sergiu IANCIUC wrote:
> < !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> < html><head><title>Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update</title>
> < META http-equiv=Content-Type content="text/html; charset=windows-1251">
> < meta http-equiv="Content-Style-Type" content="text/css">
> < style type="text/css"><!--

Please do not send HTML mails to the APWG list.

(And, for that matter, avoid full-quotes)

thanks,

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160502/c00c6ca0/attachment.sig>

From info at rivebit.com  Thu May  5 15:53:48 2016
From: info at rivebit.com (info at rivebit.com)
Date: Thu, 5 May 2016 13:53:48 +0000
Subject: [address-policy-wg] I support this policy
Message-ID: <BD1FAC62-071C-4BDE-9076-EDFBAC848491@rivebit.com>

I support this policy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160505/5ca0d681/attachment.html>

From sander at steffann.nl  Thu May  5 16:06:55 2016
From: sander at steffann.nl (Sander Steffann)
Date: Thu, 5 May 2016 17:06:55 +0300
Subject: [address-policy-wg] I support this policy
In-Reply-To: <BD1FAC62-071C-4BDE-9076-EDFBAC848491@rivebit.com>
References: <BD1FAC62-071C-4BDE-9076-EDFBAC848491@rivebit.com>
Message-ID: <2D089E1B-CFD5-485C-A2FC-8CC71B74856B@steffann.nl>

Hello,

Welcome this this working group. Might I ask you to introduce yourself? Your info@ email address and the lack of a name in your message make it difficult to understand who you are.

> I support this policy

Which policy are you talking about?

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160505/82fa758f/attachment.sig>

From info at rivebit.com  Thu May  5 19:55:29 2016
From: info at rivebit.com (info at rivebit.com)
Date: Thu, 5 May 2016 17:55:29 +0000
Subject: [address-policy-wg] I support this policy
In-Reply-To: <2D089E1B-CFD5-485C-A2FC-8CC71B74856B@steffann.nl>
References: <BD1FAC62-071C-4BDE-9076-EDFBAC848491@rivebit.com>
 <2D089E1B-CFD5-485C-A2FC-8CC71B74856B@steffann.nl>
Message-ID: <CD5B83E5-DD21-4511-A028-A5BC09FC4E20@rivebit.com>

Sorry I missed it in the object.

I was referring the policy 2015-05 , https://www.ripe.net/participate/policies/proposals/2015-05.

Many thanks
Roberto




On 05/05/16 16:06, "Sander Steffann" <sander at steffann.nl> wrote:

>Hello,
>
>Welcome this this working group. Might I ask you to introduce yourself? Your info@ email address and the lack of a name in your message make it difficult to understand who you are.
>
>> I support this policy
>
>Which policy are you talking about?
>
>Cheers,
>Sander
>

From gert at space.net  Thu May  5 20:06:07 2016
From: gert at space.net (Gert Doering)
Date: Thu, 5 May 2016 20:06:07 +0200
Subject: [address-policy-wg] I support this policy
In-Reply-To: <CD5B83E5-DD21-4511-A028-A5BC09FC4E20@rivebit.com>
References: <BD1FAC62-071C-4BDE-9076-EDFBAC848491@rivebit.com>
 <2D089E1B-CFD5-485C-A2FC-8CC71B74856B@steffann.nl>
 <CD5B83E5-DD21-4511-A028-A5BC09FC4E20@rivebit.com>
Message-ID: <20160505180607.GA56633@Space.Net>

Hi,

On Thu, May 05, 2016 at 05:55:29PM +0000, info at rivebit.com wrote:
> Sorry I missed it in the object.
> 
> I was referring the policy 2015-05 , https://www.ripe.net/participate/policies/proposals/2015-05.
> 
> Many thanks
> Roberto

Please take some effort to properly configure your mail client so that
it displays a full name.  Now we know your first name, but it's still 
a bit strangfe to talk to "hey Mr. info at rivebit.com"

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160505/21f4eb61/attachment.sig>

From abolhasaniir at yahoo.com  Thu May  5 19:03:15 2016
From: abolhasaniir at yahoo.com (Mojtaba Abolhasani)
Date: Thu, 5 May 2016 10:03:15 -0700
Subject: [address-policy-wg] additional /22
Message-ID: <1462467795.36153.YahooMailMobile@web125202.mail.ne1.yahoo.com>

+1 2015-05
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160505/ed37177c/attachment.html>

From abolhasaniir at yahoo.com  Thu May  5 19:06:03 2016
From: abolhasaniir at yahoo.com (Mojtaba Abolhasani)
Date: Thu, 5 May 2016 10:06:03 -0700
Subject: [address-policy-wg] additional /22
Message-ID: <1462467963.20024.YahooMailMobile@web125202.mail.ne1.yahoo.com>

+1 to 2015-05
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160505/f728f415/attachment.html>

From borhan.h at gmail.com  Fri May  6 12:25:00 2016
From: borhan.h at gmail.com (Rayanravesh Sena)
Date: Fri, 6 May 2016 14:55:00 +0430
Subject: [address-policy-wg]  additional /22
Message-ID: <CAHcvUkBaA0R3i3YK9Rb+xPHLtOrVPQRmtO41++sbLtWfOT1dnQ@mail.gmail.com>

+1 2015-05
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160506/d1d1bb5b/attachment.html>

From borhan.h at gmail.com  Fri May  6 13:24:30 2016
From: borhan.h at gmail.com (Rayanravesh Sena)
Date: Fri, 06 May 2016 11:24:30 +0000
Subject: [address-policy-wg] Support the 2015-05 Policy
Message-ID: <CAHcvUkBFMz75r2Lmv0oxuWT_83Q05rLrVtPoW5uGS4umS2pe1Q@mail.gmail.com>

I think this policy is fair, i support it.

With luck,
Borhan Habibi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160506/89d63395/attachment.html>

From ripe-wgs.cs at schiefner.de  Fri May  6 14:18:15 2016
From: ripe-wgs.cs at schiefner.de (Carsten Schiefner)
Date: Fri, 6 May 2016 14:18:15 +0200
Subject: [address-policy-wg] Support the 2015-05 Policy
In-Reply-To: <CAHcvUkBFMz75r2Lmv0oxuWT_83Q05rLrVtPoW5uGS4umS2pe1Q@mail.gmail.com>
References: <CAHcvUkBFMz75r2Lmv0oxuWT_83Q05rLrVtPoW5uGS4umS2pe1Q@mail.gmail.com>
Message-ID: <afa27c83-0aec-b0a8-e703-0fb926cfe242@schiefner.de>

Dear Rayanravesh Sena/Borhan Habibi split personality -

On 06.05.2016 13:24, Rayanravesh Sena wrote:
> I think this policy is fair, i support it.

who are you? And if yes: how many?

Best regards,

	Carsten



From borhan.h at gmail.com  Fri May  6 18:30:05 2016
From: borhan.h at gmail.com (Rayanravesh Sena)
Date: Fri, 06 May 2016 16:30:05 +0000
Subject: [address-policy-wg] Disabuse
Message-ID: <CAHcvUkB=OdsNL5=DbDBeuhHqrNXYjAKKm8cQsnmfVzZSkXkn-A@mail.gmail.com>

Hi,
My name is Borhan Habibi and my company name is Rayanravesh Sena, I sent my
first email without noticing it has wrong from address field, so thought it
would be better to resend it with my own name. I'm just one person, Hope it
is clear to you and any one else got confused,

Borhan Habibi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160506/0914d59a/attachment.html>

From sander at steffann.nl  Sat May  7 18:51:10 2016
From: sander at steffann.nl (Sander Steffann)
Date: Sat, 7 May 2016 18:51:10 +0200
Subject: [address-policy-wg] Disabuse
In-Reply-To: <CAHcvUkB=OdsNL5=DbDBeuhHqrNXYjAKKm8cQsnmfVzZSkXkn-A@mail.gmail.com>
References: <CAHcvUkB=OdsNL5=DbDBeuhHqrNXYjAKKm8cQsnmfVzZSkXkn-A@mail.gmail.com>
Message-ID: <C8561779-4E5B-45B5-B729-7923E2637144@steffann.nl>

Hi Borhan,

> My name is Borhan Habibi and my company name is Rayanravesh Sena, I sent my first email without noticing it has wrong from address field, so thought it would be better to resend it with my own name.

FYI: Your mail client still send mail from Rayanravesh Sena <borhan.h at gmail.com>

> I'm just one person, Hope it is clear to you and any one else got confused,

The number of people doesn't matter that much anyway in the RIPE Policy Development Process. Decisions are based on consensus, not on number of "votes".

To help a policy proposal forward the objections to the proposal have to be addressed. At this point in time we have many people saying that they like 2015-05, but also many people objecting to i.e. not leaving enough space for newcomers in the years to come. Extra people saying +1 or -1 is not helping us forward now, this working group needs to discuss to see if there is a way to remove the raised objections.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160507/079e9c5f/attachment.sig>

From behbahani at soshiant.net  Sun May  8 15:11:02 2016
From: behbahani at soshiant.net (Ehsan Behbahani)
Date: Sun, 08 May 2016 17:41:02 +0430
Subject: [address-policy-wg] agreement
Message-ID: <WC20160508131102.720003@soshiant.net>

-----Original Message-----
From: "Ehsan Behbahani" <behbahani at soshiant.net>
To: apwg at ripe.net
Date: Sun, 08 May 2016 17:39:44 +0430
Subject: agreement


Hi

we are agree about theLast /8 Allocation Criteria Revision proposal .
https://www.ripe.net/participate/policies/proposals/2015-05 
[https://www.ripe.net/participate/policies/proposals/2015-05]


RegID: ir.shnt

best regards.

Ehsan behbahani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160508/b7447e5f/attachment.html>

From sander at steffann.nl  Mon May  9 10:42:00 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 9 May 2016 10:42:00 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <WC20160508131102.720003@soshiant.net>
References: <WC20160508131102.720003@soshiant.net>
Message-ID: <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>

Hello Ehsan,

> we are agree about the Last /8 Allocation Criteria Revision proposal .
> https://www.ripe.net/participate/policies/proposals/2015-05

thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.

> RegID: ir.shnt

You don't need to state your RegID in this working group. This working group is open to all interested parties, not just RIPE LIRs. Discussions are always between people, not organisations.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/69f6276e/attachment.sig>

From fz at voixit.com  Mon May  9 12:37:56 2016
From: fz at voixit.com (=?UTF-8?Q?Fabio_Zannicol=c3=b2_-_Voix_s.r.l.?=)
Date: Mon, 9 May 2016 12:37:56 +0200
Subject: [address-policy-wg] 2015-05 proposal
Message-ID: <57306884.8090602@voixit.com>

Hi,
I would like to share with you my opinion on Last /8 Allocation Criteria 
Revision proposal (2015-05).
Today small companies have competitiveness problems due to lack of IPv4 
resources.
I consider unfair the current treatment, the big companies have stocks 
of IPv4 addresses.
We need a balance between resource conservation and fair treatment, in 
addition to those already proposed my suggestions are:

-allocations of a /22 every 18 months only from IPv4 Addresses Available 
Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)

-leave the current policy only for IPv4 Addresses Available in 185/8 to 
avoid the too fast depletion of resources

-the addresses acquired with this system should not be able to be 
transferred for a long period of time to avoid profit


Best regards,
Fabio Zannicol?



From hunekm at gmail.com  Mon May  9 14:07:23 2016
From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=)
Date: Mon, 09 May 2016 14:07:23 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
	2015-05
Message-ID: <1513776.frbO9UE8Y6@rumburak>

Hello,

I would also like to add my point of view on proposal 2015-05.

In my opinion, this might even slow down depletion rate of 185/8. But it does 
not cover all cases of cheating the system.

You all probably know better then me that if you want to get larger address 
space, the easiest way (and probably the cheapest) is to make new LIR, pay for 
2 years and then transfer all its resources to your main LIR and close the new 
one.

The proposed policy would probably lower the need for such practice a little 
bit, but still some space for cheating remains. I would like to see minor 
change in policy, such like that LIR could not transfer IPv4 resources from 
pool 185/8 to another LIR (or its sponsored organizations) so that receiving 
LIR (and its sponsored organizations) would held more than /22 in 185/8 pool. 
That way, it would not matter how many LIR you open, when you close LIR you 
would not be able to transfer resources to any of your other LIRs (in RIR 
region), so it would had to be returned to RIPE for new comers.

Other than that, I agree with proposed policy change (2015-05). It might 
reduce the need for cheating system by offering the official way to expand LIRs 
pools, with motivation to start using IPv6 as well as limiting LIRs to 
monetize their (in 4 and a half years) pools so they can reach /20.

Sincerely

Martin Hunek
Freenet Liberec, z.s.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/b9fc3b08/attachment.sig>

From rgori at wirem.net  Mon May  9 14:19:43 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Mon, 9 May 2016 14:19:43 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
Message-ID: <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>

Hi Sander,

Il 09/05/2016 10:42, Sander Steffann ha scritto:
> Hello Ehsan,
>
>> we are agree about the Last /8 Allocation Criteria Revision proposal .
>> https://www.ripe.net/participate/policies/proposals/2015-05
> thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.
Can you please summarize us the main objections about this 2015-05 
policy so that people can try to address a solution to those?
>
>> RegID: ir.shnt
> You don't need to state your RegID in this working group. This working group is open to all interested parties, not just RIPE LIRs. Discussions are always between people, not organisations.
>
> Cheers,
> Sander
>
kind regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/78c3c213/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/78c3c213/attachment.jpg>

From phessler at theapt.org  Mon May  9 14:29:40 2016
From: phessler at theapt.org (Peter Hessler)
Date: Mon, 9 May 2016 14:29:40 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
Message-ID: <20160509122940.GG14871@gir.theapt.org>

On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote:
:Hi Sander,
:
:Il 09/05/2016 10:42, Sander Steffann ha scritto:
:>Hello Ehsan,
:>
:>>we are agree about the Last /8 Allocation Criteria Revision proposal .
:>>https://www.ripe.net/participate/policies/proposals/2015-05
:>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.
:Can you please summarize us the main objections about this 2015-05 policy so
:that people can try to address a solution to those?

My main objection to this proposal is simple:  It depletes the available
pool for _new_ participants faster.  I strongly believe any new actor
should be able to go from zero to non-zero with the addresses available
from RIPE.  For an actor with non-zero addresses to get more addresses,
there is a secondary market.

Since that is the base of my objection, I do not see any way that a
middle ground can be met.  Based on my understanding of the other
objections, I believe this is held by at least a few others from the
objection side.

I appreciate the effort put into this proposal, but I do not think any
solution can be proposed.

(note: my stance is based on forming a LIR simply to get any amount of
announcable addresses.)

-- 
Quick!!  Act as if nothing has happened!



From sander at steffann.nl  Mon May  9 14:50:14 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 9 May 2016 14:50:14 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509122940.GG14871@gir.theapt.org>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
Message-ID: <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>

Hi Peter,

> My main objection to this proposal is simple:  It depletes the available
> pool for _new_ participants faster.  I strongly believe any new actor
> should be able to go from zero to non-zero with the addresses available
> from RIPE.  For an actor with non-zero addresses to get more addresses,
> there is a secondary market.

Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".

> Since that is the base of my objection, I do not see any way that a
> middle ground can be met.  Based on my understanding of the other
> objections, I believe this is held by at least a few others from the
> objection side.

Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem.

I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC?s IPv4 pool was expected to last for around five years.".

> I appreciate the effort put into this proposal, but I do not think any
> solution can be proposed.

The stated expected timescale already seems to be around the bare minimum lifetime that is accepted, and much less than what many people would like. I therefore have to agree that any proposal that shortens that lifetime even further will very probably not get consensus.

Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this discussion to read the mailing list archives so they can get the full current picture before they propose a solution.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/7df3c8fe/attachment.sig>

From stolpe at resilans.se  Mon May  9 14:54:37 2016
From: stolpe at resilans.se (Daniel Stolpe)
Date: Mon, 9 May 2016 14:54:37 +0200 (CEST)
Subject: [address-policy-wg] agreement
In-Reply-To: <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
Message-ID: <alpine.LNX.2.00.1605091453520.9341@server.resilans.se>


On Mon, 9 May 2016, Sander Steffann wrote:

> Hi Peter,
>
>> My main objection to this proposal is simple:  It depletes the available
>> pool for _new_ participants faster.  I strongly believe any new actor
>> should be able to go from zero to non-zero with the addresses available
>> from RIPE.  For an actor with non-zero addresses to get more addresses,
>> there is a secondary market.
>
> Indeed. It all comes down to "the needs of those in the next few years 
> with no IPv4 addresses" vs "those today who have only one /22".
>
>> Since that is the base of my objection, I do not see any way that a
>> middle ground can be met.  Based on my understanding of the other
>> objections, I believe this is held by at least a few others from the
>> objection side.
>
> Well, to make a useful discussion possible I think it's important to 
> look at the timescales. A policy that changes expected depletion from 
> e.g. 100 years to 90 years might not be a problem, but other timescales 
> will definitely be a problem.
>
> I think the timescale I have heard that people would find acceptable is 
> *at least* 5 to 10 years. If you look at the minutes of RIPE 70 
> (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see 
> a statement from RIPE NCC when discussing this policy proposal that "the 
> RIPE NCC?s IPv4 pool was expected to last for around five years.".
>
>> I appreciate the effort put into this proposal, but I do not think any
>> solution can be proposed.
>
> The stated expected timescale already seems to be around the bare 
> minimum lifetime that is accepted, and much less than what many people 
> would like. I therefore have to agree that any proposal that shortens 
> that lifetime even further will very probably not get consensus.
>
> Someone would need to come up with a radical new idea to get out of the 
> current deadlock. Which is why I urge all new participants in this 
> discussion to read the mailing list archives so they can get the full 
> current picture before they propose a solution.
>
> Cheers,
> Sander


Very well written Sander. I Completely agree with you.

Cheers,
Daniel

_________________________________________________________________________________
Daniel Stolpe           Tel:  08 - 688 11 81                   stolpe at resilans.se
Resilans AB             Fax:  08 - 55 00 21 63            http://www.resilans.se/
Box 45 094							      556741-1193
104 30 Stockholm




From arash_mpc at parsun.com  Mon May  9 15:25:56 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Mon, 9 May 2016 23:25:56 +1000
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509122940.GG14871@gir.theapt.org>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
Message-ID: <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>

Hi,

This policy may actually reduce the depletion rate for last /8, but without
it the last /8 can be used more day by day.
In the real world, even when a customer needs for example an /24, they need
to become an LIR (and get the /22 from the last /8) as their old LIR cannot
provide them with additional blocks. That also speed up the depletion of
last /8. have you considered these when you made your objection?

This policy is not increasing the demand for IPv4, It creates a possibility
for small LIRs to receive additional blocks (not from last /8) based on
some conditions, so no change in depletion rate from my point of view.

Regards,

Arash Naderpour




On Mon, May 9, 2016 at 10:29 PM, Peter Hessler <phessler at theapt.org> wrote:

> On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote:
> :Hi Sander,
> :
> :Il 09/05/2016 10:42, Sander Steffann ha scritto:
> :>Hello Ehsan,
> :>
> :>>we are agree about the Last /8 Allocation Criteria Revision proposal .
> :>>https://www.ripe.net/participate/policies/proposals/2015-05
> :>thank you for expressing your support. However, at this point in the
> discussion we have seen enough support but not enough work solving the
> objections that have een raised. That is what is needed currently to work
> towards consensus. Without addressing those objections this policy proposal
> gets stuck.
> :Can you please summarize us the main objections about this 2015-05 policy
> so
> :that people can try to address a solution to those?
>
> My main objection to this proposal is simple:  It depletes the available
> pool for _new_ participants faster.  I strongly believe any new actor
> should be able to go from zero to non-zero with the addresses available
> from RIPE.  For an actor with non-zero addresses to get more addresses,
> there is a secondary market.
>
> Since that is the base of my objection, I do not see any way that a
> middle ground can be met.  Based on my understanding of the other
> objections, I believe this is held by at least a few others from the
> objection side.
>
> I appreciate the effort put into this proposal, but I do not think any
> solution can be proposed.
>
> (note: my stance is based on forming a LIR simply to get any amount of
> announcable addresses.)
>
> --
> Quick!!  Act as if nothing has happened!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160509/05486e30/attachment.html>

From jim at rfc1035.com  Mon May  9 15:31:28 2016
From: jim at rfc1035.com (Jim Reid)
Date: Mon, 9 May 2016 14:31:28 +0100
Subject: [address-policy-wg] 2015-05 proposal
In-Reply-To: <57306884.8090602@voixit.com>
References: <57306884.8090602@voixit.com>
Message-ID: <EB922BCD-0F9C-4BA1-83CE-7B4ADDEEE6F4@rfc1035.com>


> On 9 May 2016, at 11:37, Fabio Zannicol? - Voix s.r.l. <fz at voixit.com> wrote:
> 
> Today small companies have competitiveness problems due to lack of IPv4 resources.

Tough. We?re out of IPv4. We?re all struggling due to a lack of IPv4 resources. Everyone just has to make the best of it with whatever they have now. Anyone planning to grow their network using IPv4 simply cannot base their plans on repeatedly going to the NCC and asking for more. It?s that simple.

Let?s suppose 2015-05 is adopted. We quickly burn through the remaining IPv4 pool because some LIRs continue to grow their IPv4 networks instead of coming to terms with the end of IPv4. At that point, those LIRs will have a very nasty shock. There would literally be no IPv4 remaining at the NCC. So these LIRs will then be forced to do something else: use NAT, deploy IPv6, use ALGs, buy addresses on the secondary market, whatever. These LIRs could and should be doing that "something else" now. They?re going to *have* to do it eventually and might as well start now if they?ve not already done that.

These LIRs surely know today that they cannot continue with a model that assumes they can issue IPv4 addresses forever or go back to the NCC and get more. So all these LIRs would have achieved with 2015-05 is buy themselves a little extra time to persist with a doomed model that they already know no longer works. At that point the NCC would have no IPv4 left for any future entrants who will need some IPv4 to connect to the legacy v4-only Internet.

Burning through what?s left of IPv4 for the short-term benefit of LIRs who can?t/won?t face up to the exhaustion of IPv4 seems wrong to me. Future entrants would not thank us for frittering away those resources. They?ll need some IPv4 too. We should think about their needs too. Our IPv4 address policies can?t ignore that in favour of some what appears to be mistaken/misguided short-term benefit and self-interest.

The NCC will reach IPv4 exhaustion point of course. The current policy ensures this happens much later than it would than if 2015-05 was adopted. That is a Good Thing. And that is more than enough reason to reject 2015-05.

> I consider unfair the current treatment, the big companies have stocks of IPv4 addresses.

The holders of those resources got them as a result of the prevailing allocation policies at that time. Apart from the implementation detail of the size of the allocation an LIR gets, this is exactly the same as how requests from those who apply today get IPv4 addresses according to the allocation policies which are in use now.

BTW I can?t travel back in time to buy the ticket which would have won yesterday?s lottery. That?s unfair too.

> We need a balance between resource conservation and fair treatment

IMO the existing policy already achieves that. 2015-5, if adopted, does not.

> in addition to those already proposed my suggestions are:
> 
> -allocations of a /22 every 18 months only from IPv4 Addresses Available Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)

That?s discriminatory. It?s unfair on those LIRs who have a /20 or greater.

> -leave the current policy only for IPv4 Addresses Available in 185/8 to avoid the too fast depletion of resources

No. 185/8 should not be treated as ?special?. The current last /22 policy applies to all IPv4 blocks at the NCC. That policy kicked in as soon as the NCC made its first allocation from 185/8, the last /8 it got from IANA.

> -the addresses acquired with this system should not be able to be transferred for a long period of time to avoid profit

Define ?long period of time? and ?profit?.


From arash_mpc at parsun.com  Mon May  9 16:16:18 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 00:16:18 +1000
Subject: [address-policy-wg] 2015-05 proposal
In-Reply-To: <EB922BCD-0F9C-4BA1-83CE-7B4ADDEEE6F4@rfc1035.com>
References: <57306884.8090602@voixit.com>
 <EB922BCD-0F9C-4BA1-83CE-7B4ADDEEE6F4@rfc1035.com>
Message-ID: <016d01d1a9fd$5e56c560$1b045020$@parsun.com>


>Tough. We?re out of IPv4. We?re all struggling due to a lack of IPv4 resources. Everyone just has to make the best of it with whatever they have now. Anyone >planning to grow their network using IPv4 simply cannot base their plans on repeatedly going to >the NCC and asking for more. It?s that simple.

No, not everyone struggling due to lack of IPv4. There is a market and some are selling their IPv4 to others. Are they struggling??


>Let?s suppose 2015-05 is adopted. We quickly burn through the remaining IPv4 pool because some LIRs continue to grow their IPv4 networks instead of coming to terms with the end of IPv4. At that point, those LIRs will have a very nasty shock. There would >literally be no IPv4 remaining at the NCC. So these LIRs will then be forced to do something else: use NAT, deploy IPv6, use ALGs, buy addresses on the secondary market, whatever. These LIRs could and should be doing that "something else" now. They?re >going to *have* to do it eventually and might as well start now if they?ve not already done that.

That assumption is not necessary valid,  when 2015-01 was accepted we had not that much change in depletion rate. Can you please define first what you mean from "Quickly burn"? and how this policy can do that?

>These LIRs surely know today that they cannot continue with a model that assumes they can issue IPv4 addresses forever or go back to the NCC and get more. So all these LIRs would have achieved with 2015-05 is buy themselves a little extra time to persist >with a doomed model that they already know no longer works. At that point the NCC would have no IPv4 left for any future entrants who will need some IPv4 to connect to the legacy v4-only Internet.

Indeed, that?s why there are supports from a part of community.

>Burning through what?s left of IPv4 for the short-term benefit of LIRs who can?t/won?t face up to the exhaustion of IPv4 seems wrong to me. Future entrants would not thank us for frittering away those resources. They?ll need some IPv4 too. We should think >about their needs too. Our IPv4 address policies can?t ignore that in favour of some what appears to be mistaken/misguided short-term benefit and self-interest.


>> We need a balance between resource conservation and fair treatment

>IMO the existing policy already achieves that. 2015-5, if adopted, does not.

Really? How 2015-05 make it unbalanced?

>> in addition to those already proposed my suggestions are:
>> 
>> -allocations of a /22 every 18 months only from IPv4 Addresses Available Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)

>That?s discriminatory. It?s unfair on those LIRs who have a /20 or greater.

No comment!

>> -leave the current policy only for IPv4 Addresses Available in 185/8 to avoid the too fast depletion of resources

>No. 185/8 should not be treated as ?special?. The current last /22 policy applies to all IPv4 blocks at the NCC. That policy kicked in as soon as the NCC made its first allocation from 185/8, the last /8 it got from IANA.

>> -the addresses acquired with this system should not be able to be transferred for a long period of time to avoid profit

It is not really required to treated it as "special", when it is required we can have a new policy to change the depletion rate. this is not the last policy we can discuss here :)


Cheers,

Arash






From jim at rfc1035.com  Mon May  9 17:54:27 2016
From: jim at rfc1035.com (Jim Reid)
Date: Mon, 9 May 2016 16:54:27 +0100
Subject: [address-policy-wg] 2015-05 proposal
In-Reply-To: <016d01d1a9fd$5e56c560$1b045020$@parsun.com>
References: <57306884.8090602@voixit.com>
 <EB922BCD-0F9C-4BA1-83CE-7B4ADDEEE6F4@rfc1035.com>
 <016d01d1a9fd$5e56c560$1b045020$@parsun.com>
Message-ID: <26FCEC40-A03E-4EC7-A2A0-6F527E706F67@rfc1035.com>


> On 9 May 2016, at 15:16, Arash Naderpour <arash_mpc at parsun.com> wrote:
> 
> 
>> Tough. We?re out of IPv4. We?re all struggling due to a lack of IPv4 resources. Everyone just has to make the best of it with whatever they have now. Anyone >planning to grow their network using IPv4 simply cannot base their plans on repeatedly going to >the NCC and asking for more. It?s that simple.
> 
> No, not everyone struggling due to lack of IPv4. There is a market and some are selling their IPv4 to others. Are they struggling??

I don?t know. You?d need to ask the ones who are selling. I imagine some might be off-loading surplus IPv4 space because they?ve switched to IPv6 or are well down that path. FWIW the last time I looked, it was mostly legacy space which was changing hands. That?s not subject to RIR policies.

Not that this matters. Yes, of course some LIRs will have extra IPv4 addresses. That?s largely an accident of history. The fact they benefited from the more liberal RIR policies from N years ago is no reason to tear up the current policy. Amongst other things, the current policy aims to share the pain of IPv4 run-out roughly equally between all LIRs. 

Supporters of this proposal appear want to avoid some of that pain for themselves (or delay it for a while) at the expense of others. That?s not fair, reasonable or balanced.

>> Let?s suppose 2015-05 is adopted. We quickly burn through the remaining IPv4 pool because some LIRs continue to grow their IPv4 networks instead of coming to terms with the end of IPv4. 
> 
> That assumption is not necessary valid

Nonsense.

Current policy says every LIR gets exactly one /22. 2015-05 says an LIR can get more than that and keep on coming back for even more. This means the pool of IPv4 at the NCC will be depleted at a faster rate than it would under the current policy. 2015-05 even says this.

> Can you please define first what you mean from "Quickly burn"? and how this policy can do that?

The usual dictionary definition of ?quickly burn? should be clear enough. If not, replace ?burn? with ?squander?, ?deplete?, ?exhaust?, ?fritter away?, ?use up?, etc.

Current policy says every LIR gets exactly one /22. 2015-05 says an LIR can get more than that and keep on coming back for even more. This means the pool of IPv4 at the NCC will be depleted at a faster rate than it would under the current policy. 2015-05 even says this. How often do I need to repeat this?

Suppose a boat has a leak below the waterline. What happens if you put another hole in the hull? Will it sink earlier or later than if it had just one hole?

>>> We need a balance between resource conservation and fair treatment
> 
>> IMO the existing policy already achieves that. 2015-5, if adopted, does not.
> 
> Really? How 2015-05 make it unbalanced?

This has already been explained many times. The proposal actually says so itself. I quote: "Further allocations will speed up the depletion of the free pool.?

A policy proposal which will speed up the depletion of the free pool BY DESIGN is deeply flawed and cannot hope to be either fair or balanced.

The balance in this proposal is about as ?fair and balanced? as Fox News. 2015-05 aims to encourage IPv4 exhaustion and is the very antithesis of resource conservation. Now let?s assume we agree that IPv4 exhaustion is a Good Thing. Who benefits from that policy? And are the benefits worth it? Well, the LIRs who?d gain from 2015-05 are the ones who can?t/won?t do anything about IPv4 exhaustion until it?s all gone. And even then, they?d only be able to keep going with those flawed models for a little longer than they would with the current policy.

IMO that?s not in the best interests of the community as a whole. It doesn?t result in an acceptable trade-off which justifies burning through the last dregs of IPv4.

2015-05 would allow some LIRs to keep on using IPv4 when they should have faced up to the reality of IPv4 exhaustion. That may well be to their short-term advantage. But it doesn?t change the outcome. It just brings forward the date when the NCC runs out of IPv4. That's
not fair for future entrants. It?s not fair to the LIRs who have already incurred the costs and expense of deploying NAT or IPv6 or whatever because ?more IPv4? was no longer an option. They could have deferred or not had those hassles if there was a chance of getting more than a final /22.

It?s rather ironic that supporters of 2015-05 complain that they?re at a disadvantage to the LIRs who enjoyed the more liberal allocations of the past when they want to introduce a more liberal address allocation policy now which will disadvantage future entrants. Ho hum.





From ripe at liopen.fr  Mon May  9 19:31:48 2016
From: ripe at liopen.fr (Denis Fondras)
Date: Mon, 9 May 2016 19:31:48 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
Message-ID: <20160509173148.GA16361@enforcer.ledeuns.net>

> In the real world, even when a customer needs for example an /24, they need
> to become an LIR (and get the /22 from the last /8) as their old LIR cannot
> provide them with additional blocks. That also speed up the depletion of
> last /8. have you considered these when you made your objection?
> 

They can also make their LIR job and make the unused space available to others :)

> -allocations of a /22 every 18 months only from IPv4 Addresses Available
> Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)
>

I would consider unfair that I could not get more than /20 when some players
have /19 or more.

Denis



From jim at rfc1035.com  Mon May  9 20:33:58 2016
From: jim at rfc1035.com (Jim Reid)
Date: Mon, 9 May 2016 19:33:58 +0100
Subject: [address-policy-wg] agreement
In-Reply-To: <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
Message-ID: <3BF2D1CA-FC3A-45E4-818C-9585B233C4CE@rfc1035.com>


> On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc at parsun.com> wrote:
> 
> In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?

Well I know I did.

Setting up an LIR just to get a /22 is a possibility. The NCC?s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies.

While it?s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That?s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don?t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive.

If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool?

> This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions,

While I oppose 2015-5 in principle, I?m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there?s no IPv4 left at the NCC.

That doesn?t seem fair. Unless "something which benefits me and/or my customers at someone else?s expense? is the definition of fair.

BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It?s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC?s allocations out of that last /8. 

> so no change in depletion rate from my point of view.

You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit:

b. Arguments opposing the proposal

	Further allocations will speed up the depletion of the free pool.




From arash_mpc at parsun.com  Tue May 10 02:39:49 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 10:39:49 +1000
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509173148.GA16361@enforcer.ledeuns.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <20160509173148.GA16361@enforcer.ledeuns.net>
Message-ID: <027701d1aa54$7881c3c0$69854b40$@parsun.com>


>> In the real world, even when a customer needs for example an /24, they 
>> need to become an LIR (and get the /22 from the last /8) as their old 
>> LIR cannot provide them with additional blocks. That also speed up the 
>> depletion of last /8. have you considered these when you made your
objection?
>> 

>They can also make their LIR job and make the unused space available to
others :)

Yes they can, but if they are really interested to make their LIR job. 
If the only motivation of new-comers is to get some IPv4 as their internet
service provider is not able to provide them with any, there would no do LIR
job.  (new RIPE NCC members are not necessarily from IT industry and are
forced to become LIR)

>> -allocations of a /22 every 18 months only from IPv4 Addresses 
>> Available Outside 185/8 to small LIRs (if LIR own < /20 of total 
>> allocations)
>>

>I would consider unfair that I could not get more than /20 when some
players have /19 or more.

And you consider it fair when you cannot get more than /22 when some players
have /19 or more? 
It may not be fair to everyone, but I cannot imagine a policy that can be
totally fair to all of us in the real world, we can put "unfair" label to
any policy proposal.


Arash Naderpour







From arash_mpc at parsun.com  Tue May 10 03:04:49 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 11:04:49 +1000
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509190722.GA11334@mail.webmonster.de>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <20160509190722.GA11334@mail.webmonster.de>
Message-ID: <027a01d1aa57$f6388170$e2a98450$@parsun.com>

Hi Sebastian,

I understand your point but please consider that setting up a new LIR does
not mean you are immediately eligible to receive additional /22.

- allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC
every 18 months.
- Additional /22 IPv4 allocations can be only provided from address space
outside 185/8
- Only LIRs with less than a /20 in total are eligible to receive additional
allocations
- LIRs must document their IPv6 deployment as part of the request
- Allow LIRs to request an additional /22 IPv4 allocation from the RIPE NCC
every 18 months.

And you cannot transfer out your /22 for 2years,

So affection to the depletion rate looks less than setting up multi LIR to
receive immediately an /22 from 185/8 or encouraging small businesses in
need of small blocks to become LIR. 

Regards,

Arash Naderpour





 

-----Original Message-----
From: Sebastian Benoit [mailto:benoit-lists at fb12.de] 
Sent: Tuesday, 10 May 2016 5:07 AM
To: Arash Naderpour <arash_mpc at parsun.com>
Cc: RIPE Address Policy WG <address-policy-wg at ripe.net>
Subject: Re: [address-policy-wg] agreement

Hi,

Arash Naderpour(arash_mpc at parsun.com) on 2016.05.09 23:25:56 +1000:
> Hi,
> 
> This policy may actually reduce the depletion rate for last /8, but 
> without it the last /8 can be used more day by day.
> In the real world, even when a customer needs for example an /24, they 
> need to become an LIR (and get the /22 from the last /8) as their old 
> LIR cannot provide them with additional blocks. That also speed up the 
> depletion of last / 8. have you considered these when you made your
objection?
> 
> This policy is not increasing the demand for IPv4, It creates a 
> possibility for small LIRs to receive additional blocks (not from last 
> /8) based on some conditions, so no change in depletion rate from my point
of view.

On the other hand, there is also the possibility that 2015-05 will increase
the depletion rate, not only because more address space will be handed out,
but because it will make it more attractive (from a financial point of view)
to set up a new LIR when you get more than a /22 out of it. That is, it
might make the secondary market less attractive.




From arash_mpc at parsun.com  Tue May 10 03:18:24 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 11:18:24 +1000
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
Message-ID: <027b01d1aa59$dc039a90$940acfb0$@parsun.com>

Remco,

 

Calling anyone supporting a policy delusional is not really helping the discussion we have here, you can still express your own opinion without using that.

 

 

>>. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. 

 

We have the same situation with the ?new-entrants? joined 2012 (before we reached to last /8) and the ones joined 2 years after that. 

 

>>The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about.

 

This new policy is not going to hand over any left available IP address in the pool out considering the conditions, 185/8 would be untouched.

 

Cheers,

 

Arash Naderpour

 

 

From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of remco van mook
Sent: Friday, 15 April 2016 8:50 AM
To: Marco Schmidt <mschmidt at ripe.net>; address-policy-wg at ripe.net
Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

 

Dear colleagues,

 

I'd like to reiterate my objection to this proposal. Anyone who thinks another block of 1,000 addresses is going to help them float their business is in my opinion delusional (because the next step would be an extra 2,000, then 4,000, ..). The problem is not that you're getting a /22 - the problem is that we're out of space, never to come back. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now. 

 

The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about. What does need fixing is the fact that there are a few obvious loopholes that are now being used to contravene the intention of the policy, and are being used as a rationale for this proposal. 

 

Kind regards,

 

Remco

(no hats)

 

On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt <mschmidt at ripe.net <mailto:mschmidt at ripe.net> > wrote:

Dear colleagues,

The Discussion Period for the policy proposal 2015-05, "Last /8
Allocation Criteria Revision" has been extended until 13 May 2016.

The goal of this proposal is to allow LIRs to request an additional /22
IPv4 allocation from the RIPE NCC every 18 months.

The text of the proposal has been revised based on mailing list feedback
and we have published a new version (2.0) today. As a result, a new
Discussion Phase has started for the proposal.

Some of the differences from version 1.0 include:
- Additional /22 IPv4 allocations can be only provided from address
space outside 185/8
- Only LIRs with less than a /20 in total are eligible to receive
additional allocations
- LIRs must document their IPv6 deployment as part of the request

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2015-05

We encourage you to review this policy proposal and send your comments
to <address-policy-wg at ripe.net <mailto:address-policy-wg at ripe.net> >.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/4ffacba7/attachment.html>

From arash_mpc at parsun.com  Tue May 10 03:23:37 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 11:23:37 +1000
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <alpine.DEB.2.02.1604150944500.16013@uplift.swm.pp.se>
References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org>
 <CAO1bj=ZqbMaxO9Hv9MfKvuDjWs943oVxsw9owV6omRPtHsdKcA@mail.gmail.com>
 <A96A4B58-076D-46F4-8425-05B4D09EBF94@rfc1035.com>
 <A2665200-1D6D-4CEB-963F-C69ADE1A048F@ucd.ie>
 <20160415065121.12e36e72@echo.ms.redpill-linpro.com>
 <alpine.DEB.2.02.1604150944500.16013@uplift.swm.pp.se>
Message-ID: <029001d1aa5a$966deca0$c349c5e0$@parsun.com>

Hi Mikael,

The last /8 is not really get affected by this policy, 

- Additional /22 IPv4 allocations can be only provided from address space
outside 185/8

Is it the only reason of your objection to this policy? 

Regards,

Arash Naderpour




-----Original Message-----
From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On
Behalf Of Mikael Abrahamsson
Sent: Friday, 15 April 2016 5:46 PM
To: RIPE Address Policy WG <address-policy-wg at ripe.net>
Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13
May 2016 (Last /8 Allocation Criteria Revision)

On Fri, 15 Apr 2016, Tore Anderson wrote:

> * "Niall O'Reilly" <niall.oreilly at ucd.ie>
>
>> On 14 Apr 2016, at 17:01, Jim Reid wrote:
>>
>>> I strongly disagree with the proposal
>>
>>   what Jim said, which you don't need to see again.
>>   Well said, Jim.
>
> +1

I agree with people above, I want to keep the last /8 for new future
entrants with current policy, not deplete quicker.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se




From randy at psg.com  Tue May 10 03:44:05 2016
From: randy at psg.com (Randy Bush)
Date: Tue, 10 May 2016 10:44:05 +0900
Subject: [address-policy-wg] 2015-05 Discussion Period extended until
	13	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
References: <570F9005.4090008@ripe.net> <m2r3e8umr6.wl%randy@psg.com>
 <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
Message-ID: <m21t5ahel6.wl%randy@psg.com>

you may find reading the actual last /8 policy informative.

> Last /8 is not really get affected by this policy. 
> - Additional /22 IPv4 allocations can be only provided from address space
>   outside 185/8

this is misleading or just sadly misinformed

last /8 is not an address range, it is a state reached once the ncc had
only that address range and continues on irrespective of additions or
subtractions of space to the ncc's pool.

randy



From arash_mpc at parsun.com  Tue May 10 04:17:07 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 12:17:07 +1000
Subject: [address-policy-wg] agreement
In-Reply-To: <3BF2D1CA-FC3A-45E4-818C-9585B233C4CE@rfc1035.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <3BF2D1CA-FC3A-45E4-818C-9585B233C4CE@rfc1035.com>
Message-ID: <02b601d1aa62$0fadf270$2f09d750$@parsun.com>

>While it?s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some >overheads for paperwork, legal fees and so on. That?s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don?t come with the same overheads >that come with NCC membership, so they may well be considered more valuable/attractive.

At the moment many new LIRs are just joining the RIPE NCC to get small blocks, that is happening.  


>While I oppose 2015-5 in principle, I?m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there?s no IPv4 left at the NCC.

>That doesn?t seem fair. Unless "something which benefits me and/or my customers at someone else?s expense? is the definition of fair.

>BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It?s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC?s allocations out of that last /8.

By looking at the current available IPv4 pool, (not that much change since 2012)
considering the conditions of the new policy for handing out additional /22
and keep the 185/8 untouched and leave it for new-comers. 



>You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit:
>b. Arguments opposing the proposal
>	Further allocations will speed up the depletion of the free pool.

Those arguments are the ones that the proposers foresaw and used to kick off the discussion.

Regards,

Arash Naderpour





-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com] 
Sent: Tuesday, 10 May 2016 4:34 AM
To: Arash Naderpour <arash_mpc at parsun.com>
Cc: RIPE Address Policy WG <address-policy-wg at ripe.net>
Subject: Re: [address-policy-wg] agreement


> On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc at parsun.com> wrote:
> 
> In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?

Well I know I did.

Setting up an LIR just to get a /22 is a possibility. The NCC?s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies.

While it?s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That?s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don?t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive.

If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool?

> This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions,

While I oppose 2015-5 in principle, I?m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there?s no IPv4 left at the NCC.

That doesn?t seem fair. Unless "something which benefits me and/or my customers at someone else?s expense? is the definition of fair.

BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It?s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC?s allocations out of that last /8. 

> so no change in depletion rate from my point of view.

You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit:

b. Arguments opposing the proposal

	Further allocations will speed up the depletion of the free pool.




From arash_mpc at parsun.com  Tue May 10 05:32:36 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Tue, 10 May 2016 13:32:36 +1000
Subject: [address-policy-wg] 2015-05 Discussion Period extended until
	13	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m21t5ahel6.wl%randy@psg.com>
References: <570F9005.4090008@ripe.net>	<m2r3e8umr6.wl%randy@psg.com>	<02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
 <m21t5ahel6.wl%randy@psg.com>
Message-ID: <02ce01d1aa6c$9cb25da0$d61718e0$@parsun.com>

Thanks Randy,

below is what you wrote on Apri 15:


>i do not support pigs at the last /8 trough
>the purpose of the single last /8 allocation was to allow NEW ENTRY.
>pigs coming back to the trough every 18 months is not new anything.

>randy

 can you please tell me what you meant from "last /8 allocation" there?

Cheers,

Arash Naderpour

P.S my understanding from 2015-05 is that it divides the current pool into 2
separate parts, last allocation of /8 and additional free IP pool received
from IANA. 


-----Original Message-----
From: Randy Bush [mailto:randy at psg.com] 
Sent: Tuesday, 10 May 2016 11:44 AM
To: Arash Naderpour <arash_mpc at parsun.com>
Cc: RIPE address policy WG <address-policy-wg at ripe.net>
Subject: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13
May 2016 (Last /8 Allocation Criteria Revision)

you may find reading the actual last /8 policy informative.

> Last /8 is not really get affected by this policy. 
> - Additional /22 IPv4 allocations can be only provided from address space
>   outside 185/8

this is misleading or just sadly misinformed

last /8 is not an address range, it is a state reached once the ncc had only
that address range and continues on irrespective of additions or
subtractions of space to the ncc's pool.

randy




From randy at psg.com  Tue May 10 05:54:46 2016
From: randy at psg.com (Randy Bush)
Date: Tue, 10 May 2016 12:54:46 +0900
Subject: [address-policy-wg] 2015-05 Discussion Period extended until
	13	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <02ce01d1aa6c$9cb25da0$d61718e0$@parsun.com>
References: <570F9005.4090008@ripe.net> <m2r3e8umr6.wl%randy@psg.com>
 <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
 <m21t5ahel6.wl%randy@psg.com>
 <02ce01d1aa6c$9cb25da0$d61718e0$@parsun.com>
Message-ID: <m2shxqftyx.wl%randy@psg.com>

> P.S my understanding from 2015-05 is that it divides the current pool
> into 2 separate parts, last allocation of /8 and additional free IP
> pool received from IANA.

that's nice.  as i said a bit ago, you may want to read the last /8
policy and not start trying to redifine terms.



From rgori at wirem.net  Tue May 10 07:40:25 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 10 May 2016 07:40:25 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509122940.GG14871@gir.theapt.org>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
Message-ID: <15b3b1e4-1fe1-6823-fddb-7f1d550573af@wirem.net>

Hi Peter,


Il 09/05/2016 14:29, Peter Hessler ha scritto:
> On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote:
> :Hi Sander,
> :
> :Il 09/05/2016 10:42, Sander Steffann ha scritto:
> :>Hello Ehsan,
> :>
> :>>we are agree about the Last /8 Allocation Criteria Revision proposal .
> :>>https://www.ripe.net/participate/policies/proposals/2015-05
> :>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.
> :Can you please summarize us the main objections about this 2015-05 policy so
> :that people can try to address a solution to those?
>
> My main objection to this proposal is simple:  It depletes the available
> pool for _new_ participants faster.  I strongly believe any new actor
> should be able to go from zero to non-zero with the addresses available
> from RIPE.  For an actor with non-zero addresses to get more addresses,
> there is a secondary market.
Thi is yourrespectable opinion but my one is that actual allocation rate 
is mainly due to new LIR sign up rate and in many cases they are end 
users or customers.
Plase look when 2015-01 took place: nothing changed to the pool 
allocation rate even if abusing stockpilers and seller are affected by 
the fix.
This is beacuse of real needing of space, and as newcomer eveyone is 
legitimate to reiceve its /22 but most of this cases are wasting a lot 
of space 'cause of the sign up for small needings.
When I started my business late 2014 one of my fiber carrier said "ask 
me for bandwidth and best prices but don't ask for address space. Sign 
up and get your one"
Consider also that advicing customers to sign up as LIR in most cases 
for a newcomer is also dealing with the probability to loose the 
customers that
can handle everything by theirsefl.
As a newcomer nobody would say to his customer feel free to handle 
everything  'cause I can't provide you the service.

This policy is so good in 2 main things:
- address the problem of customers make the customers giving new 
entrants a little bit more space to handle their grow and customer 
acquisition
- incentive the use IPv6. Again this is the ONLY policy that advice LIRs 
to use IPv6 actually


>
> Since that is the base of my objection, I do not see any way that a
> middle ground can be met.  Based on my understanding of the other
> objections, I believe this is held by at least a few others from the
> objection side.
>
> I appreciate the effort put into this proposal, but I do not think any
> solution can be proposed.
>
> (note: my stance is based on forming a LIR simply to get any amount of
> announcable addresses.)
>
I think the middle ground is paying annual fee per IPs in registries. 
Don't you think?
I am happy that you appreciate the effort

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/72916804/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/72916804/attachment.jpg>

From rgori at wirem.net  Tue May 10 07:46:17 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 10 May 2016 07:46:17 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <1513776.frbO9UE8Y6@rumburak>
References: <1513776.frbO9UE8Y6@rumburak>
Message-ID: <f277b49c-437f-f152-783a-a060930037ff@wirem.net>

Hi Martin,


Il 09/05/2016 14:07, Martin Hun?k ha scritto:
> Hello,
>
> I would also like to add my point of view on proposal 2015-05.
>
> In my opinion, this might even slow down depletion rate of 185/8. But it does
> not cover all cases of cheating the system.
>
> You all probably know better then me that if you want to get larger address
> space, the easiest way (and probably the cheapest) is to make new LIR, pay for
> 2 years and then transfer all its resources to your main LIR and close the new
> one.
>
> The proposed policy would probably lower the need for such practice a little
> bit, but still some space for cheating remains. I would like to see minor
> change in policy, such like that LIR could not transfer IPv4 resources from
> pool 185/8 to another LIR (or its sponsored organizations) so that receiving
> LIR (and its sponsored organizations) would held more than /22 in 185/8 pool.
> That way, it would not matter how many LIR you open, when you close LIR you
> would not be able to transfer resources to any of your other LIRs (in RIR
> region), so it would had to be returned to RIPE for new comers.
You are right but and this in this case we have to consider that RIPE 
NCC cannot deal with any kind of business process inside companies or 
natural persons
The only thing RIPE NCC can do is to check is the process is legitima 
and documented and it's very difficoult to discuss documents
provider by thir parties around the world with any kind of different law
>
> Other than that, I agree with proposed policy change (2015-05). It might
> reduce the need for cheating system by offering the official way to expand LIRs
> pools, with motivation to start using IPv6 as well as limiting LIRs to
> monetize their (in 4 and a half years) pools so they can reach /20.
>
> Sincerely
>
> Martin Hunek
> Freenet Liberec, z.s.

regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/5d76a5a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/5d76a5a8/attachment.jpg>

From rogerj at gmail.com  Tue May 10 08:07:38 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Tue, 10 May 2016 08:07:38 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
	2015-05
In-Reply-To: <1513776.frbO9UE8Y6@rumburak>
References: <1513776.frbO9UE8Y6@rumburak>
Message-ID: <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>

On Mon, May 9, 2016 at 2:07 PM, Martin Hun?k <hunekm at gmail.com> wrote:
> Hello,
>
> I would also like to add my point of view on proposal 2015-05.

hello and welcome :-)


<snip>
> The proposed policy would probably lower the need for such practice a little
> bit, but still some space for cheating remains. I would like to see minor
> change in policy, such like that LIR could not transfer IPv4 resources from
> pool 185/8 to another LIR (or its sponsored organizations) so that receiving
> LIR (and its sponsored organizations) would held more than /22 in 185/8 pool.
> That way, it would not matter how many LIR you open, when you close LIR you
> would not be able to transfer resources to any of your other LIRs (in RIR
> region), so it would had to be returned to RIPE for new comers.

The idea might sound good, however you are not very close to
regulation of normal business activity. What if some smaller ISP's
find out they want to work together, merge to create a stronger
company and they have one obvious place to cut cost - go from let's
say 3 LIR's to one... but they can't due to RIPE NCC?



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no



From ripe at liopen.fr  Tue May 10 08:15:19 2016
From: ripe at liopen.fr (Denis Fondras)
Date: Tue, 10 May 2016 08:15:19 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <027a01d1aa57$f6388170$e2a98450$@parsun.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <20160509190722.GA11334@mail.webmonster.de>
 <027a01d1aa57$f6388170$e2a98450$@parsun.com>
Message-ID: <20160510061519.GB16361@enforcer.ledeuns.net>

> Yes they can, but if they are really interested to make their LIR job.
> If the only motivation of new-comers is to get some IPv4 as their internet
> service provider is not able to provide them with any, there would no do LIR
> job.  (new RIPE NCC members are not necessarily from IT industry and are
> forced to become LIR)
>

Why wouldn't a LIR get some space on the secondary market to provide to its
customers ?

> And you consider it fair when you cannot get more than /22 when some players
> have /19 or more?

For some definition of "fair".
I came to the game later when the pool was empty, I know it and I understand it.
So, I consider "fair" I was able to get a small part of IPv4 that helped me
kickstart the business.

> At the moment many new LIRs are just joining the RIPE NCC to get small blocks,
> that is happening.
>

Some are taking advantages of this situation (open multiple LIR) to get IPv4
space. I don't see how 2015-05 would stop that even if you allow new LIR to get
more than a /22. All I can see it more faster depletion (honest LIR getting
more + dishonest LIR getting more)

I hear your arguments but I don't think 2015-05 is the right answer for the
community.

Denis



From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 08:29:43 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 08:29:43 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160509122940.GG14871@gir.theapt.org>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
Message-ID: <1462861783.3819181.603141561.48AAD60F@webmail.messagingengine.com>

> (note: my stance is based on forming a LIR simply to get any amount of
> announcable addresses.)

Hi,

With a few drawbacks - more de-aggregation, (much) more complex policy -
that could be achieved (without speeding up depletion). However, a lot
of people let me understand that complexity is a no-go.
That could even have been achieved with 2012-04 (rejected back in 2013).

--
Radu-Adrian FEURDEAN
fr.ccs



From jerome at ceriz.fr  Tue May 10 08:34:28 2016
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Tue, 10 May 2016 08:34:28 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
Message-ID: <573180F4.6040903@ceriz.fr>

Hello Roger,

Le 10/05/2016 08:07, Roger J?rgensen a ?crit :
> The idea might sound good, however you are not very close to
> regulation of normal business activity. What if some smaller ISP's
> find out they want to work together, merge to create a stronger
> company and they have one obvious place to cut cost - go from let's
> say 3 LIR's to one... but they can't due to RIPE NCC?

According to RIPE-654, two seperate process remains : one is for mergers
/ acquisition, the other is for other ressource transfers.

I think that baring transfers of such blocks will only raise market's
price for prefixes and move the market from adresses to entire LIRs.
Therefore it looks unnecessary to me.

Clocking a mere 56 adresses per months is kinda slow farming process,
but still, it would encourage some crooks to create empty shells, set it
as LIR, farm a /20, and sell control (or ownership) of that shell.

Also, a fast growing new comer could have a need for additionnal /22s
faster than the proposed timing provides. Remember we're far from that
marvelous time where customer will drop IPv4 only services and devices
anyway.

Therefore, allocation of additionnal prefixes, whilst limited to a /20
per LIR, should be *justification-based*, not time-based.

I get that /20 is still not enough for some cases, but it looks like the
max size we can afford, should be enough for a last-resort CGN, and will
prevent some crooks from operating profitably.

Best regards,

-- 
J?r?me Nicolle



From ed at tsnet.it  Tue May 10 09:18:16 2016
From: ed at tsnet.it (Enrico Diacci)
Date: Tue, 10 May 2016 09:18:16 +0200
Subject: [address-policy-wg] R:  agreement
In-Reply-To: <15b3b1e4-1fe1-6823-fddb-7f1d550573af@wirem.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <15b3b1e4-1fe1-6823-fddb-7f1d550573af@wirem.net>
Message-ID: <089501d1aa8c$201b52e0$6051f8a0$@tsnet.it>

Hi Riccardo,

 

This policy is so good in 2 main things:
- address the problem of customers make the customers giving new entrants a
little bit more space to handle their grow and customer acquisition
- incentive the use IPv6. Again this is the ONLY policy that advice LIRs to
use IPv6 actually



mainly the second one in my opinion is the important thing: if a LIR wants
take advantage of this proposal it MUST demonstrate having deployed IPv6 in
its network.

 

We could also make stronger this idea of really using IPv6 requesting 4 (or
5 now) stars of RIPEness.

 

So this may be considered such a prize to really do effort in implementing
IPv6 (and in Italy we know how we must facilitate it, with less than 0,5% of
adoption).

 

Regards,

Enrico Diacci.

 

it.tsnet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/f740a550/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6354 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/f740a550/attachment.p7s>

From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 10:02:49 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 10:02:49 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
Message-ID: <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>

Hi,

On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
> Indeed. It all comes down to "the needs of those in the next few years
> with no IPv4 addresses" vs "those today who have only one /22".

I find the situation a little more complex than that:
 - First, the "in a few years with no IPv4" is not so far away. Even
 with current policy, it is for 2020, with a lot of chance 2021. With
 the proposal, worst case scenario is that we MAY loose up to 18 months
 (more likely something in the 6-12 months range ). Which is not
 completely sure (as Martin Hun?k noted a few messages ago).
 - Second, right now the NCC is just handing out /22 to whoever can pay
 for them (with only a small extra administrative restriction during the
 last 6 months). For me this is plain "selling IP addresses" (concept
 that the NCC avoided like hell int the past), and it is also defeating
 the "keep space for later entrants" purpose. No need check (as in "do
 you really need that space" *), no requirement to deploy IPv6 of any
 kind, just a simple "pay to have it".

> Well, to make a useful discussion possible I think it's important to look
> at the timescales. A policy that changes expected depletion from e.g. 100
> years to 90 years might not be a problem, but other timescales will
> definitely be a problem.

Given the time we have left (very unlikely to have 60 moths left)
anything starts being problematic.

> I think the timescale I have heard that people would find acceptable is
> *at least* 5 to 10 years. If you look at the minutes of RIPE 70
> (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see
> a statement from RIPE NCC when discussing this policy proposal that "the
> RIPE NCC?s IPv4 pool was expected to last for around five years.".

It all depends on when we start counting. If we start counting from
09/2012, we will meet the 5 years lifetime even with the current
proposal. If we start now (10/05/2016), we will most probably NOT reach
5 years.
We will NOT get 10 years of "last /8". 
And we should probably stop thinking "X years starting from now on".
Time passes.
In the meantime, people do "whatever seems appropriate" to get more v4
space. And unfortunately more and more people find there is no other
solution than cheating in some way or another. The policy was supposed
to calm down this.

> Someone would need to come up with a radical new idea to get out of the
> current deadlock. Which is why I urge all new participants in this

Does anybody feel that a more complex policy is acceptable ? Does making
the policy more complex in order to get longer timespan for the free
pool (which does not exclude extra allocations if conditions are met) is
somthing that may get consensus ?

(*) Some time ago, a lot of "new players" would have started by being
single-homed and having one (or more) "ASSIGNED PA" block(s) from their
upstream. Then they were taking an ASN, and then became LIRs. Those
going LIR from day one were not exactly commonplace.
Today, even for those that are ok with being single-homed with an
"ASSIGNED PA" from their upstream, if the size of the requested block
goes beyond a certain size (commonly /24, occasionally down to /26),
they are recommended (or even pushed) to become a LIR and get their /22.
There are others that just "can afford" to spend some money to become
LIR and get some space, even if it's not really used, just in case
things go wrong in the future.

--
Radu-Adrian FEURDEAN
fr.ccs



From phessler at theapt.org  Tue May 10 10:48:57 2016
From: phessler at theapt.org (Peter Hessler)
Date: Tue, 10 May 2016 10:48:57 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <3BF2D1CA-FC3A-45E4-818C-9585B233C4CE@rfc1035.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <3BF2D1CA-FC3A-45E4-818C-9585B233C4CE@rfc1035.com>
Message-ID: <20160510084857.GK14871@gir.theapt.org>

On 2016 May 09 (Mon) at 19:33:58 +0100 (+0100), Jim Reid wrote:
:
:> On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc at parsun.com> wrote:
:> 
:> In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?
:
:Well I know I did.
:
:Setting up an LIR just to get a /22 is a possibility. The NCC???s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies.
:
:While it???s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That???s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don???t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive.
:
:If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool?
:

I did exactly that, we created a LIR primarily to get the allocation.  At
the time we looked, the prices on the secondary market were approx
$10/IP, which is far more than the costs of joining RIPE.


:> This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions,
:
:While I oppose 2015-5 in principle, I???m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there???s no IPv4 left at the NCC.
:
:That doesn???t seem fair. Unless "something which benefits me and/or my customers at someone else???s expense??? is the definition of fair.
:
:BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It???s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC???s allocations out of that last /8. 
:
:> so no change in depletion rate from my point of view.
:
:You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit:
:
:b. Arguments opposing the proposal
:
:	Further allocations will speed up the depletion of the free pool.
:
:

-- 
When more and more people are thrown out of work, unemployment
results.
		-- Calvin Coolidge



From aled.w.morris at googlemail.com  Tue May 10 14:12:58 2016
From: aled.w.morris at googlemail.com (Aled Morris)
Date: Tue, 10 May 2016 13:12:58 +0100
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
	2015-05
In-Reply-To: <573180F4.6040903@ceriz.fr>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
Message-ID: <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>

I am troubled by the new members joining RIPE purely to obtain IPv4 address
space.

Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
price as membership (?3,400 i.e. joining fee + 1 year subs) to anyone who
wants one since they can get one anyway by joining.

It would save the admin overheads and would identify members as those
actually committed to performing as LIRs.

I can't imagine this will be a popular suggestion, I'm just putting it out
there.

Aled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/27a065b5/attachment.html>

From phessler at theapt.org  Tue May 10 14:16:14 2016
From: phessler at theapt.org (Peter Hessler)
Date: Tue, 10 May 2016 14:16:14 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
Message-ID: <20160510121614.GL14871@gir.theapt.org>

This was called "Provider Independent" and for IPv4, it was killed off
some years ago.

You can still get PI IPv6 space, however.


On 2016 May 10 (Tue) at 13:12:58 +0100 (+0100), Aled Morris wrote:
:I am troubled by the new members joining RIPE purely to obtain IPv4 address
:space.
:
:Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
:price as membership (???3,400 i.e. joining fee + 1 year subs) to anyone who
:wants one since they can get one anyway by joining.
:
:It would save the admin overheads and would identify members as those
:actually committed to performing as LIRs.
:
:I can't imagine this will be a popular suggestion, I'm just putting it out
:there.
:
:Aled

-- 
		WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.



From frettled at gmail.com  Tue May 10 14:53:46 2016
From: frettled at gmail.com (Jan Ingvoldstad)
Date: Tue, 10 May 2016 14:53:46 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
Message-ID: <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>

On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN <
ripe-wgs at radu-adrian.feurdean.net> wrote:

> Hi,
>
> On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
> > Indeed. It all comes down to "the needs of those in the next few years
> > with no IPv4 addresses" vs "those today who have only one /22".
>
> I find the situation a little more complex than that:
>  - First, the "in a few years with no IPv4" is not so far away. Even
>  with current policy, it is for 2020, with a lot of chance 2021. With
>  the proposal, worst case scenario is that we MAY loose up to 18 months
>  (more likely something in the 6-12 months range ). Which is not
>  completely sure (as Martin Hun?k noted a few messages ago).
>  - Second, right now the NCC is just handing out /22 to whoever can pay
>  for them (with only a small extra administrative restriction during the
>  last 6 months). For me this is plain "selling IP addresses" (concept
>  that the NCC avoided like hell int the past), and it is also defeating
>  the "keep space for later entrants" purpose. No need check (as in "do
>  you really need that space" *), no requirement to deploy IPv6 of any
>  kind, just a simple "pay to have it".
>

This could be solved without introducing yet another way to deplete the
remaining pool.

The problem with 2015-05, is its similarity to how certain acts of Congress
in the US come to pass:

You bundle what you want with something else, to sweeten the deal.

So here is how you can fix the deadlock:

Unbundle. Split the proposal in two parts.

Part A: Additional requirements for IPv4 allocations

Part B: Additional periodical IPv4 allocations for existing LIRs

This would, for instance, make it easy for me to say "yes" to part A, and
"no" to part B, instead of "no" to the entire package.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/87d1c326/attachment.html>

From jim at rfc1035.com  Tue May 10 15:14:09 2016
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 10 May 2016 14:14:09 +0100
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
	2015-05
In-Reply-To: <20160510121614.GL14871@gir.theapt.org>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <20160510121614.GL14871@gir.theapt.org>
Message-ID: <65AD6AEC-2A3B-4EC1-BED0-9870E5B68ED4@rfc1035.com>


> On 10 May 2016, at 13:16, Peter Hessler <phessler at theapt.org> wrote:
> 
> This was called "Provider Independent"

No it wasn?t. RIPE NCC has never sold IP addresses of any sort.

LIRs pay membership fees to the NCC. In return they get certain services. One of those services is allocation of globally unique numbering resources.




From mike.oghia at gmail.com  Tue May 10 15:27:13 2016
From: mike.oghia at gmail.com (Michael Oghia)
Date: Tue, 10 May 2016 16:27:13 +0300
Subject: [address-policy-wg] agreement
In-Reply-To: <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
Message-ID: <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>

Hi all,

I have been following the discussion and I strongly support Jan's
suggestion, especially since the bulk of the contention seems to be with
what Jan describes as Part B. Does anyone know if it is possible to split
the proposal into two parts?

Best,
-Michael
__________________

Michael J. Oghia
Istanbul, Turkey
Journalist & editor
2015 ISOC IGF Ambassador
Skype: mikeoghia
Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn
<https://www.linkedin.com/in/mikeoghia>

On Tue, May 10, 2016 at 3:53 PM, Jan Ingvoldstad <frettled at gmail.com> wrote:

> On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN <
> ripe-wgs at radu-adrian.feurdean.net> wrote:
>
>> Hi,
>>
>> On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
>> > Indeed. It all comes down to "the needs of those in the next few years
>> > with no IPv4 addresses" vs "those today who have only one /22".
>>
>> I find the situation a little more complex than that:
>>  - First, the "in a few years with no IPv4" is not so far away. Even
>>  with current policy, it is for 2020, with a lot of chance 2021. With
>>  the proposal, worst case scenario is that we MAY loose up to 18 months
>>  (more likely something in the 6-12 months range ). Which is not
>>  completely sure (as Martin Hun?k noted a few messages ago).
>>  - Second, right now the NCC is just handing out /22 to whoever can pay
>>  for them (with only a small extra administrative restriction during the
>>  last 6 months). For me this is plain "selling IP addresses" (concept
>>  that the NCC avoided like hell int the past), and it is also defeating
>>  the "keep space for later entrants" purpose. No need check (as in "do
>>  you really need that space" *), no requirement to deploy IPv6 of any
>>  kind, just a simple "pay to have it".
>>
>
> This could be solved without introducing yet another way to deplete the
> remaining pool.
>
> The problem with 2015-05, is its similarity to how certain acts of
> Congress in the US come to pass:
>
> You bundle what you want with something else, to sweeten the deal.
>
> So here is how you can fix the deadlock:
>
> Unbundle. Split the proposal in two parts.
>
> Part A: Additional requirements for IPv4 allocations
>
> Part B: Additional periodical IPv4 allocations for existing LIRs
>
> This would, for instance, make it easy for me to say "yes" to part A, and
> "no" to part B, instead of "no" to the entire package.
> --
> Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/72f02b6a/attachment.html>

From ripe-wgs.cs at schiefner.de  Tue May 10 15:44:21 2016
From: ripe-wgs.cs at schiefner.de (Carsten Schiefner)
Date: Tue, 10 May 2016 15:44:21 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
Message-ID: <833e5e96-3641-b838-76c3-4f5175ce3077@schiefner.de>

Hi Aled,

On 10.05.2016 14:12, Aled Morris wrote:
> I am troubled by the new members joining RIPE purely to obtain IPv4
> address space.
> 
> Perhaps (shields up!)

that might in fact be a good idea, yes... ;-)

> RIPE could simply offer /22 for purchase at the
> same price as membership (?3,400 i.e. joining fee + 1 year subs) to
> anyone who wants one since they can get one anyway by joining.
> 
> It would save the admin overheads and would identify members as those
> actually committed to performing as LIRs.

This would actually be PI space then.

Apart from this, I'd rather like to have them *WITHIN* the RIPE NCC as a
legal entity under Dutch law than somewhere *OUTSIDE*, free floating
around and at best only loosely coupled to the RIPE NCC by some T&Cs.

My $0.02 - best

	-C.



From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 16:31:58 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 16:31:58 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160510061519.GB16361@enforcer.ledeuns.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <CAGpkpTP3rq5auwXkLrQ-pzp5uGiWuRj+JSX4_jEHN9h6TX+G3g@mail.gmail.com>
 <20160509190722.GA11334@mail.webmonster.de>
 <027a01d1aa57$f6388170$e2a98450$@parsun.com>
 <20160510061519.GB16361@enforcer.ledeuns.net>
Message-ID: <1462890718.1164976.603553625.262421C5@webmail.messagingengine.com>


On Tue, May 10, 2016, at 08:15, Denis Fondras wrote:

> Why wouldn't a LIR get some space on the secondary market to provide to
> its customers ?

Because: 
 - for a small LIR it's still too expensive (usual quote is 11-13 USD/IP
 for /22 to /24)
 - there is some risk of "bad quality IPs" (blacklists, bad reputation,
 bad and slow-to-update geoloc data)
 - missing business procedures/confidence (issue of using escrow account
 does not help)

> Some are taking advantages of this situation (open multiple LIR) to get IPv4
> space. I don't see how 2015-05 would stop that even if you allow new LIR to get
> more than a /22. All I can see it more faster depletion (honest LIR getting
> more + dishonest LIR getting more)

It will not stop dishonest ones. May checking the actual need may slow
them down a little bit, but that is not sure either.
However, the honest ones will not have to use the same practices that
they already consider "cheating".

> I hear your arguments but I don't think 2015-05 is the right answer for the
> community.

If you have any ideas, you're welcome to share.

--
Radu-Adrian FEURDEAN
fr.ccs



From niall.oreilly at ucd.ie  Tue May 10 16:39:59 2016
From: niall.oreilly at ucd.ie (Niall O'Reilly)
Date: Tue, 10 May 2016 15:39:59 +0100
Subject: [address-policy-wg] agreement
In-Reply-To: <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
 <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
Message-ID: <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>

On 10 May 2016, at 14:27, Michael Oghia wrote:

> Hi all,
>
> I have been following the discussion and I strongly support Jan's
> suggestion, especially since the bulk of the contention seems to be with
> what Jan describes as Part B. Does anyone know if it is possible to split
> the proposal into two parts?

  Yes.

  If it were my proposal, here's how I would go about it.

  Withdraw the current proposal.
  The proposer can always do this during the process.

  Introduce two new proposals (2016-somenumber and 2016-someothernumber)
  respectively containing the "Part A" and "Part B" material from the
  current proposal.

  There may be other ways of doing it, but this seems simple and effective.

  Best regards,

  Niall O'Reilly



From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 16:40:03 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 16:40:03 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
Message-ID: <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>

On Tue, May 10, 2016, at 14:12, Aled Morris wrote:
> I am troubled by the new members joining RIPE purely to obtain IPv4
> address space.
> 
> Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
> price as membership (?3,400 i.e. joining fee + 1 year subs) to anyone who
> wants one since they can get one anyway by joining.
> 
> It would save the admin overheads and would identify members as those
> actually committed to performing as LIRs.

Great idea !
I would actually like to have NCC's opinion on that one.  
For now, I have the impression that the administrative overhead is just
a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses".

--
Radu-Adrian FEURDEAN
fr.ccs



From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 16:46:15 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 16:46:15 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <20160510121614.GL14871@gir.theapt.org>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <20160510121614.GL14871@gir.theapt.org>
Message-ID: <1462891575.1168275.603581673.35C66B74@webmail.messagingengine.com>

On Tue, May 10, 2016, at 14:16, Peter Hessler wrote:
> This was called "Provider Independent" and for IPv4, it was killed off
> some years ago.

Yes, except that the need for "provider independent" IP blocks did not
disappear. Only the "ASSIGNED PI" status for new blocks did. The
"ALLOCATED PA" is a good enough substitute for those needing it.
Then there's still the "multihome with ASSIGNED PA phenomenon" and the
"don't need multihoming, just a /24" (actually anything from /23 to /26
may qualify). For the second one, if done by the LIR it may actually
decrease the depletion rate (saving months lost with extra allocations). 

--
Radu-Adrian FEURDEAN
fr.ccs



From mike.oghia at gmail.com  Tue May 10 16:54:30 2016
From: mike.oghia at gmail.com (Michael Oghia)
Date: Tue, 10 May 2016 17:54:30 +0300
Subject: [address-policy-wg] agreement
In-Reply-To: <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
 <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
 <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
Message-ID: <CAMCMt7oFb_SgtwNNoG-v9=2fhu-at=Q_PcNpP+8GS_QjJiWsnA@mail.gmail.com>

Hi all,

Thank you for clarifying Niall. I suggest then that the original proposer
weigh into this process with his/her suggestions on going forward and
potentially incorporating this recommendation to split the proposal into
two parts.

Best,
-Michael
__________________

Michael J. Oghia
Istanbul, Turkey
Journalist & editor
2015 ISOC IGF Ambassador
Skype: mikeoghia
Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn
<https://www.linkedin.com/in/mikeoghia>

On Tue, May 10, 2016 at 5:39 PM, Niall O'Reilly <niall.oreilly at ucd.ie>
wrote:

> On 10 May 2016, at 14:27, Michael Oghia wrote:
>
> > Hi all,
> >
> > I have been following the discussion and I strongly support Jan's
> > suggestion, especially since the bulk of the contention seems to be with
> > what Jan describes as Part B. Does anyone know if it is possible to split
> > the proposal into two parts?
>
>   Yes.
>
>   If it were my proposal, here's how I would go about it.
>
>   Withdraw the current proposal.
>   The proposer can always do this during the process.
>
>   Introduce two new proposals (2016-somenumber and 2016-someothernumber)
>   respectively containing the "Part A" and "Part B" material from the
>   current proposal.
>
>   There may be other ways of doing it, but this seems simple and effective.
>
>   Best regards,
>
>   Niall O'Reilly
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/082719f7/attachment.html>

From gert at space.net  Tue May 10 17:16:43 2016
From: gert at space.net (Gert Doering)
Date: Tue, 10 May 2016 17:16:43 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
Message-ID: <20160510151643.GM3978@Space.Net>

Hi,

On Tue, May 10, 2016 at 04:40:03PM +0200, Radu-Adrian FEURDEAN wrote:
> On Tue, May 10, 2016, at 14:12, Aled Morris wrote:
> > I am troubled by the new members joining RIPE purely to obtain IPv4
> > address space.
> > 
> > Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
> > price as membership (???3,400 i.e. joining fee + 1 year subs) to anyone who
> > wants one since they can get one anyway by joining.
> > 
> > It would save the admin overheads and would identify members as those
> > actually committed to performing as LIRs.
> 
> Great idea !
> I would actually like to have NCC's opinion on that one.  
> For now, I have the impression that the administrative overhead is just
> a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses".

This is a horrible idea, tbh.

The RIPE NCC is a *membership* organization, so "sell off stuff" is totally 
not in line with the NCC's mission of providing numbers to members.

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/61d4530d/attachment.sig>

From jerome at ceriz.fr  Tue May 10 17:17:00 2016
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Tue, 10 May 2016 17:17:00 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
Message-ID: <5731FB6C.8090008@ceriz.fr>

Hi Radu,

Le 10/05/2016 16:40, Radu-Adrian FEURDEAN a ?crit :
> For now, I have the impression that the administrative overhead is just
> a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses".

IP adresses cannot be sold, it's public domain.

What's beeing sold is a service to ensure uniqueness and a well
maintained registry. One-time fees won't cover that.

Whenever we decide to put a facial value onto adress blocks, we'd get in
a slipery slope leading to the demise of innovation and competitive
telecom market (re-read the taxi licence analogy). And it sure won't
help to deploy IPv6 anyway, because incumbents will then be urged to
slow its deployment in order to preserve their (now valued) advantage.

Best regards,

-- 
J?r?me Nicolle



From aled.w.morris at googlemail.com  Tue May 10 17:25:08 2016
From: aled.w.morris at googlemail.com (Aled Morris)
Date: Tue, 10 May 2016 16:25:08 +0100
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
	2015-05
In-Reply-To: <5731FB6C.8090008@ceriz.fr>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
 <5731FB6C.8090008@ceriz.fr>
Message-ID: <CAO1bj=bJfkABQJdYyRSA0FFnC0NFOfiz31_QC6ztp_6_9ZbNqQ@mail.gmail.com>

On 10 May 2016 at 16:17, J?r?me Nicolle <jerome at ceriz.fr> wrote:

> What's beeing sold is a service to ensure uniqueness and a well
> maintained registry. One-time fees won't cover that.
>

My bad, I should have said RIPE could "licence" or "mark as registered" the
/22 address block not "sell".

There is a recurring fee for PI space which I would assume would apply in
this case, and the company obtaining the /22 would also have to find a
sponsor LIR for their assignment.

But again, I'm not necessarily advocating this, just pointing out that
having a growing number of "fake" members, especially ones who do not share
in any way with the ideals and goals of RIPE, could be bad for RIPE as an
organisation in the long term.

Aled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/096e6715/attachment.html>

From gert at space.net  Tue May 10 17:42:57 2016
From: gert at space.net (Gert Doering)
Date: Tue, 10 May 2016 17:42:57 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAO1bj=bJfkABQJdYyRSA0FFnC0NFOfiz31_QC6ztp_6_9ZbNqQ@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
 <5731FB6C.8090008@ceriz.fr>
 <CAO1bj=bJfkABQJdYyRSA0FFnC0NFOfiz31_QC6ztp_6_9ZbNqQ@mail.gmail.com>
Message-ID: <20160510154257.GN3978@Space.Net>

Hi,

On Tue, May 10, 2016 at 04:25:08PM +0100, Aled Morris wrote:
> There is a recurring fee for PI space which I would assume would apply in
> this case, and the company obtaining the /22 would also have to find a
> sponsor LIR for their assignment.

Basically this would be "PI", which got removed from the last /8 policy
for a reason (and trying to bring it back did not even come near to
any sort of consensus on who should be allowed to have some and who not).

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/387aea79/attachment.sig>

From tom.hill at bytemark.co.uk  Tue May 10 17:51:23 2016
From: tom.hill at bytemark.co.uk (Tom Hill)
Date: Tue, 10 May 2016 16:51:23 +0100
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
Message-ID: <5732037B.3050409@bytemark.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/05/16 13:12, Aled Morris wrote:
> I am troubled by the new members joining RIPE purely to obtain
> IPv4 address space.

I've still never seen any figures to support this, and thus it sounds
like FUD to justify some sort of IPv4 ransacking policy each and every
time I hear it.

Are there any figures to back up the assertion that "crooks" are
eating away at 185/8? I don't think I've ever seen any concrete
evidence of a widespread problem as yet.

It occurs to me that there will always be bad actors as long as we
desire the freedom to be able to acquire companies with Memberships
and pay only one set of Membership fees. I'm not actually sure if
abuse of this system should a problem for the RIPE community, the RIPE
NCC, or indeed a problem for the relevant authorities to investigate
(i.e. fraud).

Despite the possibility for abuse, I so far remain convinced that it's
worth keeping 185/8 as a reserved range for new entrants, and indeed
keeping any address space returned from the IANA for as long as we can
to - hopefully - help continue that policy long into the future.

There's nothing in 2015-05 that I find agreeable in this context,
particularly if we discount the assertion that abuse of the /8 policy
is harming depletion in a meaningful fashion.


(P.S. Not to point fingers at you directly, Aled; you're just the last
person to mention it in the thread before it changed direction.)

- -- 
Tom Hill
Network Engineer

Bytemark Hosting
http://www.bytemark.co.uk/
tel. +44 1904 890 890
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXMgN7AAoJEH2fKbrp2sQ6vPAIANOay9s+6KIDi8Tb0fhFedXe
5VcBB10PF9r49jSAcidwKSQ5bJJbqJd/VzIrZMnevPNQw8FZfX+xOlpsebMx4Ezt
bfxzGJTO5JZ/ghc4PtCDbvj317dVy6rCftciylpmzHfMEzzpHHC1323NyWHf9/Hp
1EN2Hdjtsz+BVMGHOPfKHIpOAzyeCdXQ1e7HBsGKDhStzM0ygJrXtwBib3BiApc8
KNwyJFGY8Wb39Llb9w5PypXb5L51W71Or6kApcZvhkmTuo25aVS5Tvg/F5eIJ042
EEDdzgkLvN04jJdSZdYNW3VavoPQ1MGx+gtith6JF0YxlKkom2Wccb+QSgh/wcI=
=7Yd2
-----END PGP SIGNATURE-----



From tore at fud.no  Tue May 10 17:56:45 2016
From: tore at fud.no (Tore Anderson)
Date: Tue, 10 May 2016 17:56:45 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
Message-ID: <20160510175645.17fd467f@envy.e5.y.home>

* Radu-Adrian FEURDEAN

> - Second, right now the NCC is just handing out /22 to whoever can
> pay for them (with only a small extra administrative restriction
> during the last 6 months). For me this is plain "selling IP
> addresses" (concept that the NCC avoided like hell int the past), and
> it is also defeating the "keep space for later entrants" purpose. No
> need check (as in "do you really need that space" *), no requirement
> to deploy IPv6 of any kind, just a simple "pay to have it".

Time for a history lesson...

It has been true for a very long time, certainly for much longer than
the last /8 policy has been around, that new members (LIRs) have been
pretty much guaranteed to receive an minimum-sized IPv4 allocation.

The requester needed to be a member with assignments to make. That's
pretty much all there was to it. The logic: If a new LIR is about to
make >0 IPv4 assigments (sized >0 in total), then that LIR obviously
is in need of an IPv4 allocation sized >0, thus automatically
qualifying for a /n. (/n is the minimum allocation size at the time of
the request. Prior to the activation of the ?last /8? policy it was
a /21, while today it is a /22.)

If you read ripe-649 closely you'll see that the above holds true
today: New LIRs with assignments to make get a minimum-sized IPv4
allocation.

So this part of the policy hasn't really changed. It might seem like
it, but in reality it is because two avenues that previously allowed
end users to obtain IPv4 space in a far easier way than "become an LIR"
is or ever was have been closed - thus making the "become an LIR" avenue
increase in popularity:

1) Receiving PA assignments from an LIR/ISP. Before IPv4 was running
out, there was no incentive for an LIR/ISP to not give an end user all
the space he needed; the LIR/ISP could easily cover such "loss" with
additional allocations from the NCC. That's no longer the case, so
LIR/ISPs that aren't completely out of free IPv4 space have every
reason to be very conservative about making PA assigments, e.g., by
reserving them for the highest-value customers.

2) Receiving PI assignments via a sponsoring LIR/ISP or directly from
the NCC. The ?last /8? policy killed off IPv4 PI, except for IXP and
temporary use.

In summary: if one starts out by equating "accepting new paying members"
with "selling IP addresses", then the RIPE NCC has been seeling IP
addresses since its inception. It's not a new thing at all. (It's not
limited to IPv4 either, by the way: Any new member joining today gets
to pick up a "complimentary" IPv6 /29 welcome gift.)

What is new, though, is that we're essentially out of IPv4. This has
caused the community to sacrifice the previous convenient and cheap
avenues of obtaining voluminous IPv4 delegations for the sake of
conservation. Even though this obviously cannot stave off full and utter
depletion indefinitely, I believe it is the right thing to do for the
sake of new entrants joining the community in the years to come. I do
not support 2015-05 because to me it represents a reversal of this
course.

Tore



From jerome at ceriz.fr  Tue May 10 18:17:49 2016
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Tue, 10 May 2016 18:17:49 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <5732037B.3050409@bytemark.co.uk>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <5732037B.3050409@bytemark.co.uk>
Message-ID: <573209AD.9060804@ceriz.fr>

Hello Tom,

Le 10/05/2016 17:51, Tom Hill a ?crit :
> Are there any figures to back up the assertion that "crooks" are
> eating away at 185/8? I don't think I've ever seen any concrete
> evidence of a widespread problem as yet.

Did you recently got an inetnum ? Nowadays, the minute you get a block,
you get 10 free e-mails asking to lease a /24 out of it.

When your business is growing and your network is running off address
space' vapors, you're looking out for any oportunity to recover unused
adresses (really easy to do when you only got a mere /22 : usually
none). Then turn to the "Transfer (Blackmarket) Listing Service" and get
indecent (side) offers for newly assigned prefixes put up for rent.

I don't need numbers to see there's something wrong : a market for
adress space must NOT exist. The listing service must be dismantled, and
no one should be able to profit from wrongly privatised public domain,
period.

Unused inetnums must return to pool, and LIR's able to justify their
needs _periodicaly_ should be able to get some more juice off the
available pool, if they're also contributing to getting us all out of
this mess by actively promoting IPv6.

Or am I a bit too commie for this discussion ?

-- 
J?r?me Nicolle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/b5ce00c3/attachment.sig>

From gert at space.net  Tue May 10 18:22:57 2016
From: gert at space.net (Gert Doering)
Date: Tue, 10 May 2016 18:22:57 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <573209AD.9060804@ceriz.fr>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <5732037B.3050409@bytemark.co.uk> <573209AD.9060804@ceriz.fr>
Message-ID: <20160510162257.GT3978@Space.Net>

Hi,

On Tue, May 10, 2016 at 06:17:49PM +0200, J?r?me Nicolle wrote:
> When your business is growing and your network is running off address
> space' vapors, you're looking out for any oportunity to recover unused
> adresses (really easy to do when you only got a mere /22 : usually
> none). Then turn to the "Transfer (Blackmarket) Listing Service" and get
> indecent (side) offers for newly assigned prefixes put up for rent.
> 
> I don't need numbers to see there's something wrong : a market for
> adress space must NOT exist. The listing service must be dismantled, and
> no one should be able to profit from wrongly privatised public domain,
> period.
> 
> Unused inetnums must return to pool, and LIR's able to justify their
> needs _periodicaly_ should be able to get some more juice off the
> available pool, if they're also contributing to getting us all out of
> this mess by actively promoting IPv6.
> 
> Or am I a bit too commie for this discussion ?

Bring up a workable proposal to ensure that this can be done, and we'll
discuss it.  Emphasis on *workable*, ensuring that people will not be
able to just ignore the results and revert to lying to the NCC.

So far, pragmatism led to the acceptance of a market *provided* people
will update the registry information (so it is not a *black* market) - which
is vastly better for the overall system than "look, I have this unused /16, 
do you want to rent it for $vastsums, but do not tell anybody!".

As long as money can be made out of IPv4 space (read: people are going to
pay for it), it will be made.

If you all go to IPv6, IPv4 space will totally lose its value.  Just sayin'

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160510/cd78dfc0/attachment.sig>

From tom.hill at bytemark.co.uk  Tue May 10 18:40:50 2016
From: tom.hill at bytemark.co.uk (Tom Hill)
Date: Tue, 10 May 2016 17:40:50 +0100
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <573209AD.9060804@ceriz.fr>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <5732037B.3050409@bytemark.co.uk> <573209AD.9060804@ceriz.fr>
Message-ID: <57320F12.6000504@bytemark.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/05/16 17:17, J?r?me Nicolle wrote:
> Did you recently got an inetnum ? Nowadays, the minute you get a
> block, you get 10 free e-mails asking to lease a /24 out of it.

This is not the same problem that I was referring to?

It so happens that what you're referencing is also completely
irrelevant to 2015-05, or the IPv4 austerity procedure; you can
happily ignore any business offering to lease your IPs, and even if
you accepted their offer, the IP space would still not be not
allocated to those persons indefinitely.

- -- 
Tom Hill
Network Engineer

Bytemark Hosting
http://www.bytemark.co.uk/
tel. +44 1904 890 890
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXMg8SAAoJEH2fKbrp2sQ6diUH/0oibUrH0EyCaoAm2AXz/GkU
XWI627oXQbDuOk6IdxHLgzAELuRpQoNS9AjebGFpJZ3nnv+iuxXuuHF8i/Jnt5pr
pjP9Q63bgEHuBX689kAXEwP6KgnMw4rnh3ivCHTOj63JHTJ1YFPGj2ZxPo1FNQMQ
d1rdicWUpaWsdm4xKeALjuUEPFK1kZrZb+hjRCgjrjGnr84htzufOn0gOS//Mswm
EuFi3kAmqqaoYQcOzIsmIod+YOUhah1+arsSFsdh1LM8b1cyuh/o8CTpg+gURAyh
VkAlcBpOUOEJR+ePEE+2LuxWqgWOtMgoHwa+UW2whOtjTcdC84lF3XXRwqHG6oo=
=keoH
-----END PGP SIGNATURE-----



From ripe-wgs at radu-adrian.feurdean.net  Tue May 10 21:40:53 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 10 May 2016 21:40:53 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <5731FB6C.8090008@ceriz.fr>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
 <5731FB6C.8090008@ceriz.fr>
Message-ID: <1462909253.652142.603892993.37592841@webmail.messagingengine.com>

On Tue, May 10, 2016, at 17:17, J?r?me Nicolle wrote:
> Hi Radu,
> 
> Le 10/05/2016 16:40, Radu-Adrian FEURDEAN a ?crit :
> > For now, I have the impression that the administrative overhead is just
> > a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses".
> 
> IP adresses cannot be sold, it's public domain.
> 
> What's beeing sold is a service to ensure uniqueness and a well
> maintained registry. One-time fees won't cover that.

Jerome,

The problem is the "multiple LIR accounts per member". Of course, it
does arrange some members' business, but it still sounds like "purchase
parts in an investment fund".
OK, that situation is suspended since november, but follow-up on 27/05
(voting results).

One of the ideas behind 2015-05 was to calm down the need for such
practice. Some people do not agree, and some may start considering the
"extra LIR" option as normal.

Not to mention that some people simply do not agree with that and make a
more than decent living out of it.

> Whenever we decide to put a facial value onto adress blocks, we'd get in
> a slipery slope leading to the demise of innovation and competitive
> telecom market (re-read the taxi licence analogy). And it sure won't

Unfortunately we're already on the slippery slope. How far, check here :
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/ipv4/ipv4-transfer-statistics
.

--
Radu-Adrian FEURDEAN
fr.ccs



From swmike at swm.pp.se  Wed May 11 07:14:54 2016
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 11 May 2016 07:14:54 +0200 (CEST)
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <029001d1aa5a$966deca0$c349c5e0$@parsun.com>
References: <570F9005.4090008@ripe.net> <20160414125115.GC25856@gir.theapt.org>
 <CAO1bj=ZqbMaxO9Hv9MfKvuDjWs943oVxsw9owV6omRPtHsdKcA@mail.gmail.com>
 <A96A4B58-076D-46F4-8425-05B4D09EBF94@rfc1035.com>
 <A2665200-1D6D-4CEB-963F-C69ADE1A048F@ucd.ie>
 <20160415065121.12e36e72@echo.ms.redpill-linpro.com>
 <alpine.DEB.2.02.1604150944500.16013@uplift.swm.pp.se>
 <029001d1aa5a$966deca0$c349c5e0$@parsun.com>
Message-ID: <alpine.DEB.2.02.1605110714060.7599@uplift.swm.pp.se>

On Tue, 10 May 2016, Arash Naderpour wrote:

> Hi Mikael,
>
> The last /8 is not really get affected by this policy,
>
> - Additional /22 IPv4 allocations can be only provided from address space
> outside 185/8
>
> Is it the only reason of your objection to this policy?

No. When I said last-/8 I meant addresses available to be handed out to 
new entrants.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se



From rgori at wirem.net  Wed May 11 07:50:34 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Wed, 11 May 2016 07:50:34 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <089501d1aa8c$201b52e0$6051f8a0$@tsnet.it>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <15b3b1e4-1fe1-6823-fddb-7f1d550573af@wirem.net>
 <089501d1aa8c$201b52e0$6051f8a0$@tsnet.it>
Message-ID: <80a4b9d8-7422-e114-4585-dab4007e3528@wirem.net>

Goodmorning Enrico,

thank you for your opinion

Il 10/05/2016 09:18, Enrico Diacci ha scritto:
>
> Hi Riccardo,
>
> This policy is so good in 2 main things:
> - address the problem of customers make the customers giving new 
> entrants a little bit more space to handle their grow and customer 
> acquisition
> - incentive the use IPv6. Again this is the ONLY policy that advice 
> LIRs to use IPv6 actually
>
> mainly the second one in my opinion is the important thing: if a LIR 
> wants take advantage of this proposal it MUST demonstrate having 
> deployed IPv6 in its network.
>
> We could also make stronger this idea of really using IPv6 requesting 
> 4 (or 5 now) stars of RIPEness.
>
> So this may be considered such a prize to really do effort in 
> implementing IPv6 (and in Italy we know how we must facilitate it, 
> with less than 0,5% of adoption).
>
I think higher the prerequisites wouldn't be a problem
The problem is that he is against the proposal is very interested in 
saving IPv4 space instead of start thinking that incentiving IPv6 could 
be a solution to slow down the allocation rate.
I think for most people is a matter of money: no more IPv4 no value in 
it. With IPv6 deployed and available no problem with IPv4 exhaustion.
>
> Regards,
>
> Enrico Diacci.
>
> it.tsnet
>

kind regards
Riccardo Gori
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/ec868b12/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/ec868b12/attachment.jpg>

From rgori at wirem.net  Wed May 11 07:51:21 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Wed, 11 May 2016 07:51:21 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
Message-ID: <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>

Hi Sander, Hi Peter,

Il 09/05/2016 14:50, Sander Steffann ha scritto:
> Hi Peter,
>
>> My main objection to this proposal is simple:  It depletes the available
>> pool for _new_ participants faster.  I strongly believe any new actor
>> should be able to go from zero to non-zero with the addresses available
>> from RIPE.  For an actor with non-zero addresses to get more addresses,
>> there is a secondary market.
> Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
What about those holding large space and changed the policy to be 
triggered when reaced a last /8 and not before?
Looks like eating the chocolate top cover of the cake and leave the dry 
part to the others. Here's your crumbs we are very respective.
>
>> Since that is the base of my objection, I do not see any way that a
>> middle ground can be met.  Based on my understanding of the other
>> objections, I believe this is held by at least a few others from the
>> objection side.
> Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem.

>
> I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC?s IPv4 pool was expected to last for around five years.".
>
>> I appreciate the effort put into this proposal, but I do not think any
>> solution can be proposed.
> The stated expected timescale already seems to be around the bare minimum lifetime that is accepted, and much less than what many people would like. I therefore have to agree that any proposal that shortens that lifetime even further will very probably not get consensus.
>
> Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this discussion to read the mailing list archives so they can get the full current picture before they propose a solution.
>
> Cheers,
> Sander

This policy is a real way to slow down a little bit the allocation rate 
for the reasons above stated.
In total there are about 13700 LIRs about 9.05 millions addresses of 
185/8 have been allocated since 2012

Otherwise is possible to change completly the way the unused space is 
handled. Why don't place a pay per use?
I think we would see a lot of transfert take place and allocation rate 
will magically slow down


regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/cd9d379e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/cd9d379e/attachment.jpg>

From gert at space.net  Wed May 11 08:53:28 2016
From: gert at space.net (Gert Doering)
Date: Wed, 11 May 2016 08:53:28 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
Message-ID: <20160511065328.GW3978@Space.Net>

Hi,

On Wed, May 11, 2016 at 07:51:21AM +0200, Riccardo Gori wrote:
> > Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
> What about those holding large space and changed the policy to be 
> triggered when reaced a last /8 and not before?
> Looks like eating the chocolate top cover of the cake and leave the dry 
> part to the others. Here's your crumbs we are very respective.

Would you have preferred the ARIN way?  "Oops, we have reached exhaustion,
nothing left, good buy to new entrants"?

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/82b6187b/attachment.sig>

From rogerj at gmail.com  Wed May 11 09:02:33 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Wed, 11 May 2016 09:02:33 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m21t5ahel6.wl%randy@psg.com>
References: <570F9005.4090008@ripe.net> <m2r3e8umr6.wl%randy@psg.com>
 <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
 <m21t5ahel6.wl%randy@psg.com>
Message-ID: <CAKFn1SFqXjkXnY5ScLUXeLCPfKmBXVBCspLQ2RyPp6Sv=vZ7Vw@mail.gmail.com>

On Tue, May 10, 2016 at 3:44 AM, Randy Bush <randy at psg.com> wrote:
> you may find reading the actual last /8 policy informative.
>
>> Last /8 is not really get affected by this policy.
>> - Additional /22 IPv4 allocations can be only provided from address space
>>   outside 185/8
>
> this is misleading or just sadly misinformed
>
> last /8 is not an address range, it is a state reached once the ncc had
> only that address range and continues on irrespective of additions or
> subtractions of space to the ncc's pool.

minor correction, it is a state that was reached once IANA allocated the
last /8 to all the RIR's, and it affect _all_ address space after that point.



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no



From rgori at wirem.net  Wed May 11 09:22:50 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Wed, 11 May 2016 09:22:50 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SFqXjkXnY5ScLUXeLCPfKmBXVBCspLQ2RyPp6Sv=vZ7Vw@mail.gmail.com>
References: <570F9005.4090008@ripe.net> <m2r3e8umr6.wl%randy@psg.com>
 <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com> <m21t5ahel6.wl%randy@psg.com>
 <CAKFn1SFqXjkXnY5ScLUXeLCPfKmBXVBCspLQ2RyPp6Sv=vZ7Vw@mail.gmail.com>
Message-ID: <a7ac8eb9-8d3b-cd7c-10e4-1cee7e458ea3@wirem.net>


Il 11/05/2016 09:02, Roger J?rgensen ha scritto:
> On Tue, May 10, 2016 at 3:44 AM, Randy Bush <randy at psg.com> wrote:
>> you may find reading the actual last /8 policy informative.
>>
>>> Last /8 is not really get affected by this policy.
>>> - Additional /22 IPv4 allocations can be only provided from address space
>>>    outside 185/8
>> this is misleading or just sadly misinformed
>>
>> last /8 is not an address range, it is a state reached once the ncc had
>> only that address range and continues on irrespective of additions or
>> subtractions of space to the ncc's pool.
> minor correction, it is a state that was reached once IANA allocated the
> last /8 to all the RIR's, and it affect _all_ address space after that point.
>
>
>
If I am not wrong standing on the information collected on this list the 
new allocation criteria was triggered when first allocation from 185/8 
has been made.

Please see Ingrid Wijte email 20/04/2016 to the list
[...]
The RIPE NCC started to allocate from 185/8 on 14 September 2012, when 
we could no longer satisfy a request for address space without touching 
185/8. That moment triggered section 5.1 that states that RIPE NCC 
members can request a one time /22 allocation (1,024 IPv4 addresses).
[...]

My understanding is that the policy was already there but the community 
(we) at that date considered fair end up the good part of cake before 
triggering the new rule
Rumors says that there are a lot of suspicius allocation done just one 
or two weeks before triggering the "last /8"

regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/f4582954/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/f4582954/attachment.jpg>

From rogerj at gmail.com  Wed May 11 09:32:45 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Wed, 11 May 2016 09:32:45 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <a7ac8eb9-8d3b-cd7c-10e4-1cee7e458ea3@wirem.net>
References: <570F9005.4090008@ripe.net> <m2r3e8umr6.wl%randy@psg.com>
 <02a001d1aa5c$99966ae0$ccc340a0$@parsun.com>
 <m21t5ahel6.wl%randy@psg.com>
 <CAKFn1SFqXjkXnY5ScLUXeLCPfKmBXVBCspLQ2RyPp6Sv=vZ7Vw@mail.gmail.com>
 <a7ac8eb9-8d3b-cd7c-10e4-1cee7e458ea3@wirem.net>
Message-ID: <CAKFn1SEst6r02ATsBKvdZVE2vOqOgKHVtyYVSJMhBuAfHDDc8g@mail.gmail.com>

On Wed, May 11, 2016 at 9:22 AM, Riccardo Gori <rgori at wirem.net> wrote:

>
> Il 11/05/2016 09:02, Roger J?rgensen ha scritto:
>
> <snip>
>
> minor correction, it is a state that was reached once IANA allocated the
> last /8 to all the RIR's, and it affect _all_ address space after that point.
>
>
>
>
> If I am not wrong standing on the information collected on this list the
> new allocation criteria was triggered when first allocation from 185/8 has
> been made.
>
> Please see Ingrid Wijte email 20/04/2016 to the list
> [...]
> The RIPE NCC started to allocate from 185/8 on 14 September 2012, when we
> could no longer satisfy a request for address space without touching 185/8.
> That moment triggered section 5.1 that states that RIPE NCC members can
> request a one time /22 allocation (1,024 IPv4 addresses).
> [...]
>
>
... too early in the morning, you're right. My point was that it affect all
IPv4 addresses after that point in time, not just 185.




-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/55a11d99/attachment.html>

From remco.vanmook at gmail.com  Wed May 11 09:47:54 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Wed, 11 May 2016 09:47:54 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
Message-ID: <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>


Arash,



> On 10 May 2016, at 03:18 , Arash Naderpour <arash_mpc at parsun.com> wrote:
> 
> Remco, <>
> 
> Calling anyone supporting a policy delusional is not really helping the discussion we have here, you can still express your own opinion without using that.
> 

you can't have it both ways - entitle me to my opinion and at the same time saying I'm not allowed to voice it if you don't like it.
I stand by what I said, and I can't help being a bit surprised that it took you almost a month to respond to this part of my statement.

> 
> >>. I also object to the notion that new entrants who joined the game recently have any more entitlement than new entrants 2 years from now.
> 
> We have the same situation with the ?new-entrants? joined 2012 (before we reached to last /8) and the ones joined 2 years after that.
> 
> >>The final /8 policy in the RIPE region has been, in my opinion, a remarkable success because there's actually still space left to haggle about.
> 
> This new policy is not going to hand over any left available IP address in the pool out considering the conditions, 185/8 would be untouched.
> 

Again, you can't have it both ways. Current policy is not limited to 185/8, so your proposal does have an impact. Actually 185/8 is more than half gone by now (9571 allocations that I can see as of this morning) - effectively this means the proposal wants over half of what remains in the pool to get released to existing LIRs who've already received their last /22. This cuts the lifespan of the pool for new entrants by more than half, no?



Remco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/cccc8ae5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/cccc8ae5/attachment.sig>

From rgori at wirem.net  Wed May 11 09:53:06 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Wed, 11 May 2016 09:53:06 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160511065328.GW3978@Space.Net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
Message-ID: <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>

Hi Gert,

Il 11/05/2016 08:53, Gert Doering ha scritto:
> Hi,
>
> On Wed, May 11, 2016 at 07:51:21AM +0200, Riccardo Gori wrote:
>>> Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
>> What about those holding large space and changed the policy to be
>> triggered when reaced a last /8 and not before?
>> Looks like eating the chocolate top cover of the cake and leave the dry
>> part to the others. Here's your crumbs we are very respective.
> Would you have preferred the ARIN way?  "Oops, we have reached exhaustion,
> nothing left, good buy to new entrants"?
We can't say ARIN was wrong because actually did a better job in IPv6 
growth.
I am not saying there's the best way. Ways are thousand and 2015-05 
doesn't pretend to be the best policy ever.
Current allocation criteria obviously created discontent and was even 
abused generating quick selling of 185/8 just for profit.
Sander noticed there are people here that are confirming that a change 
is accepted and someone else noticed that 2015-05 can be re-written or 
re-invented to meet better the tasks
You as a chair should accept this and should help the community to 
understand how to follow up with a reasonable solution

>
> Gert Doering
>          -- NetMaster

regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/fb2e817a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/fb2e817a/attachment.jpg>

From jim at rfc1035.com  Wed May 11 10:04:32 2016
From: jim at rfc1035.com (Jim Reid)
Date: Wed, 11 May 2016 09:04:32 +0100
Subject: [address-policy-wg] making progress with 2015-05
In-Reply-To: <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
Message-ID: <9D481A5E-E43C-4814-885C-9591C9028ED7@rfc1035.com>


> On 11 May 2016, at 08:53, Riccardo Gori <rgori at wirem.net> wrote:
> 
> Sander noticed there are people here that are confirming that a change is accepted and someone else noticed that 2015-05 can be re-written or re-invented to meet better the tasks
> You as a chair should accept this and should help the community to understand how to follow up with a reasonable solution

The WG?s co-chairs have not expressed an opinion on this proposal. This is to be expected since they have to make the consensus determination if 2015-05 reaches that point.

Others have pointed out flaws and raised substantial objections. These issues have not been answered, let alone resolved.

Supporters of 2015-05 should accept this and should help the community to understand how to follow up with a reasonable solution.

We?re waiting.


PS: Apologies for a relevant and meaningful Subject: header.




From garry at nethinks.com  Wed May 11 10:14:57 2016
From: garry at nethinks.com (Garry Glendown)
Date: Wed, 11 May 2016 10:14:57 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
Message-ID: <868b6a7d-7822-3d97-c17b-01cbcc0bbf50@nethinks.com>

Hi,
>>> What about those holding large space and changed the policy to be 
>>> triggered when reaced a last /8 and not before?
>>> Looks like eating the chocolate top cover of the cake and leave the dry 
>>> part to the others. Here's your crumbs we are very respective.
>> Would you have preferred the ARIN way?  "Oops, we have reached exhaustion,
>> nothing left, good buy to new entrants"?
> We can't say ARIN was wrong because actually did a better job in IPv6
> growth.
Not sure if ARIN and it's (IMHO) failed IPv4 policy was the reason for
the better IPv6 growth, but any new entrant to the ISP market is paying
a hefty fee for it ... because even though the ARIN region may have a
higher IPv6 deployment, running and IPv6-only ISP business is out of the
question ... so companies have to go out and pay for an IPv4 block in
order to be able to do ANY business ... does that seem fair?

I reckon the only way to actually create a fair market would be to
either take away a percentage of assigned v4 addresses from ALL current
owners to redistribute to new entries to the market, or set a date for
disabling public v4 routing ... or maybe a third solution: Let all RIRs
take on the ARIN policy, do away with all remaining v4 addresses within
a couple days due to the incoming flood of requests, that way the price
for v4 transfers will skyrocket, making it necessary for existing v4
holders to finally implement v6, hopefully causing the v6 availability
to reach a tipping point quickly ...

I guess you will agree that neither of those solutions will be
implemented in the foreseeable future ... therefore, I agree with
sticking to the current v4 policies in an attempt to keep at least a
basic set of addresses available for new companies until the time that
public v4 has been deemed more or less irrelevant ... (hopefully, I'll
live to see the day ...)

-garry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/5f4ccf6f/attachment.html>

From ed at tsnet.it  Wed May 11 10:29:17 2016
From: ed at tsnet.it (Enrico Diacci)
Date: Wed, 11 May 2016 10:29:17 +0200
Subject: [address-policy-wg] R:  making progress with 2015-05
In-Reply-To: <9D481A5E-E43C-4814-885C-9591C9028ED7@rfc1035.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
 <9D481A5E-E43C-4814-885C-9591C9028ED7@rfc1035.com>
Message-ID: <0b7301d1ab5f$35cc7690$a16563b0$@tsnet.it>

I try to go beyond the 2015-05: 

When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6
may require an additional /22 (if you do not already have space equivalent
to a /20) stating its reasons for the new allocation with a project and
proving to have it completed within one year.

This new /22 will in no way be transferred before 3-5 years.

I tried to remove the term of 18 months: what do you think about?

Regards, Enrico Diacci.
it.tsnet


-----Messaggio originale-----
Da: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Per conto
di Jim Reid
Inviato: mercoled? 11 maggio 2016 10:05
A: Riccardo Gori
Cc: RIPE Address Policy WG
Oggetto: [address-policy-wg] making progress with 2015-05


> On 11 May 2016, at 08:53, Riccardo Gori <rgori at wirem.net> wrote:
> 
> Sander noticed there are people here that are confirming that a change 
> is accepted and someone else noticed that 2015-05 can be re-written or 
> re-invented to meet better the tasks You as a chair should accept this 
> and should help the community to understand how to follow up with a 
> reasonable solution

The WG?s co-chairs have not expressed an opinion on this proposal. This is
to be expected since they have to make the consensus determination if
2015-05 reaches that point.

Others have pointed out flaws and raised substantial objections. These
issues have not been answered, let alone resolved.

Supporters of 2015-05 should accept this and should help the community to
understand how to follow up with a reasonable solution.

We?re waiting.


PS: Apologies for a relevant and meaningful Subject: header.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6354 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/9ed5be26/attachment.p7s>

From mschmidt at ripe.net  Wed May 11 11:05:58 2016
From: mschmidt at ripe.net (Marco Schmidt)
Date: Wed, 11 May 2016 11:05:58 +0200
Subject: [address-policy-wg] Comment on IPv4 depletion rate for proposal
 2015-05
In-Reply-To: <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
References: <1513776.frbO9UE8Y6@rumburak>
 <CAKFn1SH4=mnxCxjjpXJPPvH2w+LswiVVsvUx-4X9eMa26DEuzA@mail.gmail.com>
 <573180F4.6040903@ceriz.fr>
 <CAO1bj=YkgL52mGKhnBVCkrdaaNxj_vGg-W6S7vyWw6vCAo_Qfw@mail.gmail.com>
 <1462891203.1166537.603577177.0AB0B709@webmail.messagingengine.com>
Message-ID: <5732F5F6.8030703@ripe.net>

Dear Radu-Adrian,

Thank you for your question.

To provide IPv4 address space to non-members would require a policy 
change, as current policies only allow the registration of IPv4 
allocations to LIRs and IPv4 assignments to IXPs.

However, RIPE policies cannot define fees for resource registration. 
Such fees are calculated by the RIPE NCC and approved by the membership. 
The basis for this calculation is the financial resources needed to 
provide the services described in the RIPE NCC Activity Plan and Budget.

I hope this clarifies your question.

Kind regards,
Marco Schmidt
Policy Development Officer

On 10/05/2016 16:40, Radu-Adrian FEURDEAN wrote:
> On Tue, May 10, 2016, at 14:12, Aled Morris wrote:
>> I am troubled by the new members joining RIPE purely to obtain IPv4
>> address space.
>>
>> Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
>> price as membership (?3,400 i.e. joining fee + 1 year subs) to anyone who
>> wants one since they can get one anyway by joining.
>>
>> It would save the admin overheads and would identify members as those
>> actually committed to performing as LIRs.
> Great idea !
> I would actually like to have NCC's opinion on that one.
> For now, I have the impression that the administrative overhead is just
> a pretext to be able to say "nonono, we DO NOT sell IPv4 addresses".
>
> --
> Radu-Adrian FEURDEAN
> fr.ccs
>
>




From jim at rfc1035.com  Wed May 11 11:50:43 2016
From: jim at rfc1035.com (Jim Reid)
Date: Wed, 11 May 2016 10:50:43 +0100
Subject: [address-policy-wg] R:  making progress with 2015-05
In-Reply-To: <0b7301d1ab5f$35cc7690$a16563b0$@tsnet.it>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
 <9D481A5E-E43C-4814-885C-9591C9028ED7@rfc1035.com>
 <0b7301d1ab5f$35cc7690$a16563b0$@tsnet.it>
Message-ID: <891F8470-6FC6-4412-B8AD-D9796F77B3D4@rfc1035.com>


> On 11 May 2016, at 09:29, Enrico Diacci <ed at tsnet.it> wrote:
> 
> When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6
> may require an additional /22 (if you do not already have space equivalent
> to a /20) stating its reasons for the new allocation with a project and
> proving to have it completed within one year.
> 
> This new /22 will in no way be transferred before 3-5 years.
> 
> I tried to remove the term of 18 months: what do you think about?

Not a lot. But thanks for the suggestions and for trying to move things forward.

First off, I am adamantly opposed to any policy proposal which will speed up depletion of the NCC?s IPv4 pool. Though if someone can come up with a convincing case for wiping it out, I would reconsider. Until then, the current policy is the least worst option IMO and we should keep it.

Second, coupling any policy to RIPEness metrics is a very bad idea. Those metrics may change or even go away. [Who decides about that BTW.] They can be easily gamed too. Just do whatever needs to be done with IPv6 to get the extra IPv4 space and then take it down. Repeat.

Third, I think it?s unwise to have a firm rule on transfers. Though I understand why you?ve suggested this: it?s meant to stop LIRs selling off these extra addresses. For one thing, there can be valid reasons for transferring space that don?t involve selling IPv4 addresses - a business reorganisation for instance. Next, if an LIR wants extra /22s in order to sell the addresses, they?d still do that irrespective of what the transfer restrictions were in place.





From nick at foobar.org  Wed May 11 12:15:01 2016
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 11 May 2016 11:15:01 +0100
Subject: [address-policy-wg] R:  making progress with 2015-05
In-Reply-To: <891F8470-6FC6-4412-B8AD-D9796F77B3D4@rfc1035.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <004d149e-a297-7893-257c-2e56f4526f23@wirem.net>
 <9D481A5E-E43C-4814-885C-9591C9028ED7@rfc1035.com>
 <0b7301d1ab5f$35cc7690$a16563b0$@tsnet.it>
 <891F8470-6FC6-4412-B8AD-D9796F77B3D4@rfc1035.com>
Message-ID: <57330625.7050702@foobar.org>

Jim Reid wrote:
> Third, I think it?s unwise to have a firm rule on transfers. Though I
> understand why you?ve suggested this: it?s meant to stop LIRs selling
> off these extra addresses. For one thing, there can be valid reasons
> for transferring space that don?t involve selling IPv4 addresses - a
> business reorganisation for instance. Next, if an LIR wants extra
> /22s in order to sell the addresses, they?d still do that
> irrespective of what the transfer restrictions were in place.

fourth: this suggestion proposes to revert to a "needs" based allocation
policy.  This policy was removed a couple of years ago for good reasons
which are still valid now and it is not realistic to expect that the
clock is going to be turned back on this.

Nick



From ripe-wgs at radu-adrian.feurdean.net  Wed May 11 14:42:02 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Wed, 11 May 2016 14:42:02 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160511065328.GW3978@Space.Net>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
Message-ID: <1462970522.1468945.604612873.0D80084B@webmail.messagingengine.com>

On Wed, May 11, 2016, at 08:53, Gert Doering wrote:

> Would you have preferred the ARIN way?  "Oops, we have reached
> exhaustion, nothing left, good buy to new entrants"?

My understanding is that ARIN is not yet "dry". There still is some
space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed
to be pretty restrictive, but I saw networks that prove me otherwise).
And they still allow "further allocations" from that block (provided the
"restrictive" conditions are met for all blocks). And it's evey 6 months
not every 18 months.

So it seems that issuing IPv4 space is still possible even after you cry
out loud everywhere that you have none left. Don't tell me we (small
LIRs) have to do the same with only a /22 in stock :)

--
Radu-Adrian FEURDEAN
fr.ccs



From ripe-wgs at radu-adrian.feurdean.net  Wed May 11 14:52:05 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Wed, 11 May 2016 14:52:05 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
Message-ID: <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>

On Wed, May 11, 2016, at 09:47, Remco van Mook wrote:

> Again, you can't have it both ways. Current policy is not limited to
> 185/8, so your proposal does have an impact. Actually 185/8 is more than
> half gone by now (9571 allocations that I can see as of this morning) -
> effectively this means the proposal wants over half of what remains in
> the pool to get released to existing LIRs who've already received their
> last /22. This cuts the lifespan of the pool for new entrants by more
> than half, no?

No, because:
 - it will not be dedicated to "further allocations"
 - there are some extra conditions that makes a lot of people not to
 qualify
 - with the time passing, when 185/8 is over, the "first /22 from last
 /8" will start being allocated from the same space as "further
 allocations".

--
Radu-Adrian FEURDEAN
fr.ccs



From phessler at theapt.org  Wed May 11 14:52:57 2016
From: phessler at theapt.org (Peter Hessler)
Date: Wed, 11 May 2016 14:52:57 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <1462970522.1468945.604612873.0D80084B@webmail.messagingengine.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <1462970522.1468945.604612873.0D80084B@webmail.messagingengine.com>
Message-ID: <20160511125257.GN14871@gir.theapt.org>

On 2016 May 11 (Wed) at 14:42:02 +0200 (+0200), Radu-Adrian FEURDEAN wrote:
:On Wed, May 11, 2016, at 08:53, Gert Doering wrote:
:
:> Would you have preferred the ARIN way?  "Oops, we have reached
:> exhaustion, nothing left, good buy to new entrants"?
:
:My understanding is that ARIN is not yet "dry". There still is some
:space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed
:to be pretty restrictive, but I saw networks that prove me otherwise).
:And they still allow "further allocations" from that block (provided the
:"restrictive" conditions are met for all blocks). And it's evey 6 months
:not every 18 months.
:
:So it seems that issuing IPv4 space is still possible even after you cry
:out loud everywhere that you have none left. Don't tell me we (small
:LIRs) have to do the same with only a /22 in stock :)
:
:--
:Radu-Adrian FEURDEAN
:fr.ccs
:

The 23.128/10 block is ONLY for /24-/28 allocations.  These are not
intended as general purpose IP blocks, and are ONLY allowed to be used
for the IPv6 trasition (DNS servers, NAT64 gateways, etc).  People
violating the ARIN rules shouldn't be used as an excuse for us to change
the rules in RIPE.

https://www.arin.net/announcements/2014/20140130.html

ARIN does not count them as part of the available ranges for
allocation, so we should not assume they are part of the normal pool.


-- 
If you're going to do something tonight that you'll be sorry for
tomorrow morning, sleep late.
		-- Henny Youngman



From remco.vanmook at gmail.com  Wed May 11 21:53:12 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Wed, 11 May 2016 21:53:12 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
Message-ID: <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>


> On 11 May 2016, at 14:52 , Radu-Adrian FEURDEAN <ripe-wgs at radu-adrian.feurdean.net> wrote:
> 
> On Wed, May 11, 2016, at 09:47, Remco van Mook wrote:
> 
>> Again, you can't have it both ways. Current policy is not limited to
>> 185/8, so your proposal does have an impact. Actually 185/8 is more than
>> half gone by now (9571 allocations that I can see as of this morning) -
>> effectively this means the proposal wants over half of what remains in
>> the pool to get released to existing LIRs who've already received their
>> last /22. This cuts the lifespan of the pool for new entrants by more
>> than half, no?
> 
> No, because:
> - it will not be dedicated to "further allocations"
> - there are some extra conditions that makes a lot of people not to
> qualify
> - with the time passing, when 185/8 is over, the "first /22 from last
> /8" will start being allocated from the same space as "further
> allocations".
> 

OK, have it your way. Let's look at some numbers:

Available in 185/8 right now: ~ 6,950 /22s (1)
Available outside 185/8 right now: ~ 8,180 /22s (1)

New LIRs since January 2013: ~4,600 (2,3)
Budgeted membership growth for the rest of 2016: ~ 1,500 (2)

Before 2016 is out, around 4,000 existing LIRs will have qualified under the proposed policy to get another allocation.
Half the 'outside 185' pool will be gone by the end of this year.

Based on an extrapolated growth rate of new members, the '185' pool should last until early 2019.
At that point, another 4,000 existing LIRs will have qualified under the proposed policy for another /22 from the 'outside' pool. This pool is now empty as well.

So, under the new policy, it will be game over for all involved somewhere in early 2019.
The space you argue would be available for new entrants outside the '185 pool' was gone by the time it was needed.

Now let's look at the current policy. As of today, a total of about 15,130 /22s are available.
Based on an extrapolated growth rate of new members, the available pool should last until 2025 (although the uncertainties are quite high if you extrapolate that far out)

So on one hand, we have a proposal that will be game over for all in about 3 years, or we keep the existing policy that shares the pain for existing and future LIRs well into the next decade.

At which point, IPv6 will have saved the world from global heating, or so they tell me.

The proposed policy has an impact (even the policy proposal itself says so (4)), and one that I strongly object to.

(if any of the NCC staff wants to verify my numbers, feel free to do so)

Sources:
1) https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph
2) https://www.ripe.net/participate/meetings/gm/meetings/may-2016/supporting-documents/ripe-ncc-annual-report-2015
3) https://labs.ripe.net/statistics
4) https://www.ripe.net/participate/policies/proposals/2015-05

Remco
(no hats)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160511/bd62668b/attachment.sig>

From ripe-wgs at radu-adrian.feurdean.net  Wed May 11 23:21:14 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Wed, 11 May 2016 23:21:14 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
Message-ID: <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>

On Wed, May 11, 2016, at 21:53, Remco van Mook wrote:
> OK, have it your way. Let's look at some numbers:
> 
> Available in 185/8 right now: ~ 6,950 /22s (1)
> Available outside 185/8 right now: ~ 8,180 /22s (1)

I'm OK with that.

> New LIRs since January 2013: ~4,600 (2,3)
> Budgeted membership growth for the rest of 2016: ~ 1,500 (2)
> 
> Before 2016 is out, around 4,000 existing LIRs will have qualified under
> the proposed policy to get another allocation.
> Half the 'outside 185' pool will be gone by the end of this year.

At the same time, 4472 LIRs do not have any IPv4 space. Is it possible
to know how many of them never requested it, 3.5 years after (or more
likely 2 years after all the restrictions have been lifted) ?
Do you really think all eligible LIRs will make the request within 6
months ?

> Based on an extrapolated growth rate of new members, the '185' pool
> should last until early 2019.

I see an average 12 months allocation rate of over 270 allocations/month
(and rising).
That leaves us (185/8 and recovered) 4 years 8 months (if allocation
rate remains steady - but it is increasing). 
For 185/8 only, that is (less than) 25.75 months, which is more like
mid-2018.
Continuing outside of 185/8, at the same rate, we get around
dec-2020/maybe jan-2021.
But that's missing the following:
 - allocations/month are on the rise, new members are on the rise
 - not much effect from 2015-01
 - no visible effect from suspending "multiple LIRs per member" (lower
 maximum, but steady high level).
 - things can change either way, rendering any estimation ..... very
 estimative....

> At that point, another 4,000 existing LIRs will have qualified under the
> proposed policy for another /22 from the 'outside' pool. This pool is now
> empty as well.

Not over-night.

> So, under the new policy, it will be game over for all involved somewhere
> in early 2019.
> The space you argue would be available for new entrants outside the '185
> pool' was gone by the time it was needed.

It will not be completely depleted, just reduced (and I can accept
"reduced by 50%").

> or we keep the existing policy that shares the pain for
> existing and future LIRs well into the next decade.

This is the problem that is supposed to be fixed : the pain.
And if at the same time we can also do something effective for boosting
IPv6 deployment, the pain level may be even less when the v4 pool will
be really empty.

> At which point, IPv6 will have saved the world from global heating, or so they tell me.

So they told me too, I discovered that it's much more complicated.

> (if any of the NCC staff wants to verify my numbers, feel free to do so)

Please !
Since it's not easy to find the following information: 
 - if a LIR received or not it's "last /22" (cannot distinguish from one
 that get it and sold it)
 - if a LIR has performed an "outbound" transfer or not
Thanks.




From ripe-wgs at radu-adrian.feurdean.net  Wed May 11 23:34:11 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Wed, 11 May 2016 23:34:11 +0200
Subject: [address-policy-wg] agreement
In-Reply-To: <20160511125257.GN14871@gir.theapt.org>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <7ceedb81-f9a4-6520-4f3c-c108bc74c158@wirem.net>
 <20160511065328.GW3978@Space.Net>
 <1462970522.1468945.604612873.0D80084B@webmail.messagingengine.com>
 <20160511125257.GN14871@gir.theapt.org>
Message-ID: <1463002451.3439072.605182417.05553AE5@webmail.messagingengine.com>

On Wed, May 11, 2016, at 14:52, Peter Hessler wrote:

> The 23.128/10 block is ONLY for /24-/28 allocations.  These are not

A /24 every 6 months (provided that conditions keep being fulfilled).
Because less than /24 is pretty much useless.

> intended as general purpose IP blocks, and are ONLY allowed to be used
> for the IPv6 trasition (DNS servers, NAT64 gateways, etc).  

Some people tell me that "last /8" in RIPE-land is supposed to serve the
same purpose, even if it's not written.
Plus, you *CAN* get more than 4 x /24 in ARIN-land (to date 2 x /24, but
the allocation rate is really low).

> People violating the ARIN rules shouldn't be used as an excuse for us to change
> the rules in RIPE.
> 
> https://www.arin.net/announcements/2014/20140130.html
> 
> ARIN does not count them as part of the available ranges for
> allocation, so we should not assume they are part of the normal pool.

It's not the violation of ARIN rules, it's the fact that ARIN is *NOT*
v4-exhausted. They still have available space, even if they call it
otherwise.
And it's used (or at least supposed) to reward people with real IPv6
deployment.



From remco.vanmook at gmail.com  Thu May 12 00:06:42 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Thu, 12 May 2016 00:06:42 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
Message-ID: <1781AA03-9EC3-499C-8171-0640AC072614@gmail.com>


My apologies to all on the list - this will be my last email about this version of 2015-05.

> On 11 May 2016, at 23:21 , Radu-Adrian FEURDEAN <ripe-wgs at radu-adrian.feurdean.net> wrote:
> 
> On Wed, May 11, 2016, at 21:53, Remco van Mook wrote:
>> OK, have it your way. Let's look at some numbers:
>> 
>> Available in 185/8 right now: ~ 6,950 /22s (1)
>> Available outside 185/8 right now: ~ 8,180 /22s (1)
> 
> I'm OK with that.
> 
>> New LIRs since January 2013: ~4,600 (2,3)
>> Budgeted membership growth for the rest of 2016: ~ 1,500 (2)
>> 
>> Before 2016 is out, around 4,000 existing LIRs will have qualified under
>> the proposed policy to get another allocation.
>> Half the 'outside 185' pool will be gone by the end of this year.
> 
> At the same time, 4472 LIRs do not have any IPv4 space. Is it possible
> to know how many of them never requested it, 3.5 years after (or more
> likely 2 years after all the restrictions have been lifted) ?
> Do you really think all eligible LIRs will make the request within 6
> months ?
> 

I don't know about the 4,472, but let's say 1,000 of them will, at some point.

What  has been claimed by a multitude of proponents of this proposal is that apparently a single /22 is woefully inadequate to run your business on. I don't even disagree.
All of those 4,000 have never received more than a single /22. Given the option to get more, following the rationale of the proposers, I would be very surprised if they didn't jump at that opportunity.

The same goes for every new LIR - and they would even be able to include the second /22 in their business planning, so that's another 4,000.

Quite a few LIRs who signed up during the 'run out fairly' period (2011-2012) also don't have a /20 of IPv4 address space, I don't have a number but let's put that at another 500.

Finally, according to the proposed policy LIRs can come back every 18 months - so by mid 2018 the first group of 4,000 comes back again.

That puts the total number of requests for additional /22s by mid 2018 at 13,500. That's 150% of the space you wanted to make available.

There won't be space for newcomers in there.

Remco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/867947ad/attachment.sig>

From rgori at wirem.net  Thu May 12 07:24:38 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Thu, 12 May 2016 07:24:38 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
Message-ID: <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>

Goodmoring Remco,

I read that you don't want to comment more about 2015-05.
I'll respect you and I won't wait for an answer and we can leave 
everything for a quick chat in Copenhagen but I have to leave my comment 
on your analisys.

In your example you suppose that every LIR under a /20 will request an 
additional /22 (every 18 months after a /22 allocation has been 
reiceved) and standing on you will litterally "burn" out the space in 3 
years.

Let's see what has been done in the past:
In september 2012 there were about 9000 LIRs members and at the end of 
2013 the number grows up to 10000 LIRs.
So in your view "last /8" would have distributed about 10000 /22 on 
15130 availables from 185/8 at the end of 2013, leaving about 5000 /22 
in the pool.
In this vision you couldn't expect to leave to new entrants no more than 
5 - 6 thousand /22.
Please explain how the current policy obtained a "success", luck? Why 
such policy was accepted and reached its consensum at that time?

2015-05 requires to act for IPv6
Current policy required in the past to obtain an IPv6 allocation and do 
exacly nothing more
Nowadays the allocation policy requires just pay the fee and do nothing.

regards
Riccardo

Il 11/05/2016 21:53, Remco van Mook ha scritto:
>> On 11 May 2016, at 14:52 , Radu-Adrian FEURDEAN <ripe-wgs at radu-adrian.feurdean.net> wrote:
>>
>> On Wed, May 11, 2016, at 09:47, Remco van Mook wrote:
>>
>>> Again, you can't have it both ways. Current policy is not limited to
>>> 185/8, so your proposal does have an impact. Actually 185/8 is more than
>>> half gone by now (9571 allocations that I can see as of this morning) -
>>> effectively this means the proposal wants over half of what remains in
>>> the pool to get released to existing LIRs who've already received their
>>> last /22. This cuts the lifespan of the pool for new entrants by more
>>> than half, no?
>> No, because:
>> - it will not be dedicated to "further allocations"
>> - there are some extra conditions that makes a lot of people not to
>> qualify
>> - with the time passing, when 185/8 is over, the "first /22 from last
>> /8" will start being allocated from the same space as "further
>> allocations".
>>
> OK, have it your way. Let's look at some numbers:
>
> Available in 185/8 right now: ~ 6,950 /22s (1)
> Available outside 185/8 right now: ~ 8,180 /22s (1)
>
> New LIRs since January 2013: ~4,600 (2,3)
> Budgeted membership growth for the rest of 2016: ~ 1,500 (2)
>
> Before 2016 is out, around 4,000 existing LIRs will have qualified under the proposed policy to get another allocation.
> Half the 'outside 185' pool will be gone by the end of this year.
>
> Based on an extrapolated growth rate of new members, the '185' pool should last until early 2019.
> At that point, another 4,000 existing LIRs will have qualified under the proposed policy for another /22 from the 'outside' pool. This pool is now empty as well.
>
> So, under the new policy, it will be game over for all involved somewhere in early 2019.
> The space you argue would be available for new entrants outside the '185 pool' was gone by the time it was needed.
>
> Now let's look at the current policy. As of today, a total of about 15,130 /22s are available.
> Based on an extrapolated growth rate of new members, the available pool should last until 2025 (although the uncertainties are quite high if you extrapolate that far out)
>
> So on one hand, we have a proposal that will be game over for all in about 3 years, or we keep the existing policy that shares the pain for existing and future LIRs well into the next decade.
>
> At which point, IPv6 will have saved the world from global heating, or so they tell me.
>
> The proposed policy has an impact (even the policy proposal itself says so (4)), and one that I strongly object to.
>
> (if any of the NCC staff wants to verify my numbers, feel free to do so)
>
> Sources:
> 1) https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph
> 2) https://www.ripe.net/participate/meetings/gm/meetings/may-2016/supporting-documents/ripe-ncc-annual-report-2015
> 3) https://labs.ripe.net/statistics
> 4) https://www.ripe.net/participate/policies/proposals/2015-05
>
> Remco
> (no hats)

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/e6e0ff84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/e6e0ff84/attachment.jpg>

From sander at steffann.nl  Thu May 12 14:16:39 2016
From: sander at steffann.nl (Sander Steffann)
Date: Thu, 12 May 2016 14:16:39 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
Message-ID: <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>

Hi Riccardo,

> Please explain how the current policy obtained a "success", luck? Why such policy was accepted and reached its consensum at that time?

I can answer that one.

For 2010-02 (https://www.ripe.net/participate/policies/proposals/2010-02) the WG started working down from one /8. Then the proposal started RIPE NCC had ?7540 LIRs. Using a /22 per LIR would allow for 16000 LIRs, so more than double the amount at the time. A /16 of address space was set aside for unforeseen circumstances, and the policy states that that reservation would become part of the main pool if not used for such unforeseen circumstances when the pool runs out.

I think Daniel's comment at the time sums it up quite nicely:
> And we have to care about new LIRs, we need to reserve some address space for them - as lots of internet resources will be accessible only over IPv4 for long period after depletion. It's about survivance of free allocatable IPv4 address space as long as possible.


2011-03 (https://www.ripe.net/participate/policies/proposals/2011-03) updated the policy regarding returned address space. If I remember correctly the arguments on the list at the time were that by putting all the returned address space in the same pool as 185/8 it was made sure that we wouldn't end up in a policy limbo where it was not clear which policy applied to which IPv4 addresses.

Another good quote, Dave wrote about 2011-03:
> And, frankly, we should take every opportunity remaining to expand the meagre pool of IPv4 addresses we leave to our children.


And that's how we arrived at today's policy.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/3f24cbb2/attachment.sig>

From mozafary at greenweb.ir  Thu May 12 15:56:08 2016
From: mozafary at greenweb.ir (Mozafary Mohammad)
Date: Thu, 12 May 2016 17:26:08 +0330
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
Message-ID: <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>

Hi

The suggested Rule is a way to support new and small LIR, There is many 
small LIR they need new IP addresses, The Rule can help them.

Thanks


On 5/12/2016 3:46 PM, Sander Steffann wrote:
> Hi Riccardo,
>
>> Please explain how the current policy obtained a "success", luck? Why such policy was accepted and reached its consensum at that time?
> I can answer that one.
>
> For 2010-02 (https://www.ripe.net/participate/policies/proposals/2010-02) the WG started working down from one /8. Then the proposal started RIPE NCC had ?7540 LIRs. Using a /22 per LIR would allow for 16000 LIRs, so more than double the amount at the time. A /16 of address space was set aside for unforeseen circumstances, and the policy states that that reservation would become part of the main pool if not used for such unforeseen circumstances when the pool runs out.
>
> I think Daniel's comment at the time sums it up quite nicely:
>> And we have to care about new LIRs, we need to reserve some address space for them - as lots of internet resources will be accessible only over IPv4 for long period after depletion. It's about survivance of free allocatable IPv4 address space as long as possible.
>
> 2011-03 (https://www.ripe.net/participate/policies/proposals/2011-03) updated the policy regarding returned address space. If I remember correctly the arguments on the list at the time were that by putting all the returned address space in the same pool as 185/8 it was made sure that we wouldn't end up in a policy limbo where it was not clear which policy applied to which IPv4 addresses.
>
> Another good quote, Dave wrote about 2011-03:
>> And, frankly, we should take every opportunity remaining to expand the meagre pool of IPv4 addresses we leave to our children.
>
> And that's how we arrived at today's policy.
>
> Cheers,
> Sander
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/c78670d1/attachment.html>

From randy at psg.com  Thu May 12 15:48:27 2016
From: randy at psg.com (Randy Bush)
Date: Thu, 12 May 2016 15:48:27 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
Message-ID: <m2mvnvcrpw.wl%randy@psg.com>

it's not just our grandchildren.  if the last /8 policy had not been put
in place and taken seriously, *today's* new LIRs might not be able to get
IPv4 space.

randy



From sander at steffann.nl  Thu May 12 16:52:43 2016
From: sander at steffann.nl (Sander Steffann)
Date: Thu, 12 May 2016 16:52:43 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m2mvnvcrpw.wl%randy@psg.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
Message-ID: <11CE5231-36F7-4305-9EB9-01883701C21D@steffann.nl>

Hi,

> Op 12 mei 2016, om 15:48 heeft Randy Bush <randy at psg.com> het volgende geschreven:
> 
> it's not just our grandchildren.  if the last /8 policy had not been put
> in place and taken seriously, *today's* new LIRs might not be able to get
> IPv4 space.

True. Without the current policy that started with 185/8 the NCC would have run out somewhere between December 2012 and January 2013 (based on an allocation rate of ?3.5 /8s per year, which was the rate at the time). Everybody who got any address space from the NCC after September 2012 should be happy that their predecessors took their needs into account ;)

Cheers!
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/a480c95e/attachment.sig>

From mschmidt at ripe.net  Thu May 12 16:53:12 2016
From: mschmidt at ripe.net (Marco Schmidt)
Date: Thu, 12 May 2016 16:53:12 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
Message-ID: <573498D8.2040901@ripe.net>

Dear Remco and Radu-Adrian,

On 11/05/2016 23:21, Radu-Adrian FEURDEAN wrote:
>> (if any of the NCC staff wants to verify my numbers, feel free to do so)
> Please !
> Since it's not easy to find the following information:
>   - if a LIR received or not it's "last /22" (cannot distinguish from one
>   that get it and sold it)
>   - if a LIR has performed an "outbound" transfer or not
> Thanks.
>
>
>
Thank you for your questions. We have some numbers to help the discussion.

As of today, 8,831 of our 13,755 members have requested a final /22 IPv4 
allocation under the last /8 policy.

This means that there are currently 4,924 LIRs that may still request a 
/22 allocation. This figure includes LIRs that opened recently ? if we 
look only at older members, there are currently 4,791 LIRs that have 
been open for more than six months and still haven?t requested their 
final IPv4 allocation.

We also note that the proposal introduces limits around transfers. 
Currently we count 723 LIRs that have transferred IPv4 resources to 
another entity and so would not qualify for future allocations under the 
proposal.

Regarding how long the available pool will last, we estimate a period of 
around five years under the current policy. In the next few days, we 
will publish a RIPE Labs article that will give more insight into what 
we?re basing this estimate on, such as membership development trends and 
returned IPv4 address space.

Kind regards,
Marco Schmidt
Policy Development Officer



From rgori at wirem.net  Thu May 12 17:41:06 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Thu, 12 May 2016 17:41:06 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
Message-ID: <c6b04af0-ce8b-507a-2446-b9862d45a439@wirem.net>

Hi Sander,

thank you for your answer


Il 12/05/2016 14:16, Sander Steffann ha scritto:
> Hi Riccardo,
>
>> Please explain how the current policy obtained a "success", luck? Why such policy was accepted and reached its consensum at that time?
> I can answer that one.
>
> For 2010-02 (https://www.ripe.net/participate/policies/proposals/2010-02) the WG started working down from one /8. Then the proposal started RIPE NCC had ?7540 LIRs. Using a /22 per LIR would allow for 16000 LIRs, so more than double the amount at the time. A /16 of address space was set aside for unforeseen circumstances, and the policy states that that reservation would become part of the main pool if not used for such unforeseen circumstances when the pool runs out.
My point here is that as when "last /8" was tought was to deploy IPv6 
and leave space to new entrants.
So objecting that 2015-05 will burn the free pool just because every LIR 
under /20 can request a /22 it's not point if wasn't the same in the 
past. We should attain at the historical datas to forecast or read an 
impact analisys about it.
 From approval of 2010-02 and 14 September 2012, when the policy was 
triggered, the number of LIRs grew from about 7540 to about 9000-10000. 
It would be able to forecast a grow of about 1500-2000 per year.
Leaving the oportunity to any old LIRs (that reiceved allocation from 18 
Jan 2011 up to 14/09/2012 under the old policy) to obtain a /22 after 14 
September 2012 would made everyone able to forecast not more 7000-9000 
/22 to new LIRs (LIRs after 09/2012)
Let me say another time there are many stranges big allocations made 
just two weeks before the new policy took place.

>
> I think Daniel's comment at the time sums it up quite nicely:
>> And we have to care about new LIRs, we need to reserve some address space for them - as lots of internet resources will be accessible only over IPv4 for long period after depletion. It's about survivance of free allocatable IPv4 address space as long as possible.

> 2011-03 (https://www.ripe.net/participate/policies/proposals/2011-03) updated the policy regarding returned address space. If I remember correctly the arguments on the list at the time were that by putting all the returned address space in the same pool as 185/8 it was made sure that we wouldn't end up in a policy limbo where it was not clear which policy applied to which IPv4 addresses.
Please note that the current text is:
[...]
This section only applies to address space that is returned to the RIPE 
NCC and that will not be returned to the IANA but re-issued by the RIPE 
NCC itself.
[...]

I am not able to fully understand this because I don't know what happens 
to returned address space and when not is handable by RIPE itself  and 
should be returned to IANA cleaned and issued back to RIR.

>
> Another good quote, Dave wrote about 2011-03:
>> And, frankly, we should take every opportunity remaining to expand the meagre pool of IPv4 addresses we leave to our children.
>
> And that's how we arrived at today's policy.
>
> Cheers,
> Sander
>
Thank you to all old LIRs that didn't request their last /22 so I had 
the oportunity to request for it early Jan/2015.
Anyway I strongly think the policy should go voer IPv4 and do something 
for IPv6!

regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/f02bd84a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/f02bd84a/attachment.jpg>

From rgori at wirem.net  Thu May 12 18:00:07 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Thu, 12 May 2016 18:00:07 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m2mvnvcrpw.wl%randy@psg.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
Message-ID: <0eebb1fe-f79c-e823-84c9-f94a61a79f72@wirem.net>

Hi Randy,

that's why we (defined somewhere pigs) are not rewriting base concept of 
"last /8"
We are proposing to help LIRs to gain some sustainability of their new 
businesses.
This is 'cause some LIRs in the past eated almost all the space and 
created stockpiles of unused space and some years later created the well 
known transfert market where to lease/buy space for money profit.
At the same time we are trying to remind to anyone there's a IPv6 to 
deploy that is supposed to be the real solution (and disappeared from 
allocation policies).

again many thanks to all LIRs that didn't request their last /22
regards
Riccardo

Il 12/05/2016 15:48, Randy Bush ha scritto:
> it's not just our grandchildren.  if the last /8 policy had not been put
> in place and taken seriously, *today's* new LIRs might not be able to get
> IPv4 space.
>
> randy
>

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/61571080/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/61571080/attachment.jpg>

From phessler at theapt.org  Thu May 12 18:15:17 2016
From: phessler at theapt.org (Peter Hessler)
Date: Thu, 12 May 2016 18:15:17 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <0eebb1fe-f79c-e823-84c9-f94a61a79f72@wirem.net>
References: <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
 <0eebb1fe-f79c-e823-84c9-f94a61a79f72@wirem.net>
Message-ID: <20160512161516.GU14871@gir.theapt.org>

On 2016 May 12 (Thu) at 18:00:07 +0200 (+0200), Riccardo Gori wrote:
:We are proposing to help LIRs to gain some sustainability of their new
:businesses.

First you say this.

:again many thanks to all LIRs that didn't request their last /22

And then you say this.


You seem to be contradicting yourself in the same email.


-- 
We don't know who discovered water, but we're certain it wasn't a
fish.



From rgori at wirem.net  Thu May 12 18:17:55 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Thu, 12 May 2016 18:17:55 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160512161516.GU14871@gir.theapt.org>
References: <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
 <0eebb1fe-f79c-e823-84c9-f94a61a79f72@wirem.net>
 <20160512161516.GU14871@gir.theapt.org>
Message-ID: <87928a25-b093-da98-368d-717dff5c61ab@wirem.net>

Hi Peter,


Il 12/05/2016 18:15, Peter Hessler ha scritto:
> On 2016 May 12 (Thu) at 18:00:07 +0200 (+0200), Riccardo Gori wrote:
> :We are proposing to help LIRs to gain some sustainability of their new
> :businesses.
>
> First you say this.
>
> :again many thanks to all LIRs that didn't request their last /22
>
> And then you say this.
>
>
> You seem to be contradicting yourself in the same email.
Sorry, you are right.
I am referring to LIRs born before 14/09/2012 that didn't request their /22
>
>
regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/e5d15424/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160512/e5d15424/attachment.jpg>

From wilhelm at boeddinghaus.de  Thu May 12 18:46:01 2016
From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus)
Date: Thu, 12 May 2016 18:46:01 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m2mvnvcrpw.wl%randy@psg.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
Message-ID: <b406816e-3ef7-08da-f786-14bb2d6fc8e2@boeddinghaus.de>

Am 12.05.2016 um 15:48 schrieb Randy Bush:
> it's not just our grandchildren.  if the last /8 policy had not been put
> in place and taken seriously, *today's* new LIRs might not be able to get
> IPv4 space.
>
> randy
>
Well said.

Look at the other RIRs who cannot offer any IPv4 space to new members. 
The market is more or less fixed. New ISPs cannot easily develop new 
business models and innovate. But we in RIPE region can, because of the 
strict policy. Let`s keep it.

We have talked about IPv6 so many times, there is no way to speed up 
IPv6 deployment by writing a policy. IPv6 will come, see the growth 
rates in several coutries. Apple is demanding it for the software, this 
will help. There are many companies moving to IPv6. And many enterprises 
become LIR to get IPv6 space. They want to become independant from their 
providers, never want to renumber again and see, that the Internet is  
important for their business and they take back control. Getting IPv4 
space is sometimes just an addon (a very nice one, I admit).

I oppose 2015-05 and want to stick with the current policy of not 
burning down the RIPE NCC IPv4 pool for short term profit. Welcome new 
players on the market with an IPv4 address block as long as possible.

Wilhelm



From tore at fud.no  Thu May 12 20:37:00 2016
From: tore at fud.no (Tore Anderson)
Date: Thu, 12 May 2016 20:37:00 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <c6b04af0-ce8b-507a-2446-b9862d45a439@wirem.net>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <c6b04af0-ce8b-507a-2446-b9862d45a439@wirem.net>
Message-ID: <20160512203700.2aa9641b@envy.e5.y.home>

* Riccardo Gori

> Thank you to all old LIRs that didn't request their last /22 so I had 
> the oportunity to request for it early Jan/2015.

Marco estimated that the pool would last for around five years under
the current policy[1]. For the sake of the argument, let's assume he's
spot on, to the exact day.

[1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-May/011247.html

That means that on the 11th of May 2021, a new entrant will receive the
very last /22. That last entrant could then be - like you - thanking
the "old LIRs" - yours included - for showing restraint in not passing
2015-05, giving him the opportunity to request and receive his /22.

If on the other hand 2015-05 passes, that /22 would obviously no longer
be available for allocation on the 11th of May 2021. An (at that point
in time) "old LIR" - maybe yours - would instead have received it as an
additional allocation under the 2015-05 policy. The new entrant
certaintly wouldn't be thanking anyone for their selflessness.

Tore



From davidm at futureinquestion.net  Thu May 12 23:13:09 2016
From: davidm at futureinquestion.net (David Monosov)
Date: Thu, 12 May 2016 23:13:09 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <1781AA03-9EC3-499C-8171-0640AC072614@gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
 <1781AA03-9EC3-499C-8171-0640AC072614@gmail.com>
Message-ID: <5734F1E5.8030409@futureinquestion.net>

It would be completely irrational for any LIR that qualifies for additional IPv4
space not to request it.

Any LIRs not having done so yet despite qualifying are likely running on
auto-pilot in the enterprise world or are prevented from doing so by
organizational red tape of some sort.

There is undoubtedly a price point at which instead of the e-mails from would-be
IPv4 brokers currently circulating that solicit LIRs to sell or lease
unadvertised / unused space, LIRs will begin receiving e-mails from the same
brokers with the subject line "Did you know you qualify for additional IP space
you could sell at a considerable profit? We can help!".

I suspect Remco's back-of-a-napkin calculations are actually incredibly
conservative, and would like to reiterate my objection to 2015-05 and any future
policy aiming to loosen the allocation criteria of the remaining crumbs of IPv4.

Seeking to maximize the return on one's LIR fees is a perfectly rational
expression of self-interest, but it is hardly a demonstration of responsible
custodianship of the future of the Internet.

--
Respectfully yours,

David Monosov

On 12/05/16 00:06, Remco van Mook wrote:
> 
> There won't be space for newcomers in there.
> 
> Remco
> 



From arash_mpc at parsun.com  Fri May 13 03:01:55 2016
From: arash_mpc at parsun.com (Arash Naderpour)
Date: Fri, 13 May 2016 11:01:55 +1000
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <5734F1E5.8030409@futureinquestion.net>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
 <1781AA03-9EC3-499C-8171-0640AC072614@gmail.com>
 <5734F1E5.8030409@futureinquestion.net>
Message-ID: <CAGpkpTOX84tfO_9n5bEkWvnCFT8ZK5UUp3eGA8DXzgcNAF2cyw@mail.gmail.com>

That's not true, I know some LIRs qualified for /22 not requesting it and
they are not running on auto-pilot (there are fully aware of the market
situation)

Arash

On Fri, May 13, 2016 at 7:13 AM, David Monosov <davidm at futureinquestion.net>
wrote:

> It would be completely irrational for any LIR that qualifies for
> additional IPv4
> space not to request it.
>
> Any LIRs not having done so yet despite qualifying are likely running on
> auto-pilot in the enterprise world or are prevented from doing so by
> organizational red tape of some sort.
>
> There is undoubtedly a price point at which instead of the e-mails from
> would-be
> IPv4 brokers currently circulating that solicit LIRs to sell or lease
> unadvertised / unused space, LIRs will begin receiving e-mails from the
> same
> brokers with the subject line "Did you know you qualify for additional IP
> space
> you could sell at a considerable profit? We can help!".
>
> I suspect Remco's back-of-a-napkin calculations are actually incredibly
> conservative, and would like to reiterate my objection to 2015-05 and any
> future
> policy aiming to loosen the allocation criteria of the remaining crumbs of
> IPv4.
>
> Seeking to maximize the return on one's LIR fees is a perfectly rational
> expression of self-interest, but it is hardly a demonstration of
> responsible
> custodianship of the future of the Internet.
>
> --
> Respectfully yours,
>
> David Monosov
>
> On 12/05/16 00:06, Remco van Mook wrote:
> >
> > There won't be space for newcomers in there.
> >
> > Remco
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160513/29fe6069/attachment.html>

From bruecknerc at googlemail.com  Thu May 12 23:10:49 2016
From: bruecknerc at googlemail.com (=?windows-1252?Q?Carsten_Br=FCckner?=)
Date: Thu, 12 May 2016 23:10:49 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <b406816e-3ef7-08da-f786-14bb2d6fc8e2@boeddinghaus.de>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1bf5b4fc-bb9d-4ef2-d86c-ceaa44673c3a@wirem.net>
 <51DE2A39-A5D8-4ED5-911F-445896B5F159@steffann.nl>
 <fed3b882-527b-621a-479e-f02c78dfbae8@greenweb.ir>
 <m2mvnvcrpw.wl%randy@psg.com>
 <b406816e-3ef7-08da-f786-14bb2d6fc8e2@boeddinghaus.de>
Message-ID: <04A0BFE6-7B2D-42A0-B085-574D8DF77D64@gmail.com>

Hi everyone,
I agree with Wilhelms arguments and I want to add my personal thoughts about 2015-05. I dont think that it is a good thing, if depletation of the RIPE NCCs IPv4 address pool will speed up and in my opinion it is the wrong signal to support the NCCs members with the historical internet addressing standard. There is a new successor standard, that will bring complete new possibilities for an internet infrastructure with an open standard for equal footing chances to step into the business. There is no need for more IPv4 addresses unless for migration use.
In addition I think, that the comparision with the runout policies from other RIRs is not a valid argument. RIPEs current last /8 policy runs great and gives equal chances for new members in a mid term run. Therefore, I oppose the policy proposal 2015-05.
Regards,
Carsten


> Am 12.05.2016 um 18:46 schrieb Wilhelm Boeddinghaus <wilhelm at boeddinghaus.de>:
> 
> Am 12.05.2016 um 15:48 schrieb Randy Bush:
>> it's not just our grandchildren.  if the last /8 policy had not been put
>> in place and taken seriously, *today's* new LIRs might not be able to get
>> IPv4 space.
>> 
>> randy
>> 
> Well said.
> 
> Look at the other RIRs who cannot offer any IPv4 space to new members. The market is more or less fixed. New ISPs cannot easily develop new business models and innovate. But we in RIPE region can, because of the strict policy. Let`s keep it.
> 
> We have talked about IPv6 so many times, there is no way to speed up IPv6 deployment by writing a policy. IPv6 will come, see the growth rates in several coutries. Apple is demanding it for the software, this will help. There are many companies moving to IPv6. And many enterprises become LIR to get IPv6 space. They want to become independant from their providers, never want to renumber again and see, that the Internet is  important for their business and they take back control. Getting IPv4 space is sometimes just an addon (a very nice one, I admit).
> 
> I oppose 2015-05 and want to stick with the current policy of not burning down the RIPE NCC IPv4 pool for short term profit. Welcome new players on the market with an IPv4 address block as long as possible.
> 
> Wilhelm
> 




From sander at steffann.nl  Fri May 13 14:03:28 2016
From: sander at steffann.nl (Sander Steffann)
Date: Fri, 13 May 2016 14:03:28 +0200
Subject: [address-policy-wg] Draft agenda for RIPE 72
Message-ID: <B063495F-1908-4596-A2A4-1E459E11753F@steffann.nl>

Hi APWG folks,

Below you can find a draft for the RIPE address policy WG meeting's agenda,
which will take place in Copenhagen in the following time slots:

Wednesday, May 25, 09:00 - 10:30
Wednesday, May 25, 11:00 - 12:30

If you have anything else you want to see on the agenda, or if we need
to change anything, please let us know.  So far, the agenda is fairly
light - if you have something you want to address, or that bothers you,
let us know and we make room for you :-)

The distribution of items to the two timeslot is somewhat subject to
the time spent on discussion - but we'll try to stick to what's published.

regards,

Sander Steffann,
Gert D?ring,
APWG chairs


----------------------------------------------------------------------
Wednesday, 09:00-10:30
----------------------------------------------------------------------

A. Administrative Matters
   (welcome, thanking the scribe, approving the minutes, etc.)

B. WG Chair Selection

C. Current Policy Topics
   Marco Schmidt, NCC PDO

F. Discussion of open policy proposals


----------------------------------------------------------------------
Wednesday, 11:00-12:30
----------------------------------------------------------------------

Welcome back

G. Market concentration in the transfers of IPv4 space
   Alain Durand and Gabe Fried

D. Feedback From NCC Registration Service
   Andrea Cima

Y. Open Policy Hour

   The Open Policy Hour is a showcase for your policy ideas.
   If you have a policy proposal you'd like to debut, prior
   to formally submitting it, here is your opportunity.

Z. AOB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160513/bc0426ac/attachment.sig>

From ripe-wgs at radu-adrian.feurdean.net  Sat May 14 09:35:38 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Sat, 14 May 2016 09:35:38 +0200
Subject: [address-policy-wg] Splitting 2015-05 in two
In-Reply-To: <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
 <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
 <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
Message-ID: <1463211338.1241903.607583873.2EF31A85@webmail.messagingengine.com>

On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
>   If it were my proposal, here's how I would go about it.
> 
>   Withdraw the current proposal.
>   The proposer can always do this during the process.
> 
>   Introduce two new proposals (2016-somenumber and 2016-someothernumber)
>   respectively containing the "Part A" and "Part B" material from the
>   current proposal.

Hello,

As the proposal was written, the "part B" (allocation condition
including v6 deployment) would have no sense on its own, since it only
applies to the results of "part A" (further allocations).
In order to have a "part B" that makes any sens, it would mean that
current rules for allocation of the "first /22 from last /8" would have
to change:
 - for a "real" first allocation (LIR that never received a v4
 allocation before) either conditions would not apply, or a new system
 would have to be created where the allocation is time-limited, and at
 the end of time limit the allocated block is either returned (condition
 not met) or made "regular allocation" (condition met).
 - for LIRs that had previously allocated IPv4 space, condition applied
 directly.



From frettled at gmail.com  Sat May 14 10:16:05 2016
From: frettled at gmail.com (Jan Ingvoldstad)
Date: Sat, 14 May 2016 10:16:05 +0200
Subject: [address-policy-wg] Splitting 2015-05 in two
In-Reply-To: <1463211338.1241903.607583873.2EF31A85@webmail.messagingengine.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
 <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
 <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
 <1463211338.1241903.607583873.2EF31A85@webmail.messagingengine.com>
Message-ID: <CAEffzkxskESRYX-kYnRuZhSqDtzjc+u-70528Nmujrg-3dwO-g@mail.gmail.com>

On Sat, May 14, 2016 at 9:35 AM, Radu-Adrian FEURDEAN <
ripe-wgs at radu-adrian.feurdean.net> wrote:

> On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
> >   If it were my proposal, here's how I would go about it.
> >
> >   Withdraw the current proposal.
> >   The proposer can always do this during the process.
> >
> >   Introduce two new proposals (2016-somenumber and 2016-someothernumber)
> >   respectively containing the "Part A" and "Part B" material from the
> >   current proposal.
>
> Hello,
>
> As the proposal was written,


Yep, and this is why the suggestion starts with "withdraw the current
proposal", also because that will make it easier to proceed.


> the "part B" (allocation condition
> including v6 deployment) would have no sense on its own, since it only
> applies to the results of "part A" (further allocations).
>

This is indeed a weakness of the current proposal.


> In order to have a "part B" that makes any sens, it would mean that
> current rules for allocation of the "first /22 from last /8" would have
> to change:
>  - for a "real" first allocation (LIR that never received a v4
>  allocation before) either conditions would not apply, or a new system
>  would have to be created where the allocation is time-limited, and at
>  the end of time limit the allocated block is either returned (condition
>  not met) or made "regular allocation" (condition met).
>  - for LIRs that had previously allocated IPv4 space, condition applied
>  directly.
>
>
This seems like putting the cart before the horse.

Allocation conditions should be introduced _first_, as a "part A".

Then a separate proposal for additional allocations should be introduced
_second_, as a "part B".

This corresponds well to your own claim that your proposal intends to
preserve the pool, and should not deplete it rapidly, and will perhaps even
make it possible to proceed.

To me, this is the test of whether you actually stand by that claim.

-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160514/74989169/attachment.html>

From ripe-wgs at radu-adrian.feurdean.net  Sat May 14 11:27:32 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Sat, 14 May 2016 11:27:32 +0200
Subject: [address-policy-wg] Splitting 2015-05 in two
In-Reply-To: <CAEffzkxskESRYX-kYnRuZhSqDtzjc+u-70528Nmujrg-3dwO-g@mail.gmail.com>
References: <WC20160508131102.720003@soshiant.net>
 <3D370D18-2037-4696-9F2E-B77C7862119A@steffann.nl>
 <64be3b2d-700f-a408-3a28-15ff2aecbd6d@wirem.net>
 <20160509122940.GG14871@gir.theapt.org>
 <83C22EE8-8660-4012-B7A5-9EA4BB809C2F@steffann.nl>
 <1462867369.3844326.603151545.1DBFD7AD@webmail.messagingengine.com>
 <CAEffzkxAMN20EWgDbbX8FDXYufBpVSLL=zeHvAa6erbDjwOOdw@mail.gmail.com>
 <CAMCMt7o8CCJv4=di0301vO=GZ92p3RVzTCTm81xThFRXL9dkPw@mail.gmail.com>
 <63130B6C-4259-42D3-B135-F79F89B70DB8@ucd.ie>
 <1463211338.1241903.607583873.2EF31A85@webmail.messagingengine.com>
 <CAEffzkxskESRYX-kYnRuZhSqDtzjc+u-70528Nmujrg-3dwO-g@mail.gmail.com>
Message-ID: <1463218052.1269200.607627481.77DF7FC3@webmail.messagingengine.com>

On Sat, May 14, 2016, at 10:16, Jan Ingvoldstad wrote:
> This seems like putting the cart before the horse.
> 
> Allocation conditions should be introduced _first_, as a "part A".

Ok, got it, I messed the order.
Sill, the question remains on what is the scope of "Part A" (condition
for allocation) ?
For old LIRs (that got an allocation before 14/09/2012), that shouldn't
be a problem unless community decides otherwise

The question is for new LIRs : how can you ask them to fulfill the
conditions when they never had anything (nada, zero, LIR just opened) in
the first place ?
 - ask them to start deployment using somebody else's space (ASSIGNED PA
 from transit, leased space) ?
 - lease them the block for X months/years (trial period) than take it
 back if at the end of trial period the condition is not met ?
 - keep the current status for them, which pretty much voids the purpose
 of the condition ?

--
Radu-Adrian FEURDEAN
fr.ccs



From ripe-wgs.cs at schiefner.de  Sat May 14 13:00:25 2016
From: ripe-wgs.cs at schiefner.de (Carsten Schiefner)
Date: Sat, 14 May 2016 13:00:25 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 May 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAGpkpTOX84tfO_9n5bEkWvnCFT8ZK5UUp3eGA8DXzgcNAF2cyw@mail.gmail.com>
References: <570F9005.4090008@ripe.net>
 <CAJ--xAXN=q4D_baemPV+ogUg1vQ8Eut1d0fFL0A7PszYczVEuw@mail.gmail.com>
 <027b01d1aa59$dc039a90$940acfb0$@parsun.com>
 <75F902AC-AA1F-4AC0-B2CA-35744C4921A1@gmail.com>
 <1462971125.1473103.604646665.75642BE5@webmail.messagingengine.com>
 <8AAFE154-67DE-4867-A2F1-1B7F56AA2819@gmail.com>
 <1463001674.3435652.605127697.07A44D1E@webmail.messagingengine.com>
 <1781AA03-9EC3-499C-8171-0640AC072614@gmail.com>
 <5734F1E5.8030409@futureinquestion.net>
 <CAGpkpTOX84tfO_9n5bEkWvnCFT8ZK5UUp3eGA8DXzgcNAF2cyw@mail.gmail.com>
Message-ID: <926de8f8-e0bd-92a0-3ae2-9b18a44006cb@schiefner.de>

Hi Arash -

On 13.05.2016 03:01, Arash Naderpour wrote:
> That's not true, I know some LIRs qualified for /22 not requesting it
> and they are not running on auto-pilot (there are fully aware of the
> market situation) 

OK, even then: your point is?

Do you empty your bank account the second your employer has transfered
your salary?

At least I let it sit there until I need it, knowing, assuming or at
least hoping it sits there safe and sound.

So why would an LIR that has not yet requested its last /22 because it
simply doesn't need it at the moment still request it right now when it
is ensured that it can also request its last chunk from the cake at any
given time in the future?

Provided that the underlying conditions do not change, of course.

Best,

	-C.

> On Fri, May 13, 2016 at 7:13 AM, David Monosov
> <davidm at futureinquestion.net <mailto:davidm at futureinquestion.net>> wrote:
> 
>     It would be completely irrational for any LIR that qualifies for
>     additional IPv4
>     space not to request it.
> 
>     Any LIRs not having done so yet despite qualifying are likely running on
>     auto-pilot in the enterprise world or are prevented from doing so by
>     organizational red tape of some sort.
> 
>     [...]



From mschmidt at ripe.net  Tue May 17 14:05:26 2016
From: mschmidt at ripe.net (Marco Schmidt)
Date: Tue, 17 May 2016 14:05:26 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the
	Final /8 Policy)
Message-ID: <573B0906.3060708@ripe.net>

Dear colleagues,

A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
is now available for discussion.

The goal of this proposal is to limit IPv4 from the remaining address pool
to one /22 per LIR (regardless of how it was received).
These ?final /22? allocations will receive a separate status with 
several restrictions:

-    These allocation are not transferrable
-    LIRs may only retain one final /22 following a merger or acquisition
-    Sub-allocations are not possible
-    Reverse delegation authority can not delegated to another party

You can find the full proposal at:

     https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this proposal and send your comments to
<address-policy-wg at ripe.net> before 15 June 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC



From remco.vanmook at gmail.com  Tue May 17 14:08:01 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Tue, 17 May 2016 14:08:01 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>


Thank you Marco.

Dear colleagues,

Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.

The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.

We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:

- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.

And, outside of policy but enforceable as business rules following from this policy proposal:
- No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
- No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22

Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.

Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.

Kind regards,

Remco van Mook
(no hats)


> On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net> wrote:
> 
> Dear colleagues,
> 
> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
> is now available for discussion.
> 
> The goal of this proposal is to limit IPv4 from the remaining address pool
> to one /22 per LIR (regardless of how it was received).
> These ?final /22? allocations will receive a separate status with several restrictions:
> 
> -    These allocation are not transferrable
> -    LIRs may only retain one final /22 following a merger or acquisition
> -    Sub-allocations are not possible
> -    Reverse delegation authority can not delegated to another party
> 
> You can find the full proposal at:
> 
>    https://www.ripe.net/participate/policies/proposals/2016-03
> 
> We encourage you to review this proposal and send your comments to
> <address-policy-wg at ripe.net> before 15 June 2016.
> 
> Regards
> 
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/1aedf671/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/1aedf671/attachment.sig>

From ripe at liopen.fr  Tue May 17 14:33:21 2016
From: ripe at liopen.fr (Denis Fondras)
Date: Tue, 17 May 2016 14:33:21 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <20160517123321.GB1488@belenos>

Hello all,

> 
> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or
> sub-allocated;

Will current 'ALLOCATED PA' be changed to 'ALLOCATED FINAL' ?

Denis



From remco.vanmook at gmail.com  Tue May 17 14:40:21 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Tue, 17 May 2016 14:40:21 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <20160517123321.GB1488@belenos>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <20160517123321.GB1488@belenos>
Message-ID: <05DD6D31-3B90-48F7-B4CD-6174DA3E2E8D@gmail.com>


> On 17 May 2016, at 14:33 , Denis Fondras <ripe at liopen.fr> wrote:
> 
> Hello all,
> 
>> 
>> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or
>> sub-allocated;
> 
> Will current 'ALLOCATED PA' be changed to 'ALLOCATED FINAL' ?
> 

For allocations handed out after 'final /8' came into effect, yes.

Remco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/4bec7830/attachment.sig>

From boggits at gmail.com  Tue May 17 14:44:16 2016
From: boggits at gmail.com (boggits)
Date: Tue, 17 May 2016 13:44:16 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>

On 17 May 2016 at 13:08, Remco van Mook <remco.vanmook at gmail.com> wrote:

>
> Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll
> be talking about this proposal during the first APWG session.
>

So this includes LIR's who already have (through acquisition of other
companies) multiple /22 from the last /8

That kinda sucks...

In general I can see the point *but* please can we just stack the
deckchairs neatly on the side and get into the boats...


J
-- 

James Blessing
07989 039 476
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/160344ce/attachment.html>

From apwg at c4inet.net  Tue May 17 15:44:14 2016
From: apwg at c4inet.net (Sascha Luck [ml])
Date: Tue, 17 May 2016 14:44:14 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <20160517134414.GB862@cilantro.c4inet.net>

On Tue, May 17, 2016 at 02:05:26PM +0200, Marco Schmidt wrote:
>A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>is now available for discussion.
>
>The goal of this proposal is to limit IPv4 from the remaining address pool
>to one /22 per LIR (regardless of how it was received).
>These ???final /22??? allocations will receive a separate status with 
>several restrictions:
>
>-    These allocation are not transferrable
>-    LIRs may only retain one final /22 following a merger or acquisition
>-    Sub-allocations are not possible
>-    Reverse delegation authority can not delegated to another party

I would like to see a statement from NCC Legal on the legality of
any of these proposals with particular emphasis on EU "barrier to
entry" legislation.

rgds,
Sascha Luck



From remco.vanmook at gmail.com  Tue May 17 14:46:02 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Tue, 17 May 2016 14:46:02 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
Message-ID: <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>


> On 17 May 2016, at 14:44 , boggits <boggits at gmail.com> wrote:
> 
> 
> 
> On 17 May 2016 at 13:08, Remco van Mook <remco.vanmook at gmail.com <mailto:remco.vanmook at gmail.com>> wrote:
> 
> Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.
> 
> So this includes LIR's who already have (through acquisition of other companies) multiple /22 from the last /8

It doesn't apply retroactively - so if you have already merged LIRs and are currently holding multiple /22s form the final /8 you're fine. It does stop future cases though.


Remco



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/41d0f54f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/41d0f54f/attachment.sig>

From tom at kebab.org.pl  Tue May 17 14:46:45 2016
From: tom at kebab.org.pl (=?UTF-8?B?IlRvbWFzeiDFmmzEhXNraSBAIEtFQkFCIg==?=)
Date: Tue, 17 May 2016 14:46:45 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <573B12B5.5030303@kebab.org.pl>

W dniu 2016-05-17 o 14:08, Remco van Mook pisze:

> - Any excess space will have to be returned to the RIEP NCC within 180 
> days (however I don't intend that this is applied retroactively);
>
>

Dear Remco and All @ APWG

It should be clearly written that the policy proposal is not 
retroactive. With the current text the intention is not clear.

Best regards

Tomasz ?l?ski
pl.skonet



From apwg at c4inet.net  Tue May 17 15:52:21 2016
From: apwg at c4inet.net (Sascha Luck [ml])
Date: Tue, 17 May 2016 14:52:21 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
Message-ID: <20160517135221.GC862@cilantro.c4inet.net>

On Tue, May 17, 2016 at 02:46:02PM +0200, Remco van Mook wrote:
>It doesn't apply retroactively - so if you have already merged
>LIRs and are currently holding multiple /22s form the final /8
>you're fine. It does stop future cases though.

So it puts new entrants at a competitive disadvantage to existing
LIRs? I'm sure that will look just *great* in court.

rgds,
Sascha Luck





From dominik at clouvider.co.uk  Tue May 17 14:58:49 2016
From: dominik at clouvider.co.uk (Dominik Nowacki)
Date: Tue, 17 May 2016 12:58:49 +0000
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking
 Down	the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <HE1PR06MB1675ED925F0B497BE365F3CBF2480@HE1PR06MB1675.eurprd06.prod.outlook.com>

Hello,
I disagree with the proposal.

Any such proposal would cause issues with ability of smaller players merging into larger ones, effectively blocking them becoming competitive to the long established LIRs, effectively giving an unfair advantage to the big players.

Kind Regards,
Dominik
Clouvider Limited

From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Remco van Mook
Sent: 17 May 2016 13:08
To: Marco Schmidt <mschmidt at ripe.net>
Cc: address-policy-wg at ripe.net
Subject: Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)


Thank you Marco.

Dear colleagues,

Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.

The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.

We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:

- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.

And, outside of policy but enforceable as business rules following from this policy proposal:
- No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
- No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22

Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.

Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.

Kind regards,

Remco van Mook
(no hats)


On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net<mailto:mschmidt at ripe.net>> wrote:

Dear colleagues,

A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
is now available for discussion.

The goal of this proposal is to limit IPv4 from the remaining address pool
to one /22 per LIR (regardless of how it was received).
These ?final /22? allocations will receive a separate status with several restrictions:

-    These allocation are not transferrable
-    LIRs may only retain one final /22 following a merger or acquisition
-    Sub-allocations are not possible
-    Reverse delegation authority can not delegated to another party

You can find the full proposal at:

   https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this proposal and send your comments to
<address-policy-wg at ripe.net<mailto:address-policy-wg at ripe.net>> before 15 June 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/fffde693/attachment.html>

From nick at foobar.org  Tue May 17 15:01:17 2016
From: nick at foobar.org (Nick Hilliard)
Date: Tue, 17 May 2016 14:01:17 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <573B161D.3090908@foobar.org>

Like the curate's egg, this proposal is good in parts. Here's the good part:

> - Explicitly state that the current IPv4 allocation policy applies to
> all available IPv4 address space held by the RIPE NCC that has not
> been reserved or marked to be returned to IANA

The rest of the proposal is - like the rest of the curate's egg - best
deposited in the compost bin.

Specifically, it will not deal with the problem that the RIPE NCC was
set up to do, namely to ensure accurate registration of resources.  On
the contrary, it will encourage black-market transfer of /22s and
probably a proliferation of one-allocation-per-shelf-company
allocations, because paying ?1400 per annum for 1024 addresses is still
a cheaper option in the medium term than buying addresses outright on
the market (1024/?1400 = ?0.73 per address per annum).

At this stage, APWG is being trolled with "let's change the last /8
policy" proposals.  It's clear that there isn't consensus on 2015-05 and
that there won't be any consensus on this proposal either, so I'd
politely like to ask the chairs to do two things:

1. declare their opinion on whether 2015-05 reached consensus

2. use the bunfight which is inevitably going to happen in Copenhagen to
allow them to exercise more restraint about what sort of proposals hit
the mailing list in future so that we don't spend years wasting time
squabbling about the dregs sitting at the bottom of the ipv4 allocation
barrel.

(ap-wg chairs: for the record, this is a "I object" email).

Nick



From bogdan at rotariu.ro  Tue May 17 15:03:33 2016
From: bogdan at rotariu.ro (Bogdan-Stefan Rotariu)
Date: Tue, 17 May 2016 16:03:33 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <etPan.573b16a5.1e9481a0.2b7@doohs-iMac>

Dear Remco,

For a few months now, we have been talking on how to give some supplementary IP?s to LIR?s and now you are proposing a policy to retrieve back some already allocated IP space?

Even if we are in the afterlife of IPv4, you cannot force the return of /22?s from the last /8 after a merger or acquisition.

How do will RIPE plan to deal with the already transferred /22?s from the /8, or the already sub allocated IP spaces?
There are many LIR?s that announce more than 1 /22?s from the /8, we should try to focus on the abuse and not dramatically change a policy that almost works.

At this moment I have no idea how but maybe we should implement an anti-abuse policy with full powered department that can deal with ?creative interpretations??

I really do understand your good intention here but instead of fixing the ?creative interpretations? it will cause more and more issues.

I am against this proposal as it is unfair, and some or maybe of us do not agree with?retroactively policies, we already know how the work from our?governments?:)

Thanks,


--?
Bogdan-Stefan Rotariu
Sent with Airmail

On 17 May 2016 at 15:09:14, Remco van Mook (remco.vanmook at gmail.com) wrote:


Thank you Marco.?

Dear colleagues,

Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.

The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.

We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:

- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);?
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.

And, outside of policy but enforceable as business rules following from this policy proposal:
- No RPKI?for any 'ALLOCATED FINAL' blocks over a single /22
- No routing registry entries?for any 'ALLOCATED FINAL' blocks over a single /22

Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.

Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.

Kind regards,

Remco van Mook
(no hats)


On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net> wrote:

Dear colleagues,

A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
is now available for discussion.

The goal of this proposal is to limit IPv4 from the remaining address pool
to one /22 per LIR (regardless of how it was received).
These ?final /22? allocations will receive a separate status with several restrictions:

- ???These allocation are not transferrable
- ???LIRs may only retain one final /22 following a merger or acquisition
- ???Sub-allocations are not possible
- ???Reverse delegation authority can not delegated to another party

You can find the full proposal at:

???https://www.ripe.net/participate/policies/proposals/2016-03

We encourage you to review this proposal and send your comments to
<address-policy-wg at ripe.net> before 15 June 2016.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/3652b512/attachment.html>

From office at ip4market.ru  Tue May 17 15:14:01 2016
From: office at ip4market.ru (Staff)
Date: Tue, 17 May 2016 16:14:01 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <HE1PR06MB1675ED925F0B497BE365F3CBF2480@HE1PR06MB1675.eurprd06.prod.outlook.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <HE1PR06MB1675ED925F0B497BE365F3CBF2480@HE1PR06MB1675.eurprd06.prod.outlook.com>
Message-ID: <0f2c6255-7562-4f33-e886-d0a7a1741388@ip4market.ru>

I disagree with the proposal too. That's another one bad policy example.

1) small companies will be very hard to join ipv4.
2) unfair play between big and small IPv4 owners.
3) in final that will not change current IPv4 distribution from last /8
significantly.

Any policy should help people to use global Ipv4 space effectively for
progress, but I can't see anything in this one policity that would help.

If the policy reason is just to make all Ipv4 management/getting harder
- may be just close giving IPv4 and that all?

The policy should make the world simple but not harder.

I talk a lot of with new small companies who want to start with IPv4.
They say bad about too much RIPE rules and police. For beginners it's
too hard to join all this, and this policy make it harder.


Yuri at IP4market


On 17.05.2016 15:58, Dominik Nowacki wrote:
> Hello,
> 
> I disagree with the proposal.
> 
>  
> 
> Any such proposal would cause issues with ability of smaller players
> merging into larger ones, effectively blocking them becoming competitive
> to the long established LIRs, effectively giving an unfair advantage to
> the big players.
> 
>  
> 
> Kind Regards,
> 
> Dominik
> 
> Clouvider Limited
> 
>  
> 
> *From:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On
> Behalf Of *Remco van Mook
> *Sent:* 17 May 2016 13:08
> *To:* Marco Schmidt <mschmidt at ripe.net>
> *Cc:* address-policy-wg at ripe.net
> *Subject:* Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking
> Down the Final /8 Policy)
> 
>  
> 
>  
> 
> Thank you Marco. 
> 
>  
> 
> Dear colleagues,
> 
>  
> 
> Yes, this is another policy proposal about IPv4. It's even about the
> current allocation policy (confusingly known as 'last /8'). I'm sorry
> it's come to this.
> 
>  
> 
> The proposal doesn't aim to change a lot about the *intended* goals of
> the last /8 policy - instead, it tries to clarify the current policy and
> lock it down against creative interpretations.
> 
>  
> 
> We're in the IPv4 afterlife, and have been for about 3.5 years. The last
> scrap of IPv4 space that any LIR can get is meant for a specific purpose
> - to facilitate migration to IPv6. The age of the 32 bit integers is
> over. The other purpose of the 'last /8' policy is to be able to hand
> out IPv4 space to new entrants for as long as feasible. These specific
> purposes are currently not reflected anywhere once a block has been
> allocated, and this proposal means to change that. To summarise the
> proposed changes:
> 
>  
> 
> - All allocations handed out under the 'last /8 policy' will be
> (re-)registered as 'ALLOCATED FINAL';
> 
> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or
> sub-allocated;
> 
> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space,
> regardless of how they got it;
> 
> - Any excess space will have to be returned to the RIEP NCC within 180
> days (however I don't intend that this is applied retroactively); 
> 
> - DNS reverse delegation will be limited to the LIR itself, and is
> limited to a total of a /22 in space.
> 
>  
> 
> And, outside of policy but enforceable as business rules following from
> this policy proposal:
> 
> - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
> 
> - No routing registry entries for any 'ALLOCATED FINAL' blocks over a
> single /22
> 
>  
> 
> Basically, every LIR gets 1 allocation, and if you no longer need it or
> you end up having more, you have to return the excess. All the extra
> limitations should be workable if you're using the space the way it was
> intended, but make it unattractive to collect allocations for other
> purposes.
> 
>  
> 
> Let's hear your thoughts. I'll be at the RIPE meeting next week where
> I'll be talking about this proposal during the first APWG session.
> 
>  
> 
> Kind regards,
> 
>  
> 
> Remco van Mook
> 
> (no hats)
> 
>  
> 
>  
> 
>     On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net
>     <mailto:mschmidt at ripe.net>> wrote:
> 
>      
> 
>     Dear colleagues,
> 
>     A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>     is now available for discussion.
> 
>     The goal of this proposal is to limit IPv4 from the remaining
>     address pool
>     to one /22 per LIR (regardless of how it was received).
>     These ?final /22? allocations will receive a separate status with
>     several restrictions:
> 
>     -    These allocation are not transferrable
>     -    LIRs may only retain one final /22 following a merger or
>     acquisition
>     -    Sub-allocations are not possible
>     -    Reverse delegation authority can not delegated to another party
> 
>     You can find the full proposal at:
> 
>        https://www.ripe.net/participate/policies/proposals/2016-03
> 
>     We encourage you to review this proposal and send your comments to
>     <address-policy-wg at ripe.net <mailto:address-policy-wg at ripe.net>>
>     before 15 June 2016.
> 
>     Regards
> 
>     Marco Schmidt
>     Policy Development Officer
>     RIPE NCC
> 
>  
> 




From jim at rfc1035.com  Tue May 17 15:18:58 2016
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 17 May 2016 14:18:58 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <573B161D.3090908@foobar.org>
References: <573B0906.3060708@ripe.net> <573B161D.3090908@foobar.org>
Message-ID: <6F88A694-84CE-49EB-97DD-3C4D617C1195@rfc1035.com>


> On 17 May 2016, at 14:01, Nick Hilliard <nick at foobar.org> wrote:
> 
> so that we don't spend years wasting time squabbling about the dregs sitting at the bottom of the ipv4 allocation barrel.

However... our mission, if we choose to accept it, could be to waste time squabbling over these last dregs policy proposals until long after the IPv4 pool has gone. :-)




From jim at rfc1035.com  Tue May 17 15:35:38 2016
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 17 May 2016 14:35:38 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <20160517135221.GC862@cilantro.c4inet.net>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <20160517135221.GC862@cilantro.c4inet.net>
Message-ID: <5CDC0E8F-C443-43B8-ABFD-8ABE651250F9@rfc1035.com>


> On 17 May 2016, at 14:52, Sascha Luck [ml] <apwg at c4inet.net> wrote:
> 
> So it puts new entrants at a competitive disadvantage to existing LIRs?

It has been that way ever since SRI first started doling out Class A, B and C blocks in the 1980s.

No matter what the prevailing policy might be, new LIRs are by definition going to be disadvantaged because the NCC and the RIR system more generally has a far smaller (and almost empty) pool of IPv4 address space to allocate from. Get over it. We can?t conjure up an infinite supply of IPv4 space to give everyone at least as much as they think they need. The only question now is to decide what?s the best or least worst to share that pain of distributing what?s left.




From gert at space.net  Tue May 17 15:38:44 2016
From: gert at space.net (Gert Doering)
Date: Tue, 17 May 2016 15:38:44 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B161D.3090908@foobar.org>
References: <573B0906.3060708@ripe.net>
 <573B161D.3090908@foobar.org>
Message-ID: <20160517133844.GG3978@Space.Net>

Hi,

On Tue, May 17, 2016 at 02:01:17PM +0100, Nick Hilliard wrote:
> I'd politely like to ask the chairs to do two things:
> 
> 1. declare their opinion on whether 2015-05 reached consensus

Right now, we have no consensus to move forward.  We're currently 
discussing with the proposers what to do next - extend the discussion 
phase (to formally include the RIPE72 AP WG meeting), or withdraw.

> 2. use the bunfight which is inevitably going to happen in Copenhagen to
> allow them to exercise more restraint about what sort of proposals hit
> the mailing list in future so that we don't spend years wasting time
> squabbling about the dregs sitting at the bottom of the ipv4 allocation
> barrel.

I'm hearing you, and we think this discussion is indeed necessary (to be
held on wednesday about 09:30-10:30) to see whether there is general WG
consensus to move towards a more liberal (2015-05-ish), strict (2016-03-ish),
or "leave it as it is!" last /8 policy.  And then, decide what to do with
upcoming policy proposals.

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/45922147/attachment.sig>

From aleksbulgakov at gmail.com  Tue May 17 17:03:36 2016
From: aleksbulgakov at gmail.com (Aleksey Bulgakov)
Date: Tue, 17 May 2016 18:03:36 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <20160517133844.GG3978@Space.Net>
References: <573B0906.3060708@ripe.net> <573B161D.3090908@foobar.org>
 <20160517133844.GG3978@Space.Net>
Message-ID: <CAOcKdzsaqNRcUHXefWFOWHrmv8seWNyaxrY+vbLV7=DioLUjGQ@mail.gmail.com>

ALLOCATED FINAL: This address space has been allocated to an LIR and
no assignments made from it are portable.

What does it mean "are portable"?

2016-05-17 16:38 GMT+03:00 Gert Doering <gert at space.net>:
> Hi,
>
> On Tue, May 17, 2016 at 02:01:17PM +0100, Nick Hilliard wrote:
>> I'd politely like to ask the chairs to do two things:
>>
>> 1. declare their opinion on whether 2015-05 reached consensus
>
> Right now, we have no consensus to move forward.  We're currently
> discussing with the proposers what to do next - extend the discussion
> phase (to formally include the RIPE72 AP WG meeting), or withdraw.
>
>> 2. use the bunfight which is inevitably going to happen in Copenhagen to
>> allow them to exercise more restraint about what sort of proposals hit
>> the mailing list in future so that we don't spend years wasting time
>> squabbling about the dregs sitting at the bottom of the ipv4 allocation
>> barrel.
>
> I'm hearing you, and we think this discussion is indeed necessary (to be
> held on wednesday about 09:30-10:30) to see whether there is general WG
> consensus to move towards a more liberal (2015-05-ish), strict (2016-03-ish),
> or "leave it as it is!" last /8 policy.  And then, decide what to do with
> upcoming policy proposals.
>
> 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 (0)89/32356-444           USt-IdNr.: DE813185279



-- 
----------
Best regards,
Aleksey Bulgakov
Tel.: +7 (926)690-87-29



From remco.vanmook at gmail.com  Tue May 17 17:27:07 2016
From: remco.vanmook at gmail.com (=?utf-8?B?cmVtY28udmFubW9va0BnbWFpbC5jb20=?=)
Date: Tue, 17 May 2016 17:27:07 +0200
Subject: [address-policy-wg]
 =?utf-8?q?2016-03_New_Policy_Proposal_=28Lock?=
 =?utf-8?q?ing_Down_the_Final_/8_Policy=29?=
Message-ID: <573b384b.8a37c20a.82daa.2d1d@mx.google.com>

It means it's not allocated PI, in line with the other definitions in chapter 7.

Remco

Sent from my HTC

----- Reply message -----
From: "Aleksey Bulgakov" <aleksbulgakov at gmail.com>
To: "Gert Doering" <gert at space.net>
Cc: "Marco Schmidt" <mschmidt at ripe.net>, "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Date: Tue, May 17, 2016 17:03

ALLOCATED FINAL: This address space has been allocated to an LIR and
no assignments made from it are portable.

What does it mean "are portable"?

2016-05-17 16:38 GMT+03:00 Gert Doering <gert at space.net>:
> Hi,
>
> On Tue, May 17, 2016 at 02:01:17PM +0100, Nick Hilliard wrote:
>> I'd politely like to ask the chairs to do two things:
>>
>> 1. declare their opinion on whether 2015-05 reached consensus
>
> Right now, we have no consensus to move forward.  We're currently
> discussing with the proposers what to do next - extend the discussion
> phase (to formally include the RIPE72 AP WG meeting), or withdraw.
>
>> 2. use the bunfight which is inevitably going to happen in Copenhagen to
>> allow them to exercise more restraint about what sort of proposals hit
>> the mailing list in future so that we don't spend years wasting time
>> squabbling about the dregs sitting at the bottom of the ipv4 allocation
>> barrel.
>
> I'm hearing you, and we think this discussion is indeed necessary (to be
> held on wednesday about 09:30-10:30) to see whether there is general WG
> consensus to move towards a more liberal (2015-05-ish), strict (2016-03-ish),
> or "leave it as it is!" last /8 policy.  And then, decide what to do with
> upcoming policy proposals.
>
> 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 (0)89/32356-444           USt-IdNr.: DE813185279



-- 
----------
Best regards,
Aleksey Bulgakov
Tel.: +7 (926)690-87-29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/8d60975d/attachment.html>

From jerome at ceriz.fr  Tue May 17 16:26:45 2016
From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=)
Date: Tue, 17 May 2016 16:26:45 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <ce711b94-f3e6-2e9f-48c3-fd3752afa42e@ceriz.fr>

Hello,

I firmly oppose this policy proposal for the following reasons :

* Interference with routing

I always understood RIPE NCC must not consider routing issues as
legitimate (when justificating address space requests was a thing), the
counterpart could be implicit.

De-agregating a /22 is legitimate in many cases, especially when it's
your only available block. Restricting route objects or RPKI will lead
to *weaken routing's security* and *reduce the registry's quality*.

It would also make it impossible to mitigate BGP hijacking if a
legitimate announce cannot counter a more specific illegitimate one.

* Not concise enough

The proposal actually means "Every /8 PA is now a PI". Such policy
should be written in its simpliest form, which in this case is an 8
words sentence.

* Not adressing the multi-LIR issue

If such proposal AND the re-authorization of multiple LIR account per
member both gets to pass, it would almost feel legitimate to create
multiple LIRs in order to be allowed to secure our networks by
de-agregating some critical prefixes off it.

Encouraging the waste of address space seems incompatible with the
community's best interests.

* Unclear non-transferability

There are two kinds of possible transfers :

- The legitimate one is Mergure and Acquisition, which reflects real
network and business events.
- The crook's one is the listing service, used to get profits off
privatizing the public domain.

Only the second one should be banned, or mergure and acquisitions won't
be properly reflected into the registry.

* Unfairness to new entrants

The issue regarding new entrants with legitimate needs for more than a
/22 beeing unable to compete against incubents, who never had to justify
their dispendious tendancies regarding ERXs and over /16 PAs, could be
considered as unlawfull to some market authorities.



Considering these 4 major points (and the pedantic one), I would hope
for immediate dismissal of the proposal.


Best regards,


-- 
J?r?me Nicolle
+33 6 19 31 27 14



From jim at rfc1035.com  Tue May 17 16:26:24 2016
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 17 May 2016 15:26:24 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <06F494B7-D469-486B-BCEE-03C9A8AB5312@rfc1035.com>


> On 17 May 2016, at 13:08, Remco van Mook <remco.vanmook at gmail.com> wrote:
> 
> The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.
> 
> ...
> 
> Let's hear your thoughts.

I broadly agree with Nick?s position.

The clarifying part of 2016-03 should be put into a separate proposal. ie The current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA.

This tweak is just good housekeeping and should be non-controversial. I hope that a new proposal along those lines would get consensus and be quickly adopted since it?s clarifying some unintended confusion in the current policy text.

While I am sort of in agreement with some of the other aspects of 2016-03, these should go into into another proposal because those ideas may well run into troubled waters. It would be a pity if the above clarification got held up because of the likely squabbling over 2016-03?s suggestions on transfers and return of space. It would be better if those two different strands didn?t have to share the same fate. They?re orthogonal to each other too.

Consider this a ?meh? on 2016-03. I don?t support the proposal but I don?t object to it either.


From remco.vanmook at gmail.com  Tue May 17 20:04:50 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Tue, 17 May 2016 20:04:50 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <ce711b94-f3e6-2e9f-48c3-fd3752afa42e@ceriz.fr>
References: <573B0906.3060708@ripe.net>
 <ce711b94-f3e6-2e9f-48c3-fd3752afa42e@ceriz.fr>
Message-ID: <23F67E2B-89CF-4E0A-A6F0-FDE9AD733818@gmail.com>



Hi Jerome,


> On 17 May 2016, at 16:26 , J?r?me Nicolle <jerome at ceriz.fr> wrote:
> 
> Hello,
> 
> I firmly oppose this policy proposal for the following reasons :

I will try to address your objections below:

> 
> * Interference with routing
> 
> I always understood RIPE NCC must not consider routing issues as
> legitimate (when justificating address space requests was a thing), the
> counterpart could be implicit.
> 
> De-agregating a /22 is legitimate in many cases, especially when it's
> your only available block. Restricting route objects or RPKI will lead
> to *weaken routing's security* and *reduce the registry's quality*.
> 
> It would also make it impossible to mitigate BGP hijacking if a
> legitimate announce cannot counter a more specific illegitimate one.
> 

It does not interfere with routing. It specifically states 'up to a total of a /22 of IPv4 space'. It doesn't say it's supposed to be a single block. How you want to carve up that /22 is up to you.


> * Not concise enough
> 
> The proposal actually means "Every /8 PA is now a PI". Such policy
> should be written in its simpliest form, which in this case is an 8
> words sentence.

No, it doesn't mean "every /8 PA is now a PI".  There are some broad similarities with the old PI policy. The concept of "PI" no longer exists in current IPv4 allocation policy except for transfers; an attempt to revive IPv4 PI failed.

> 
> * Not adressing the multi-LIR issue
> 
> If such proposal AND the re-authorization of multiple LIR account per
> member both gets to pass, it would almost feel legitimate to create
> multiple LIRs in order to be allowed to secure our networks by
> de-agregating some critical prefixes off it.
> 
> Encouraging the waste of address space seems incompatible with the
> community's best interests.

I don't see how this wastes address space any more than current policy. I also don't see how you'd need multiple LIRs to 'de-aggregate some critical prefixes'. On top of that, conservation went out the window with the acceptance of 2013-03.


> 
> * Unclear non-transferability
> 
> There are two kinds of possible transfers :
> 
> - The legitimate one is Mergure and Acquisition, which reflects real
> network and business events.
> - The crook's one is the listing service, used to get profits off
> privatizing the public domain.
> 
> Only the second one should be banned, or mergure and acquisitions won't
> be properly reflected into the registry.

I explicitly didn't want to express any opinions on what kind of transfers ought to be allowed. If regular transfers get banned, going through the M&A process - especially with empty shell companies - is trivial; which is why I'm proposing that it doesn't matter how you ended up with those extra blocks; you can't have more than 1.

Right now, it doesn't matter how big or how small your organisation is, or how many address space you need, you get a /22. Once. However, the exception crept in that if you acquire or merge with other companies, this limitation does not currently apply. However practical, this exception needs to be contained if you want to effectively limit the marketability of these blocks.

> 
> * Unfairness to new entrants
> 
> The issue regarding new entrants with legitimate needs for more than a
> /22 beeing unable to compete against incubents, who never had to justify
> their dispendious tendancies regarding ERXs and over /16 PAs, could be
> considered as unlawfull to some market authorities.
> 

Legitimate need or not, setting up new LIRs or shell companies to become LIRs in order to gain extra address space to me is pretty obvious exploitation of a loophole in policy. It's like tax avoidance - it's not illegal but did you really open up a business in Panama for legitimate reasons?
If you think this is unfair, every bit of needs based allocation policy (RFC 2050 and onwards) in the last 20 years has been unfair, and the fact that it's now down to just /22s is more or less irrelevant. No market authorities I'm aware of have objected to allocation policy during the past 2 decades.

It's actually the other way around. Right now, we're all aware of creative interpretation of the current IPv4 allocation policy. If we don't try to address this behaviour, it would be very easy to assume that the community is approving of it. And that is a stick that new entrants a couple of years from now will use against us.

Kind regards,

Remco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/8bdda405/attachment.sig>

From rogerj at gmail.com  Tue May 17 20:12:31 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Tue, 17 May 2016 20:12:31 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>

On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt at ripe.net> wrote:
> Dear colleagues,
>
> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
> is now available for discussion.

What really amaze me. We are using tons of time here in ag-wg talking
over IPv4 while there is not half that activity over in IPv6-wg.


I take that as a statement that everyone know everything there is to
know about IPv6, there are nothing more to discuss or learn, no
questions to ask, we are all using it so very few people are left
behind in IPv4 land... soon to be isolated island not able to talk
with anyone.

... is that how it is?



Why aren't all of you with HUGE and MAJOR problem (sorry for the caps)
with lack of IPv4 address over in IPv6-wg bombing us with question on
how to get out of your current trouble?
Asking all kind of stupid and newbie questions? I'm very sure there
are tons of people standing in line to help you out.

https://www.ripe.net/participate/ripe/wg/ipv6





PS 1 : chairs - I object to this policy and the other one trying to
sort a problem that can't be sorted in IPv4 land, only IPv6 can.


PS 2 : Nick Hillard summarized it very well here:
<start copy>
Like the curate's egg, this proposal is good in parts. Here's the good part:

> - Explicitly state that the current IPv4 allocation policy applies to
> all available IPv4 address space held by the RIPE NCC that has not
> been reserved or marked to be returned to IANA
<end copy>

-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no



From jim at rfc1035.com  Tue May 17 20:23:49 2016
From: jim at rfc1035.com (Jim Reid)
Date: Tue, 17 May 2016 19:23:49 +0100
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
Message-ID: <45984D42-989E-481F-A58D-53EE7E3077A0@rfc1035.com>


> On 17 May 2016, at 19:12, Roger J?rgensen <rogerj at gmail.com> wrote:
> 
> What really amaze me. We are using tons of time here in ag-wg talking
> over IPv4 while there is not half that activity over in IPv6-wg.

Indeed. It?s like the old joke about politics in academia: the bickering and in-fighting is so acrimonious because the stakes are so low.

Mind you, IPv6 address allocation policy is such a no-brainer it doesn?t need much work. 

Perhaps we can keep discussions on IPv4 allocation policies going until after the heat death of the universe. :-)




From aleksbulgakov at gmail.com  Tue May 17 20:24:45 2016
From: aleksbulgakov at gmail.com (Aleksey Bulgakov)
Date: Tue, 17 May 2016 21:24:45 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
Message-ID: <CAOcKdzve9u9j+NF-T9qnirrYKbnV7N8exrZJ6Tvu-NZn7q_fnw@mail.gmail.com>

5.1.4. All allocations will be marked in the RIPE database as ?ALLOCATED FINAL?

Does it mean that all IPs from the 185./8 will be markead as
?ALLOCATED FINAL? or I am wrong?

2016-05-17 21:12 GMT+03:00 Roger J?rgensen <rogerj at gmail.com>:
> On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt at ripe.net> wrote:
>> Dear colleagues,
>>
>> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>> is now available for discussion.
>
> What really amaze me. We are using tons of time here in ag-wg talking
> over IPv4 while there is not half that activity over in IPv6-wg.
>
>
> I take that as a statement that everyone know everything there is to
> know about IPv6, there are nothing more to discuss or learn, no
> questions to ask, we are all using it so very few people are left
> behind in IPv4 land... soon to be isolated island not able to talk
> with anyone.
>
> ... is that how it is?
>
>
>
> Why aren't all of you with HUGE and MAJOR problem (sorry for the caps)
> with lack of IPv4 address over in IPv6-wg bombing us with question on
> how to get out of your current trouble?
> Asking all kind of stupid and newbie questions? I'm very sure there
> are tons of people standing in line to help you out.
>
> https://www.ripe.net/participate/ripe/wg/ipv6
>
>
>
>
>
> PS 1 : chairs - I object to this policy and the other one trying to
> sort a problem that can't be sorted in IPv4 land, only IPv6 can.
>
>
> PS 2 : Nick Hillard summarized it very well here:
> <start copy>
> Like the curate's egg, this proposal is good in parts. Here's the good part:
>
>> - Explicitly state that the current IPv4 allocation policy applies to
>> all available IPv4 address space held by the RIPE NCC that has not
>> been reserved or marked to be returned to IANA
> <end copy>
>
> --
>
> Roger Jorgensen           | ROJO9-RIPE
> rogerj at gmail.com          | - IPv6 is The Key!
> http://www.jorgensen.no   | roger at jorgensen.no
>



-- 
----------
Best regards,
Aleksey Bulgakov
Tel.: +7 (926)690-87-29



From krb at enicom.ru  Tue May 17 20:28:27 2016
From: krb at enicom.ru (=?windows-1251?B?yvPv8Oj/7e7iINDu7ODt?=)
Date: Tue, 17 May 2016 20:28:27 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the
	Final /8 Policy)
Message-ID: <98089212.20160517202827@enicom.ru>

Dear colleagues,

It's  no secret that the remaining blocks IPV4 - is the object of sale and purchase some sort of business. And this is a
problem.

Respected  community,  we  should  think  about and finally form an idea and a road map how to finally bury the IPV4 and
motivation to develop the path to go to the Internet to IPV6 irrevocably. Otherwise we will be until the end of his life
to stagnate and share of long-dead body IPV4.

----------
Best regards,
Kupriyanov Roman   (ru.enigma)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3068 bytes
Desc: S/MIME Cryptographic Signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/7dd47937/attachment.p7s>

From gert at space.net  Tue May 17 21:23:39 2016
From: gert at space.net (Gert Doering)
Date: Tue, 17 May 2016 21:23:39 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <98089212.20160517202827@enicom.ru>
References: <98089212.20160517202827@enicom.ru>
Message-ID: <20160517192339.GI3978@Space.Net>

Hi,

On Tue, May 17, 2016 at 08:28:27PM +0200, ????????? ????? wrote:
> Respected  community,  we  should  think  about and finally form an idea and a road map how to finally bury the IPV4 and
> motivation to develop the path to go to the Internet to IPV6 irrevocably. Otherwise we will be until the end of his life
> to stagnate and share of long-dead body IPV4.

We're all ears.  Please let us know what we should do.

We tried

 - make IPv6 policy as easy as possible
 - offer IPv6 trainings (for free!)
 - require IPv6 in various forms in the IPv4 policy
 - advertise IPv6 at every possible opportunity
 - even have a working group to help people iron out IPv6 problems

Gert
-- 
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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5082 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/5ff7fdbe/attachment.bin>

From aleksbulgakov at gmail.com  Tue May 17 21:29:21 2016
From: aleksbulgakov at gmail.com (Aleksey Bulgakov)
Date: Tue, 17 May 2016 22:29:21 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <20160517192339.GI3978@Space.Net>
References: <98089212.20160517202827@enicom.ru>
 <20160517192339.GI3978@Space.Net>
Message-ID: <CAOcKdzuZucaUFu2YNGFjU=wLNgVSEQir--3dMpcmowHXjsvt4g@mail.gmail.com>

Hi.

Didn't you think to review other /8 or what allocations were made before
2012?
17 ??? 2016 ?. 22:23 ???????????? "Gert Doering" <gert at space.net> ???????:

> Hi,
>
> On Tue, May 17, 2016 at 08:28:27PM +0200, ????????? ????? wrote:
> > Respected  community,  we  should  think  about and finally form an idea
> and a road map how to finally bury the IPV4 and
> > motivation to develop the path to go to the Internet to IPV6
> irrevocably. Otherwise we will be until the end of his life
> > to stagnate and share of long-dead body IPV4.
>
> We're all ears.  Please let us know what we should do.
>
> We tried
>
>  - make IPv6 policy as easy as possible
>  - offer IPv6 trainings (for free!)
>  - require IPv6 in various forms in the IPv4 policy
>  - advertise IPv6 at every possible opportunity
>  - even have a working group to help people iron out IPv6 problems
>
> Gert
> --
> 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 (0)89/32356-444           USt-IdNr.: DE813185279
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/0063b561/attachment.html>

From elvis at velea.eu  Tue May 17 21:31:02 2016
From: elvis at velea.eu (Elvis Daniel Velea)
Date: Tue, 17 May 2016 22:31:02 +0300
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <573B7176.1070704@velea.eu>

Dears,

I oppose to the current policy proposal as written. It does not mean 
that a second version would not be acceptable but this one has a few 
major problems:

On 5/17/16 3:08 PM, Remco van Mook wrote:
>
> Thank you Marco.
>
> Dear colleagues,
>
> Yes, this is another policy proposal about IPv4. It's even about the 
> current allocation policy (confusingly known as 'last /8'). I'm sorry 
> it's come to this.
>
> The proposal doesn't aim to change a lot about the *intended* goals of 
> the last /8 policy - instead, it tries to clarify the current policy 
> and lock it down against creative interpretations.
This is true. However, it creates several problems and fixes only one. 
The fix - allocations from 'last /8' can not be transferred any longer 
(once this proposal is accepted and becomes policy).
>
> We're in the IPv4 afterlife, and have been for about 3.5 years. The 
> last scrap of IPv4 space that any LIR can get is meant for a specific 
> purpose - to facilitate migration to IPv6. The age of the 32 bit 
> integers is over. The other purpose of the 'last /8' policy is to be 
> able to hand out IPv4 space to new entrants for as long as feasible. 
> These specific purposes are currently not reflected anywhere once a 
> block has been allocated, and this proposal means to change that. To 
> summarise the proposed changes:
>
> - All allocations handed out under the 'last /8 policy' will be 
> (re-)registered as 'ALLOCATED FINAL';
All allocations (as in all those that were allocated since 2012?) or 
only the ones that are going to be allocated once this proposal becomes 
policy?
> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or 
> sub-allocated;
I would agree with the 'no transfer' ban but do not agree with the no 
sub-allocation. If someone wants to 'sub-allocate', they can easily 
create assignments. This can not be enforced except if we forbid the 
creation of sub-allocated PA objects using business rules. But even if 
we use business rules, that will only block the creation of 
sub-allocation blocks to the LIRs that really want to follow every word 
of the policy, the abusers will continue to abuse.
> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, 
> regardless of how they got it;
What if an LIR has already received a transfer of a 'last-/8' block. 
They have paid for it and the RIPE NCC has approved the transfer. 
Requesting those back would lead to the NCC being sued over and over again.

As we have discussed privately, you do not intend for this policy 
proposal to apply retroactively. If that is the case, then you need to 
figure out a solution for those that will have 2 or more 'last-/8' 
blocks before this proposal becomes policy. That is why I believe a 
second version is needed as this one is not clear.
> - Any excess space will have to be returned to the RIEP NCC within 180 
> days (however I don't intend that this is applied retroactively);
If you want this not to be applied retroactively, it must be very clear 
in the policy proposal. It looks like it would not apply retroactively 
the way this proposal is worded but it's not very clear.
> - DNS reverse delegation will be limited to the LIR itself, and is 
> limited to a total of a /22 in space.
How can the NCC enforce this? Why should 'ALLOCATED FINAL' IPv4 blocks 
have specific rules regarding reverse delegation but not the rest? Will 
this not be confusing?
>
> And, outside of policy but enforceable as business rules following 
> from this policy proposal:
> - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
> - No routing registry entries for any 'ALLOCATED FINAL' blocks over a 
> single /22
Just like with reverse delegation, I oppose to having 'special' rules 
for the routing of 'ALLOCATED FINAL' blocks.

Additionally, and this is the reason I mainly oppose, if this proposal 
would become policy it would force every single small company that needs 
IPv4 addresses for its operations to hire someone to handle the 
communication with the RIPE NCC, the routing and the reverse delegation 
for their 'last-/8 allocation'.

Currently most customers of LIRs are redirected to the RIPE NCC (to 
become LIRs and get a /22) if they need (a few) IP addresses. This 
policy proposal forbids the LIR to manage the address space of the small 
- newly created - LIR (their customer).

We currently manage and maintain the address space of several customers 
of ours (LIRs). This policy proposal aims to request each of our 
customers to hire their own IT team because an other entity can not 
manage their 'last-/8' allocation (but it's ok for the other allocations 
they hold).
Forbidding routing/reverse dns to be managed by the large ISP or a 
consultant is one of the big problems of this proposal. Also, this can 
be easily worked around and I doubt the NCC can even enforce this rule.
>
> Basically, every LIR gets 1 allocation, and if you no longer need it 
> or you end up having more, you have to return the excess. All the 
> extra limitations should be workable if you're using the space the way 
> it was intended, but make it unattractive to collect allocations for 
> other purposes.
>
> Let's hear your thoughts. I'll be at the RIPE meeting next week where 
> I'll be talking about this proposal during the first APWG session.

NEWTEXT: 5.1.5: An allocation marked "ALLOCATED FINAL" is valid as long 
as it remains with the LIR it was allocated to. If an LIR, due to 
mergers, acquisitions or other means gains additional allocations marked 
"ALLOCATED FINAL", all but the equivalent of a single /22 will be 
de-registered by the RIPE NCC within 180 days.

Let's take the following example:

LIR A receives their 'last-/8' allocation in 2014.
In 2015 it transfers (transfer or merger) an other 'last-/8' allocation.
In 2016Q2 this policy proposal is approved and the RIPE NCC updates the 
RIPE Database objects. Now they have two 'ALLOCATED FINAL' blocks.
In 2016Q4 they want to transfer a non-last-/8 allocation, will they be 
forced to return one of the two ALLOCATED FINAL blocks?

If not, why?
If yes, how long do you think it will take until the NCC is taken to court?


NEWTEXT: 5.4: [...] Sub-allocations cannot be made from allocations with 
a status of "ALLOCATED FINAL". The meanings of the various "status:" 
attribute values are described in Section 7.0.

Why? What would be the difference between a Sub-allocation and an 
Assignment in this case?
Are we really adding stuff in the policy that works against the 
registration goal?


NEWTEXT 3.0: [...] For "ALLOCATED FINAL" IPv4 address space, authority 
may not be delegated to another party, and the reverse delegation will 
be limited to a total of a /22 of IPv4 address space.

How can this be enforced? Since when is the community or the NCC getting 
involved in how someone manages their network and/or reverse delegation?
Again, how long do you think it will take before the RIPE NCC is taken 
to court for implementing a policy proposal that forces new (small) LIRs 
(or even older, bigger ones) to cancel their contracts with their ISP or 
consultants for the management of their resources/LIR?
>
> Kind regards,
>
> Remco van Mook
> (no hats)
>
Regards,
Elvis
(wearing a fedora while writing this reply)
>
>> On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net 
>> <mailto:mschmidt at ripe.net>> wrote:
>>
>> Dear colleagues,
>>
>> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>> is now available for discussion.
>>
>> The goal of this proposal is to limit IPv4 from the remaining address 
>> pool
>> to one /22 per LIR (regardless of how it was received).
>> These ?final /22? allocations will receive a separate status with 
>> several restrictions:
>>
>> -    These allocation are not transferrable
>> -    LIRs may only retain one final /22 following a merger or acquisition
>> -    Sub-allocations are not possible
>> -    Reverse delegation authority can not delegated to another party
>>
>> You can find the full proposal at:
>>
>> https://www.ripe.net/participate/policies/proposals/2016-03
>>
>> We encourage you to review this proposal and send your comments to
>> <address-policy-wg at ripe.net <mailto:address-policy-wg at ripe.net>> 
>> before 15 June 2016.
>>
>> Regards
>>
>> Marco Schmidt
>> Policy Development Officer
>> RIPE NCC
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/623eb48b/attachment.html>

From ripe-wgs at radu-adrian.feurdean.net  Tue May 17 22:13:43 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 17 May 2016 22:13:43 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
Message-ID: <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>

On Tue, May 17, 2016, at 14:46, Remco van Mook wrote:
> > So this includes LIR's who already have (through acquisition of other companies) multiple /22 from the last /8
> 
> It doesn't apply retroactively - so if you have already merged LIRs and
> are currently holding multiple /22s form the final /8 you're fine. It
> does stop future cases though.

This is not exactly my reading of the new 5.1.5.
If a LIR already holds several /22 and stays the way it is, OK, it stays
the same.
However, if a LIR, holding several "last /22" *today* acquires another
LIR having a "last /22" and proceeds to a merger, in my reading it is
supposed to loose the equivalent of "last /8 space" it already has.

And I this cannot stop me thinking about the incitation of keeping as
many LIRs as possible alive. You can always buy another company and keep
the LIR, and this will be exactly what will happen if this policy gets
implemented.
This is basically a first (err, or is it a second) step to transforming
RIPE NCC to a profitable "for profit" company. And if it will not be
RIPE NCC getting the profits, it will be the "old LIRs" getting all the
benefits (one single membership fee instead of several). I can see a hat
there....

Otherwise:
 - still no incitation to deploy IPv6. Zero. Nada. a.k.a. "IPv4 is good,
 please go to the market; IPv6 really is irrelevant".
 - I don't get the point for the "reverse delegation restriction". BTW,
 how do you define "another party" ?
 - see the arguments for 2015-05 (I suppose this proposal is just the
 counter-reaction to that one), what you say is just dust in new
 entrants' eyes : "you have a /22 to start, but nothing more to live".
 It also misses the point of what is a "new entrant" today : i.e. not
 always someone prepared to do the "registry" job - "registry" like the
 "R" in LIR.

Circumvention : keep up with multiple LIRs, for NCC's profit.

But after all, I can also understand the very high possibility that this
proposal is only a bad joke (even it we're May 15th, not April 1st).

Just in case it's not clear, I'm completely against.
--
Radu-Adrian FEURDEAN
fr.ccs



From ripe-wgs at radu-adrian.feurdean.net  Tue May 17 22:45:37 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Tue, 17 May 2016 22:45:37 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
Message-ID: <1463517937.1744118.610738265.5015CF10@webmail.messagingengine.com>

On Tue, May 17, 2016, at 20:12, Roger J?rgensen wrote:

> Why aren't all of you with HUGE and MAJOR problem (sorry for the caps)
> with lack of IPv4 address over in IPv6-wg bombing us with question on
> how to get out of your current trouble?

Most probably because some of us did our part in IPv6 deployment to the
extent we are allowed to do by our management, but the problem is
elsewhere.
In my precise case:
 - left $JOB[-3] in an "5 stars-ready" state 4 years ago (there was no
 5th star at that time), and it's still 5 stars at this day. 4 "on-net"
 offices fully dual-staked. IPv6 on auto-pilot since about one year.
 - left $JOB[-1] with 5 stars. Auto-pilot until recently (when it almost
 crashed).
 - $JOB[0] (current) : pretty successful deployment for residential,
 pretty *UN*-successful on pro (some customers accept getting IPv6 by
 default, some don't, some others insert their v4-only equipment),
 almost complete failure on corporate ("no time to waste on this"). NOC
 is dual-stacked, rest of the company office staff (~90%) - no plans for
 the next 5-10 years.

Still no change in the need for v4 address space. And don't tell me
about CGN, address market is almost a better choice.

So, what questions would you like me to bomb ipv6-wg with ?



From gert at space.net  Tue May 17 22:49:52 2016
From: gert at space.net (Gert Doering)
Date: Tue, 17 May 2016 22:49:52 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAOcKdzuZucaUFu2YNGFjU=wLNgVSEQir--3dMpcmowHXjsvt4g@mail.gmail.com>
References: <98089212.20160517202827@enicom.ru>
 <20160517192339.GI3978@Space.Net>
 <CAOcKdzuZucaUFu2YNGFjU=wLNgVSEQir--3dMpcmowHXjsvt4g@mail.gmail.com>
Message-ID: <20160517204952.GK3978@Space.Net>

Hi,

On Tue, May 17, 2016 at 10:29:21PM +0300, Aleksey Bulgakov wrote:
> Didn't you think to review other /8 or what allocations were made before
> 2012?

How's that going to bury IPv4 and "develop the path to go to the Internet
to IPv6"?

Folks, the only way to move towards IPv6 is to *do* it.  Stop waiting
for everyone else to move for you, or move first (I've done that - moved
first, that is - 17 years ago!).  Deploy IPv6, and if someone runs 
a service important to your customers that has no IPv6, have your
customers tell them that this someone needs to get work done.

And if your suppliers do not have IPv6, go and find other suppliers that
do have (instead of finding excuses why you still buy IPv4-only products).

It will be lots of work, and lots of argueing, and sometimes it will be
more expensive.  But the wall is coming, and no matter how hard you argue
IPv4 policy will make it last forever.  You're already 5 years too late.

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/71f6a3bd/attachment.sig>

From remco.vanmook at gmail.com  Wed May 18 00:24:32 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Wed, 18 May 2016 00:24:32 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
	the Final /8 Policy)
In-Reply-To: <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
Message-ID: <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>


Radu-Adrian,

can you please clarify and substantiate this part of your response?

> 
> This is basically a first (err, or is it a second) step to transforming
> RIPE NCC to a profitable "for profit" company. And if it will not be
> RIPE NCC getting the profits, it will be the "old LIRs" getting all the
> benefits (one single membership fee instead of several). I can see a hat
> there....

Kind regards,

Remco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160518/13ae098e/attachment.sig>

From tore at fud.no  Wed May 18 08:06:21 2016
From: tore at fud.no (Tore Anderson)
Date: Wed, 18 May 2016 08:06:21 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
Message-ID: <20160518080621.210d6de6@echo.ms.redpill-linpro.com>

Hi Remco,

> Yes, this is another policy proposal about IPv4. It's even about the
> current allocation policy (confusingly known as 'last /8').

The proposal claim to ?explicitly state that the current IPv4
allocation policy applies to all available IPv4 address space held by
the RIPE NCC that has not been reserved or marked to be returned to
IANA?. But is current policy really ambigous in this regard? IIRC this
was already fixed in 2011-03.

> The last scrap of IPv4 space that any LIR can get is meant for a
> specific purpose - to facilitate migration to IPv6.

Actually, that particular clause was removed by 2014-04.

> - All allocations handed out under the 'last /8 policy' will be
> (re-)registered as 'ALLOCATED FINAL';

Okay, whatever, although I am far from certain that this cosmetic change
is worth the risk/trouble (breaking tools etc).

> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or
> sub-allocated;

With regards to transfers, do we have data that show that this is still
a problem that needs fixing after 2015-01 was passed?

With regards to sub-allocations, I fail to understand what problem are
you trying to solve? Isn't delegating resources downstream towards
end-users (i.e., making assignments or sub-allocations) essentially the
whole point of operating an LIR? Stopping LIRs from doing "LIR stuff"
seems ill advised to me - or what am I missing here?

> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space,
> regardless of how they got it;
> - Any excess space will have to be returned to the RIEP NCC within
> 180 days (however I don't intend that this is applied retroactively);

The proposal needs guidance to the NCC as to which specific /22 the NCC
should de-register. The oldest? The least-assigned?

> - DNS reverse delegation will be limited to the LIR itself, and is
> limited to a total of a /22 in space.

Uhm. Why? And how exactly would this be enforced?

> And, outside of policy but enforceable as business rules following
> from this policy proposal:
> - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
> - No routing registry entries for any 'ALLOCATED FINAL' blocks over a
> single /22

Okay, so it's good this is not mentioned in the actual proposed new
policy text (even though it says otherwise in the summary), because
these suggestions makes absolutely zero sense to me. Why would we try to
prevent operators from accurately describing their routing policies in
the RIPE database and publish corresponding ROAs?

> Basically, every LIR gets 1 allocation, and if you no longer need it
> or you end up having more, you have to return the excess. All the
> extra limitations should be workable if you're using the space the
> way it was intended, but make it unattractive to collect allocations
> for other purposes.

I'm quite willing to discuss a policy proposal that focuses on the first
part of this. That is, ensure that a single LIR can only hold a single
"final" /22 and stopping creative hoarding. However, such a proposal
would also need to provide some discussion and preferably hard data
that shows that 2015-01 isn't working.

The extra limitations, however, make this propsal a non-starter for me.
You claim that they're workable "if you're using the space the way it
was intended", but I highly doubt that it was ever the intention of the
RIPE community that an LIR shouldn't be allowed to perform standard LIR
tasks with its final /22 like delegating reverse DNS, creating
sub-allocations, ROAs, route objects, etc.

If on the other hand those restrictions were only meant to impact
"hoader LIRs" with >1 final /22, then it seems to me that the mandatory
de-registration is sufficient as it will automatically implement all of
the proposed restrictions (and more) for the excessive /22s, while
leaving "legitimate" final /22s alone.

(I don't see any text in the actual proposal that implements the ?if
you no longer need it [..], you have to return the excess? requirement
you described above, by the way.)

Tore



From mir at ripe.net  Wed May 18 09:57:41 2016
From: mir at ripe.net (Mirjam Kuehne)
Date: Wed, 18 May 2016 09:57:41 +0200
Subject: [address-policy-wg] New on RIPE Labs: RIPE NCC Membership and
 Available IPv4 Statistics - an Update
In-Reply-To: <09f00658-a353-4393-eade-df89ee8b33c7@ripe.net>
References: <09f00658-a353-4393-eade-df89ee8b33c7@ripe.net>
Message-ID: <7e28a96d-7a47-7ae2-6c8c-ad8d0065c30b@ripe.net>


Dear colleagues,

Ahead of RIPE 72, we wanted to take another look at our membership
statistics. Was membership growth affected by the Executive Board's
resolution preventing multiple LIR accounts? And how will the growth in
new LIRs affect the projected lifespan of the available IPv4 pool?

Please read more on RIPE Labs:

https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-and-available-ipv4-statistics-an-update?pk_campaign=labs&pk_kwd=list-apwg

Kind regards,
Mirjam Kuehne
RIPE NCC



From ripe at liopen.fr  Wed May 18 10:13:15 2016
From: ripe at liopen.fr (Denis Fondras)
Date: Wed, 18 May 2016 10:13:15 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <20160518080621.210d6de6@echo.ms.redpill-linpro.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <20160518080621.210d6de6@echo.ms.redpill-linpro.com>
Message-ID: <20160518081315.GD16361@enforcer.ledeuns.net>

I do not support this proposal as long as this is not cleared :

> With regards to sub-allocations, I fail to understand what problem are
> you trying to solve? Isn't delegating resources downstream towards
> end-users (i.e., making assignments or sub-allocations) essentially the
> whole point of operating an LIR? Stopping LIRs from doing "LIR stuff"
> seems ill advised to me - or what am I missing here?
> 

However I support the spirit of this proposal where allocation from RIPE and
usage of IPv4 should be made harder. If IPv4 requires more work than IPv6 then
perhaps we will see an increase in IPv6 usage (or I might be naive)

> The proposal needs guidance to the NCC as to which specific /22 the NCC
> should de-register. The oldest? The least-assigned?
> 

I don't think so. LIR might be free to give back any /22 it suits better.

Denis



From sander at steffann.nl  Thu May 19 12:03:26 2016
From: sander at steffann.nl (Sander Steffann)
Date: Thu, 19 May 2016 12:03:26 +0200
Subject: [address-policy-wg] Agenda for APWG sessions at RIPE 72
Message-ID: <180D48A6-8595-4C78-9762-F5A0D9B4472B@steffann.nl>

Hi APWG folks,

below you can find a draft for the RIPE address policy WG meeting's
agenda, which will take place in Copenhagen in the following time
slots:

Wednesday, May 25, 09:00 - 10:30
Wednesday, May 25, 11:00 - 12:30

If you have anything else you want to see on the agenda, or if we
need to change anything, please let us know.

The distribution of items to the two timeslot is somewhat subject
to the time spent on discussion - but we'll try to stick to what's
published.

regards,

Sander Steffann,
Gert D?ring
APWG chairs


----------------------------------------------------------------------
Wednesday, 09:00-10:30
----------------------------------------------------------------------

A. Administrative Matters                                        5 min
    (welcome, thanking the scribe, approving the minutes, etc.)


B. WG Chair Selection                                           10 min
    - longest-serving chair (Sander Steffann) stepping down
    - willing to be re-appointed and serve another term


C. Current Policy Topics - Marco Schmidt, NCC PDO               25 min

    - global policy overview
      "what's going on?"

    - common policy topics in all regions
      (end of IPv4, transfers, ...)

    - overview over concluded proposals in the RIPE region
      since RIPE 71

    - brief overview over new proposals

      2016-01 (AAWG) Include Legacy Internet Resource Holders in
                     the Abuse-c Policy

      2016-02 Resource Authentication Key ( RAK ) code for third
              party authentication

      2016-03 Locking Down the Final /8 Policy


F. Discussion of open policy proposals                          50 min

    2015-04 RIPE Resource Transfer Policies
            Erik Bais

    2015-05 Revision of Last /8 Allocation Criteria
            Discussion phase not leading to consensus

    2016-03 Locking Down the Final /8 Policy
            Remco van Mook

    - Discuss the direction of our IPv4 allocation policy in general:
      Is it good enough, do we want it to be more liberal, or do we
      want it to be stricter?


----------------------------------------------------------------------
Wednesday, 11:00-12:30
----------------------------------------------------------------------

Welcome back

G. Market concentration in the transfers of IPv4 space          30 min
    Alain Durand and Gabe Fried


D. Feedback From NCC Registration Service - Andrea Cima         45 min
    (+ discussion with the group)

    - IPv6 /48 potential policy bug
    - Update on ALLOCATED PI/ALLOCATED Unspecified
    - Legacy transfers straight after Inter-RIR transfer
    - Why RIPE NCC asks for prefix to be announced during ASN request
    - IPv4 IXP assignments
    - LIRs collect multiple IPv6 allocations


Y. Open Policy Hour                                             15 min

    The Open Policy Hour is a showcase for your policy ideas.
    If you have a policy proposal you'd like to debut, prior
    to formally submitting it, here is your opportunity.


Z. AOB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160519/c21fbf31/attachment.sig>

From athina.fragkouli at ripe.net  Thu May 19 12:06:57 2016
From: athina.fragkouli at ripe.net (Athina Fragkouli)
Date: Thu, 19 May 2016 12:06:57 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573D7D5F.7050304@ripe.net>
References: <573D7D5F.7050304@ripe.net>
Message-ID: <573D9041.5070803@ripe.net>

Dear Sasha, all,

The concern you raise was addressed back in 2009, when the RIPE
community was discussing three different last /8 policy proposals (the
proposals 2008-06, 2009-3 and 2009-04). All three policy proposals
allowed one single /22 allocation per LIR.

Back then the RIPE NCC received legal advice from external legal
advisers with an expertise in EU Competition Law. The advise was based
on the assumption that each new LIR would receive no more than a single
/22. The RIPE NCC had shared this legal advise with the RIPE community
and has presented on it at RIPE 59 in Lisbon:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2009-October/004743.html
https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20091006/c9513ab7/attachment.pdf
http://ripe59.ripe.net/presentations/pawlik-final-shalsh-8.pdf

The outcome of the advise was the following:

"The proposed final /8 policies are likely to comply with the conditions
of article 81(3) EC: they contribute to optimising distribution and/or
to promoting technical progress; in so doing, they benefit consumers;
they do not appear to impose restrictions which are not indispensable to
the attainment of their objective of optimising the usage of the IPv4
unallocated pool; and they do not eliminate competition in respect of
the IPv4 unallocated pool.
[...]
For future reference, [...] any final /8 policy adopted by the RIPE
Community and implemented by RIPE NCC should:
(i) continue to be adopted by means of the bottom-up, consensus driven
open policy development process of the RIPE Community;
(ii) be as open as possible (i.e., involve as many LIRs as possible,
which is the case for the currently proposed policies); and
(iii) be applied in a clear non-discriminatory manner, and third parties
(new LIRs) should have fair, reasonable and non-discriminatory access."

I would like to highlight that since 2009 article 81(3) has been
renumbered to 101(3) of the Treaty of the Functioning of the European
Union, but the content remains the same:
http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:12008E101

I hope this helps.

Kind regards,

Athina Fragkouli
Head of Legal
RIPE NCC


> Subject: 	Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking
> Down the Final /8 Policy)
> Date: 	Tue, 17 May 2016 14:44:14 +0100
> From: 	Sascha Luck [ml] <apwg at c4inet.net>
> To: 	address-policy-wg at ripe.net
> 
> 
> 
> On Tue, May 17, 2016 at 02:05:26PM +0200, Marco Schmidt wrote:
>>A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>>is now available for discussion.
>>
>>The goal of this proposal is to limit IPv4 from the remaining address pool
>>to one /22 per LIR (regardless of how it was received).
>>These ???final /22??? allocations will receive a separate status with 
>>several restrictions:
>>
>>-    These allocation are not transferrable
>>-    LIRs may only retain one final /22 following a merger or acquisition
>>-    Sub-allocations are not possible
>>-    Reverse delegation authority can not delegated to another party
> 
> I would like to see a statement from NCC Legal on the legality of
> any of these proposals with particular emphasis on EU "barrier to
> entry" legislation.
> 
> rgds,
> Sascha Luck
> 
> 
> 
> 






From woeber at cc.univie.ac.at  Thu May 19 12:35:27 2016
From: woeber at cc.univie.ac.at (Wilfried Woeber)
Date: Thu, 19 May 2016 12:35:27 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <573D96EF.4020808@cc.univie.ac.at>


The only provision in the list of 4 items below which I would support
is the first one: "These allocation[s] are not transferable"

In the case that these addresses are no longer used or needed, they have to be
returned to "Last /8" Pool at the RIPE NCC.

Number 2 - is a non-starter for me, because it is easily circumvented and
difficult to check and to enforce.

Number 3 - has already been commented on, as contradicting the model and mode
of operation of an LIR.

Number 4 - I don't get, neither what the intention is, nor the mechanism to
manage that.

Wilfried

On 2016-05-17 14:05, Marco Schmidt wrote:
> Dear colleagues,
> 
> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
> is now available for discussion.
> 
> The goal of this proposal is to limit IPv4 from the remaining address pool
> to one /22 per LIR (regardless of how it was received).
> These ?final /22? allocations will receive a separate status with several restrictions:
> 
> -    These allocation are not transferrable
> -    LIRs may only retain one final /22 following a merger or acquisition
> -    Sub-allocations are not possible
> -    Reverse delegation authority can not delegated to another party
> 
> You can find the full proposal at:
> 
>     https://www.ripe.net/participate/policies/proposals/2016-03
> 
> We encourage you to review this proposal and send your comments to
> <address-policy-wg at ripe.net> before 15 June 2016.
> 
> Regards
> 
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
> 



From kai.rottleb at knt.io  Thu May 19 13:08:04 2016
From: kai.rottleb at knt.io (Kai Rottleb)
Date: Thu, 19 May 2016 13:08:04 +0200
Subject: [address-policy-wg] comment on "Revision of Last /8 Allocation
	Criteria"
Message-ID: <938BBB2A-64C3-476B-ABCD-D993B4810868@knt.io>

Dear Mr. Schmidt,

I want to make a comment on your proposal "Revision of Last /8 Allocation Criteria?.
https://www.ripe.net/participate/policies/proposals/2015-05 <https://www.ripe.net/participate/policies/proposals/2015-05>

We became RIPE member about 1,5 years ago. We have received one single /22 subnet. Due to groth requirement, we have purchased an additional /23 subnet a few weeks ago in an auction.

In you proposal it is stated that for an additional /22 allocation the member ?must not have transferred any IPv4 address space before?.

I hope this requirement only concernes transfers away from us, not to us. Otherwise I find it very unfair that we are punished for organizing additional subnets in a legal way for our regular business. We don?t intend to trade with those IPs.

Best regards,

Kai Rottleb
 


 
--
KNT Internet, Inh. Kai Rottleb
Riethnordhaeuser Str. 71 
99189 Hassleben, Germany
Mail: 	kai.rottleb at knt.io <mailto:kai.rottleb at knt.io>  
Tel: 	036201 61055
Mobil: 	01723971017

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160519/37705fbd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3575 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160519/37705fbd/attachment.p7s>

From rgori at wirem.net  Fri May 20 08:02:39 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Fri, 20 May 2016 08:02:39 +0200
Subject: [address-policy-wg] comment on "Revision of Last /8 Allocation
 Criteria"
In-Reply-To: <938BBB2A-64C3-476B-ABCD-D993B4810868@knt.io>
References: <938BBB2A-64C3-476B-ABCD-D993B4810868@knt.io>
Message-ID: <69554717-ac70-cab2-4d7d-44a38a1a26f4@wirem.net>

Dear Kai,


Il 19/05/2016 13:08, Kai Rottleb ha scritto:
> Dear Mr. Schmidt,
>
> I want to make a comment on your proposal "Revision of Last /8 
> Allocation Criteria?.
> https://www.ripe.net/participate/policies/proposals/2015-05
>
> We became RIPE member about 1,5 years ago. We have received one single 
> /22 subnet. Due to groth requirement, we have purchased an additional 
> /23 subnet a few weeks ago in an auction.
>
> In you proposal it is stated that for an additional /22 allocation the 
> member ?must not have transferred any IPv4 address space before?.
The statement is "3.1. The LIR has not transferred any IPv4 address 
space to another LIR, a member of another RIR, or an End User."
"transfert [...] to" should be understood as "The LIR has not 
transferred any IPv4 address space out of its registry" that was 
actually even the text in version 1.
>
> I hope this requirement only concernes transfers away from us, not to 
> us. Otherwise I find it very unfair that we are punished for 
> organizing additional subnets in a legal way for our regular business. 
> We don?t intend to trade with those IPs.
This would not affect LIRs that reiceved space.
>
> Best regards,
>
> Kai Rottleb
>
>
>
> --
> KNT Internet, Inh. Kai Rottleb
> Riethnordhaeuser Str. 71
> 99189 Hassleben, Germany
> Mail: kai.rottleb at knt.io <mailto:kai.rottleb at knt.io>
> Tel: 036201 61055
> Mobil: 01723971017
>
regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160520/5f30c048/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160520/5f30c048/attachment.jpg>

From mschmidt at ripe.net  Fri May 20 15:02:43 2016
From: mschmidt at ripe.net (Marco Schmidt)
Date: Fri, 20 May 2016 15:02:43 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
Message-ID: <573F0AF3.6040803@ripe.net>

Dear colleagues,

The Discussion Period for the proposal 2015-05, "Last /8 Allocation 
Criteria Revision"
has been extended until 13 June 2016.

You can find the full proposal at:

     https://www.ripe.net/participate/policies/proposals/2015-05


We encourage you to review this policy proposal and send your comments
to <address-policy-wg at ripe.net>.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC



From alain.bidron at orange.com  Fri May 20 15:09:02 2016
From: alain.bidron at orange.com (alain.bidron at orange.com)
Date: Fri, 20 May 2016 13:09:02 +0000
Subject: [address-policy-wg] [policy-announce] 2015-05 Discussion Period
 extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <573F0AF1.9000903@ripe.net>
References: <573F0AF1.9000903@ripe.net>
Message-ID: <12757_1463749743_573F0C6F_12757_4107_1_2CC74BDED0EEFC42BA4E8BF16103FCCA374A9C20@OPEXCLILM24.corporate.adroot.infra.ftgroup>



Envoy? depuis mon mobile Orange


----- Reply message -----
De : "Marco Schmidt" <mschmidt at ripe.net>
Pour : "policy-announce at ripe.net" <policy-announce at ripe.net>
Objet : [policy-announce] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
Date : ven., mai 20, 2016 15:03



Dear colleagues,

The Discussion Period for the proposal 2015-05, "Last /8 Allocation
Criteria Revision"
has been extended until 13 June 2016.

You can find the full proposal at:

     https://www.ripe.net/participate/policies/proposals/2015-05


We encourage you to review this policy proposal and send your comments
to <address-policy-wg at ripe.net>.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160520/f1e4a53f/attachment.html>

From gert at space.net  Fri May 20 15:17:13 2016
From: gert at space.net (Gert Doering)
Date: Fri, 20 May 2016 15:17:13 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <573F0AF3.6040803@ripe.net>
References: <573F0AF3.6040803@ripe.net>
Message-ID: <20160520131713.GL1755@Space.Net>

Dear Working Group,

On Fri, May 20, 2016 at 03:02:43PM +0200, Marco Schmidt wrote:
> The Discussion Period for the proposal 2015-05, "Last /8 Allocation 
> Criteria Revision" has been extended until 13 June 2016.

this has been decided by proposers and WG chairs based on your discussion
and the upcoming AP meeting at RIPE72 (next wednesday) - keep the proposal
active until after the discussion there (see below), then decide how to
proceed.


From the discussion it was very clear that there is no consensus today
to go ahead - without going into detail, it's clear that there are two
strong factions, one that wants to preserve the remaining /22s for 
"as long as possible", while the other one wants to ease the pain for 
those LIRs that have too little IPv4 today, willing to incur earlier 
total run-out as a consequence.

Given 2016-03 as a proposal that tries to restrict /22 distribution even
more, we now need to basically agree as a working group which is the
path we want to follow

  - leave things as they are (with minor tweaks)
  - be more restrictive (2016-03)
  - be more liberal in handing out addresses (2015-05)

so the chairs have decided that this needs a somewhat wider discussion
than focussing on just the individual proposals - and based on that, the
proposers can then either witdraw, or tweak their proposals to match the
general direction.

We want this discussion to take place next Wednesday, 09:30, in 
Copenhagen (plus remote participation, of course) - mainly because it is
much easier to get a feeling for the "general direction" when doing a
face to face discussion than by e-mail.

Of course, the consequence of that discussion will be "specific proposals
on the list" (or not, we'll see) - so as usual, the consensus building
will still happen here on the list.

See ya next week,

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160520/7a45fb04/attachment.sig>

From rogerj at gmail.com  Sat May 21 09:45:22 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Sat, 21 May 2016 09:45:22 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160520131713.GL1755@Space.Net>
References: <573F0AF3.6040803@ripe.net>
	<20160520131713.GL1755@Space.Net>
Message-ID: <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>

On Fri, May 20, 2016 at 3:17 PM, Gert Doering <gert at space.net> wrote:
> Dear Working Group,
>
> On Fri, May 20, 2016 at 03:02:43PM +0200, Marco Schmidt wrote:
>> The Discussion Period for the proposal 2015-05, "Last /8 Allocation
>> Criteria Revision" has been extended until 13 June 2016.
>
> this has been decided by proposers and WG chairs based on your discussion
> and the upcoming AP meeting at RIPE72 (next wednesday) - keep the proposal
> active until after the discussion there (see below), then decide how to
> proceed.
>
>
> From the discussion it was very clear that there is no consensus today
> to go ahead - without going into detail, it's clear that there are two
> strong factions, one that wants to preserve the remaining /22s for
> "as long as possible", while the other one wants to ease the pain for
> those LIRs that have too little IPv4 today, willing to incur earlier
> total run-out as a consequence.

Since we've supposed to work toward something that can gain consensus
I've got a few questions for the authors, and those supporting 2015-05.


So far all I've heard, I might have missed something, is that there is a
need for more addresses. None have said why, or where there is a
need. Why do you need more addresses and for what?

Be specific, is it for having more address for the end-users? Datacenter?
Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no



From rogerj at gmail.com  Sat May 21 09:55:31 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Sat, 21 May 2016 09:55:31 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <573B0906.3060708@ripe.net>
References: <573B0906.3060708@ripe.net>
Message-ID: <CAKFn1SGNj3CiLOuZFdUqYS+3f6M9Hb2n3NT7ApZ7RLEKYF4e_w@mail.gmail.com>

On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt at ripe.net> wrote:
> Dear colleagues,
>
> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
> is now available for discussion.
>
> The goal of this proposal is to limit IPv4 from the remaining address pool
> to one /22 per LIR (regardless of how it was received).
> These ?final /22? allocations will receive a separate status with several
> restrictions:
>
> -    These allocation are not transferrable
> -    LIRs may only retain one final /22 following a merger or acquisition
> -    Sub-allocations are not possible
> -    Reverse delegation authority can not delegated to another party
>
> You can find the full proposal at:
>
>     https://www.ripe.net/participate/policies/proposals/2016-03
<snip>

Hi all,

Based on the extended discussion on the other proposal on the table
and that we are supposed to work together toward consensus I got
a few questions to the community regarding this proposal.


Since this proposal opened the door on introducing restriction on
an IPv4 block I'll follow that up...

1.) what sort of restriction are we willing to put on address space? How
and where, and in what direction can we think of restriction? On where
it be used? On how it can be used, and what type of restriction?
You have to publish IPv6 for any services/things using this address
space?



2.) the second part of the question, please do not mix it up with the
first one, how can restriction be implemented and enforced? Do we
have to introduce "need based requests" again? RPKI? Withdraw?
Just - if we're following the path of restriction, what tools do we have
available?



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no



From nick at foobar.org  Sat May 21 12:05:16 2016
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 21 May 2016 11:05:16 +0100
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
Message-ID: <574032DC.3020600@foobar.org>

Roger J?rgensen wrote:
> Be specific, is it for having more address for the end-users? Datacenter?
> Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?

[x] all of the above, and more.

This question isn't relevant as it seems - lots of organisations have
their needs and the RIPE NCC cannot and should not be arbiter of whose
need is greatest or should take precedence.

What's relevant is that due to a shortage of IPv4 address space,
businesses are being forced to change business practices.  This impacts
on AP-WG because on the one hand, there are some addresses left at the
bottom of the RIPE NCC barrel, and on the other, many LIRs are looking
at these addresses, realising that if they could only get their hands on
some of them, it would make life a whole lot easier.  AP-WG is seen as a
place that could potentially tilt the balance one way or another, if
only consensus could be gained.

There are no good solutions to the problem at hand, only compromises.
If the current policy is changed to something else, the people who
benefit in the short term will be happier and the people who pay for
this generosity will be disappointed.

And, as has been pointed out repeatedly by many people for many years,
full depletion is only a couple of years down the road, regardless of
what allocation policy is applied.  Any change of policy is little more
than rearranging deck-chairs on the Titanic.

The ship is going down and there is nothing that anyone in the world can
do to prevent this.

Nick




From gert at space.net  Sat May 21 13:20:24 2016
From: gert at space.net (Gert Doering)
Date: Sat, 21 May 2016 13:20:24 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <574032DC.3020600@foobar.org>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
Message-ID: <20160521112024.GR1755@Space.Net>

Hi,

On Sat, May 21, 2016 at 11:05:16AM +0100, Nick Hilliard wrote:
> Roger J?rgensen wrote:
> > Be specific, is it for having more address for the end-users? Datacenter?
> > Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?
> 
> [x] all of the above, and more.
> 
> This question isn't relevant as it seems - lots of organisations have
> their needs and the RIPE NCC cannot and should not be arbiter of whose
> need is greatest or should take precedence.

Right - *but* it might be an interesting idea to turn around this discussion,
away from haggling about the last scraps, into being able to give more 
useful guidance to LIRs.

Like,

  - if you need to connect end-users, best practice is dual-stack with
    native IPv6 and CGNAT IPv4 (it stinks, but gets the job done while
    content is not IPv6 capable everyhwere)

  - if you run a data-center, run ipv6-only on the inside, and add 
    Tore-style NAT46 to give each service a single public IPv4 address
    (insert pointer to RFC...)

etc.

While not truly *APWG* relevant, we could at least find out where the
highest pain is, and then throw the ball over to the IPv6 WG to provide 
solutions :-)  (totally IETF style).

Gert
-- 
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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160521/5db1ed3c/attachment.sig>

From nick at foobar.org  Sat May 21 17:52:05 2016
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 21 May 2016 16:52:05 +0100
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160521112024.GR1755@Space.Net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org> <20160521112024.GR1755@Space.Net>
Message-ID: <57408425.103@foobar.org>

Gert Doering wrote:
> Right - *but* it might be an interesting idea to turn around this discussion,
> away from haggling about the last scraps, into being able to give more 
> useful guidance to LIRs.
> 
> Like,
> 
>   - if you need to connect end-users, best practice is dual-stack with
>     native IPv6 and CGNAT IPv4 (it stinks, but gets the job done while
>     content is not IPv6 capable everyhwere)
> 
>   - if you run a data-center, run ipv6-only on the inside, and add 
>     Tore-style NAT46 to give each service a single public IPv4 address
>     (insert pointer to RFC...)
> 
> etc.
> 
> While not truly *APWG* relevant, we could at least find out where the
> highest pain is, and then throw the ball over to the IPv6 WG to provide 
> solutions :-)  (totally IETF style).

That sounds like an offer to write the document.

Nick



From ripe at liopen.fr  Sat May 21 18:30:10 2016
From: ripe at liopen.fr (Denis Fondras)
Date: Sat, 21 May 2016 18:30:10 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAKFn1SGNj3CiLOuZFdUqYS+3f6M9Hb2n3NT7ApZ7RLEKYF4e_w@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <CAKFn1SGNj3CiLOuZFdUqYS+3f6M9Hb2n3NT7ApZ7RLEKYF4e_w@mail.gmail.com>
Message-ID: <20160521163010.GK16361@enforcer.ledeuns.net>

On Sat, May 21, 2016 at 09:55:31AM +0200, Roger J?rgensen wrote:
> 
> 1.) what sort of restriction are we willing to put on address space? How
> and where, and in what direction can we think of restriction? On where
> it be used? On how it can be used, and what type of restriction?
> You have to publish IPv6 for any services/things using this address
> space?
> 

As long as there is space available on the IPv4 market, there is no need to
change the "no more than one /22 per LIR" rule. Keep the remaining RIR pool for
new entrants.
Once the market is dry, we can relax the rule.

Speaking of IPv6, I can't see what more we can do. We provide address without
justification, we provide tools, documentation and training for free. Many of
us, as a community, are ready to help people not confident to kickstart.
When you ask why IPv6 is not deployed :
- no need : then you'll pay your need for IPv4 at the market price
- not enough information or support : if you need help, the community can help.
- no support from transit provider or equipement vendor : unfortunately, it
  will be hard for RIPE to bring willing IPv6 provider in your area or pay for
  your gear if you can't afford the right provider.



From rgori at wirem.net  Sun May 22 10:25:49 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Sun, 22 May 2016 10:25:49 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
Message-ID: <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>

Hi Roger,

thank you for your questions. I try to answer below


Il 21/05/2016 09:45, Roger J?rgensen ha scritto:
> On Fri, May 20, 2016 at 3:17 PM, Gert Doering <gert at space.net> wrote:
>> Dear Working Group,
>>
>> On Fri, May 20, 2016 at 03:02:43PM +0200, Marco Schmidt wrote:
>>> The Discussion Period for the proposal 2015-05, "Last /8 Allocation
>>> Criteria Revision" has been extended until 13 June 2016.
>> this has been decided by proposers and WG chairs based on your discussion
>> and the upcoming AP meeting at RIPE72 (next wednesday) - keep the proposal
>> active until after the discussion there (see below), then decide how to
>> proceed.
>>
>>
>>  From the discussion it was very clear that there is no consensus today
>> to go ahead - without going into detail, it's clear that there are two
>> strong factions, one that wants to preserve the remaining /22s for
>> "as long as possible", while the other one wants to ease the pain for
>> those LIRs that have too little IPv4 today, willing to incur earlier
>> total run-out as a consequence.
> Since we've supposed to work toward something that can gain consensus
> I've got a few questions for the authors, and those supporting 2015-05.
>
>
> So far all I've heard, I might have missed something, is that there is a
> need for more addresses. None have said why, or where there is a
> need. Why do you need more addresses and for what?
In my opinion there's a trend change from what happened years before.
Standing on  current allocation rate and LIRs sign up rate we can see 
there's general trend in the internet growth.
Internet grew a lot up to 2000-2002 then the trend was pretty the same 
up to few year ago.
I think it's mainly due to the fact that in many countries become an 
"operator" is easier than before
As example in Italy we had many restrictions that made things very 
difficoult without a good capital fund behind.
Nowadays things are easier and many new small operators are coming to 
the market.
The WISP market grew a lot in these years look at You can look at 
Ubiquity or Candium Networks sells.
In Italy is the fiber time and carry and transport fiber optics is 
easier than before.
So, in my opinion that's why we are registering such big growth trend in 
LIR sign ups.
In the meanwhile Last /8 allocation policy in showing out its limits 
that created some competitive problems to new entrants.

And at the same time we (as community) and RIPE NCC as our point of 
coordination weren't able to provide a reable solution to help IPv6 
adoption.
Small operators has less capitals, rsources and experience but the 
policy asked them to act before the big ones.

2015-05 trys to address competivive disvantage of new entrants and small 
operators while reminding everyone there's only a solution: IPv6.
If you try to adopt it you may find your way out of the problem.
The clear suspect I have is that there are too many interest to keep 
calm about IPv6 to save market value of IPv4 as long as possibile.

>
> Be specific, is it for having more address for the end-users? Datacenter?
> Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?
>
>
It's happening: end customers of new operators (read as new LIRs) are 
requesting new services such as datacenters or multihoming and IPv6 
deployment in the meanwhile.
Those are the tipical request that I reiceve. For example to multihome 
and bgp a customer I need a /24
What if I have no address space to provide?  I can ask my customer to 
sign up and he will get a /22 automatically wasting a 3 x /24
I think in many cases this is why we are registering such new sign up 
growth trends.
I already said in past emails that when I started our business of fiber 
optic provider the carrier said to us "ask us for transport and access 
but not for addresses. sign up and get yours"
This is reflecting in all the chain from top to bottom. This could be a 
point where to act. If we turn the request re-introducing justification 
and we turn minimum request to a /24
we can address this kind of problem while slowing down LIRs sign up rate 
to obtain a /23 or /24 to address this kind of requests

hope this help in understand small player needings
regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/55dacb4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/55dacb4d/attachment.jpg>

From rgori at wirem.net  Sun May 22 10:29:37 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Sun, 22 May 2016 10:29:37 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <574032DC.3020600@foobar.org>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
Message-ID: <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>



Il 21/05/2016 12:05, Nick Hilliard ha scritto:
> Roger J?rgensen wrote:
>> Be specific, is it for having more address for the end-users? Datacenter?
>> Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?
> [x] all of the above, and more.
>
> This question isn't relevant as it seems - lots of organisations have
> their needs and the RIPE NCC cannot and should not be arbiter of whose
> need is greatest or should take precedence.
>
> What's relevant is that due to a shortage of IPv4 address space,
> businesses are being forced to change business practices.  This impacts
> on AP-WG because on the one hand, there are some addresses left at the
> bottom of the RIPE NCC barrel, and on the other, many LIRs are looking
> at these addresses, realising that if they could only get their hands on
> some of them, it would make life a whole lot easier.  AP-WG is seen as a
> place that could potentially tilt the balance one way or another, if
> only consensus could be gained.
>
> There are no good solutions to the problem at hand, only compromises.
> If the current policy is changed to something else, the people who
> benefit in the short term will be happier and the people who pay for
> this generosity will be disappointed.
IPv6
>
> And, as has been pointed out repeatedly by many people for many years,
> full depletion is only a couple of years down the road, regardless of
> what allocation policy is applied.  Any change of policy is little more
> than rearranging deck-chairs on the Titanic.
>
> The ship is going down and there is nothing that anyone in the world can
> do to prevent this.
>
> Nick
>
every policy that makes IPv6 adoption a must can help slow down IPv4 
allocation rate and in the meanwhile will even lower IPv4 maket value
that's why there is the so called "no solution"
sorry for brevity, family time....
regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/caccceff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/caccceff/attachment.jpg>

From gert at space.net  Sun May 22 10:36:43 2016
From: gert at space.net (Gert Doering)
Date: Sun, 22 May 2016 10:36:43 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
 <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
Message-ID: <20160522083643.GV1755@Space.Net>

Hi,

On Sun, May 22, 2016 at 10:29:37AM +0200, Riccardo Gori wrote:
> every policy that makes IPv6 adoption a must can help slow down IPv4 
> allocation rate and in the meanwhile will even lower IPv4 maket value
> that's why there is the so called "no solution"
> sorry for brevity, family time....

The problem with that is: by imposing "YOU MUST DO IPv6!" on requestors
that only have a /22 yet (assuming that we could find a meaningful way
to check IPv6 deployment that cannot be cheated) - you're not going to
solve the thing that people are complaining about in this thread:
"old LIRs that have enough IPv4 space and are not deploying IPv6!"

New LIRs - holders of /22 - have all the incentives to deploy IPv6
already (because they do not have enough IPv4 to number everything with
public v4 addresses) - but how would such a policy incentivize a big
content provider that has enough v4, is not growing in number of external
visible services (= doesn't need more v4 addresses), and has no v6?

These are the sore spots today: content and cloud providers - and neither
are likely to fall under this policy.

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/b8613f0f/attachment.sig>

From frettled at gmail.com  Sun May 22 11:33:54 2016
From: frettled at gmail.com (Jan Ingvoldstad)
Date: Sun, 22 May 2016 11:33:54 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160522083643.GV1755@Space.Net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
 <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
 <20160522083643.GV1755@Space.Net>
Message-ID: <CAEffzkxUToV=kYYe2Q3VfqOfoT_DDw2UK87+FAGEkF6vUZ3Gug@mail.gmail.com>

On Sun, May 22, 2016 at 10:36 AM, Gert Doering <gert at space.net> wrote:
>
>
> New LIRs - holders of /22 - have all the incentives to deploy IPv6
> already (because they do not have enough IPv4 to number everything with
> public v4 addresses) - but how would such a policy incentivize a big
> content provider that has enough v4, is not growing in number of external
> visible services (= doesn't need more v4 addresses), and has no v6?
>
> These are the sore spots today: content and cloud providers - and neither
> are likely to fall under this policy.
>
>
Thank you, Gert, for this very concise summary of the major grief that
cannot and will not be solved, neither by 2015-05 nor by 2016-03.


-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/17dd381d/attachment.html>

From tore at fud.no  Sun May 22 12:01:45 2016
From: tore at fud.no (Tore Anderson)
Date: Sun, 22 May 2016 12:01:45 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
Message-ID: <20160522120145.7098fc53@envy.e5.y.home>

* Riccardo Gori

> and we turn minimum request to a /24
> we can address this kind of problem while slowing down LIRs sign up rate 
> to obtain a /23 or /24 to address this kind of requests

This, in isolation, I think is idea worth exploring further.

The minimum allocation size started out as a /19 (cf. ripe-136). Over
time it's been adjusted down to the current /22. I think it might be
prudent to continue this trend at some point.

For example: change it to a /23 at the point when the NCC pool reaches
the equivalent of a /9, and then to a /24 when the pool reaches the
equivalent of a /24.

This would ensure the last /9-equivalent could accomodate three times
as many new entrants (24576) than if we continue with /22s (8192).

One would hope that even though the future new entrants will continue
to need some IPv4 to start their business, the amount will decrease as
IPv6 deployment increases. That is, a new entrant receiving a final /23
in 2017 might find it about as useful the final /22 was to a new
entrant in 2013.

Depending on how the membership fees and the pricing in the second-hand
IPv4 market develops, this could also help discourage abuse: if
everything else remains the same, the cost per address would
essentially double at each adjustment.


Another thing worth considering (separately) is to stop issuing
additional allocations. An "old LIR" (one that held IPv4 allocations on
the 14th of September 2012 that hasn't needed to request its final /22
in the four years since, is likely not growing anyway and that space is
better spent for new entrants. Four years is in any case a much longer
period than the LIRs last allocation was supposed to last.

Basically we'd need to change bullet #2 in ripe-649 section 5.1 to just
say ?an LIR that currently hold or have previously held an IPv4
allocation is not eligible? or something like that. As an added bonus,
we'd then get rid of the quirky unexplained 14-09-2012 date referenced
in the current text.

This would prevent "old LIRs" that are already holding lots of address
space, perhaps mostly unused, from being able to pick up a final /22
anyway. I can easily see that a "new LIR" making very efficient use of
its final /22 while being unable to request another would find this very
unfair, as would the new entrants that inevitably would be denied any
final IPv4 allocations down the line (due to full depletion happening
earlier).

Unfortunately I won't be in Copenhagen so just consider this me
thinking out loud here on the list instead of at the Open Policy Hour.
I'm not going to submit any proposals myself though so anyone should
feel free to take the above ideas and run with them.

Tore



From wilhelm at boeddinghaus.de  Sun May 22 12:27:29 2016
From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus)
Date: Sun, 22 May 2016 12:27:29 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160522120145.7098fc53@envy.e5.y.home>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
Message-ID: <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>

Hi,


Am 22.05.2016 um 12:01 schrieb Tore Anderson:
> * Riccardo Gori
>
>> and we turn minimum request to a /24
>> we can address this kind of problem while slowing down LIRs sign up rate
>> to obtain a /23 or /24 to address this kind of requests
> This, in isolation, I think is idea worth exploring further.
>
> The minimum allocation size started out as a /19 (cf. ripe-136). Over
> time it's been adjusted down to the current /22. I think it might be
> prudent to continue this trend at some point.
>
> For example: change it to a /23 at the point when the NCC pool reaches
> the equivalent of a /9, and then to a /24 when the pool reaches the
> equivalent of a /24.
>
> This would ensure the last /9-equivalent could accomodate three times
> as many new entrants (24576) than if we continue with /22s (8192).
>
> One would hope that even though the future new entrants will continue
> to need some IPv4 to start their business, the amount will decrease as
> IPv6 deployment increases. That is, a new entrant receiving a final /23
> in 2017 might find it about as useful the final /22 was to a new
> entrant in 2013.
>
> Depending on how the membership fees and the pricing in the second-hand
> IPv4 market develops, this could also help discourage abuse: if
> everything else remains the same, the cost per address would
> essentially double at each adjustment.
>
>
> Another thing worth considering (separately) is to stop issuing
> additional allocations. An "old LIR" (one that held IPv4 allocations on
> the 14th of September 2012 that hasn't needed to request its final /22
> in the four years since, is likely not growing anyway and that space is
> better spent for new entrants. Four years is in any case a much longer
> period than the LIRs last allocation was supposed to last.
>
> Basically we'd need to change bullet #2 in ripe-649 section 5.1 to just
> say ?an LIR that currently hold or have previously held an IPv4
> allocation is not eligible? or something like that. As an added bonus,
> we'd then get rid of the quirky unexplained 14-09-2012 date referenced
> in the current text.
>
> This would prevent "old LIRs" that are already holding lots of address
> space, perhaps mostly unused, from being able to pick up a final /22
> anyway. I can easily see that a "new LIR" making very efficient use of
> its final /22 while being unable to request another would find this very
> unfair, as would the new entrants that inevitably would be denied any
> final IPv4 allocations down the line (due to full depletion happening
> earlier).
>
> Unfortunately I won't be in Copenhagen so just consider this me
> thinking out loud here on the list instead of at the Open Policy Hour.
> I'm not going to submit any proposals myself though so anyone should
> feel free to take the above ideas and run with them.
>
> Tore
>

in a membership organisation we have to treat all members equal when it 
comes to distributing the final IPv4 networks. You cannot take the right 
to request the final /22 away just because a member had no need so far 
to ask for it. This should have been put in the policy a few years ago 
(like "you have 4 years to request your /22") , but you cannot change 
this today working backward.

Wilhelm



From gert at space.net  Sun May 22 12:33:24 2016
From: gert at space.net (Gert Doering)
Date: Sun, 22 May 2016 12:33:24 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
 <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
Message-ID: <20160522103323.GW1755@Space.Net>

Hi,

On Sun, May 22, 2016 at 12:27:29PM +0200, Wilhelm Boeddinghaus wrote:
> in a membership organisation we have to treat all members equal when it 
> comes to distributing the final IPv4 networks. You cannot take the right 
> to request the final /22 away just because a member had no need so far 
> to ask for it. This should have been put in the policy a few years ago 
> (like "you have 4 years to request your /22") , but you cannot change 
> this today working backward.

We can change the rules for *future* allocations and have done so a few
times in the past... (along that same line of argument, one could have 
said that "you cannot deny future participants a proper needs-based 
*large* allocation" when going to /22).  There is no set-in-stone 
"right to request the final /22" - there's an IPv4 allocation and 
assignment policy, which sets the rules for future allocation/assignment 
requests, and that currently(!) permits allocation of a single /22.

OTOH, I'm not sure if I see a pressing need here - LIRs that haven't
asked for their /22 yet because they don't need it might just never show
up, because they don't need it...

gert
-- 
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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/8a2d76ba/attachment.sig>

From ripe-wgs at radu-adrian.feurdean.net  Sun May 22 12:45:06 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Sun, 22 May 2016 12:45:06 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
Message-ID: <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>

Remco,

As you may know, the "multiple LIRs" is for the moment least expensive
way of getting around the "one /22" restriction. Combined withe the
removal of "need checking", this very much looks like selling /22 to
anybody willing to pay a sign-up and at least one year of membership.

This may not have been intentional, but it looks to me as a first step
to "turning commercial".

With your proposal, while the idea was to discourage the "multiple LIR"
practice, I have very serious doubts that it will happen this way. Given
the current market price (which is only the most important show-stopper,
but not the only one), with your proposal it would take about 5 years of
membership to get at a similar level. With all that money going to the
NCC. IF the NCC really whishes to keep its not-for-profit status, this
will result in reduced membership, one reduced membership for older
LIRs, but several memberships for the LIRs in "desperate need" (mostly
small new ones).

And of course, it would look more like a business of "leasing
IPv4 blocks".

... and you DO have a NCC hat.

I hope it does clarify my previous e-mail.

On Wed, May 18, 2016, at 00:24, Remco van Mook wrote:
>
> Radu-Adrian, can you please clarify and substantiate this part of your
> response?
>
> > This is basically a first (err, or is it a second) step to
> > transforming RIPE NCC to a profitable "for profit" company. And if
> > it will not be RIPE NCC getting the profits, it will be the "old
> > LIRs" getting all the benefits (one single membership fee instead of
> > several). I can see a hat there....

--
Radu-Adrian FEURDEAN
fr.ccs



From tore at fud.no  Sun May 22 12:58:50 2016
From: tore at fud.no (Tore Anderson)
Date: Sun, 22 May 2016 12:58:50 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160522103323.GW1755@Space.Net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
 <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
 <20160522103323.GW1755@Space.Net>
Message-ID: <20160522125850.2f3c0dc6@envy.e5.y.home>

* Gert Doering

> OTOH, I'm not sure if I see a pressing need here - LIRs that haven't
> asked for their /22 yet because they don't need it might just never
> show up, because they don't need it...

Absolutely true.

However, in my opition it would be more about fixing a couple of
perception problems that leads to policy proposals like 2015-05:

- Complaints ? la ?it's unfair that the haves ("old LIRs") get to
  request additional allocations while we have-nots ("new LIRs") do
  not? will no longer have any merit.

- It'd make sure the NCC's allocation pool is really reserved for new
  entrants. We often claim that it is, but currently that is only a
  half-truth.

Tore



From frettled at gmail.com  Sun May 22 13:02:13 2016
From: frettled at gmail.com (Jan Ingvoldstad)
Date: Sun, 22 May 2016 13:02:13 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
 <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
Message-ID: <CAEffzkz759sY1uzqufMMYUjB5r-5xVrhYSgpwzT-sTdFmLo90g@mail.gmail.com>

On Sun, May 22, 2016 at 12:45 PM, Radu-Adrian FEURDEAN <
ripe-wgs at radu-adrian.feurdean.net> wrote:

> Remco,
>
> As you may know, the "multiple LIRs" is for the moment least expensive
> way of getting around the "one /22" restriction. Combined withe the
> removal of "need checking", this very much looks like selling /22 to
> anybody willing to pay a sign-up and at least one year of membership.
>
> This may not have been intentional, but it looks to me as a first step
> to "turning commercial".
>
> With your proposal, while the idea was to discourage the "multiple LIR"
> practice, I have very serious doubts that it will happen this way. Given
> the current market price (which is only the most important show-stopper,
> but not the only one), with your proposal it would take about 5 years of
> membership to get at a similar level. With all that money going to the
> NCC. IF the NCC really whishes to keep its not-for-profit status, this
> will result in reduced membership, one reduced membership for older
> LIRs, but several memberships for the LIRs in "desperate need" (mostly
> small new ones).
>
>
I don't find your response clarifying in the least.

You seem to be confused about what constitutes non-profit and what
constitutes for-profit or "commercial". Making _a_ profit does not
automatically make you a for-profit/commercial enterprise.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/567669e8/attachment.html>

From nick at foobar.org  Sun May 22 13:10:12 2016
From: nick at foobar.org (Nick Hilliard)
Date: Sun, 22 May 2016 12:10:12 +0100
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
 <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
Message-ID: <57419394.5060503@foobar.org>

Riccardo Gori wrote:
>> There are no good solutions to the problem at hand, only compromises.
>> If the current policy is changed to something else, the people who
>> benefit in the short term will be happier and the people who pay for
>> this generosity will be disappointed.
> IPv6

If ipv6 provided full backwards compatibility with ipv4, it would be a
solution.

Any organisation which is forced into providing ipv4 connectivity using
an ipv6 transition mechanism will operate at a competitive disadvantage
to an organisation which can provide native ipv4.  This isn't a swipe at
ipv6: it's simply an observation that we have come to depend on features
of ipv4 which cannot be fully replicated using ipv6 transition mechanisms.

This is why I referred to migrating to ipv6 as a compromise.  Long term,
it may be a good compromise and many years down the road, it may even be
better than ipv4.  But as long as there are ipv4 addresses available, it
is condemned to being second best by the legacy of the existing
single-stacked ipv4 install base.

> every policy that makes IPv6 adoption a must can help slow down IPv4
> allocation rate and in the meanwhile will even lower IPv4 maket value
> [...]

I don't believe there is any evidence to support either of these statements.

Also, please bear in mind that if strong policies caused better adoption
of new protocols, we would be having this discussion using X.400.

Nick



From ripe-wgs at radu-adrian.feurdean.net  Sun May 22 14:52:08 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Sun, 22 May 2016 14:52:08 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAEffzkz759sY1uzqufMMYUjB5r-5xVrhYSgpwzT-sTdFmLo90g@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
 <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
 <CAEffzkz759sY1uzqufMMYUjB5r-5xVrhYSgpwzT-sTdFmLo90g@mail.gmail.com>
Message-ID: <1463921528.3602938.615112609.59650FB5@webmail.messagingengine.com>

On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote:
> You seem to be confused about what constitutes non-profit and what
> constitutes for-profit or "commercial". Making _a_ profit does not
> automatically make you a for-profit/commercial enterprise.

Investment fund would probably be more appropriate. So is it possible to
have a non-profit investment fund ? For me "non-profit" means not
actively seeking profit; target being a zero end-of year result.



From randy at psg.com  Sun May 22 15:02:36 2016
From: randy at psg.com (Randy Bush)
Date: Sun, 22 May 2016 15:02:36 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
 <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
Message-ID: <m2eg8uxn2r.wl%randy@psg.com>

> in a membership organisation we have to treat all members equal when it 
> comes to distributing the final IPv4 networks.

i think the attached may help here.

we also have to keep in our minds and hearts that we are also stewards
of the internet as a whole; where most people have yet to get online,
and new isp entrants who need addresses will continue to be born.

randy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: equality-vs-equity.jpg
Type: image/jpeg
Size: 328712 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/8cb7ca8e/attachment.jpg>

From frettled at gmail.com  Sun May 22 16:11:07 2016
From: frettled at gmail.com (Jan Ingvoldstad)
Date: Sun, 22 May 2016 16:11:07 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <1463921528.3602938.615112609.59650FB5@webmail.messagingengine.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
 <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
 <CAEffzkz759sY1uzqufMMYUjB5r-5xVrhYSgpwzT-sTdFmLo90g@mail.gmail.com>
 <1463921528.3602938.615112609.59650FB5@webmail.messagingengine.com>
Message-ID: <CAEffzkx1qUosyuTz9e+OvXqoosRp7QV19BxFTOGdVh_f-Lz5Gg@mail.gmail.com>

On Sun, May 22, 2016 at 2:52 PM, Radu-Adrian FEURDEAN <
ripe-wgs at radu-adrian.feurdean.net> wrote:

> On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote:
> > You seem to be confused about what constitutes non-profit and what
> > constitutes for-profit or "commercial". Making _a_ profit does not
> > automatically make you a for-profit/commercial enterprise.
>
> Investment fund would probably be more appropriate. So is it possible to
> have a non-profit investment fund ? For me "non-profit" means not
> actively seeking profit; target being a zero end-of year result.
>

I see no evidence that the RIPE NCC is "actively seeking profit" in any
reasonable sense of that phrase.

Could you please take that rhetoric out by the barn, shoot it, and bury it
in a deep grave, so we don't have to see it anymore?

-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/4123d74a/attachment.html>

From gert at space.net  Sun May 22 16:21:29 2016
From: gert at space.net (Gert Doering)
Date: Sun, 22 May 2016 16:21:29 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <1463921528.3602938.615112609.59650FB5@webmail.messagingengine.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
 <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
 <CAEffzkz759sY1uzqufMMYUjB5r-5xVrhYSgpwzT-sTdFmLo90g@mail.gmail.com>
 <1463921528.3602938.615112609.59650FB5@webmail.messagingengine.com>
Message-ID: <20160522142129.GA1755@Space.Net>

Hi,

On Sun, May 22, 2016 at 02:52:08PM +0200, Radu-Adrian FEURDEAN wrote:
> Investment fund would probably be more appropriate. So is it possible to
> have a non-profit investment fund ? For me "non-profit" means not
> actively seeking profit; target being a zero end-of year result.

And this is what the NCC is doing - target being a zero result.

There is money on the bank accounts, with the goal of being enough to
sustain the NCC for somewhat over a year in case something catastrophic
happens.  If that money were to grow significantly, the NCC would have
to pay taxes, which we all do not want - which is why the surplus was
refunded last year.

(All of this is more a matter for the membership meeting, though, where
detailed financial numbers are presented)

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/48415561/attachment.sig>

From randy at psg.com  Sun May 22 16:42:38 2016
From: randy at psg.com (Randy Bush)
Date: Sun, 22 May 2016 16:42:38 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until
	13	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <m2eg8uxn2r.wl%randy@psg.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
 <dfff3a58-a8d6-b80f-f7a0-c6ae191c4690@boeddinghaus.de>
 <m2eg8uxn2r.wl%randy@psg.com>
Message-ID: <m2a8jixig1.wl%randy@psg.com>

two people said i was not sufficiently obvious, so i hacked a little

-------------- next part --------------
A non-text attachment was scrubbed...
Name: equality-vs-equity copy.jpg
Type: image/jpeg
Size: 353140 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160522/737bfa62/attachment.jpg>

From tore at fud.no  Sun May 22 20:32:56 2016
From: tore at fud.no (Tore Anderson)
Date: Sun, 22 May 2016 20:32:56 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
References: <573B0906.3060708@ripe.net>
 <B8BBB672-5A4C-4B0B-A87A-555DDA1339C0@gmail.com>
 <CAL5RSTJwE7B9kG6rg69OzMBobG-DLQ1S6ai63PmWW_ytC+9bcA@mail.gmail.com>
 <2BCB1967-0DC9-46CE-B2AD-DA31F8023176@gmail.com>
 <1463516023.1736300.610698785.535E8333@webmail.messagingengine.com>
 <21C77A0E-3EC3-4DB6-A9E8-4F404F88F09C@gmail.com>
 <1463913906.3575841.615050713.32772DF2@webmail.messagingengine.com>
Message-ID: <20160522203256.3a23ed7b@envy.e5.y.home>

* Radu-Adrian FEURDEAN

> As you may know, the "multiple LIRs" is for the moment least expensive
> way of getting around the "one /22" restriction. Combined withe the
> removal of "need checking", this very much looks like selling /22 to
> anybody willing to pay a sign-up and at least one year of membership.

I've attempted to explain to you before[1] why this line of reasoning
makes no sense, but I'll try again in case you missed it the first
time around.

The RIPE NCC has always been automatically handing out minimum-sized
initial IPv4 allocations to new members. This you can see already in
ripe-136, which dates all the way back from 1996:

?The first allocation will be made automatically by the RIPE NCC,
generally upon receipt of the first assignment request from the local
IR. Because there is no information about the rate at which a new IR
will make address assignments, the size of the first allocation is
always a /19 (8092 addresses).?

"Need checking" was only used whenever the new LIR requested an initial
allocation *larger* than the minimum allocation size, something the
policy was later updated to allow for. (Figuring out exactly when that
happened is an exercise left for the reader.)

When the ?last /8? policy was implemented, the possibility to request
larger-than-minimal initial allocations was removed, so the procedure
for receiving an initial allocation essentially reverted back to what
it was in 1996: the initial allocation is a fixed size prefix that is
given automatically to any new LIR requesting it.

In short: today's practise of automatically giving minimum-sized
allocation to new LIRs is something the RIPE NCC has been doing since
its inception, and it's all in accordance with the RIPE community's
policies. If you're going to continue to accuse the NCC of ?selling
IPv4?, then you'll have to claim that that's something they've *always*
done, and furthermore that they're currently ?selling IPv6? in exactly
the same way.

Or, even better, you can stop making this nonsensical accusation.

Tore

[1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-May/011215.html



From rogerj at gmail.com  Mon May 23 14:38:00 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Mon, 23 May 2016 14:38:00 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
Message-ID: <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>

On Sun, May 22, 2016 at 10:25 AM, Riccardo Gori <rgori at wirem.net> wrote:

> Hi Roger,
>
> thank you for your questions. I try to answer below
>
> Il 21/05/2016 09:45, Roger J?rgensen ha scritto:
>
> <snip>
>
> Be specific, is it for having more address for the end-users? Datacenter?
> Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?
>
>
>
> It's happening: end customers of new operators (read as new LIRs) are
> requesting new services such as datacenters or multihoming and IPv6
> deployment in the meanwhile.
> Those are the tipical request that I reiceve. For example to multihome and
> bgp a customer I need a /24
> What if I have no address space to provide?  I can ask my customer to sign
> up and he will get a /22 automatically wasting a 3 x /24
> I think in many cases this is why we are registering such new sign up
> growth trends.
> I already said in past emails that when I started our business of fiber
> optic provider the carrier said to us "ask us for transport and access but
> not for addresses. sign up and get yours"
> This is reflecting in all the chain from top to bottom. This could be a
> point where to act. If we turn the request re-introducing justification and
> we turn minimum request to a /24
> we can address this kind of problem while slowing down LIRs sign up rate
> to obtain a /23 or /24 to address this kind of requests
>
>
> hope this help in understand small player needings
>
>
You have given me no real reason, just nice to have. We passed nice to have
some years ago.

End users cannot continue to get a /24, there are not enough address space
for that, sorry but that's life. Sure some operators have enough and that's
unfair for others. Only way for them to get something like that is to
either become LIR, or use IPv6. Why is it so hard to understand that?


So I ask _again_, where is the IPv4 need? What type of usage is it ment
for? We've passed the "it's nice to have" some years ago, now we're down to
, do you _really_ need 10 addresses? Can you survive with 2 and deploy IPv6?



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/d92f3465/attachment.html>

From rgori at wirem.net  Mon May 23 14:48:45 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Mon, 23 May 2016 14:48:45 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
Message-ID: <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>

Hi Roger,


Il 23/05/2016 14:38, Roger J?rgensen ha scritto:
> On Sun, May 22, 2016 at 10:25 AM, Riccardo Gori <rgori at wirem.net 
> <mailto:rgori at wirem.net>> wrote:
>
>     Hi Roger,
>
>     thank you for your questions. I try to answer below
>
>
>     Il 21/05/2016 09:45, Roger J?rgensen ha scritto:
>>     <snip>
>
>>     Be specific, is it for having more address for the end-users? Datacenter?
>>     Services? Infrastructure? IPv6-to-IPv4 services? CGN? Proxyes?
>>
>>
>     It's happening: end customers of new operators (read as new LIRs)
>     are requesting new services such as datacenters or multihoming and
>     IPv6 deployment in the meanwhile.
>     Those are the tipical request that I reiceve. For example to
>     multihome and bgp a customer I need a /24
>     What if I have no address space to provide?  I can ask my customer
>     to sign up and he will get a /22 automatically wasting a 3 x /24
>     I think in many cases this is why we are registering such new sign
>     up growth trends.
>     I already said in past emails that when I started our business of
>     fiber optic provider the carrier said to us "ask us for transport
>     and access but not for addresses. sign up and get yours"
>     This is reflecting in all the chain from top to bottom. This could
>     be a point where to act. If we turn the request re-introducing
>     justification and we turn minimum request to a /24
>     we can address this kind of problem while slowing down LIRs sign
>     up rate to obtain a /23 or /24 to address this kind of requests
>
>     hope this help in understand small player needings
>
>
> You have given me no real reason, just nice to have. We passed nice to 
> have some years ago.
>
> End users cannot continue to get a /24, there are not enough address 
> space for that, sorry but that's life. Sure some operators have enough 
> and that's unfair for others. Only way for them to get something like 
> that is to either become LIR, or use IPv6. Why is it so hard to 
> understand that?
I meant a datacenter to be multihomed.
I consider my customers that hosts a datacenter to be multihomed to be 
end-users since they are interested only in their own business and don't 
care about IP or LIRs stuff.
They just need good quality internet presence and availability.
My tipical business customer is software houses / saas clusters hosting 
company / or datacenter itself.
I would use "consumer" for end user home customer.

>
>
> So I ask _again_, where is the IPv4 need? What type of usage is it 
> ment for? We've passed the "it's nice to have" some years ago, now 
> we're down to , do you _really_ need 10 addresses? Can you survive 
> with 2 and deploy IPv6?
I think I answered, It's not nice to have, It's business demand and LIRs 
should be able to offer... with a /22 I can serve just up to 2 or 3 of 
my tipical business  customers.
This is lack of competitiveness.
>
>
>
> -- 
>
> Roger Jorgensen           | ROJO9-RIPE
> rogerj at gmail.com <mailto:rogerj at gmail.com>          | - IPv6 is The Key!
> http://www.jorgensen.no   | roger at jorgensen.no <mailto:roger at jorgensen.no>
regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/5a8a8e04/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/5a8a8e04/attachment.jpg>

From sander at steffann.nl  Mon May 23 14:57:38 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 23 May 2016 14:57:38 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <57408425.103@foobar.org>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org> <20160521112024.GR1755@Space.Net>
 <57408425.103@foobar.org>
Message-ID: <34E3AFD5-18CC-4F43-AA00-F3C413C35FAF@steffann.nl>

Hi,

> Op 21 mei 2016, om 17:52 heeft Nick Hilliard <nick at foobar.org> het volgende geschreven:
> 
> Gert Doering wrote:
>> Right - *but* it might be an interesting idea to turn around this discussion,
>> away from haggling about the last scraps, into being able to give more
>> useful guidance to LIRs.
>> 
>> Like,
>> 
>>  - if you need to connect end-users, best practice is dual-stack with
>>    native IPv6 and CGNAT IPv4 (it stinks, but gets the job done while
>>    content is not IPv6 capable everyhwere)
>> 
>>  - if you run a data-center, run ipv6-only on the inside, and add
>>    Tore-style NAT46 to give each service a single public IPv4 address
>>    (insert pointer to RFC...)
>> 
>> etc.
>> 
>> While not truly *APWG* relevant, we could at least find out where the
>> highest pain is, and then throw the ball over to the IPv6 WG to provide
>> solutions :-)  (totally IETF style).
> 
> That sounds like an offer to write the document.

Hans Petter just made a nice statement in the opening plenary. I'm taking this to the BCOP session this afternoon to see if we can write this down properly.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/2157590b/attachment.sig>

From rogerj at gmail.com  Mon May 23 14:58:23 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Mon, 23 May 2016 14:58:23 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
Message-ID: <CAKFn1SFLf_jag3h5DQGNgpevsjk94SZPrVNtW1TRNhcA2UGGoA@mail.gmail.com>

On Mon, May 23, 2016 at 2:48 PM, Riccardo Gori <rgori at wirem.net> wrote:

> Hi Roger,
>
> Il 23/05/2016 14:38, Roger J?rgensen ha scritto:
>
> On Sun, May 22, 2016 at 10:25 AM, Riccardo Gori <rgori at wirem.net> wrote:
>
>> Hi Roger,
>>
>> thank you for your questions. I try to answer below
>>
>> Il 21/05/2016 09:45, Roger J?rgensen ha scritto:
>>
>> <snip>
>>
>> So I ask _again_, where is the IPv4 need? What type of usage is it ment
> for? We've passed the "it's nice to have" some years ago, now we're down to
> , do you _really_ need 10 addresses? Can you survive with 2 and deploy IPv6?
>
> I think I answered, It's not nice to have, It's business demand and LIRs
> should be able to offer... with a /22 I can serve just up to 2 or 3 of my
> tipical business  customers.
> This is lack of competitiveness.
>

sorry if I sound hard/insulting, to me it sounds like you have an outdated
business model that are doomed to go down soon, you can't grow this way.
Change to IPv6 where you actual can have some growth and option for the
future.


What you are illustrating is that somehow, despite all the effort from many
parties the world do not seems to understand that there are no more IPv4,
the growth has to come from IPv6.



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/fcd3c6fe/attachment.html>

From randy at psg.com  Mon May 23 14:59:08 2016
From: randy at psg.com (Randy Bush)
Date: Mon, 23 May 2016 14:59:08 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
Message-ID: <m2h9dpvskj.wl%randy@psg.com>

> I meant a datacenter to be multihomed.
> I consider my customers that hosts a datacenter to be multihomed to be 
> end-users since they are interested only in their own business and don't 
> care about IP or LIRs stuff.
> They just need good quality internet presence and availability.

welcome to the post-ipv4 world.  run an ipv6 datacenter and use nat64.

randy



From nick at foobar.org  Mon May 23 15:35:36 2016
From: nick at foobar.org (Nick Hilliard)
Date: Mon, 23 May 2016 14:35:36 +0100
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
Message-ID: <57430728.4000906@foobar.org>

Roger J?rgensen wrote:
>  We've passed the "it's nice to have" some years ago, now we're down
> to , do you _really_ need 10 addresses? Can you survive with 2 and
> deploy IPv6?

No really, we're not.  The RIPE Community exited the "do you really need
X addresses?" stage in 2014.

We're now at the stage where LIRs need to do what they feel is necessary
to preserve their remaining stocks of IP addresses in the way that they
feel is most appropriate for their long term requirements.

There are training courses, policy documents, endless discussions, ARC
checks and more advice available than you can shake a stick at, all of
which is aimed at helping inform LIRs about depletion and what to do.

But ultimately it is up to the LIRs.  Neither the RIPE Community nor the
RIPE NCC has any business beating them with sticks to get them to plan
for their futures.  If they do not do this, it is not the responsibility
of the RIPE NCC or the RIPE Community to do it for them.

If LIRs need more IPv4 address space after their single allocation from
the RIPE NCC, then they need to look on the open market.

If/when the open market dries up or becomes too expensive, then there
will be no options left except ipv6 and/or even more NAT.

Nick



From tore at fud.no  Mon May 23 20:57:29 2016
From: tore at fud.no (Tore Anderson)
Date: Mon, 23 May 2016 20:57:29 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
Message-ID: <20160523205729.12d1155f@envy.e5.y.home>

* Riccardo Gori

> I think I answered, It's not nice to have, It's business demand and LIRs 
> should be able to offer... with a /22 I can serve just up to 2 or 3 of 
> my tipical business  customers.
> This is lack of competitiveness.

So, let me get this straight:

In order to facilitate growing your business beyond three customers,
you've submitted a RIPE policy proposal that'd let you get eventually
another 3*/22 from the free pool. This would then allow you to grow your
business to having 8-12 customers. Right?

Assuming 2015-05 does go through: when your prospective customer number
13 is knocking on your door, should we then expect you to return with
another policy proposal to change 2015-05 /20 ceiling to /18?

Assuming that proposal also goes through: should we expect you to return
again, asking the RIPE community to extend the /18 ceiling by another
two bits, so that you can take on customer number 49?

And so on...

In any case, it is inevitable that at some point in time the RIPE NCC
will simply not have any IPv4 address space to give you, regardless of
what the policy allows. What will you do then, exactly? And why aren't
you already doing it today?

Tore



From rgori at wirem.net  Mon May 23 21:43:51 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Mon, 23 May 2016 21:43:51 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160523205729.12d1155f@envy.e5.y.home>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
Message-ID: <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>

Tore,

can we turn back to non silly insinuations? and please stop personal 
attacks. If your read again 2015-05 you can easily find out that is not 
so silly.

Currently the only reasonable objection about 2015-05 is that may (I 
underline may) speed up the allocation rate.
Please note that this ojection is based on the insinuation that every 
LIR qualifing for ad additional /22 will ask for it.
You should note the same was done with last /8: about 16000 /22 with 
about 8000 LIRs at that time datas are on the list.
So with the same insinuation no more than half the block to future 
member cames from who toughs last /8.
There's was no idea at that time about recovered space from IANA.
 From this point of view there's no difference between the two policies.

Rorger asked to explain what kind of needs or problems the policy is 
going to address and I reported clear examples.
Current LIRs sign up rate is affacted by LIRs asking their end-users to 
sign up to save their ip resources and these customers are wasting space
creating other unused space you can find this in 2015-05 and much more

regards
Riccardo


Il 23/05/2016 20:57, Tore Anderson ha scritto:
> * Riccardo Gori
>
>> I think I answered, It's not nice to have, It's business demand and LIRs
>> should be able to offer... with a /22 I can serve just up to 2 or 3 of
>> my tipical business  customers.
>> This is lack of competitiveness.
> So, let me get this straight:
>
> In order to facilitate growing your business beyond three customers,
> you've submitted a RIPE policy proposal that'd let you get eventually
> another 3*/22 from the free pool. This would then allow you to grow your
> business to having 8-12 customers. Right?
>
> Assuming 2015-05 does go through: when your prospective customer number
> 13 is knocking on your door, should we then expect you to return with
> another policy proposal to change 2015-05 /20 ceiling to /18?
>
> Assuming that proposal also goes through: should we expect you to return
> again, asking the RIPE community to extend the /18 ceiling by another
> two bits, so that you can take on customer number 49?
>
> And so on...
>
> In any case, it is inevitable that at some point in time the RIPE NCC
> will simply not have any IPv4 address space to give you, regardless of
> what the policy allows. What will you do then, exactly? And why aren't
> you already doing it today?
>
> Tore

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/751502bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/751502bd/attachment.jpg>

From sander at steffann.nl  Mon May 23 22:06:21 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 23 May 2016 22:06:21 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
 <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
Message-ID: <878466F7-4644-4998-AA6F-E6040278E863@steffann.nl>

Hi Ricardo,

> If your read again 2015-05 you can easily find out that is not so silly.
> Currently the only reasonable objection about 2015-05 is that may  (I underline may) speed up the allocation rate.
> Please note that this ojection is based on the insinuation [...]

Ok, this is enough. This is not an insinuation. There have been plenty of numbers that show the effects that 2015-05 will have. They have been discussed, and there is clearly no consensus.

Let's stop this right here. It is clear that 2015-05 doesn't have consensus and never will get consensus. I am sorry, you have done your best to get this policy proposal through the process, but you didn't succeed.

We are going to discuss which direction to move in on Thursday at the RIPE meeting. We will report to this list based on that.

But don't start saying that the objections to your policy proposal are insinuations...

Cheers,
Sander





From sander at steffann.nl  Mon May 23 22:09:15 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 23 May 2016 22:09:15 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160523205729.12d1155f@envy.e5.y.home>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
Message-ID: <1451BF17-CCA8-454B-84A9-3257E560C0A1@steffann.nl>

Hi Tore,

> In order to facilitate growing your business beyond three customers, [...]

Please don't exaggerate like that. I understand what you mean, but please don't make it personal.

> In any case, it is inevitable that at some point in time the RIPE NCC will simply not have any IPv4 address space to give you, regardless of what the policy allows. What will you do then, exactly? And why aren't you already doing it today?

Good point, this is what we should focus on. The IPv4 business model used over, we need to look at sustainable solutions.

Cheers,
Sander





From rgori at wirem.net  Mon May 23 22:53:00 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Mon, 23 May 2016 22:53:00 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <878466F7-4644-4998-AA6F-E6040278E863@steffann.nl>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
 <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
 <878466F7-4644-4998-AA6F-E6040278E863@steffann.nl>
Message-ID: <9cb20280-efb8-d810-f92b-7b3590e1ed6e@wirem.net>

Hi Sander,

Il 23/05/2016 22:06, Sander Steffann ha scritto:
> Hi Ricardo,
>
>> If your read again 2015-05 you can easily find out that is not so silly.
>> Currently the only reasonable objection about 2015-05 is that may  (I underline may) speed up the allocation rate.
>> Please note that this ojection is based on the insinuation [...]
> Ok, this is enough. This is not an insinuation. There have been plenty of numbers that show the effects that 2015-05 will have. They have been discussed, and there is clearly no consensus.
Insinuations can be inapproriate. Sorry if I looked unpolite. We talked 
about forecasts.
Anyway the fact is history. Last /8 was released with about 16000 /22 
from a community of about 7500 LIRs qualifing theirself for a /22 the 
day after.
About 50% of them asked for it nowadays.
About 60% of 13500 LIRs holds less a /20 and currently wa have almost a 
/8 thank to recovered space and LIRs didn't request a last /22.

>
> Let's stop this right here. It is clear that 2015-05 doesn't have consensus and never will get consensus. I am sorry, you have done your best to get this policy proposal through the process, but you didn't succeed.
I am not expecting consensum. I just want to be serius about the 
considerations and the discussion that can come to some costructive for 
everyone.
Someone choosed to turn it into joke and irony.
>
> We are going to discuss which direction to move in on Thursday at the RIPE meeting. We will report to this list based on that.
>
> But don't start saying that the objections to your policy proposal are insinuations...
>
> Cheers,
> Sander
>
>

regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/2ac480c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/2ac480c0/attachment.jpg>

From aled.w.morris at googlemail.com  Mon May 23 23:14:47 2016
From: aled.w.morris at googlemail.com (Aled Morris)
Date: Mon, 23 May 2016 22:14:47 +0100
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
Message-ID: <CAO1bj=bTzPM45NkA_Dk1yJjtpbG4VMty1yEjpmeoBH1uiK0wWA@mail.gmail.com>

On 23 May 2016 at 13:48, Riccardo Gori <rgori at wirem.net> wrote:

> I think I answered, It's not nice to have, It's business demand and LIRs
> should be able to offer... with a /22 I can serve just up to 2 or 3 of my
> tipical business  customers.
>

I had the same misunderstanding of the last /8 policy too.

That /22 you get isn't for allocating to customers, it's for running a 6/4
NAT translation pool to allow your new and future customers (who are
single-stack IPv6) to access the old IPv4 Internet.

Hope that helps clarify things.

Aled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/2713c6da/attachment.html>

From rogerj at gmail.com  Mon May 23 23:21:06 2016
From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=)
Date: Mon, 23 May 2016 23:21:06 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
 <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
Message-ID: <CAKFn1SE3GncBpCnz-TDzs2RBNE0Y4Jq-P5DtTRfH6O2r7u5q2g@mail.gmail.com>

On Mon, May 23, 2016 at 9:43 PM, Riccardo Gori <rgori at wirem.net> wrote:

> <snip>
> Rorger asked to explain what kind of needs or problems the policy is going
> to address and I reported clear examples.
> Current LIRs sign up rate is affacted by LIRs asking their end-users to
> sign up to save their ip resources and these customers are wasting space
> creating other unused space you can find this in 2015-05 and much more
>
>
>
you gave me no good answer except demonstrated that you haven't yet
realized that there is no more IPv4 to get.



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj at gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger at jorgensen.no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/eefc66dc/attachment.html>

From sander at steffann.nl  Mon May 23 23:35:34 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 23 May 2016 23:35:34 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <9cb20280-efb8-d810-f92b-7b3590e1ed6e@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
 <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
 <878466F7-4644-4998-AA6F-E6040278E863@steffann.nl>
 <9cb20280-efb8-d810-f92b-7b3590e1ed6e@wirem.net>
Message-ID: <8F56D67E-A668-4BEA-A75E-B71DFBB0B3C3@steffann.nl>

Hi Ricardo,

> I am not expecting consensum. I just want to be serius about the considerations and the discussion that can come to some costructive for everyone.

We have had that discussion here on the list. Let's finish this with a constructive discussion on Thursday.

> Someone choosed to turn it into joke and irony.

After talking about a policy proposal that is not leading to consensus for multiple discussion periods, I can't blame them. People seem to want to close this discussion. Let's do so on Thursday and discuss where to go from there.

Cheers,
Sander





From noreply at insideicloud.icloud.com  Mon May 23 23:37:00 2016
From: noreply at insideicloud.icloud.com (mostafa shahdadi)
Date: Mon, 23 May 2016 21:37:00 +0000 (GMT)
Subject: [address-policy-wg] =?utf-8?b?4oCcUklQRSA3MuKAnSBoYXMgYmVlbiBj?=
	=?utf-8?q?anceled=2E?=
Message-ID: <1556925950.20311400.1464039420508.JavaMail.email@email.apple.com>

?RIPE 72? has been canceled.

starts: All-Day, Monday, May 23, 2016
ends: All-Day, Friday, May 27, 2016

location: Copenhagen, Denmark

note: now

deleted by: mostafa shahdadi


---
iCloud is a service provided by Apple.
Apple ID:  https://appleid.apple.com/choose-your-country/
Support:  https://www.apple.com/support/icloud/ww
Terms and Conditions:  https://www.apple.com/legal/internet-services/icloud/ww/
Privacy Policy:  https://www.apple.com/legal/internet-services/privacy/
Copyright 2016 Apple Inc. 1 Infinite Loop, Cupertino, CA 95014, United States.
All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/8b24eca3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iCal-20160523-143700.ics
Type: text/calendar
Size: 484 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160523/8b24eca3/attachment.ics>

From rgori at wirem.net  Tue May 24 05:59:52 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 24 May 2016 05:59:52 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <57419394.5060503@foobar.org>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <574032DC.3020600@foobar.org>
 <e5e9f332-5c88-d571-8acf-90a2830b58a3@wirem.net>
 <57419394.5060503@foobar.org>
Message-ID: <319bd1c4-22af-d16a-8788-52edc6848655@wirem.net>

Hi Nick,


Il 22/05/2016 13:10, Nick Hilliard ha scritto:
> Riccardo Gori wrote:
>>> There are no good solutions to the problem at hand, only compromises.
>>> If the current policy is changed to something else, the people who
>>> benefit in the short term will be happier and the people who pay for
>>> this generosity will be disappointed.
>> IPv6
> If ipv6 provided full backwards compatibility with ipv4, it would be a
> solution.
>
> Any organisation which is forced into providing ipv4 connectivity using
> an ipv6 transition mechanism will operate at a competitive disadvantage
> to an organisation which can provide native ipv4.  This isn't a swipe at
> ipv6: it's simply an observation that we have come to depend on features
> of ipv4 which cannot be fully replicated using ipv6 transition mechanisms.
>
> This is why I referred to migrating to ipv6 as a compromise.  Long term,
> it may be a good compromise and many years down the road, it may even be
> better than ipv4.  But as long as there are ipv4 addresses available, it
> is condemned to being second best by the legacy of the existing
> single-stacked ipv4 install base.
IPv6 is the solution provided to us by IETF to grow the internet.
I saw many limitations of IPv4 were exceeded by technology solutions 
p2p, nat etc.
it can happen for IPv6 too, some breaking technology can speed up the 
adoption
and maybe new ideas can overcome use difficulties or limitations
>> every policy that makes IPv6 adoption a must can help slow down IPv4
>> allocation rate and in the meanwhile will even lower IPv4 maket value
>> [...]
> I don't believe there is any evidence to support either of these statements.
I just saw very to low interest in IPv6 around policies and this make me 
have a bad feeling, that's it.
>
> Also, please bear in mind that if strong policies caused better adoption
> of new protocols, we would be having this discussion using X.400.
>
> Nick
regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/149c3e00/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/149c3e00/attachment.jpg>

From rgori at wirem.net  Tue May 24 06:06:07 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 24 May 2016 06:06:07 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <CAKFn1SFLf_jag3h5DQGNgpevsjk94SZPrVNtW1TRNhcA2UGGoA@mail.gmail.com>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <CAKFn1SFLf_jag3h5DQGNgpevsjk94SZPrVNtW1TRNhcA2UGGoA@mail.gmail.com>
Message-ID: <cc7bbc39-8334-7c1a-61c1-3f7a204169c3@wirem.net>

Hi Roger,


Il 23/05/2016 14:58, Roger J?rgensen ha scritto:
> On Mon, May 23, 2016 at 2:48 PM, Riccardo Gori <rgori at wirem.net 
> <mailto:rgori at wirem.net>> wrote:
>
>     Hi Roger,
>
>
>     Il 23/05/2016 14:38, Roger J?rgensen ha scritto:
>>     On Sun, May 22, 2016 at 10:25 AM, Riccardo Gori <rgori at wirem.net
>>     <mailto:rgori at wirem.net>> wrote:
>>
>>         Hi Roger,
>>
>>         thank you for your questions. I try to answer below
>>
>>
>>         Il 21/05/2016 09:45, Roger J?rgensen ha scritto:
>>>         <snip>
>>
>>     So I ask _again_, where is the IPv4 need? What type of usage is
>>     it ment for? We've passed the "it's nice to have" some years ago,
>>     now we're down to , do you _really_ need 10 addresses? Can you
>>     survive with 2 and deploy IPv6?
>     I think I answered, It's not nice to have, It's business demand
>     and LIRs should be able to offer... with a /22 I can serve just up
>     to 2 or 3 of my tipical business  customers.
>     This is lack of competitiveness.
>
>
> sorry if I sound hard/insulting, to me it sounds like you have an 
> outdated business model that are doomed to go down soon, you can't 
> grow this way.
> Change to IPv6 where you actual can have some growth and option for 
> the future.
>
>
> What you are illustrating is that somehow, despite all the effort from 
> many parties the world do not seems to understand that there are no 
> more IPv4, the growth has to come from IPv6.
if you look at the policy proposal we are just addressing the same point.
You'll get some more if your are aware that IPv6 is the solutions and 
you demonstrate you are doing something.
>
>
>
> -- 
>
> Roger Jorgensen           | ROJO9-RIPE
> rogerj at gmail.com <mailto:rogerj at gmail.com>          | - IPv6 is The Key!
> http://www.jorgensen.no   | roger at jorgensen.no <mailto:roger at jorgensen.no>
regards
Riccardo
-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/d7efad9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/d7efad9b/attachment.jpg>

From rgori at wirem.net  Tue May 24 06:13:44 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 24 May 2016 06:13:44 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160522120145.7098fc53@envy.e5.y.home>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
Message-ID: <31b1e6b2-1988-1145-35cf-ba2f2fe756ae@wirem.net>

Hi again Tore,

Il 22/05/2016 12:01, Tore Anderson ha scritto:
> * Riccardo Gori
>
>> and we turn minimum request to a /24
>> we can address this kind of problem while slowing down LIRs sign up rate
>> to obtain a /23 or /24 to address this kind of requests
> This, in isolation, I think is idea worth exploring further.
>
> The minimum allocation size started out as a /19 (cf. ripe-136). Over
> time it's been adjusted down to the current /22. I think it might be
> prudent to continue this trend at some point.
>
> For example: change it to a /23 at the point when the NCC pool reaches
> the equivalent of a /9, and then to a /24 when the pool reaches the
> equivalent of a /24.
>
> This would ensure the last /9-equivalent could accomodate three times
> as many new entrants (24576) than if we continue with /22s (8192).
>
> One would hope that even though the future new entrants will continue
> to need some IPv4 to start their business, the amount will decrease as
> IPv6 deployment increases. That is, a new entrant receiving a final /23
> in 2017 might find it about as useful the final /22 was to a new
> entrant in 2013.
>
> Depending on how the membership fees and the pricing in the second-hand
> IPv4 market develops, this could also help discourage abuse: if
> everything else remains the same, the cost per address would
> essentially double at each adjustment.
>
>
> Another thing worth considering (separately) is to stop issuing
> additional allocations. An "old LIR" (one that held IPv4 allocations on
> the 14th of September 2012 that hasn't needed to request its final /22
> in the four years since, is likely not growing anyway and that space is
> better spent for new entrants. Four years is in any case a much longer
> period than the LIRs last allocation was supposed to last.
>
> Basically we'd need to change bullet #2 in ripe-649 section 5.1 to just
> say ?an LIR that currently hold or have previously held an IPv4
> allocation is not eligible? or something like that. As an added bonus,
> we'd then get rid of the quirky unexplained 14-09-2012 date referenced
> in the current text.
>
> This would prevent "old LIRs" that are already holding lots of address
> space, perhaps mostly unused, from being able to pick up a final /22
> anyway. I can easily see that a "new LIR" making very efficient use of
> its final /22 while being unable to request another would find this very
> unfair, as would the new entrants that inevitably would be denied any
> final IPv4 allocations down the line (due to full depletion happening
> earlier).
>
> Unfortunately I won't be in Copenhagen so just consider this me
> thinking out loud here on the list instead of at the Open Policy Hour.
> I'm not going to submit any proposals myself though so anyone should
> feel free to take the above ideas and run with them.
>
> Tore
those above statements are the most constructives.
So we agree toghether that last /8 had its good effects but can be tuned 
to adapt itself to the current times coming?

regards
Riccardo

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/8286f321/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/8286f321/attachment.jpg>

From tore at fud.no  Tue May 24 07:57:45 2016
From: tore at fud.no (Tore Anderson)
Date: Tue, 24 May 2016 07:57:45 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <31b1e6b2-1988-1145-35cf-ba2f2fe756ae@wirem.net>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <20160522120145.7098fc53@envy.e5.y.home>
 <31b1e6b2-1988-1145-35cf-ba2f2fe756ae@wirem.net>
Message-ID: <20160524075745.1c126136@envy.e5.y.home>

* Riccardo Gori

> Hi again Tore,
> 
> Il 22/05/2016 12:01, Tore Anderson ha scritto:
> > * Riccardo Gori
> >  
> >> and we turn minimum request to a /24
> >> we can address this kind of problem while slowing down LIRs sign up rate
> >> to obtain a /23 or /24 to address this kind of requests  
> > This, in isolation, I think is idea worth exploring further.
> >
> > The minimum allocation size started out as a /19 (cf. ripe-136). Over
> > time it's been adjusted down to the current /22. I think it might be
> > prudent to continue this trend at some point.
> >
> > For example: change it to a /23 at the point when the NCC pool reaches
> > the equivalent of a /9, and then to a /24 when the pool reaches the
> > equivalent of a /24.
> >
> > This would ensure the last /9-equivalent could accomodate three times
> > as many new entrants (24576) than if we continue with /22s (8192).
> >
> > One would hope that even though the future new entrants will continue
> > to need some IPv4 to start their business, the amount will decrease as
> > IPv6 deployment increases. That is, a new entrant receiving a final /23
> > in 2017 might find it about as useful the final /22 was to a new
> > entrant in 2013.
> >
> > Depending on how the membership fees and the pricing in the second-hand
> > IPv4 market develops, this could also help discourage abuse: if
> > everything else remains the same, the cost per address would
> > essentially double at each adjustment.
> >
> >
> > Another thing worth considering (separately) is to stop issuing
> > additional allocations. An "old LIR" (one that held IPv4 allocations on
> > the 14th of September 2012 that hasn't needed to request its final /22
> > in the four years since, is likely not growing anyway and that space is
> > better spent for new entrants. Four years is in any case a much longer
> > period than the LIRs last allocation was supposed to last.
> >
> > Basically we'd need to change bullet #2 in ripe-649 section 5.1 to just
> > say ?an LIR that currently hold or have previously held an IPv4
> > allocation is not eligible? or something like that. As an added bonus,
> > we'd then get rid of the quirky unexplained 14-09-2012 date referenced
> > in the current text.
> >
> > This would prevent "old LIRs" that are already holding lots of address
> > space, perhaps mostly unused, from being able to pick up a final /22
> > anyway. I can easily see that a "new LIR" making very efficient use of
> > its final /22 while being unable to request another would find this very
> > unfair, as would the new entrants that inevitably would be denied any
> > final IPv4 allocations down the line (due to full depletion happening
> > earlier).
> >
> > Unfortunately I won't be in Copenhagen so just consider this me
> > thinking out loud here on the list instead of at the Open Policy Hour.
> > I'm not going to submit any proposals myself though so anyone should
> > feel free to take the above ideas and run with them.
> >
> 
> those above statements are the most constructives.
> So we agree toghether that last /8 had its good effects but can be tuned 
> to adapt itself to the current times coming?

I believe the ?last /8? policy so has been, and continue to, work very
well. If not for that policy, the new members joining since 2013 or so
would not have been able to request any IPv4 at all.

Of course, it is certainly possible to tune it further - after all, the
RIPE community has done precisely that on several occasions already. I
don't see it as a *necessity* though; that is, the policy isn't broken
(it's working as intended and quite well too) so it doesn't really need
fixing. I'd be happy enough if we leave it as-is too.

Tore



From garry at nethinks.com  Tue May 24 08:39:54 2016
From: garry at nethinks.com (Garry Glendown)
Date: Tue, 24 May 2016 08:39:54 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
 June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <20160523205729.12d1155f@envy.e5.y.home>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
Message-ID: <f143a7b8-3d58-9820-b6f0-2541fa9ddf16@nethinks.com>

Hi *,

initially reading, nowadays just browsing over the posts about 2015-05,
I don't get it ...

Yes, I understand the pain new LIRs have with the limited availability
of v4 addresses. We have a small local provider, a small city that has
gone through the trouble of installing a FO infrastructure to provide
high-speed internet to most of its citizens, and has to do with their
/22 assignment (they became an LIR to get those) for something around
(currently) 3k customers, of those something like 100+ businesses. They
run native v6 dual-stacked with CGN v4, which - especially for the
business customers - isn't the optimal solution (just using a /29 for
each business would more or less deplete their public v4 range). So yes,
they would love to get more v4, but they can't.

I keep reading phrases like "it's not fair", "it's anti-competitive".
Hell yes it is. But business has never been fair. If you're coming late
to a supper, you may not get all the best pieces of the food that was
available at the beginning. If you're late to the business, many
customers will already have found a different provider for their
requirements and will often not even talk to you. So what, you have to
live with it. You knew you were a late entry, if you didn't know what
you were getting into, if you are surprised by the limitations of both
the market itself and RIPE specifically, you obviously didn't do your
homework! Heck, even if you already have a /20, /19 or whatever and are
running out of v4 addresses - why are you surprised? v4 was running out
a long time ago, which was only delayed by NAT "technology", a kluge to
allow for a better technology (IPv6) to be finished and rolled out - 15
years later and too many providers still do not see the necessity of
rolling out v6.

Who is to blame? Well, of course those providers, most likely ones that
still have sufficient amounts of free v4 addresses. To a minor degree
possibly their customers, as they ought to be requesting dual-stacked
internet from their ISPs. But why should they? Everything is working,
and setting up v6 doesn't (in most cases) earn them any benefits.

So what could be done? Technically, not much I guess. Sure, we could
level the playing field, the RIRs could pass a policy retracting half of
all assigned v4 addresses annually from anybody holding - say - /20 or
larger. Even going down to 50% would most likely require many LIRs to
actually roll out v6, apart from annoy a whole lot of people, as the
ISPs would be forced to renumber the remaining IP assignments to their
customers.

Would such a policy change be enforceable? I doubt it, or at the very
least many of the larger ISPs will fight it with all they have (read:
law suits).

So, as it is, we have a situation in which many large ISPs give a f*ck
about the IPv4 scarcity, stick with their pool of v4 addresses and wait
until actual customers request v6, which won't happen, so there is no
business case to implement it for quite some time. Many other ISPs have
to make do, and are at a weaker business position than should be
necessary, but there's nothing we as a RIPE community can do except keep
up the current policy to at least allow for SOME possibility of getting
on the net for new entries, and keep pushing v6 in the market, in a hope
to make customers aware of the necessity of v6 to THEIR business! Maybe
then more ISPs will finally invest in the future of their part of the
Internet.

Oh, and just in case you were still wondering: I'm against loosening the
last /8 policy ...

Garry

--
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/00e7f5f8/attachment.html>

From rgori at wirem.net  Tue May 24 11:12:36 2016
From: rgori at wirem.net (Riccardo Gori)
Date: Tue, 24 May 2016 11:12:36 +0200
Subject: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down
 the Final /8 Policy)
In-Reply-To: <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
References: <573B0906.3060708@ripe.net>
 <CAKFn1SEOSom+H45LjEK00jWjmApVLoJ=zgMus0D0xwKREea00A@mail.gmail.com>
Message-ID: <6bd7c030-6927-eef3-39d7-1d8171b577d5@wirem.net>



Il 17/05/2016 20:12, Roger J?rgensen ha scritto:
> On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt at ripe.net> wrote:
>> Dear colleagues,
>>
>> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"
>> is now available for discussion.
> What really amaze me. We are using tons of time here in ag-wg talking
> over IPv4 while there is not half that activity over in IPv6-wg.
>
>
> I take that as a statement that everyone know everything there is to
> know about IPv6, there are nothing more to discuss or learn, no
> questions to ask, we are all using it so very few people are left
> behind in IPv4 land... soon to be isolated island not able to talk
> with anyone.
>
> ... is that how it is?
>
>
>
> Why aren't all of you with HUGE and MAJOR problem (sorry for the caps)
> with lack of IPv4 address over in IPv6-wg bombing us with question on
> how to get out of your current trouble?
> Asking all kind of stupid and newbie questions? I'm very sure there
> are tons of people standing in line to help you out.
>
> https://www.ripe.net/participate/ripe/wg/ipv6
Thank you for focusing all of us on it.
>
>
>
>
>
> PS 1 : chairs - I object to this policy and the other one trying to
> sort a problem that can't be sorted in IPv4 land, only IPv6 can.
>
>
> PS 2 : Nick Hillard summarized it very well here:
> <start copy>
> Like the curate's egg, this proposal is good in parts. Here's the good part:
>
>> - Explicitly state that the current IPv4 allocation policy applies to
>> all available IPv4 address space held by the RIPE NCC that has not
>> been reserved or marked to be returned to IANA
> <end copy>
>

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/2051c690/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/2051c690/attachment.jpg>

From sander at steffann.nl  Tue May 24 12:30:35 2016
From: sander at steffann.nl (Sander Steffann)
Date: Tue, 24 May 2016 12:30:35 +0200
Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13
	June 2016 (Last /8 Allocation Criteria Revision)
In-Reply-To: <8F56D67E-A668-4BEA-A75E-B71DFBB0B3C3@steffann.nl>
References: <573F0AF3.6040803@ripe.net> <20160520131713.GL1755@Space.Net>
 <CAKFn1SHNzHxrRgSsDLVK=We4V4S7AOLXLPaRcPCGPaJhDWC9Fw@mail.gmail.com>
 <2ebdb078-f0c3-8a1b-f9cd-097a16469c8f@wirem.net>
 <CAKFn1SHODYhx_CCTEhX5fosCcvG7svRrg+v8L_ssRxbBaCkNZA@mail.gmail.com>
 <a27c9dde-27ef-2b94-7374-892c20cc94b0@wirem.net>
 <20160523205729.12d1155f@envy.e5.y.home>
 <d305c24f-668c-3d3e-48c4-e2ae9fc4eeca@wirem.net>
 <878466F7-4644-4998-AA6F-E6040278E863@steffann.nl>
 <9cb20280-efb8-d810-f92b-7b3590e1ed6e@wirem.net>
 <8F56D67E-A668-4BEA-A75E-B71DFBB0B3C3@steffann.nl>
Message-ID: <66957B59-DB8A-478A-8B81-E904A678B497@steffann.nl>

Hi everybody,

> We have had that discussion here on the list. Let's finish this with a constructive discussion on Thursday.

The RIPE meeting has just started its second day, and my brain has already melted down.
s/Thursday/Wednesday/

Repeat: the session is on WEDNESDAY

Sorry for the confusion

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160524/b88aa8c6/attachment.sig>

From mir at ripe.net  Tue May 24 15:25:37 2016
From: mir at ripe.net (Mirjam Kuehne)
Date: Tue, 24 May 2016 15:25:37 +0200
Subject: [address-policy-wg] New on RIPE Labs: Developments in IPv4 Transfers
Message-ID: <7f12b9a8-278a-d8af-4ba4-68893c560d74@ripe.net>

Dear colleagues,

In May 2015, we looked at IPv4 transfers in the RIPE NCC service region
and found signs of an emerging market. Both the number and size of
transfers conducted under RIPE Policy showed an upward trend in the
years 2013-2014.

One year later, we take another look. Did this trend continue? What have
been the effects of the inter-RIR transfer policy?

Please read on RIPE Labs:

https://labs.ripe.net/Members/wilhelm/developments-in-ipv4-transfers?pk_campaign=labs&pk_kwd=list-apwg

Kind regards,
Mirjam Kuehne
RIPE NCC



From mschmidt at ripe.net  Tue May 24 16:31:52 2016
From: mschmidt at ripe.net (Marco Schmidt)
Date: Tue, 24 May 2016 16:31:52 +0200
Subject: [address-policy-wg] Join the Address Policy WG Discussions Tomorrow
Message-ID: <574465D8.9020901@ripe.net>

Dear colleagues,

Tomorrow at RIPE 72, the Address Policy Working Group will be discussing 
the following policy proposals:

- 2015-04, "RIPE Resource Transfer Policies"
- 2015-05, "Revision of Last /8 Allocation Criteria"
- 2016-03, "Locking Down the Final /8 Policy"

While no decisions are made during this session, it?s a good opportunity 
to discuss the proposals and give feedback directly to the proposers.

If you can't attend tomorrow?s session in person, you can participate 
remotely. The following link will provide you with a live webstream and 
a chat client.

     https://ripe72.ripe.net/live/main/

The session begins at 07:00 UTC on 25 May 2016.

We encourage you to join the discussion if you have an opinion about one 
of these proposals.

The second Address Policy Working Group session begins at 9:00 UTC on 
the same day and includes a presentation on "Market Concentration in the 
Transfer of IPv4 Space?, as well as feedback from the RIPE NCC's 
Registration Services Department. We invite you to tune in to see these 
presentations as well.

Kind regards,

Marco Schmidt
Policy Development Officer
RIPE NCC



From remco.vanmook at gmail.com  Wed May 25 09:52:55 2016
From: remco.vanmook at gmail.com (Remco van Mook)
Date: Wed, 25 May 2016 09:52:55 +0200
Subject: [address-policy-wg] opposition to 2015-04
Message-ID: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>


Dear all,

as just mentioned during the address policy session, I'm withdrawing my objection to 2015-04. While I do think a discussion about policy structure still needs to be held, I don't think it should hold up this proposal any longer. This can be fixed after adoption - as long as we're aware.

I do maintain my suggestion to put references in place where chapters about transfers are removed from other sections of policy.

Kind regards,

Remco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160525/362507e0/attachment.sig>

From aleksbulgakov at gmail.com  Wed May 25 09:57:23 2016
From: aleksbulgakov at gmail.com (Aleksey Bulgakov)
Date: Wed, 25 May 2016 10:57:23 +0300
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
Message-ID: <CAOcKdztwYEVz1eFpX9wFHqw51E5gnwiRkoNKF3gpsaX3DmdtLg@mail.gmail.com>

Please, go to https://ripe72.ripe.net/live/main/ . There is discussion
about IPv4 proposals now.

2016-05-25 10:52 GMT+03:00 Remco van Mook <remco.vanmook at gmail.com>:
>
> Dear all,
>
> as just mentioned during the address policy session, I'm withdrawing my objection to 2015-04. While I do think a discussion about policy structure still needs to be held, I don't think it should hold up this proposal any longer. This can be fixed after adoption - as long as we're aware.
>
> I do maintain my suggestion to put references in place where chapters about transfers are removed from other sections of policy.
>
> Kind regards,
>
> Remco



-- 
----------
Best regards,
Aleksey Bulgakov
Tel.: +7 (926)690-87-29



From elvis at v4escrow.net  Wed May 25 10:27:41 2016
From: elvis at v4escrow.net (Elvis Daniel Velea)
Date: Wed, 25 May 2016 10:27:41 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
Message-ID: <574561FD.7010502@v4escrow.net>

Dears,

as mentioned during the policy session, I am opposing to this (version 
of) the policy proposal.

While I was sure that I did voice this concern over the mailing list, I 
can not find the e-mail now. But I am sure I did voice this concern and 
the opposition at previous RIPE Meeting(s).
As long as this proposal adds the 2 years holding period of scarce 
resources moved through M&As (which are 'regulated' through a RIPE NCC 
procedure) I will oppose to it.

I am not going to go into examples wars of why some company would want 
to transfer/move/merge/etc.. resources within a 2 years period. While I 
agree that transfers should have a holding (or call it anti-flip) period 
and I even proposed 2015-01 (which is now part of policy), I do not 
agree that we should include M&As in the same bucket.

If a new version of this policy proposal would be only about transfers 
of IP addresses, and not try to sneak in M&As into the same document, I 
would agree with it.

my 2 cents,
elvis

On 5/25/16 9:52 AM, Remco van Mook wrote:
> Dear all,
>
> as just mentioned during the address policy session, I'm withdrawing my objection to 2015-04. While I do think a discussion about policy structure still needs to be held, I don't think it should hold up this proposal any longer. This can be fixed after adoption - as long as we're aware.
>
> I do maintain my suggestion to put references in place where chapters about transfers are removed from other sections of policy.
>
> Kind regards,
>
> Remco

-- 
<http://v4escrow.net> 	


  Elvis Daniel Velea


    Chief Executive Officer

E-mail: elvis at V4Escrow.net <mailto:elvis at v4escrow.net>
Mobile: +1 (702) 970 0921

Recognised IPv4 Broker/Facilitator in:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160525/7a48a8a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jfijecgg.png
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160525/7a48a8a9/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbgefebj.png
Type: image/png
Size: 12287 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160525/7a48a8a9/attachment-0001.png>

From ww at hubs.net.uk  Thu May 26 11:07:03 2016
From: ww at hubs.net.uk (William Waites)
Date: Thu, 26 May 2016 09:07:03 +0000
Subject: [address-policy-wg] ALLOCATED FINAL and M&As
Message-ID: <86y46xnq6g.fsf@naartjie.uucp>

This suggestion is intended to address the problem of abusively opening
many LIRs or many companies to make new members to stockpile addresses
from the last /8.

First, if there are intended to be special rules applying to these
addresses, they should have a special status to make it clear. For the
sake of argument ALLOCATED FINAL. This doesn't change anything, it just
makes things a bit more explicit.

Any organisation should be entitled to at most one such FINAL allocation
from RIPE (if we go back to multiple LIR accounts, only one of them may
get a FINAL block). FINAL allocations are only for use on the Internet,
not for internal, non-announced uses: that is a legitimate use case, but
don't squander the last of the pool for that.

Transfers of FINAL blocks are only allowed if they are demonstrably in
use. "In use" means (1) announced in the global BGP tables and (2) with
documentation of deployment in a non-trivial topology, i.e. assigning
everything in the /22 to a single host so that it answers ICMP packets
doesn't fly.

Yes, there are still ways to game this, but the bar is much higher. Yes,
it means that the NCC has to do more work to check that transfers are
legitimate, but that is a necessary cost for dealing with the problem of
the bad actors.

---

Motivation/disclosure.

HUBS is made up of a dozen or so small rural providers mostly in the
south of Scotland. We are an LIR and allocate addresses to them on
pretty much the same basis as we get them from RIPE. We encourage them
to do IPv6 but made an explicit choice not to dictate or interfere in
their internal operations. They may use their IPv4 allocations for
"CG"-NAT, or assign them to customers, and we offer advice but not more.

Another organisation, WHAN, was set up to do this along similar lines on
the west coast (and actually to extend the model by making a distributed
IXP for their networks to connect to rather than looking like a transit
provider). There is some overlap of people (exactly two) but they
operate in a different geographical area and the set of member networks 
is completely disjoint.

At some point it is quite possible that these two organistions will
merge. That would be extremely and unnecessarily painful if that meant
that networks already assigned and in use had to be returned. These 
organisations are already operating in areas characterised by market
failure, on extremely tight budgets largely reliant on volunteers to
provide the only option for decent Internet access. The policy that has
been mooted of a rigid rule of exactly one final allocation per
organisation would be hugely damaging.

Best wishes,

William Waites
Network Engineer
HUBS AS60241



From ebais at a2b-internet.com  Mon May 30 00:45:31 2016
From: ebais at a2b-internet.com (Erik Bais)
Date: Mon, 30 May 2016 00:45:31 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <574561FD.7010502@v4escrow.net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
Message-ID: <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>

Hi Elvis,  

 

I oppose to your word choice that we are trying to sneak something in, with
this policy. 

 

As stated during the discussion at the AP, a change to the holdership will
to fall under the same restrictions as the transfers currently, that was
pointed out AND discussed since version 1. 

 

If a company is currently doing a M&A after that particular company has
become a (new) LIR since 6 months, it means it needs to keep the LIR open
for another 18 months.. 

For any M&A, the cost for a membership fee of 18 months will not be a deal
breaker for an actual business take-over ? unless one is trying to game the
system.  

 

To give an indication,  the damage of a diner with 7 people at the MASH
Penthouse at the RIPE72 venue can be more expensive ...  

 

Thanks for the feedback. 

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens
Elvis Daniel Velea
Verzonden: woensdag 25 mei 2016 10:28
Aan: address-policy-wg at ripe.net
Onderwerp: Re: [address-policy-wg] opposition to 2015-04

 

Dears,

as mentioned during the policy session, I am opposing to this (version of)
the policy proposal.

While I was sure that I did voice this concern over the mailing list, I can
not find the e-mail now. But I am sure I did voice this concern and the
opposition at previous RIPE Meeting(s).
As long as this proposal adds the 2 years holding period of scarce resources
moved through M&As (which are 'regulated' through a RIPE NCC procedure) I
will oppose to it. 

I am not going to go into examples wars of why some company would want to
transfer/move/merge/etc.. resources within a 2 years period. While I agree
that transfers should have a holding (or call it anti-flip) period and I
even proposed 2015-01 (which is now part of policy), I do not agree that we
should include M&As in the same bucket.

If a new version of this policy proposal would be only about transfers of IP
addresses, and not try to sneak in M&As into the same document, I would
agree with it.

my 2 cents,
elvis

On 5/25/16 9:52 AM, Remco van Mook wrote:

 
Dear all,
 
as just mentioned during the address policy session, I'm withdrawing my
objection to 2015-04. While I do think a discussion about policy structure
still needs to be held, I don't think it should hold up this proposal any
longer. This can be fixed after adoption - as long as we're aware.
 
I do maintain my suggestion to put references in place where chapters about
transfers are removed from other sections of policy.
 
Kind regards,
 
Remco

 

-- 


 <http://v4escrow.net> 

 


Elvis Daniel Velea


Chief Executive Officer


E-mail: elvis at V4Escrow.net <mailto:elvis at V4Escrow.net> 
Mobile: +1 (702) 970 0921


Recognised IPv4 Broker/Facilitator in:




 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/f765908d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/f765908d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 193 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/f765908d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 12287 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/f765908d/attachment-0002.png>

From ebais at a2b-internet.com  Mon May 30 00:47:32 2016
From: ebais at a2b-internet.com (Erik Bais)
Date: Mon, 30 May 2016 00:47:32 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
Message-ID: <002f01d1b9fc$22a37590$67ea60b0$@a2b-internet.com>

Thanks Remco. 

We'll take your suggestion in mind before moving to last call. 

Regards,
Erik Bais 

-----Oorspronkelijk bericht-----
Van: Remco van Mook [mailto:remco.vanmook at gmail.com] 
Verzonden: woensdag 25 mei 2016 9:53
Aan: address-policy-wg at ripe.net
CC: Erik Bais <erik at bais.name>
Onderwerp: opposition to 2015-04


Dear all,

as just mentioned during the address policy session, I'm withdrawing my
objection to 2015-04. While I do think a discussion about policy structure
still needs to be held, I don't think it should hold up this proposal any
longer. This can be fixed after adoption - as long as we're aware.

I do maintain my suggestion to put references in place where chapters about
transfers are removed from other sections of policy.

Kind regards,

Remco




From elvis at velea.eu  Mon May 30 00:55:50 2016
From: elvis at velea.eu (Elvis Daniel Velea)
Date: Mon, 30 May 2016 01:55:50 +0300
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
Message-ID: <574B7376.5000109@velea.eu>

Hi Erik,

On 5/30/16 1:45 AM, Erik Bais wrote:
>
> Hi Elvis,
>
> I oppose to your word choice that we are trying to sneak something in, 
> with this policy.
>
> As stated during the discussion at the AP, a change to the holdership 
> will to fall under the same restrictions as the transfers currently, 
> that was pointed out AND discussed since version 1.
>
that was my mistake, I was sure I had pointed it out in an older 
e-mail.. can't find it so it probably never made it to the list and was 
in draft status forever :)
>
> If a company is currently doing a M&A after that particular company 
> has become a (new) LIR since 6 months, it means it needs to keep the 
> LIR open for another 18 months..
>
> For any M&A, the cost for a membership fee of 18 months will not be a 
> deal breaker for an actual business take-over ? unless one is trying 
> to game the system.
>
well, this is what I was opposing to. However, after further discussions 
offline, I no longer think this is quite such a bad idea. So, I no 
longer oppose.
>
> To give an indication,  the damage of a diner with 7 people at the 
> MASH Penthouse at the RIPE72 venue can be more expensive ...
>
you never invited me there... I would've wanted to see the proof.
>
> Thanks for the feedback.
>
so, +1 to the proposal.

cheers,
elvis
>
> Regards,
>
> Erik Bais
>
> *Van:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] 
> *Namens *Elvis Daniel Velea
> *Verzonden:* woensdag 25 mei 2016 10:28
> *Aan:* address-policy-wg at ripe.net
> *Onderwerp:* Re: [address-policy-wg] opposition to 2015-04
>
> Dears,
>
> as mentioned during the policy session, I am opposing to this (version 
> of) the policy proposal.
>
> While I was sure that I did voice this concern over the mailing list, 
> I can not find the e-mail now. But I am sure I did voice this concern 
> and the opposition at previous RIPE Meeting(s).
> As long as this proposal adds the 2 years holding period of scarce 
> resources moved through M&As (which are 'regulated' through a RIPE NCC 
> procedure) I will oppose to it.
>
> I am not going to go into examples wars of why some company would want 
> to transfer/move/merge/etc.. resources within a 2 years period. While 
> I agree that transfers should have a holding (or call it anti-flip) 
> period and I even proposed 2015-01 (which is now part of policy), I do 
> not agree that we should include M&As in the same bucket.
>
> If a new version of this policy proposal would be only about transfers 
> of IP addresses, and not try to sneak in M&As into the same document, 
> I would agree with it.
>
> my 2 cents,
> elvis
>
> On 5/25/16 9:52 AM, Remco van Mook wrote:
>
>     Dear all,
>
>     as just mentioned during the address policy session, I'm withdrawing my objection to 2015-04. While I do think a discussion about policy structure still needs to be held, I don't think it should hold up this proposal any longer. This can be fixed after adoption - as long as we're aware.
>
>     I do maintain my suggestion to put references in place where chapters about transfers are removed from other sections of policy.
>
>     Kind regards,
>
>     Remco
>
> -- 
>
> <http://v4escrow.net>
>
> 	
>
>
>   Elvis Daniel Velea
>
>
>     Chief Executive Officer
>
> E-mail:elvis at V4Escrow.net <mailto:elvis at V4Escrow.net>
> Mobile: +1 (702) 970 0921
>
> Recognised IPv4 Broker/Facilitator in:
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/851c69b0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/851c69b0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 193 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/851c69b0/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12287 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/851c69b0/attachment-0002.png>

From apwg at c4inet.net  Mon May 30 17:23:19 2016
From: apwg at c4inet.net (Sascha Luck [ml])
Date: Mon, 30 May 2016 16:23:19 +0100
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
Message-ID: <20160530152319.GF862@cilantro.c4inet.net>

On Mon, May 30, 2016 at 12:45:31AM +0200, Erik Bais wrote:
>As stated during the discussion at the AP, a change to the
>holdership will to fall under the same restrictions as the
>transfers currently, that was pointed out AND discussed since
>version 1.

The fact remains that policy has no business regulating into the
business transactions of members (vulgo M&A) and I oppose it for
that reason alone. 

rgds,
Sascha Luck



From sander at steffann.nl  Mon May 30 17:44:05 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 30 May 2016 17:44:05 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <20160530152319.GF862@cilantro.c4inet.net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
Message-ID: <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>

Hi Sasha,

> The fact remains that policy has no business regulating into the
> business transactions of members (vulgo M&A) and I oppose it for
> that reason alone.

RIPE policy does regulate IP allocations and under what conditions you are allowed to have/transfer/etc them. I agree that RIPE policy cannot regulate an organisation's M&A itself, but what happens to IP allocations when M&A happens definitely is in scope.

Not expressing any opinion in favour or against, just clarifying scope :)

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/23940369/attachment.sig>

From apwg at c4inet.net  Mon May 30 18:53:10 2016
From: apwg at c4inet.net (Sascha Luck [ml])
Date: Mon, 30 May 2016 17:53:10 +0100
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
 <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
Message-ID: <20160530165310.GG862@cilantro.c4inet.net>

On Mon, May 30, 2016 at 05:44:05PM +0200, Sander Steffann wrote:
>RIPE policy does regulate IP allocations and under what
>conditions you are allowed to have/transfer/etc them. I agree
>that RIPE policy cannot regulate an organisation's M&A itself,
>but what happens to IP allocations when M&A happens definitely
>is in scope.

RIPE policy has, until recently, explicitly recognised that M&A (and
what happens to resources due to those) is not in scope for the
PDP. It is only since "last /8" that certain elements of the
"community" have tried, by hook or by crook, to arrogate
themselves the right to decide what happens to resources in the
event of M&A.

rgds,
Sascha Luck


>
>Not expressing any opinion in favour or against, just clarifying
>scope :)
>
>Cheers, Sander
>





From sander at steffann.nl  Mon May 30 17:57:20 2016
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 30 May 2016 17:57:20 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <20160530165310.GG862@cilantro.c4inet.net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
 <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
 <20160530165310.GG862@cilantro.c4inet.net>
Message-ID: <9D3C1270-93CF-42A2-93A9-98B193184B27@steffann.nl>

Hi Sasha,

> RIPE policy has, until recently, explicitly recognised that M&A (and
> what happens to resources due to those) is not in scope for the
> PDP. It is only since "last /8" that certain elements of the
> "community" have tried, by hook or by crook, to arrogate
> themselves the right to decide what happens to resources in the
> event of M&A.

It has always been in scope, it just hasn't been very interesting to write policy about. Until now when people are using it as a way to circumvent policy.

Cheers,
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/b585c81a/attachment.sig>

From gert at space.net  Mon May 30 18:55:03 2016
From: gert at space.net (Gert Doering)
Date: Mon, 30 May 2016 18:55:03 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <20160530165310.GG862@cilantro.c4inet.net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
 <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
 <20160530165310.GG862@cilantro.c4inet.net>
Message-ID: <20160530165503.GZ52179@Space.Net>

Hi,

On Mon, May 30, 2016 at 05:53:10PM +0100, Sascha Luck [ml] wrote:
> RIPE policy has, until recently, explicitly recognised that M&A (and

"explicitly" implies that this has been, uh, explicitly written down 
somewhere.  Could you provide a reference?

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 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160530/f03721da/attachment.sig>

From apwg at c4inet.net  Mon May 30 20:31:42 2016
From: apwg at c4inet.net (Sascha Luck [ml])
Date: Mon, 30 May 2016 19:31:42 +0100
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <20160530165503.GZ52179@Space.Net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
 <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
 <20160530165310.GG862@cilantro.c4inet.net>
 <20160530165503.GZ52179@Space.Net>
Message-ID: <20160530183142.GH862@cilantro.c4inet.net>

On Mon, May 30, 2016 at 06:55:03PM +0200, Gert Doering wrote:
>"explicitly" implies that this has been, uh, explicitly written down
>somewhere.  Could you provide a reference?

I was sure I'd read an explicit declaration that transfers due to
business transactions do not fall under transfer policies in one
of the alloc/assignment policy docs, however I might have been
wrong and was thinking of ripe-654 which is a Organisational
Document. 
This document, in sec 2.0 recognises transfers thus:

A member must inform the RIPE NCC ifone or bothof the following
changes occurs: 

Internet Number Resource are transferred. Such transfers may take
place:

Because of a change in the members business structure, for
example in the case of a merger or acquisition of the members
organisation.

In the case of a transfer of Internet number resources from the
member to another party according to RIPE Policies (section 5.5
and 6.4 of IPv4 Address Allocation and Assignment Policies for
the RIPE NCC Service Region , section 8 of IPv6 Address
Allocation and Assignment Policy and section 4.0 of Autonomous
System (AS) Number Assignment Policies ). Such a transfer may
also be facilitated through the RIPE NCC Listing Service .

The member changes its official legal name . Such a change may
occur, for example, because of a merger or acquisition of the
members organisation.

So there are transfers due to M&A, name changes, and *according
to transfer policy*. Three separate cases.

Which also means that 2015-04, stating explicitly that M&A
transfers are subject to policy, contradicts ripe-654 and would
trigger a change of this document - which I hope would be subject
to membership approval via GM vote.

rgds,
Sascha Luck




From ripe-wgs at radu-adrian.feurdean.net  Mon May 30 23:10:15 2016
From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN)
Date: Mon, 30 May 2016 23:10:15 +0200
Subject: [address-policy-wg] opposition to 2015-04
In-Reply-To: <20160530183142.GH862@cilantro.c4inet.net>
References: <7D0CA2AE-236D-477E-98A5-A8AE34C29EC3@gmail.com>
 <574561FD.7010502@v4escrow.net>
 <002701d1b9fb$de159020$9a40b060$@a2b-internet.com>
 <20160530152319.GF862@cilantro.c4inet.net>
 <294326BA-BED7-4601-89A8-10E6C3A17849@steffann.nl>
 <20160530165310.GG862@cilantro.c4inet.net>
 <20160530165503.GZ52179@Space.Net>
 <20160530183142.GH862@cilantro.c4inet.net>
Message-ID: <1464642615.3816778.622945737.3846A9EA@webmail.messagingengine.com>

On Mon, May 30, 2016, at 20:31, Sascha Luck [ml] wrote:
> So there are transfers due to M&A, name changes, and *according
> to transfer policy*. Three separate cases.
> 
> Which also means that 2015-04, stating explicitly that M&A
> transfers are subject to policy, contradicts ripe-654 and would
> trigger a change of this document - which I hope would be subject
> to membership approval via GM vote.

Hi,

Well, actually, to my understanding, the M&A procedure already changed
without vote from the membership.
The whole issue is "what is a merger or an acquisition". To my current
understanding:
 - Company A purchased 100% of company B parts/shares/equity -> NOT M&A
 - Company A purchased assets of company B including network and
 customer base -> YES M&A
 - Company A and company B merge (join their assets under a common
 entity) -> YES M&A
 - Company X changing name (irrelevant of reason) -> "name change"
 (ripe-645 section 4.0)
 - Merging LIRs from the same company -> NO LONGER M&A (which changed
 without any vote), or am I wrong ?

Concerning, the proposal, there is the very confusing section 2.2 for
which says two seemingly conflicting things. The best I can understand
(which seems to be confirmed by the impact analysis) is that the 24
months interval is reset by a M&A, but M&A is not subject to it.
Whatever M&A means, which is still out of policy's scope. The wording of
section 2.2 is my only issue, but I suppose it is a minor one (how easy
to read/understand a policy is, does not seem to be an issue).

Basically, no real impact on M&A (again, whatever that means).

--
Radu-Adrian FEURDEAN
fr.ccs



