[address-policy-wg] Working group chair selection process

2015-03-19 Thread Sander Steffann
Hi Working Group,

We finally have a final draft for the working group chair selection process. 
Sorry for taking so long. Here is the text we propose to use:

---
The RIPE Address Policy Working Group aims to maintain a team of two 
Chairpersons whenever possible.

# Electing a chairperson

Once a year one of the chairs will step down, allowing new candidates the 
opportunity to become chair. The chairs take turns stepping down, and this is 
announced to the working group mailing list at least one month before the start 
of a RIPE meeting. 

The working group will select new chair(s) at the RIPE Address Policy Working 
Group session. Those present at the session, either in person or remotely, will 
determine by consensus among themselves who takes the available position(s). 
The remaining chair will determine whether consensus has been reached. If the 
working group finds itself without a chair the RIPE chair will determine 
consensus.

If no consensus can be reached then a secret ballot to elect the new chair(s) 
will be held at the working group session. Everyone physically present at the 
session can participate in the secret ballot. Votes will be counted by RIPE NCC 
Staff, and the result will be determined using proportional representation 
through the single transferable vote, otherwise known as PR-STV. The winner(s) 
of the secret ballot will become the new chair(s).

# Running for chairperson

Anybody is allowed to volunteer for a vacant chair position, including former 
chairs. 

Those who volunteer to chair the RIPE Address Policy Working Group should be 
aware of the responsibilities and work this involves. A description of the 
responsibilities of a RIPE working group chair can be found in Working Group 
Chair Job Description and Procedures (http://www.ripe.net/ripe/docs/ripe-542).

# Removing a chairperson

When a significant number of participants in the working group are unsatisfied 
with a particular chair, and this cannot be resolved by discussion within the 
working group, they can call for a vote of no confidence. The vote must be 
requested on the mailing list at least one week before a RIPE meeting. The vote 
will be resolved using a secret ballot, which will be held at the working group 
session. Everyone physically present at the meeting can participate. The votes 
will be counted by RIPE NCC Staff and the result is determined by simple 
majority. If the vote is passed the chair who is the subject of the vote will 
step down immediately.
---

We're doing a two-week last-call on this (ending on Friday 3 April) and if 
there are no objections we will use this process starting at RIPE70 in 
Amsterdam.

Cheers,
Sander  Gert
The current APWG chairs




Re: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations)

2015-03-19 Thread Sonia Garbi Gomez
Dear all

For 2015, all RIPE NCC members are charged an annual service fee of € 1,600 for 
each LIR account they hold.
For New LIRs that are established during the year, the service fee is applied 
pro rata, meaning thus that new LIRs established during the course of 2015, are 
charged as follow:

New LIR established:Total fee:  How the fee is made up:
* during first quarter   € 3,600Sign up fee (€ 2,000) + service fee (€ 
1,600)
* during second quarter  € 3,200Sign up fee (€ 2,000) + service fee (€ 
1,200)
* during third quarter   € 2,800Sign up fee (€ 2,000) + service fee (€ 
800)
* during fourth quarter  € 2,400Sign up fee (€ 2,000) + service fee (€ 
400)

I hope this clarifies the question.
best regards

Sonia Garbi Gomez
Finance Manager
RIPE NCC


[address-policy-wg] aggregating unused allocations

2015-03-19 Thread Antonis Lioumis

Hello

Recently my company got a /22 allocation through the well known transfer 
procedure between LIR's.
In the past we also got the /22 we qualify from RIPE NCC's last /8. This 
/22 was put aside for future use.
For aggregation purposes we asked RIPE NCC to return both /22 and get 
back a /21 but according to current policies this is forbidden.
Since global routing table has exceeded 50 prefixes and expected to 
grow more maybe RIPE community should rethink permitting the exchange of 
smaller IPv4 blocks with contiguous one.



Regards

Antonis Lioumis




Re: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations)

2015-03-19 Thread Elvis Daniel Velea

Hi Sonia,

those numbers were quite clear. What we were wondering is whether it is 
possible to register an LIR in Q4 2015, pay the €2400, receive the /22, 
transfer the /22, close the LIR within the same quarter.


Or, does the LIR need to pay the fee for a whole year (4 quarters) when 
they close (or transfer the /22) - regardless on which Q they were opened?


Regards,
Elvis

On 19/03/15 10:02, Sonia Garbi Gomez wrote:

Dear all

For 2015, all RIPE NCC members are charged an annual service fee of € 1,600 for 
each LIR account they hold.
For New LIRs that are established during the year, the service fee is applied 
pro rata, meaning thus that new LIRs established during the course of 2015, are 
charged as follow:

New LIR established:Total fee:  How the fee is made up:
* during first quarter€ 3,600   Sign up fee (€ 2,000) + service fee (€ 
1,600)
* during second quarter € 3,200 Sign up fee (€ 2,000) + service fee (€ 1,200)
* during third quarter  € 2,800 Sign up fee (€ 2,000) + service fee (€ 800)
* during fourth quarter € 2,400 Sign up fee (€ 2,000) + service fee (€ 400)
I hope this clarifies the question.
best regards

Sonia Garbi Gomez
Finance Manager
RIPE NCC



--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

Email: el...@v4escrow.net mailto:el...@v4escrow.net
US Phone: +1 (702) 475 5914
EU Phone: +31 (0) 61458 1914

Recognised IPv4 Broker/Facilitator in:

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you have 
received this email in error, please notify the sender immediately and 
delete the original.Any other use of this email is strictly prohibited.




Re: [address-policy-wg] aggregating unused allocations

2015-03-19 Thread Carsten Schiefner
Hi Antonis -

On 19.03.2015 09:54, Antonis Lioumis wrote:
 Recently my company got a /22 allocation through the well known transfer
 procedure between LIR's.
 In the past we also got the /22 we qualify from RIPE NCC's last /8. This
 /22 was put aside for future use.
 For aggregation purposes we asked RIPE NCC to return both /22 and get
 back a /21 but according to current policies this is forbidden.
 Since global routing table has exceeded 50 prefixes and expected to
 grow more maybe RIPE community should rethink permitting the exchange of
 smaller IPv4 blocks with contiguous one.

how about sending text for a policy (change) in this respect? :-)

Cheers,

Carsten



Re: [address-policy-wg] aggregating unused allocations

2015-03-19 Thread Scott Leibrand
For reference, in the ARIN region we just got rid of our aggregation policy
because it was almost never used, and staff had identified a loophole where
a large address holder could have requested a large aggregation block,
exhausted the free pool, and then taken their time about returning the
smaller blocks.

If you want to implement an aggregation policy in RIPE, it's probably worth
taking the ARIN experience into account and drafting the policy to deal
with those issues.

-Scott

On Thu, Mar 19, 2015 at 4:07 AM Carsten Schiefner ripe-wgs...@schiefner.de
wrote:

 Hi Antonis -

 On 19.03.2015 09:54, Antonis Lioumis wrote:
  Recently my company got a /22 allocation through the well known transfer
  procedure between LIR's.
  In the past we also got the /22 we qualify from RIPE NCC's last /8. This
  /22 was put aside for future use.
  For aggregation purposes we asked RIPE NCC to return both /22 and get
  back a /21 but according to current policies this is forbidden.
  Since global routing table has exceeded 50 prefixes and expected to
  grow more maybe RIPE community should rethink permitting the exchange of
  smaller IPv4 blocks with contiguous one.

 how about sending text for a policy (change) in this respect? :-)

 Cheers,

 Carsten