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
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
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
>
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:
>
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
>
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
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
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
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"*
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
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
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
> 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'
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
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
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
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
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
>
(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
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
20 matches
Mail list logo