Re: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update

[Gert Doering]

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>Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] 
> RIPE Policy Proposals - April Update
> < META http-equiv=Content-Type content="text/html; charset=windows-1251">
> < meta http-equiv="Content-Style-Type" content="text/css">
> < style 

Re: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update

[Sergiu IANCIUC]

Title: Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update




salut Riccardo,

I do not totally agree with you.. and I explain why.

you are talking about the case in the future.. but I give an actual example..

2 years ago my company has an allocated prefix from a LIR. After 1 year we asked additional resources and had a negative response because of the RIPE Policy limitations. after the next year the situation was the same and to receive an additional prefix we became LIR. Now, pls answer... why to not permit transfer from the old LIR to the new one if they agree on it and do it for ensure the new LIR in continuity of the prefix use (all this with condition that this prefix was allocated by the old LIR when the new LIR has the status OTHER).



Best Regards,

-
Sergiu IANCIUC
SC ITNS.NET SRL

MD-2068, Moldova
or. Chisinau, str. Miron Costin 3/1
tel.: +373 22 877 877
fax : +373 22 44 11 73
mobile: +373 690 22 111
url: http://www.itns.md

Save a tree... Don't print this email unless you have to...




Saturday, April 30, 2016, 8:33:49 AM, you wrote:






Dear Sergiu,
about your example and its eventual realtionship with the proposal 2015-05:
Company X would have not limit in receive address space as described in transfert or allocation policies.
The limit described in 2015-05 would be applied to the LIR that assigned space to Company X and, as described in your example, later transfered the space in Company X registry.
This LIR is supposed to not need address space as it moved it outside its registry so it would not be able to request an additional /22 allocation from pool outside 185/8 standing on 2015-05 proposal

On the other hand if Company X after its sing up as a new LIR after 18 months need more space and there is enough space outside 185/8  would be able to request an additional /22 standing on  2015-05 proposal. The LIR that offered the first /22 to Company X as  "assigned resource" could also request an additional /22 allocation if its registry is holding less than a /20 IPv4.

hope this help
regards
Riccardo

Il 29/04/2016 10:38, Sergiu IANCIUC ha scritto:
hello,

PLS, take in consideration the situation

Company  X  has  a  /22 from its LIR. The LIR can not offer more IPv4 
spaces   and the Company X becomes a LIR to satisfy its needs. Now, it 
is logical that the LIR (if agreed between these 2 LIRs) transfers the 
space  allocated  to the Company X (now the new LIR) AND THIS have to 
not be the part from the policy -

"requirements,  such  as  the LIR has not transferred any IPv4 address 
space before."

What are you thinking about?


Best Regards,


-
Sergiu IANCIUC
SC ITNS.NET SRL


MD-2068, Moldova
or. Chisinau, str. Miron Costin 3/1
tel.: +373 22 877 877
fax : +373 22 44 11 73
mobile: +373 690 22 111
url: http://www.itns.md


Save a tree... Don't print this email unless you have to...








This is a forwarded message
From: Marco Schmidt 
To: ncc-annou...@ripe.net
Date: Friday, April 29, 2016, 11:18:23 AM
Subject: [ncc-announce] [news] RIPE Policy Proposals - April Update


===8<==Original message text===
Dear colleagues,

Here is our monthly overview of open policy proposals and their stage in 
the RIPE Policy Development Process (PDP).

If you wish to join the discussion about a particular proposal, please 
do so on the relevant working group mailing list.

Proposals Open for Discussion:
2015-05, "Revision of Last /8 Allocation Criteria"

Proposals Awaiting Input:
2015-04, "RIPE Resource Transfer Policies"
2016-01, "Include Legacy Internet Resource Holders in the Abuse-c Policy"


Proposal Overviews:

PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria"
OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 
allocation from the RIPE NCC every 18 months. The latest version of the 
proposal suggests several requirements, such as the LIR cannot hold more 
than a /20 IPv4, must document their IPv6 deployment and has not 
transferred any IPv4 address space before.
STATUS: Discussion Phase
WHERE TO COMMENT: Address Policy Working Group: address-policy-wg@ripe.net
DEADLINE: 13 May 2016
FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05

=

The following proposals are awaiting input before they can go any 
further in the PDP.

PROPOSAL: 2015-04, "RIPE Resource Transfer Policies"
OVERVIEW: Aims to create a single transfer policy with all relevant 
information on the transfer of Internet number resources, replacing text 
in several RIPE Policies. The proposal also introduces a 24-month 
holding period for IPv4 addresses and 16-bit ASNs after any change of 
holdership.
RIPE NCC IMPACT ANALYSIS: Includes the point how the 24-month holding 
period for scarce resources will be applied.
STATUS: Review Phase – Awaiting decision from working group chair
FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-04

PROPOSAL: 2016-01, "Include Legacy Internet 

Re: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update

[Sergiu IANCIUC]

Title: Re[2]: [address-policy-wg] Fwd: [ncc-announce] [news] RIPE Policy Proposals - April Update




salut Riccardo,

1. I propose that here -

Proposals Open for Discussion:
2015-05, "Revision of Last /8 Allocation Criteria"

Proposal Overviews:

PROPOSAL: 2015-05, "Revision of Last /8 Allocation Criteria"
OVERVIEW: Aims to allow LIRs to request an additional /22 IPv4 
allocation from the RIPE NCC every 18 months. The latest version of the 
proposal suggests several requirements, such as the LIR cannot hold more 
than a /20 IPv4, must document their IPv6 deployment and has not 
transferred any IPv4 address space before.
STATUS: Discussion Phase
WHERE TO COMMENT: Address Policy Working Group: address-policy-wg@ripe.net
DEADLINE: 13 May 2016
FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2015-05

to be introduced a definition that includes in the " has not 
transferred any IPv4 address space before" list the LIR that transferred a prefix to an other LIR if this prefix was allocated to the receiving LIR when it was not the RIPE NCC member/LIR.

2. explain pls what does it signify

The latest version of the proposal suggests several requirements, such as the LIR cannot hold more than a /20 IPv4

cannot hold more then /20 unused ?




Best Regards,

-
Sergiu IANCIUC
SC ITNS.NET SRL

MD-2068, Moldova
or. Chisinau, str. Miron Costin 3/1
tel.: +373 22 877 877
fax : +373 22 44 11 73
mobile: +373 690 22 111
url: http://www.itns.md

Save a tree... Don't print this email unless you have to...




Saturday, April 30, 2016, 6:41:04 PM, you wrote:






Hi Sergiu,

thank you for your reply. I don't get if you disagree with current policy or proposed one.
Anyway:
The LIR that assisgned or allocated  the first /22 to your current new LIR can transfert the space once 24 months are passed.
This is the holding time before a transfert can take place standing on current policies.
2015-05 policy proposal won't change this aspect. 

kind regards 
Riccardo


Il 30/04/2016 11:29, Sergiu IANCIUC ha scritto:




salut Riccardo,

I do not totally agree with you.. and I explain why.

you are talking about the case in the future.. but I give an actual example..

2 years ago my company has an allocated prefix from a LIR. After 1 year we asked additional resources and had a negative response because of the RIPE Policy limitations. after the next year the situation was the same and to receive an additional prefix we became LIR. Now, pls answer... why to not permit transfer from the old LIR to the new one if they agree on it and do it for ensure the new LIR in continuity of the prefix use (all this with condition that this prefix was allocated by the old LIR when the new LIR has the status OTHER).



Best Regards,

-
Sergiu IANCIUC
SC ITNS.NET SRL

MD-2068, Moldova
or. Chisinau, str. Miron Costin 3/1
tel.: +373 22 877 877
fax : +373 22 44 11 73
mobile: +373 690 22 111
url: http://www.itns.md

Save a tree... Don't print this email unless you have to...




Saturday, April 30, 2016, 8:33:49 AM, you wrote:






Dear Sergiu,
about your example and its eventual realtionship with the proposal 2015-05:
Company X would have not limit in receive address space as described in transfert or allocation policies.
The limit described in 2015-05 would be applied to the LIR that assigned space to Company X and, as described in your example, later transfered the space in Company X registry.
This LIR is supposed to not need address space as it moved it outside its registry so it would not be able to request an additional /22 allocation from pool outside 185/8 standing on 2015-05 proposal

On the other hand if Company X after its sing up as a new LIR after 18 months need more space and there is enough space outside 185/8  would be able to request an additional /22 standing on  2015-05 proposal. The LIR that offered the first /22 to Company X as  "assigned resource" could also request an additional /22 allocation if its registry is holding less than a /20 IPv4.

hope this help
regards
Riccardo

Il 29/04/2016 10:38, Sergiu IANCIUC ha scritto:
hello,

PLS, take in consideration the situation

Company  X  has  a  /22 from its LIR. The LIR can not offer more IPv4 
spaces   and the Company X becomes a LIR to satisfy its needs. Now, it 
is logical that the LIR (if agreed between these 2 LIRs) transfers the 
space  allocated  to the Company X (now the new LIR) AND THIS have to 
not be the part from the policy -

"requirements,  such  as  the LIR has not transferred any IPv4 address 
space before."

What are you thinking about?


Best Regards,


-
Sergiu IANCIUC
SC ITNS.NET SRL


MD-2068, Moldova
or. Chisinau, str. Miron Costin 3/1
tel.: +373 22 877 877
fax : +373 22 44 11 73
mobile: +373 690 22 111
url: http://www.itns.md


Save a tree... Don't print this email unless you have to...








This is a forwarded message
From: Marco Schmidt 
To: ncc-annou...@ripe.net
Date: Friday, April 29, 2016, 11:18:23 AM
Subject: