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

Hi Sergiu,


Il 30/04/2016 19:15, Sergiu IANCIUC ha scritto:
> 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 at ripe.net <mailto:address-policy-wg at 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.
>
If I understand well your point this is already a requirement in 
2015-05. Please have a look to the full proposal at 
https://www.ripe.net/participate/policies/proposals/2015-05
point [...] "3.1. The LIR has not transferred any IPv4 address space to 
another LIR, a member of another RIR, or an End User." [...]
>
>
> 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 ?
>
Doesn't matter if the /20 is used or not. With current text of the 
2015-05 if an LIR already holds up to a /20 could not request any 
additional allocation from available pool outside 185/8.
If he didn't request a last /22 from 185/8 he can request it at any time.
Feel free to give the list your opinion about supporting 2015-05 or not.

thank you for your interest
kind regards
Riccardo
>
>
>
>
>
> 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 <mschmidt at ripe.net> <mailto:mschmidt at ripe.net>
>
> To: ncc-announce at ripe.net <mailto:ncc-announce at 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 at ripe.net <mailto:address-policy-wg at 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 Resource Holders in the
>
> Abuse-c Policy"
>
> OVERVIEW: Aims for a mandatory abuse contact for Legacy Internet
>
> Resource holders in the RIPE Database.
>
> STATUS: Discussion Phase – Awaiting decision from proposer
>
> FULL PROPOSAL: https://www.ripe.net/participate/policies/proposals/2016-01
>
>
>
> The RIPE NCC provides an overview of current RIPE Policy Proposals on 
> www.ripe.net 
> <http://www.ripe.net>:https://www.ripe.net/participate/policies/current-proposals/current-policy-proposals
>
>
> We look forward to your involvement in the PDP.
>
>
> Kind regards,
>
>
> Marco Schmidt
>
> RIPE Policy Development Officer
>
> RIPE NCC
>
>
>
>
> ===8<===========End of original message text===========
>
>
>
>
>
>
>
> -- 
>
>
> Ing. Riccardo Gori
>
> e-mail: rgori at wirem.net <mailto:rgori at wirem.net>
>
> Mobile:  +39 339 8925947
>
> Mobile:  +34 602 009 437
>
> Profile: https://it.linkedin.com/in/riccardo-gori-74201943
>
> WIREM Fiber Revolution
>
> Net-IT s.r.l.
>
> Via Cesare Montanari, 2
>
> 47521 Cesena (FC)
>
> Tel +39 0547 1955485
>
> Fax +39 0547 1950285
>
>
> --------------------------------------------------------------------
>
>  CONFIDENTIALITY NOTICE
>
> This message and its attachments are addressed solely to the persons
>
> above and may contain confidential information. If you have received
>
> the message in error, be informed that any use of the content hereof
>
> is prohibited. Please return it immediately to the sender and delete
>
> the message. Should you have any questions, please contact us by re-
>
> plying to info at wirem.net <mailto:info at wirem.net>
>
>         Thank you
>
> WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
>
> --------------------------------------------------------------------
>
>
>
> -- 
>
>
> Ing. Riccardo Gori e-mail: rgori at wirem.net 
> <mailto:rgori at wirem.net>Mobile:  +39 339 8925947 Mobile:  +34 602 009 
> 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943
>
> WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 
> Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 
> -------------------------------------------------------------------- 
> CONFIDENTIALITY NOTICE This message and its attachments are addressed 
> solely to the persons above and may contain confidential information. 
> If you have received the message in error, be informed that any use of 
> the content hereof is prohibited. Please return it immediately to the 
> sender and delete the message. Should you have any questions, please 
> contact us by re- plying to info at wirem.net <mailto:info at wirem.net>    
>    Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 
> Cesena (FC) 
> --------------------------------------------------------------------
>

-- 

Ing. Riccardo Gori
e-mail: rgori at wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile: https://it.linkedin.com/in/riccardo-gori-74201943

WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying to info at wirem.net
         Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20160430/c8c891bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logoWirem_4cm_conR.jpg
Type: image/jpeg
Size: 41774 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20160430/c8c891bc/attachment.jpg>