Re: [address-policy-wg] New RIPE Labs Article - Building a stable future for the RIPE NCC

[Remco van Mook]

Dear  colleagues,

apologies for the second email but it appears I forgot to actually add a link 
to the article:

https://labs.ripe.net/author/remco-van-mook/building-a-stable-future-for-the-ripe-ncc/
Building a Stable Future for the RIPE NCC
labs.ripe.net


Kind regards

Remco van Mook
RIPE NCC Executive Board

> On 18 Apr 2024, at 15:17, Remco van Mook  wrote:
> 
> 
> Dear colleagues,
> 
> I’d like to draw your attention to an article that was just published on RIPE 
> Labs, about building a stable future for the RIPE NCC. 
> 
> As it touches on some very foundational aspects all across the various 
> working groups and NCC membership, I thought it important to share, and I 
> would very much like to ask everyone for their input and ideas. 
> 
> In order to not spread the discussion too much across the various mailing 
> lists, I suggest that we use the general RIPE list (which I’ve put into the 
> reply-to field of this email.
> 
> I’m currently in the process of organising a BOF during RIPE 88 on this topic 
> as well and am looking forward to a constructive discussion!
> 
> Kind regards,
> 
> Remco van Mook
> RIPE NCC Executive Board 
> 
> 

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] New RIPE Labs Article - Building a stable future for the RIPE NCC

[Remco van Mook]

Dear colleagues,

I’d like to draw your attention to an article that was just published on RIPE 
Labs, about building a stable future for the RIPE NCC. 

As it touches on some very foundational aspects all across the various working 
groups and NCC membership, I thought it important to share, and I would very 
much like to ask everyone for their input and ideas. 

In order to not spread the discussion too much across the various mailing 
lists, I suggest that we use the general RIPE list (which I’ve put into the 
reply-to field of this email.

I’m currently in the process of organising a BOF during RIPE 88 on this topic 
as well and am looking forward to a constructive discussion!

Kind regards,

Remco van Mook
RIPE NCC Executive Board 



-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Chair re-appointment - RIPE86

[Remco van Mook]

Strong support for both. Thanks Leo and James for your work.

Remco


On Wed, 17 May 2023, 10:52 Erik Bais,  wrote:

> Dear Working group,
>
> As you might remember, the WG Chairs are appointed for a set term as that
> reminds us now and then, for both the WG Chair as the WG, to think about if
> we are still happy with the current chair setup.
>
> More insight on the terms can be found at the AP-WG page on the RIPE
> website: https://www.ripe.net/participate/ripe/wg/active-wg/ap
>
> This RIPE86, the first term of both James Kennedy and Leo Vegoda is done
> and both stated that they would be more than happy to do another term.
>
> As the co-Chair of AP-WG, I'm glad that both want to run again for the
> stability of the WG, however in the end it is up to the WG if you are as
> well.
>
> So during the AP-WG session, we will have time in the agenda to ask the WG
> if you like to proceed with the current WG Chair setup.
>
> If you to replace one or both WG Chairs, please let me know up front and I
> will contact you to ask a couple questions in regards of introduction ..
> and we will ask the WG if they would like a WG chair change.
>
> We like to hear in the WG if you like to support the current WG chairs (or
> not) ... this can be done by a reply on this email, or during the meeting.
>
> See you all next week in Rotterdam.
>
> Regards,
> Erik Bais
> Co-Chair AP-WG
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

[remco van mook]

Dear all,

As one of the proposers I would like to point out that this proposal is not 
about changing the default allocation size for IXPs, and as such I personally 
consider suggestions to change it out of scope for a discussion on this policy. 
On top of that, I don’t think it’s  substantive opposition to enlarging the 
lifespan of the IXP pool, which is what this proposal aims to achieve - rather, 
I consider it an expansion of what is being proposed (do THIS and do THAT, too).

That said, having seen the arguments and numbers, I will personally commit to 
drafting a policy proposal to change the default IXP location size to something 
smaller (/25, /26, /27?) once the process on the current proposal has been 
concluded.

(With apologies to Radu for stealing his thread to reply)

Kind regards

Remco van Mook


> On 12 Aug 2019, at 10:01, Radu-Adrian FEURDEAN 
>  wrote:
> 
> On Sat, Aug 10, 2019, at 10:59, Nick Hilliard wrote:
>> I agree with Wolfgang - the current version is fine, and Gert - that it
>> is important to move on this because otherwise we'll lose the
>> opportunity forever, and that would be a shame because IXPs perform an
>> important function for the Internet as a whole.
> 
> +1
> We should go on with the current version.
> *IF* you consider that lowering the default to /25 is really necesarry, you 
> can still submit a new proposal for thay, AFTER the current one is ik and the 
> extra space secured.
> 
> --
> Radu-Adrian FEURDEAN
> 



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Remco van Mook]

I support this version of the policy proposal - all of my concerns I've voiced 
previously have been addressed.


Remco

> On 27 sep. 2016, at 15:08, Marco Schmidt  wrote:
> 
> Dear colleagues,
> 
> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE 
> Resource Transfer Policies" have now been published, along with an impact 
> analysis conducted by the RIPE NCC.
> 
> The goal of this proposal is to create a single document with all relevant 
> information regarding the transfer of Internet number resources.
> 
> Some of the differences from version 3.0 include:
> 
> - Adding a reference in all related allocation and assignment policies to the 
> new transfer policy document
> - Clarification in the policy text and policy summary regarding transfers due 
> to a change in the organisation’s business (such as a merger or acquisition)
> 
> You can find the full proposal and the impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2015-04
> 
> And the draft documents at:
> https://www.ripe.net/participate/policies/proposals/2015-04/draft
> 
> We encourage you to read the draft document and send any comments to 
>  before 26 October 2016.
> 
> Regards
> 
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
> 
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03: trading the last /22?

[Remco van Mook]

Hi Elvis,


> On 20 Jun 2016, at 12:53 , Elvis Daniel Velea  wrote:
> 
> Hi Gert,
> 
> I am surprised to see that you are defending this proposal more than
> the proposer :)


Since I'm the proposer I might as well respond. You know full well I'm capable 
of defending myself in any argument, so I'm kind of sad to see this 
half-accusation flying around, even as a joke - it isn't actually about the 
proposal.

Given the state of the the discussion around v2 of this proposal, with about 
120 emails as of this afternoon, of which a substantial part are rants, 
oneliners, conspiracy theories and off-topic anger, I've all but lost track on 
what substantive arguments have been presented that haven't already been 
addressed in this discussion. And so, I can well imagine, have others.

Between Gert as chair of this working group and me as a proposer, I have the 
easier job in this discussion as I only need to respond to the bits I think are 
relevant to the proposal; Gert however, has the unfortunate task of having to 
keep track of proponents, opposers and substantive arguments against the 
proposal as written.

With that out of the way, responding to the well-made observation by James 
Blessing last week: "Do we need to have the option for an LIR to transfer to 
and LIR who hasn't already had their final allocation?"

I think that's a very good point. Ideally, we'd repeal the transfer ban from 
this proposed policy when the RIPE NCC runs out of address space to satisfy 
article 5.1 of the IPv4 allocation policy - after all, the aim of the proposal 
is to restrict speculative behaviour while sticking with 'business as usual' 
for all others. Unfortunately, looking at the quagmire that we've walked into, 
I'd be very surprised if we'd have any functional IPv4 policy forming body left 
at that point. As for the other implication of this question, meaning a 
transfer before that day, I don't see why you'd want to do that; on top of 
that, making that carve-out likely creates yet another loophole for speculative 
purposes.

I think we'd do ourselves and the chairs a massive favour if we can keep this 
discussion civil and to the point.

Kind regards,

Remco



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Remco van Mook]

Hi Radu,

> On 17 Jun 2016, at 22:18 , Radu-Adrian FEURDEAN 
> <ripe-...@radu-adrian.feurdean.net> wrote:
> 
> On Fri, Jun 17, 2016, at 21:09, Remco van Mook wrote:
>> Let me get this straight - you oppose a proposed change in policy because
>> the change itself is not part of current policy?
> 
> No, more people than you expected oppose it because you make an explicit
> reference to allocation made after a certain date in the past:
> 
> All allocations made by the RIPE NCC to LIRs after 14 September 2012
> will be marked in the RIPE Database as “ALLOCATED FINAL”.
> 
> 
> Just remove "after 14 September 2012" and you ban all transfers. Not
> necessarily a bad idea.
> 

1. I make specific reference to the date that 'final /8' came into effect in 
the same way it's used in current policy. It's not just some random day. If 
there was any other way to reference 'every allocation made under this policy' 
that wasn't hopelessly broken or confusing I would have done so.

2. You're making assumptions about my expectations. Please don't.

3. 2007-08 also impacted previously allocated IPv4 space in a massive way. The 
concept introduced in that policy is what's called 'transfers' these days. I 
remember because I wrote it.

4. I don't see how this piece of your response in any way relates to my 
question to Stefan.


>> Also, those "heavily disadvantaged members" as you describe them, only
>> have received address space thanks to a particularly selfless decision by
>> the community at the time to dedicate the last remaining address space to
>> that purpose, rather than just blowing through it by early 2013.
> 
> Like in "we won't kill you with a bullet in the head, we will kill you
> by letting you slowly bleed to death". Thanks.
> Now you try to regulate how you are allowed (or not) to heal yourself.


I don't understand what you're trying to say here. Who is "we", who is "you" 
and what does "heal yourself" mean in this context?

Remco




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Remco van Mook]

Hi Stefan,

> On 17 Jun 2016, at 19:32 , Stefan Prager  wrote:
> 
> There is no mention in the Service Agreement that allocations provided after 
> 14th September 2012 are to be treated differently than those handed out 
> before the 15th September 2012. There is also no mention in the respective 
> policies, as was mentioned during one of the talks at RIPE-72 in Denmark, 
> that allocations received after the 14th September 2012 are to be used for 
> the sole purpose of providing legacy connections to IPv4 networks.
> 
> Therefore it seems inconceivable that this proposal is allowed to go forward 
> any longer than it already has as it would seek to single out already heavily 
> disadvantaged members even more for the sole reason that they happen to be 
> holding an allocation received after the 14th September 2012.


Let me get this straight - you oppose a proposed change in policy because the 
change itself is not part of current policy?

Also, those "heavily disadvantaged members" as you describe them, only have 
received address space thanks to a particularly selfless decision by the 
community at the time to dedicate the last remaining address space to that 
purpose, rather than just blowing through it by early 2013.


Remco
heavily disadvantaged member



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Remco van Mook]

Thank you Marco.

Dear all,

I would encourage everyone to carefully read this second version (and not just 
respond "no, still hate it, kill it with fire") as it is quite different from 
the first version.

Basically the only restriction left is to disallow transfers on all "last /8 
space"* going forward, and there is some language added to the policy that 
tries to raise awareness that if you just go and parcel out that entire 
allocation to endusers, you might end up feeling a little bit silly a couple of 
years from now.

Looking forward to a positive discussion,

Remco

* any suggestions for a better title for this space are most welcome as well

> On 16 Jun 2016, at 15:58 , Marco Schmidt  wrote:
> 
> Dear colleagues,
> 
> The Discussion Period for the policy proposal 2016-03, "Locking Down the 
> Final /8 Policy" has been extended until 15 July 2016.
> 
> The goal of this proposal is to ban transfers of allocations made under the 
> final /8 policy.
> 
> 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:
> - Several restrictions have been removed
> - Adds a recommendation that LIRs should conserve whole or part of their 
> final /22 allocation for interoperability purposes
> 
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2016-03
> 
> We encourage you to review this policy proposal and send your comments to 
> .
> 
> Regards,
> 
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
> 
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

[address-policy-wg] opposition to 2015-04

[Remco van Mook]

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Remco van Mook]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Remco van Mook]

Hi Jerome,


> On 17 May 2016, at 16:26 , Jérôme Nicolle  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 
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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Remco van Mook]

> On 17 May 2016, at 14:33 , Denis Fondras  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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Remco van Mook]

Arash,



> On 10 May 2016, at 03:18 , Arash Naderpour  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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[remco van mook]

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  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 .
>
> Regards,
>
> Marco Schmidt
> Policy Development Officer
> RIPE NCC
>
>

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

[remco van mook]

Dear all,

thank you Erik for providing this helpful summary - although I do not think
I was quite as indefinite in my concerns as you put in your summary :)

I'll keep it simple and straightforward this time to prevent any confusion.

1) There is no need to restructure our set of policies based on the
intention of this proposed policy. The intended simplification and
abbreviation from the first drafts has been all but removed in this version
to fix the holes that the simplification created.

2) That being said, I do support the intended direction of this policy
proposal, but instead of creating a new separate document and ripping parts
out of existing documents, I'd much prefer the change to be reflected in
the existing set of documents, even if that means multiple documents having
near-identical pieces of text. This is policy, not a database design.

3) A discussion is needed (and I don't even know where that discussion
belongs, I'll leave that up to the RIPE chair to decide) on the structure
of our set of policies, with the goal of increasing accessibility,
transparency and reducing the risk of potential gaps, conflicts and
duplicates.

4) Only after a conclusion of the discussion under 3) we should start
entertaining policy proposals that change the nature of current policy
structure.

Kind regards,

Remco
Private Internet Citizen

On Wed, Mar 2, 2016 at 4:31 PM Erik Bais  wrote:

> Hi,
>
> As we are almost at the end of the current phase (after today. ) I would
> like to ask the AP-WG Chairs if they agree to add at least 2 weeks
> additional time to the discussion time to make sure that all pros and cons
> are discussed.
>
> Currently we are looking at an objection from Remco v. Mook ( with no hats
> )
> that there might be some future issue on similar policy changes that might
> provide a policy issue as the previous version of the draft had.
>
> While I understand his line of thinking, I don’t think that we give the
> legal team enough credit to spot future issues similar as the one in the
> past draft.. I like to think there is a learning curve …
> And I will also invite Remco to keep reading future policy proposals from
> myself and others to make sure that there aren’t any un-intentional issues
> that might be introduced in future policy.
>
> Having said that, he also stated that there is currently nothing wrong with
> the version at the table.
>
> On the final remark of Remco, if we need to see if we need to review the
> actual current structure of the policies.. I agree and I would like to have
> a good discussion on that.
> But that is to me a discussion outside the scope of this policy proposal.
>
> On the suggestion of Remco and second by Tore (also with no hats), Tore
> wrote :
>
> > Remco suggested adding references to the new policy document in lieu of
> > the removed sections in ripe-638, ripe-649, and ripe-655. I would not
> > object to that.
>
> This was later also agreed to by a (+1) from Sascha Luck (also without any
> hats), Guy Chilton (Again .. no hats..)
>
> And if we agree that the blunt removal of the transfer text in the current
> affected policies and having a single transfer document isn't clear enough,
> I'm not against adding a reference to the new proposed transfer policy
> document.
>
> The only response opposing to the current structure is Peter Koch.
>
> Peter stated that he is :
> > "Generally I'm always nervous when policy/legislation is
> > "streamlined" by "just editorial changes", and also recent experience
> here
> > would suggest extreme caution. Things get complicated when they are
> > taken out of their respective context (tempus and locus)."
>
> And I agree partially with him. Doing things with caution is something that
> we are all part of here.. And I think that we have proven that we are very
> careful on making certain changes.
> The biggest change here is indeed the editorial one, however that is to
> avoid in doing large changes while also doing editorial changes .. it was
> clear to everyone that the editorial changes was desired by the majority of
> the community when the initial changes / transfer policy text was written
> into the policies.. and this was the 'clean-up and stream-line action.'
>
> > At least, the work is incomplete as proposed now, simply because the
> > affected policies will have to be re-published with a new number and
> timestamp,
> > so the (outdated) references will have to be adjusted (this includes
> > evaluation and thus is more than a simple editorial change) and now
> > obsolete text ought to be dealt with accordingly. The necessity to
> > add normative references to a new omnibus document has already been
> mentioned.
>
> I'm reading this that Peter could live with the suggestion done by Remco
> for
> the references.. if we are going that route..
> And from what I've heard, a change like Remco suggested, would not require
> a
> complete rehash into the PDP or redoing any phases again.
>
> I hope 

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

[Remco van Mook]

Hi all,

(all hats off)

While I am highly sympathetic to harmonising transfer policies across all 
resources, I object to the proposal as written.

The really short reason is as follows (and I quote)

[The following policy will replace:

- Sections 5.5 and 6.4 in ripe-649, "IPv4 Address Allocation and Assignment 
Policies for the RIPE NCC Service Region"
- Section 4.0 in ripe-638, "Autonomous System (AS) Number Assignment Policies"
- Section 8. in ripe-655, "IPv6 Address Allocation and Assignment Policy"
- ripe-644, "Policy for Inter-RIR Transfers of Internet Resources"

Accordingly, these sections or policy documents will be deleted.]

(end quote)

Up until this policy proposal, the structure of RIPE policy documents has 
always been very much resource aligned, not process aligned. There's a document 
for IPv4, for IPv6, for ASNs. This policy proposal changes that structure in a 
material way, and inadvertently creates a matrix of resource-oriented and 
activity-oriented policies, in an attempt to harmonise and simplify.

While laudable goals, this matrix created the loophole I discovered in the 
previous version of the policy text, and the fix to that loophole in this 
version is to remove most of the simplification that was introduced. This is in 
my opinion inherent to a matrix structure for policies, and while I can't find 
a new loophole in this text right now, we'll introduce the risk for 
similar-sized loopholes in all future policy proposals. The one in this 
proposal was caught. We're likely to miss others.

So what's left is policy harmonisation between resources. I don't think that 
warrants restructuring our policies.

Of course, we've already had activity-oriented policies (the inter-RIR one, 
mergers and closures, resources for the RIPE NCC) but those were in very 
specific, well-defined areas that didn't stipulate specific requirements for 
resources, which is where the loophole potential comes in.

I'd be much more in favour of taking the proposed policy text, and merge it 
into the various existing resource policies instead of creating a separate 
document. If we DO keep it as a separate document, I must insist that instead 
of removing sections from other policy documents altogether, reference is made 
to this new policy instead.

On a broader scale, perhaps it's time to look at the structure of RIPE policy 
as a whole. The problem is, I don't have a clue where that discussion belongs, 
and whether even the PDP applies to that kind of discussion :)

Kind regards,

Remco


> On 03 Feb 2016, at 19:00 , Gert Doering  wrote:
> 
> Dear Working Group,
> 
> On Wed, Feb 03, 2016 at 02:59:06PM +0100, Marco Schmidt wrote:
>> The draft documents for version 3.0 of the policy proposal 2015-04,
>> "RIPE Resource Transfer Policies"
>> have now been published, along with an impact analysis conducted by the
>> RIPE NCC.
> 
> So this is the impact analysis you have been waiting for :-)
> 
> Please read, think about, and comment
> 
> [ ] yes, this makes sense, go there
> [ ] I agree with the general direction of having a single document, but
> I disagree with changing ___, because...
> [ ] I think we should be organizing this differently, and totally not
> group the policy documents "by activity" but "by resource" (= transfer
> policy section in the IPv4, IPv6 and AS number policy documents)
> 
> Gert Doering
>-- APWG chair
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: 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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[remco van mook]

On Tue, Oct 20, 2015 at 9:35 PM Ciprian Nica  wrote:

>
> I totally agree with Remco except this point. I know a large european
> telco that already has bought ~ 2 million IPs so they would be able to
> justify the need for a very large chunk. And, besides that the
> "justified need" was never something objective, it was easy to
> manipulate. We should just say goodbye to needs period and stick with
> one bread each so there's enough for everyone.
>
>
I think I was very specific in saying it is a bad idea for a whole bunch of
other reasons, but if you want to touch 'additional allocations for LIRs'
at all, it would be the one somewhat feasible option.

Which is all the more reason why any proposal to this end is a bad idea.

Best

Remco

Re: [address-policy-wg] We need IPv4 transfers

[remco van mook]

(all hats off)

If you design your network infrastructure so it requires a /21 to work,
when a /22 is all you're likely to get, the problem is not the policy
giving you a /22.

And as always, if you don't like a policy, propose a new one yourself.

Remco

On Mon, Jun 29, 2015 at 10:53 PM Gert Doering g...@space.net wrote:

 Hi,

 On Mon, Jun 29, 2015 at 11:23:19PM +0300, Petr Umelov wrote:
  One more argument.
 
  For example LIR has IPv4 185.100.104.0/22 and 185.100.116.0/22 (we talk
 that multi LIRs accounts don't abuse the system and LIR can have such IPs)
 
  But LIR's infrastructure needs to have /21. LIR can write to
 185.100.108.0/22 owner and change his 185.100.116.0/22.
 
  But LIR has to wait for 24 months to do it if this proposal is approved.

 There is nothing that you could do with a /21 that you could not do with
 2x /22.  Except, maybe, sell it off as a single /21.

 Next.

 Gert Doering
 -- APWG chair
 --
 have you enabled IPv6 on something today...?

 SpaceNet AGVorstand: 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

Re: [address-policy-wg] New on RIPE Labs: IPv4 Transfers in the RIPE NCC Service Region

[remco van mook]

Three years and one day ago, I wrote on this very list:

...Personally I'm rather sick and tired of hearing people say 'yes,
let's break
IPv4 so we all MUST move to IPv6'. If you think this is good policy or even
good engineering, please think again. It will make us end up with a broken
internet that, surprise, we won't be managing any more. Breaking IPv4 might
lead to increased IPv6 adoption, but not on the internet as we know it
today. Everybody who wants to connect his organisation to the internet is
going to need at least some IPv4 address space for the time being, so why
screw it up for new entrants?...

Whether this is about reinventing final /8 or about people making money on
IPv4 transfers does not make one jot of a difference.


Remco

(no hats)



On Fri, May 8, 2015 at 1:54 PM Sebastian Wiesinger sebast...@karotte.org
wrote:

 * Dan Lüdtke m...@danrl.de [2015-05-08 11:33]:
  See, we can not win this games. Let’s stop wasting energy and
  resources on dealing with legacy IP and how to make it work for a
  bit longer. New entrants are entering are market that is not fair,
  and we can not make a real difference. The only way forward is to
  push IPv6 and restore a healthy climate regarding the availability
  of IP addresses.

 Dan,

 if you don't want to invest your time trying to make this market more
 fair by all means go ahead and do something else. There are still
 people here who would like to try so that new players can enter a
 market that will be dominated by IPv4 for some time to come.

 Most people here are pushing IPv6 but as much as you want to bury IPv4
 it will still be around for some time.

 Regards

 Sebastian

 --
 GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
 SCYTHE.
 -- Terry Pratchett, The Fifth Elephant