I have the strong suspicion that this is another example of trying to
codify special/corner cases. Doing this takes disproportionate amounts
of energy and causes an ever increasing amount of undesired side
effects.
How about giving the RIPE NCC discretion to make sensible decisions
On 9 Apr 2021, at 14:20, Erik Bais wrote:
… And I would suggest to the working group to extend, if the WG
agrees, to accept both applicants, so that we are going to a 3 chair
WG. …
By all means as long as the three of you are all comfy with this and you
can work out the rotation in the
On 28 Oct 2020, at 13:33, Aleksey Bulgakov wrote:
> I understand that the NCC tries to find additional funds and implements
> additional restrictions to force their members to make additional spending.
The RIPE NCC does not do that.
Daniel
xxx == stat
---
Sent from a handheld device.
> On 9. Oct 2019, at 21:16, Hank Nussbacher wrote:
>
> On 09/10/2019 09:58, David Guo via address-policy-wg wrote:
>
> David,
>
> Thanks. But shouldn't one be able to query something like this from some
> xxx.ripe.net site rather than
On 06/02/2019 11:23, Martin Huněk wrote:
>> ...
>> c) It is not tenable for the RIPE NCC to require the first LIR on the
>> waiting list to wait for more address space than a minimal usfeful block
>> to accumulate.
>
> Here it starts. I would say get such a LIR what you have got (to /22 of
>
On 06/02/2019 11:40, Jim Reid wrote:
>
>
>> On 6 Feb 2019, at 09:39, Daniel Karrenberg wrote:
>>
>> d) The length of the waiting list and other practicalities should be
>> secondary considerations after these principles above. For instance, the
>> R
Oh my! I kept revising this and introduced crap while doing so.
For clarity:
On 06/02/2019 10:39, Daniel Karrenberg wrote:
> ... Specifically why not just say "This polixy into
> effect on September 1st 2019"?
"This policy comes into effect om Spetember 1st 2019.&quo
After reading and thinking I arrive at the following principles:
a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses
as long as it has blocks that are useful to route packets.
Note: As an individual I would very much like to just stop with this
silliness. However I do not
This policy assumes that once the RIPE NCC pool gets 'exhausted' it will
never be very large. Are we OK to continue allocating /24s in the
unlikely, but possible, event that the RIPE NCC ever gets back a larger
chunk?
If not, it would be better to re-write the policy to do two independent
On 04/02/2019 14:40, Jim Reid wrote:
>
>
>> On 4 Feb 2019, at 13:27, Sander Steffann wrote:
>>
>> It seems you misunderstand the proposal. This policy agrees with you that
>> /22s should be allocated until RIPE NCC runs out. It is about what happens
>> afterwards. We create a waiting list
10 matches
Mail list logo
