[address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

On Fri, Sep 22, 2017 at 17:40 Jetten Raymond <raymond.jetten at elisa.fi>
wrote:

> Dear AP-WG,
>
> I Oppose this 2017-03 proposal,
>
> IPv6 has been around for decades, and "we" have failed to implement it in
> time. I see no point in rewarding laziness and yet trying to again give
> more time to seriously start to implement v6. The more time we are given,
> the more time it will take, that’s how we have done it in the past, and I
> don’t see the laziness go if not forced to. Warnings were ignored, we (v6
> advocates) were laughed at, "again it will end", " you’ve told us that many
> years". Even if we only hand out a /28, we still have the basic problem,
> and it won't go away v4 WILL run out. Don’t make the suffering any longer.
>
> Rgds,
>
> Ray
>

+1

>
> -----Original Message-----
> From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On
> Behalf Of Palumbo Flavio
> Sent: 22. syyskuuta 2017 11:17
> To: Daniel Suchy <danny at danysek.cz>; address-policy-wg at ripe.net
> Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing
> Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
>
> I don't see TOO any problem in reduction of initial (minimal) IPv4
> allocation. So i support this idea TOO .
>
> -----Messaggio originale-----
> Da: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Per
> conto di Daniel Suchy
> Inviato: venerdì 22 settembre 2017 10:09
> A: address-policy-wg at ripe.net
> Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing
> Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
>
> Hello,
> /24 is de-facto standard accepted in routing tables these days and also
> /24 was used in large scale during PI assignments - so I don't see any
> problem in reduction of initial (minimal) IPv4 allocation. So i support
> this idea.
>
> But I would like to keep option for asking more than /24 (up to /22
> maximum, as was decided in the past) LIRs eligible for allocation, if LIR
> properly documents his request.
>
> From my own practice there're some LIR, where /24 is sufficient and they
> just become LIRs because there's no other real option to get independent
> addresses (old "PI") and with /22 we're just wasting limited resource.
> But there're also LIRs, where /22 will actively used.
>
> I don't see any problems in terms of RFC 2050 mentioned here and memory
> contraints, providers had to upgrade their routers in meantime anyway (at
> least due to IPv6 adoption). Fragmentation up to /24 is long-term reality
> and we had to deal with it anyway.
>
> With regards,
> Daniel
>
>
> On 09/21/2017 01:43 PM, Marco Schmidt wrote:
> > Dear colleagues,
> >
> > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4
> > Allocation, aiming to preserve a minimum of IPv4 space", is now
> available for discussion.
> >
> > The goal of this proposal is to reduce the IPv4 allocations made by
> > the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not
> > received an IPv4 allocation directly from the RIPE NCC before.
> >
> > You can find the full proposal at:
> > https://www.ripe.net/participate/policies/proposals/2017-03/
> >
> > As per the RIPE Policy Development Process (PDP), the purpose of this
> > four-week Discussion Phase is to discuss the proposal and provide
> feedback to the proposer.
> >
> > At the end of the Discussion Phase, the proposer, with the agreement
> > of the RIPE Working Group Chairs, decides how to proceed with the
> proposal.
> >
> > We encourage you to review this proposal and send your comments to
> > <address-policy-wg at ripe.net> before 20 October 2017.
> >
> > Kind regards,
> >
> > Marco Schmidt
> > Policy Development Officer
> > RIPE NCC
> >
> > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
> >
>
>
> Check Point
> Le informazioni contenute in questo messaggio di posta elettronica e in
> ogni
> eventuale documento allegato sono riservate, potrebbero essere coperte dal
> segreto professionale e possono essere utilizzate esclusivamente dal
> destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio
> o
> dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o
> divulgazione delle informazioni negli stessi contenute, sono da
> considerarsi
> come vietate e potrebbero costituire violazione delle normative ivi
> applicabili. Se ricevete questo messaggio per errore Vi preghiamo di
> volerci avvertire immediatamente tramite posta elettronica o
> telefonicamente
> e di cancellare il presente messaggio e ogni documento ad esso allegato dal
> Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a
> proteggere la nostra rete da virus e non ci assumiamo alcuna
> responsabilita'
> in ordine a possibili virus che possano essere trasferiti con la presente
> mail.
> Grazie.
>
> *****************
>
> The information contained in this e-mail and in any file transmitted with
> it
> is confidential and may be privileged for the sole use of the designated
> addressee. Any unauthorized dissemination or copying of this e-mail or its
> attachments, and any use or disclosure of any information contained in
> them,
> is strictly prohibited and may be illegal. If you are not the designated
> addressee, please notify the sender immediately by e-mail or by telephone
> and delete this e-mail and any file transmitted with it from your system.
> We make every effort to keep our network free from viruses and take no
> responsibility for any computer virus which might be transferred by way of
> this
> e-mail.
> Thank you.
>
-- 
--
Kind regards.
Lu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20170922/c47ada7f/attachment.html>