[address-policy-wg] Minutes of the RIPE87 Rome meeting

[Erik Bais]

Dear WG,

I like to wish you all a very healthy and successful 2024, on behalf of myself 
and the other AP-WG chairs.

We’ve received the minutes of the RIPE87 meeting and the RIPE NCC was so kind 
to publish them already for your review online.
And I like to thank the RIPE NCC in creating the minutes for us.

Please review the minutes and provide feedback if you think there is something 
missing or incorrect.

https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-87-address-policy-working-group-minutes

Regards,
Erik Bais
On behalf of the AP-WG Chairs.


-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down

[Erik Bais]

Dear WG,  

We have informed you in September about the fact that James Kennedy is moving 
into a new role at the RIPE NCC

We have found a willing participant from the community to help us fill the gap 
and join the AP-WG Chair collective. 

We like to introduce Alex le Heux as a new Co-Chair introduce for the following 
period, so he can see what is involved in the role as a Co-chair.  
This would mean that he will be joining Leo and myself on the AP-WG-Chair mail 
address and we can do the actual appointment / selection on the next RIPE 
meeting. 

I write to you on the ML, to ask you for your support and feedback on the 
approach. 
Also if you are considering joining, do have a chat with either Leo or myself 
during the meeting.  

Kind regards, 
Erik Bais 
On behalf of the AP-WG-Chairs


On 18/09/2023, 15:25, "address-policy-wg on behalf of Leo Vegoda" 
mailto:address-policy-wg-boun...@ripe.net> 
on behalf of l...@vegoda.org <mailto:l...@vegoda.org>> wrote:


Dear WG,


You will have seen the recent announcement that James Kennedy has
joined the RIPE NCC as Chief Registry Officer. He's stepping down from
his community leadership roles, including as co-chair of the Address
Policy WG.


Because we still have two co-chairs there is no immediate need to
recruit a replacement. Instead, we'd like to encourage anyone
considering joining the team to contact us to discuss what is
involved.


You can write to us and we can schedule a call. You can also approach
us at RIPE 87 in Rome.


Kind regards,


Leo & Erik
Address Policy WG Co-Chairs


-- 


To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg 
<https://lists.ripe.net/mailman/listinfo/address-policy-wg>



-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] 2023-02 Last Call for Comments (Minimum Size for IPv4 Temporary Assignments)

[Erik Bais]

Dear AP-WG members,

Please be aware that the Last Call for Comments of the min. size for IPv4 temp 
assignments is about to end ..  ( June 13 2023 – aka tomorrow )

As chairs we would like to receive a bit more comments / support during last 
call, as it has been silent ..

To reach consensus, we are not only looking for objections .. but also for 
support of the community and this is a request to speak up.
So even if you voiced support in previous phases, let us know again in the Last 
Call phase as well.

Have a nice day,
Erik Bais
On behalf of the AP-WG Chairs, co-Chair

From: address-policy-wg  on behalf of Karen 
Hung 
Date: Wednesday, 14 June 2023 at 10:07
To: "address-policy-wg@ripe.net" 
Subject: [address-policy-wg] 2023-02 Last Call for Comments (Minimum Size for 
IPv4 Temporary Assignments)

Dear colleagues,

Proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in 
Concluding Phase.

This policy proposal recommends setting the minimum assignment size to a /24 
while still allowing for a smaller assignment if requested by the End User. 
This policy proposal also allows routing requirements to justify the request 
for more than a /24 for research purposes.

The WG co-chairs have declared that rough consensus has been reached and the 
proposal will now move to Last Call.

As per the RIPE Policy Development Process (PDP), the purpose of this four week 
Concluding Phase is to give an opportunity to present well-justified objections 
for those who missed the previous two phases and wish to oppose the proposal.
Any objection must be made by 13 July 2023 and must be supported by an 
explanation.
If no substantive objections are raised by the end of Last Call, the proposal 
will complete the PDP and will be evaluated by the WG co-chairs for final 
consensus.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2023-02

Please e-mail any final comments about this proposal to 
mailto:address-policy-wg@ripe.net>> before 13 July 
2023.


Kind regards,
Karen Hung
On behalf of Policy Officer
RIPE NCC

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] Chair re-appointment - RIPE86

[Erik Bais]

Dear Working group,  

As you might remember, the WG Chairs are appointed for a set term as that 
reminds us now and then, for both the WG Chair as the WG, to think about if we 
are still happy with the current chair setup.

More insight on the terms can be found at the AP-WG page on the RIPE website: 
https://www.ripe.net/participate/ripe/wg/active-wg/ap  

This RIPE86, the first term of both James Kennedy and Leo Vegoda is done and 
both stated that they would be more than happy to do another term.  

As the co-Chair of AP-WG, I'm glad that both want to run again for the 
stability of the WG, however in the end it is up to the WG if you are as well.  

So during the AP-WG session, we will have time in the agenda to ask the WG if 
you like to proceed with the current WG Chair setup.  

If you to replace one or both WG Chairs, please let me know up front and I will 
contact you to ask a couple questions in regards of introduction .. and we will 
ask the WG if they would like a WG chair change.  

We like to hear in the WG if you like to support the current WG chairs (or not) 
... this can be done by a reply on this email, or during the meeting.  

See you all next week in Rotterdam.  

Regards,
Erik Bais
Co-Chair AP-WG  

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] IPv6 policy - 2nd prioritisation and outcomes discussion webinar

[Erik Bais]

This is a small reminder that we are looking forward to you see online and your 
input on the review for the IPv6 policy this afternoon.  

Regards,
Erik Bais
On behalf of the AP-WG Chair collective. 



On 21/03/2023, 22:48, "address-policy-wg on behalf of Leo Vegoda" 
mailto:address-policy-wg-boun...@ripe.net> 
on behalf of l...@vegoda.org <mailto:l...@vegoda.org>> wrote:


At RIPE 85 we continued a review of the IPv6 policy that began at RIPE
83. Several areas for improvement were agreed. We promised to host an
inter-sessional webinar to discuss priorities and the outcomes to work
towards.


We held the first webinar on Monday, 20 February 2023. You can read a
summary of what was discussed on RIPE Labs. A full recording and
minutes are published on the interim sessions page.


- https://labs.ripe.net/author/leo_vegoda/next-steps-in-ipv6-policy-work/ 
<https://labs.ripe.net/author/leo_vegoda/next-steps-in-ipv6-policy-work/>
- https://www.ripe.net/participate/ripe/wg/active-wg/ap/interim-sessions 
<https://www.ripe.net/participate/ripe/wg/active-wg/ap/interim-sessions>


The second webinar will take place on Tuesday, 11 April at 13:30 UTC
(15:30 CEST). If you want to help us set priorities and define the
outcomes the community needs you are welcome to join.


Join Zoom Meeting
https://ripe.zoom.us/j/93730573273?pwd=eWJ1WEEzSzVSSEJNKy9JeXk0L3RqZz09 
<https://ripe.zoom.us/j/93730573273?pwd=eWJ1WEEzSzVSSEJNKy9JeXk0L3RqZz09>


Leo Vegoda
for the Address Policy WG co-chairs


-- 


To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg 
<https://lists.ripe.net/mailman/listinfo/address-policy-wg>



-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] Minimum size for IPv4 temporary assignments

[Erik Bais]

Hi Edwin,

Thank you on stepping forward on this. And I think that it would make sense to 
have a discussion on this with a policy proposal on the table.

As you mentioned, this has been brought up multiple times already, so it would 
be good to see if we can get this sorted.

It would be nice if the AP-WG members could provide some insight if the would 
support (or not) a policy proposal as suggested.

Regards,
Speaking as one of the Co-Chairs,
Erik Bais

From: address-policy-wg  on behalf of Edwin 
Verheul 
Date: Thursday, 17 November 2022 at 16:24
To: "address-policy-wg@ripe.net" 
Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments

Dear colleagues of the Address Policy Working Group,

During (my first!) RIPE85 there was short discussion about the minimal size for 
IPv4 temporary assignments in this workgroup.
The policy for temporary IPv4 assignments requires you to use 50% of the 
assigned addresses [1].
This requirement pushes events or experiments into smaller assignments less 
than /24’s, which are mostly unroutable on the internet.

This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush 
[3] in Januari 2022.
It looks to me this is a legitimate reason to propose this in a policy change:


  *   Temporary IPv4 assignments ≤ /24 should NOT subject to the 50% usage 
requirement;
  *   Only smaller assignments will be handed out if the assignee is explicitly 
willing to have (sub optimal) unroutable IP space on the internet;
  *   If it is required by the assignee to advertise multiple subnets, the 
policy should allow to assign multiple /24’s( or a bigger assignment, so the 
assignee can split and advertise by themselves).

Elvis Velea and myself are willing to (co) author this proposal. We will do our 
best to hand in the proposal by the end of this year.

Any thoughts on this?

Kind regards,

Edwin Verheul
SURF
AS1103

[1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates
[2] 
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/013598.html
[3] 
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/013438.html
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies

[Erik Bais]

Hi Randy, 

I think that the time for the temp assignment to be made, stretched to 1 year 
or more, will become an issue for the NCC to work with. 
It is my personal view / feeling, that not many requests are done to the NCC 
for longer periods than specified in the policy.. And this looks like fixing 
policy for a corner case.

Not only of the point that Gert made, but also because it will make the life of 
the IPRA's must harder with the time that we add..
As we can also expect more requests to be made, if the policy would be changed 
... 

As this is for research .. have you considered working with other research 
networks that hold large amount of numbers because they were NIR's before RIPE 
was setup ? 
Like Surf in The Netherlands for instance .. or Janet in the UK.. or alike ..

If they are presented with a proper documented research request .. they will 
consider those requests and they are not bound by policy restrictions that we 
are discussing here. 

It could fix your specific case .. and that is why these orgs are actually 
doing what they are doing ..  

Regards,
Erik Bais 


On 25/01/2022, 18:34, "address-policy-wg on behalf of Randy Bush" 
 wrote:

ok, i did it again, tried to fit a square peg in a round hole.  while
the immediate problem is past, thanks to the ncc reg folk, i fear that
we could benefit from thinking a bit more about $subject.

for a research experiment, we wanted eight or a dozen routable, i.e.
/24, prefixes which we would announce from various places in the
topology.  each /24 would have one pingable address, let's assume .42.

because this is ops based research, we have to
  o go through the ncc bureaucrazy
  o actually deploy and test
  o run the measurements for a few months
  o do the analysis
  o possibly tune or vary the experiment
  o write the paper and submit it
  o wait three months for the accept/reject
  o if rejected, retune and submit to a different venue
  o the reviewers may ask for us to re-run to get fresh data for
publication
  o whine whine
this takes six to twelve months.

if you are familiar with $subject, you will sense there are two problems
here.  587 is designed for a much shorter time window, and it kind of
assumes more that 1:256 utilisation.

you can imagine that my request to registration services generated a bit
of discussion :).  as our social environment has become less tolerant,
reg services understandably wants simple rules they can follow and which
clearly justify their actions.  and geeks such as i just want our mtv
:).

i suspect we may be able to wordsmith conditions to deal with the time
length issue.  but i suspect that codification of guidelines covering
the needs & justifications for research experiments, folk qualifying
strange devices, and those doing other weird things will not be so easy.

i am considering a policy proposal in this space; but want to learn what
others see and think, and to see if it is worth the time and effort.

and can we please keep discussion focused on temporary address space
assignments?

thanks.

randy


-- 

To unsubscribe from this mailing list, get a password reminder, or change 
your subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg


-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Re: [address-policy-wg] ripe-682 Transfer Policy Problems

[Erik Bais]

 their Legacy space (not owned by the NCC) 
to be changed to RIPE PA space .. 
Which basically removes the legacy holder rights of the new holder. And 
importing their legacy into a RIPE LIR .. and if they would stop paying to the 
RIPE NCC, they would have the risk of losing their IP space (as it is RIPE PA 
space now, liked to the membership status ) .. instead of having IP space in 
their organisations name, regardless if they are a RIPE NCC member or not.. 
Also this isn't described in the Legacy services policy ( 
https://www.ripe.net/publications/docs/ripe-639 ) .. and I have no idea why 
this is being asked on each Legacy transfer to the receiving party ... 

And I haven't even touched upon inter-rir transfers .. or Legacy transfers 
itself  .. 

And with this long read .. I come to a close of the statement by itself .. 
I don't think that the transfer policy by itself is incorrect .. ( but I could 
be biased ..) ... 
That the RIPE NCC operates the transfers slightly to its own interpretation I 
can understand .. and even with the above mentioned topics, I think they do 
this very good... 
There is always room for improvement .. and we pick our battles.  

I'll be more than happy to provide you some insight on transfers from various 
type of resources and how the LIR portal options work with it. If you don't 
have access to an LIR, to see how that looks these days.  
This can be via Zoom / Teams, or if you fancy to come over to our office near 
Amsterdam for a cup of coffee.  

Regards,
Erik Bais 

 

On 22/12/2021, 16:01, "address-policy-wg on behalf of denis walker" 
 wrote:

Colleagues

The Transfer Policy ripe-682 is so vague you can drive a train through
the holes in it. I have some questions that I hope someone can answer
before Christmas as I would like to propose an amendment to this
policy in the new year.

"Any legitimate resource holder is allowed to transfer"
What does 'legitimate' mean in this context? It is not defined in this
policy document. It is no use referring to a dictionary or even some
other policy document. It needs to be defined in this policy. If it
has no specific meaning in the context of this policy, then the word
should be removed.

My understanding of a 'policy document' is that it is self contained
and consistent. None of the terms:
-RIPE NCC Member
-LIR
-Resource holder
are defined anywhere in the Transfer Policy or ripe-733, IPv4
Allocation... A policy may be dependent on another policy being in
place. You cannot transfer a resource unless it has been allocated.
You cannot allocate a resource unless there is a RIPE NCC Member and
an LIR. But you should not have to backtrack through a whole sequence
of documents to find out what a term in this policy means. This policy
can only work if people understand 'commonly accepted' definitions of
these terms. But that is open to interpretation and mis-understanding.
That could make legal enforcement of, for example, restrictions more
difficult to apply.

[As a side issue I have just quickly read through a whole series of
documents and forms on becoming a RIPE NCC Member and getting
resources. In every document/form I found:
-Legal errors
-English grammar errors
-Procedural errors
-Webpage errors
The whole process is a complete mess and needs a serious Legal/Comms 
review.]

I found the definition of a Member in one document but nowhere have I
found any definition of LIR. These terms are so fundamental to all
these policies, to not define them leaves a massive hole in their
meaning and authority. These terms seem to be so interchangeable from
one paragraph to the next. In some places the wrong term is used.

ripe-733 says allocations are made to LIRs
ripe-682 says allocations are transferred to members
ripe-682 says transfer restrictions apply to resource holders

Then we have this document

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers
which talks about 'hodership', another term not defined.

Then we have this document

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region
that conflicts with the Transfer Policy.
It also refers to Members as organisations, again without any actual 
definition.

The above document says:
"Exception: For transfers between multiple LIR accounts belonging to
the same organisation, also referred to as consolidations, the 24
months restriction will only apply once after the resources were
received from the RIPE NCC or from another organisation."

This is NOT what the Transfer Policy says. The policy makes no mention
anywhere of consolidatio

Re: [address-policy-wg] IPv4 waiting list policy

[Erik Bais]

Hi Marco,  

Thank you for the detailed information of the dispersion about the current and 
past of the waitinglist.  

To the WG:  

The current workings of the IPv4 Waitinglist is specified in the IPv4 Address 
Allocation and Assignment Policies for the RIPE NCC Service Region

https://www.ripe.net/publications/docs/ripe-733#5 

Currently there is a First Come First Serve procedure for the waitinglist .. 
and there are no limitation to allocating v4 space to members that have been 
already allocated v4 space since the waitinglist started. 

I think that I speak for the WG, that the intent for the final /8 policy and 
the waitinglist policy, is to provide IPv4 (at least a small bit) to newcomers 
.. meaning that how it currently works and how it was intended .. that this 
might not align with what the WG initially wanted.  

If a change would be desired by the WG, it should go through the PDP, meaning 
that a policy change would be required.  

As WG chairs we would like to see the position of the WG on the topic and what 
could be seen as a possible solution.  

Regards,
Erik Bais
On behalf of the AP-WG Co-Chair collective.  



On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

In the Address Policy Working Group sessions at RIPE 83, I shared our 
observations regarding the IPv4 waiting list policy. [1]

The intent of this policy was to provide newcomers with a minimal amount 
of IPv4 space for as long as possible. However, about half of these 
allocations went to members that received several /24 allocations via 
multiple LIR accounts.

As there was interest in reviewing the policy at the RIPE Meeting, I 
would like to provide more detail on the provision of IPv4 allocations 
over the last two years and the current situation with the waiting list.

In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
-2,019 allocations (48%) went to members with a single LIR account
-452 allocations (11%) went to members with 2-4 LIR accounts
-298 allocations (7%) went to members with 5-9 LIR accounts and
-1,409 allocations (34%) went to members with 10 or more LIR 
accounts (up to 33 /24 allocations to a single member)

This trend towards allocations to multiple LIR accounts has accelerated 
in the past six months. Between June and November 2021, only 24% of 
allocations went to members with a single LIR account, while 54% went to 
members with 10 or more accounts.

We see the same trend with the current waiting list. At the time of 
writing, we can see 327 requests for a /24 allocation:
-83 (25%) are from members with a single LIR account
-42 (13%) are from members with 2-4 LIRs accounts
-45 (14%) are from members with 5-9 LIR accounts
-157 (48%) are from members with 10 or more LIR accounts

Consequently, there is a significantly longer wait time for members with 
a single LIR account.

Looking at the current market prices for IPv4 in comparison to our 
membership fees, even a wait time of several months is acceptable for 
organisations that plan to transfer their allocation after the end of 
the holding period. Conversely, the long wait time will create 
uncertainty for real newcomers, especially if they can’t rely on 
IPv6-only networks.

I hope the WG finds this information useful for further discussion. If 
there is consensus to change the current situation, there are several 
approaches available – including a review of the waiting list policy and 
changing ‘per LIR’ to something else. Other approaches, such as a 
different charging scheme or changing the concept of multiple LIRs would 
need to be approved by the RIPE NCC membership.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

[1] https://ripe83.ripe.net/archives/video/642/


-- 

To unsubscribe from this mailing list, get a password reminder, or change 
your subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg


-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

[address-policy-wg] Draft agenda AP-WG RIPE82 - virtual AP-WG

[Erik Bais]

Dear working group,

In the approaching time to the RIPE82 meeting there will be a couple things 
that are going to change.

First as you may be aware, the AP-WG session is going to be on the TUESDAY 
instead of the Wednesday.
This is due to the preference of people to not have WG sessions in parallel. So 
the AP-WG session is moved to the Tuesday May 18th 10:30 am Amsterdam time 
(CEST - UTC+2)

Second this is going to be last WG session with our faithful Gert as co-Chair 
of the WG, as he is going to step down.
And because he started RIPE 44 in Amsterdam, 2003 as chair for the LIR-WG (now 
AP-WG), he is probably one of the longest serving Chairs in our community.

So, on the agenda, we have the following planned.  We will be publishing a 
couple presentations in pre-recording, so that we can have more time for 
discussions.
The publication of those pre-recordings is planned for the weekend before the 
WG session.

The session is in the meeting schedule for 90 minutes .. but we plan to do a 
short break in approx. the middle.. to allow for some fresh coffee / short 
toilet break.

So we have a pretty full agenda .. and we expect the session to allow for more 
time for discussion on various topics with this format, along with the 
information of the NCC about various topics.



--- Draft agenda AP-WG session - RIPE82

A. Administrative Matters - Gert Döring
Welcome, thanking the scribe, approving the minutes, etc.

B. WG Chair selection / appointment - Erik Bais

C. Current Policy Topics (Q based on pre-published slides/recording)
Angela Dall'Ara, PDO, RIPE NCC
- Global policy overview "What's going on?"
- Common policy topics in all regions (end of IPv4, transfers, ...)
- Brief overview of new proposals (if any)

D. Feedback from the RIPE NCC Registry Services (Q based on pre-published 
slides/recording)
Marco Schmidt, Registration Services

[5 minutes break to top-up the hot drink of your choice]

E. Introduction of candidates for the NRO NC
Ulka Athale

F. (Tentative) Agenda item arising from the DBTF
James Kennedy or another DBTF member

G. What colour is my IP(v4) space? PI addresses and LIRs
Remco van Mook

h. Systematic Review of RIPE Address Policy (Discussion)
- Proposal to review whether environmental changes since a policy were
agreed should be addressed with a policy update

Z. AOB

Hope to see you all on RIPE82.

Regards,
Gert Döring & Erik Bais,
AP-WG chairs

Re: [address-policy-wg] Request about homologation of policy documents

[Erik Bais]

Hi Kurt, 

The AP-WG Chairs are planning ( as it is quiet in the AP-WG these days anyway 
.. ) to use the time to see if we need to review all current allocation / 
assignment policies for v4, v6 and ASn's.  

This will be part of the discussions starting during the RIPE82 meeting. 

We will have a presentation on the topic about various types of IP space.. ( 
administrative types.. ) as they are technically all the same..  

It could be that the policies will be impacted after having that discussion .. 
or that the WG decides that we should review things how we look at certain 
policies. 

So yes,  let's take this into the discussion, and pick this up on the RIPE82 
AP-WG meeting after that discussion about the above topic. 

Regards,
Erik Bais 

PS. I'm glad that the RIPE-733-61 document does have the requirement in there 
to return the space ... 



On 06/04/2021, 17:19, "address-policy-wg on behalf of Kurt Kayser" 
 wrote:

Dear RIPE friends,

I have scanned the current address policy documents and I have some
questions about homologation between a couple of topics.


There are 2 main areas of concern, which I would like to discuss:

1. Validity of RIPE-451 -  (IPv6 address space policy for IXPs.) aged
well since 2009.

   Option 1: drop this document entirely - the pointer for the document
"Obtaining the address space" (RIPE-575) is anyway outdated/obsoleted.

   Option 2: Integrate a relevant paragraph in the RIPE-738 (IPv6
address allocation and assignment policy) successor document?

   For comparison: RIPE-733 (IPv4 address ---) this area is mentioned in
Section 6.1 - mainly due to minimal resources left to use.


2. Comparing Sections 6.x from RIPE-733 (IPv4 adresses allocation and
assignment policy) with RIPE-738 (IPv6 address allocation and assignment
policy)

   There are very nice paragraphs in Section 6.2 (network
infrastructure) and 6.3 (validity of an assignment) which I miss as
counterpart in RIPE-738.


One would assume that there should somewhat similar approaches on how to
assign and document used address space.

There are also other areas that could be cleaned up (such as transfers 
- completely moved out of these documents or extended?)

Suggestion: why not keep the same section numbering for identical topics?


Best regards,

Kurt Kayser

Re: [address-policy-wg] WG chair rotation 2021

[Erik Bais]

Dear AP WG,  

Maybe not as timely as initially projected, but with no further delay ... 

We have 2 prospects for the Co-Chair position for the AP-WG, as Gert is leaving 
us as co-chair after 18 years of being one of the Chairs of the AP-WG ( since 
RIPE 44 in Amsterdam, 2003 ). 
Or the LIR WG as it was called back in those days..  ( 
https://www.ripe.net/participate/meetings/ripe-meetings/ripe-44/meeting-report 
) 

Both Leo Vegoda and James Kennedy re-stated that they want to serve the WG as a 
co-Chair.  

Their motivation you can read below: 

James Kennedy: 
Clogg size M, preferably wooden.

Relevant background
- BSc degree in IT and Telecommunications from University of Limerick, 2005
- Various roles in technology in Luxembourg and Amsterdam before working for 
the Registration Services department of the RIPE NCC for 3.5 years
- Now the IP Address Manager for tier 1 Internet access provider for over 8 
years
- Regular RIPE Meeting attendee and active RIPE community member
- Author of address policy 2015-02: 
https://www.ripe.net/participate/policies/proposals/2015-02
- Member of the RIPE Database Requirements Task Force: 
https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf

Likes
- Well maintained, accurate, reliable data
- Smart process simplification
- Bottom-up, consensus-driven, open policy development

Goals as AP-WG co-chair
- Facilitate and encourage open, constructive discourse on address policy 
related topics
- Provide neutral guidance to community members interested in proposing address 
policy
- Support productive communication between the RIPE NCC and the RIPE community 
regarding address policy issues in a post-IPv4 runout world

Leo Vegoda: 

I had operational roles at two ISPs before joining the RIPE NCC's
registration services team in 2000. I led the team for several years
before joining ICANN to manage Internet Number Resources in its IANA
team at the end of 2006. I then moved into ICANN's Office of the COO
to focus on continuous improvement and organisational planning. I
started a small business in 2020, and focus on helping organisations
operating in the Internet infrastructure and community space. Clients
include Euro-IX, PeeringDB, and UKNOF. I am also currently chairing
RIPE's Code of Conduct TF.

The first meeting I attended was RIPE 35, in 2000. I have previously
submitted one policy proposal
(https://www.ripe.net/participate/policies/proposals/2006-07) and have
implemented several more, both at the RIPE NCC and ICANN.

And Leo's response in reply to the info above, as to what his shoe size is ...  
> My shoes say 255, but that is a Chinese scale. Also, I think my feet have 
> spread after a year of almost not wearing shoes.
 
Me and Gert had the pleasure on working with Leo and James in the last 6 months 
on topics in relation on the AP-WG related stuff. 
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. 

I think they have a solid understanding of the policy making and background 
which is relevant for the AP-WG and a good addition to the position. 

During RIPE82 we will have the time in the agenda for the rotation process.  
If you like to support or have specific questions / concerns, please let us 
know via the mailing list or to myself directly. 

We will send out the AP-WG RIPE82 agenda shortly. 

Regards,
Erik Bais
On behalf of the AP-WG chair team. 

Re: [address-policy-wg] FW: Policy Reciprocity

[Erik Bais]

> Right, however, a policy (proposal), could be in the direction of what 
> services are only for members with a contract.

That is already what is in the current policy for legacy holders ..  

https://www.ripe.net/publications/docs/ripe-639 <=- RIPE NCC Services to Legacy 
Internet Resource Holders
https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders
  <=- shiny colours in a nice matrix showing exactly what the options are.  

And here an example of a policy with a specific Legacy holder part in it,  the 
policy:  Resource Certification for non-members :  
https://www.ripe.net/participate/policies/proposals/2013-04 
2013-04 provided a way to include legacy holders into the RPKI system, by 
requirement that there is a contractual agreement in place with the RIPE NCC. 

Regards,
Erik Bais 


On 21/10/2020, 13:41, "address-policy-wg on behalf of JORDI PALET MARTINEZ via 
address-policy-wg"  wrote:

Right, however, a policy (proposal), could be in the direction of what 
services are only for members with a contract.

Regards,
Jordi
@jordipalet
 
 

El 21/10/20 13:07, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,
On Wed, Oct 21, 2020 at 11:07:04AM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> I agree with Shane here.
> 
> We shall correct mistakes ASAP. Legacy was a mistake, just because we 
didn't have the RIR system before, nothing else. It was not a conscious 
decision, nobody understood at that time that Internet as a "global" thing will 
need those resources and will become scarce.

There is no contractual basis on which to "fix" anything here.

Legacy holders that are willing to change their resources into regular
RIPE space can do this today.

For those that do not want to do so, let me repeat: there is no 
contractual 
basis to make them do something they do not want.

Gert Doering
-- APWG chair
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, 
Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. 
Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: [address-policy-wg] FW: Policy Reciprocity

[Erik Bais]

Thanks Jim, 

I couldn't have said it better myself. 

Also, with the Legacy transfers, there needs to be proper documentation to make 
sure all records from the past match up AND there is going to be an update in 
the RIR registry that will make sure the records are up to date. 
Updating the registry with accurate information while we do changes in the 
database on the actual owner and user of the Legacy space is a huge plus for 
the accuracy. 

Erik 

On 20/10/2020, 23:47, "address-policy-wg on behalf of Jim Reid" 
 wrote:



> On 20 Oct 2020, at 19:30, ripedenis--- via address-policy-wg 
 wrote:
> 
> Legacy space is a pain and should be normalised at every opportunity. 
Because of the market this has become a huge financial asset. If the holders 
want to cash it in, once it is sold it should lose this special, untouchable 
status.

Why? What’s the rationale for that? What good will it achieve? What problem 
does that fix?

If your concern is it’s too much of a resource drain on an RIR to track 
these transfers, then let’s first quantify the problem before deciding how to 
solve it. My gut feel is those overheads are marginal and also a tolerable part 
of doing business. It may well be less hassle to just let those costs be lost 
in the noise than trying to invent some sort of cost recovery scheme. Which 
would of course provide lots of opportunities for shed-painting and rat-holing.

> The transfer policies are their means to sell it. These policies should 
insist on sold legacy space being normalised and subject to all RIR policies.

Denis, I *strongly* disagree. Legacy space is like an RS-232 lead*: an 
annoyance from a bygone era that will always be with us. :-) We just have to 
suck it up. Unless of course one day the Internet stops using IPv4 and 
everyone’s on IPv6. [Who’s sniggering at the back!?!]

* Kids, ask your grandparents... 

What’s the justification for "normalised at every opportunity” and what do 
you mean by that anyway?

Forcing transferred legacy space to be subject to RIR policies is utterly 
wrong.

First, the space was issued before the RIR system existed. It shouldn’t be 
subject to what amounts to retrospective legislation. That probably wouldn’t 
survive the flimsiest of challenges in the courts. Besides, we agreed that 
principle during the ERX exercise some years ago when European legacy space 
moved from ARIN to the NCC. Those legacy holders were not made to pay NCC fees 
or had their holdings of legacy space influence how their future IPv4 
allocation/assignment requests got handled. Why go back on this principle now? 
What’s changed since then to justify that?

Next, if transfers involving legacy space were forced to be subject to RIR 
policies, you’d just drive those transfers underground. Or the parties involved 
would contrive “mergers” and “reorganisations” to conceal the truth that 
addresses changed hands. That would be bad in far too many ways to list here. 
What’s more important, maintaining an accurate database of address space 
holders or upholding the purity of some doctrine about nearly dead IPv4 address 
policies that are irrelevant to a post-v4 world?

FWIW we abandoned that notion of ideological purity when the LIR transfer 
policies were introduced. The consensus then (and now) was maintaining accurate 
info about who held address resources was more important than following a no 
longer credible policy of forcing LIRs to return their surplus space to the NCC 
for redistribution.

Finally, suppose the recipient of a legacy transfer is not an LIR. Your 
suggestion implies they’d have to become one. That’ll attract the attention of 
legislators, regulators and the competition authorities faster than you can say 
anti-trust lawsuit.

[address-policy-wg] FW: Policy Reciprocity

[Erik Bais]

Hi Petrit & Taiwo,

Petrit,

could you have a look at the following question from Taiwo in regards to the 
Afrinic policy proposal reciprocity with the current RIPE Transfer Policy.

To Taiwo,


Personally I would argue if reciprocity should be desired for the Afrinic 
region, as long as AFRINIC still holds IP numbers to be handed out.
I personally would prefer the AFRINIC inter-rir transfer policy to be incoming 
from other RIR’s only, to avoid the AFRINIC space to be removed from the 
region.  ( As I think Afrinic would need them more to develop its own inter 
regional growth. )
Am I correct to assume that Afrinic at the current distribution rate would have 
about 30 months of IP space left ?  So perhaps opening the bi-directional 
inter-rir transfers, could start once the AFRINIC region actually has no space 
left in its free pool.


In the RIPE region, there is a 24 month transfer limitation on the resource 
that was transferred itself, there is no further limitation on either the 
leaving (source) or receiving (target) entity to engage in other transactions.

On the point :

  *   5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy 
holders in any region

The AFRINIC legal team might have to look if this is phrased correctly, as you 
can’t (shouldn’t be able ) to move Afrinic Allocated space to a Legacy space 
holder.. Afrinic allocated space should only be able to move to any of the 
other RIR members. Not directly to a Legacy holder.
Legacy space registered in the Afrinic region could go to any organisation, 
regardless if they are a RIR member. There might be other contractual 
requirements required in the receiving RIR.. as the RIPE legacy policy would 
explain for the RIPE region.

I can see the intention, but that is not what the policy states. (or how I read 
it..)

And on point :

  *   5.7.4.3 Incoming transferred legacy resources will still be regarded as 
legacy resources.]

If you would remove the word incoming, it would provide a more bi-directional 
way of looking at it, from an AFRINIC perspective. And still leave it to the 
receiving RIR to apply their own Legacy ‘policy’

Regards,
Erik Bais

Co-chair of AP-WG

https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer 
policy ( including intra and inter-rir transfers )
https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services 
to Legacy Internet Resource Holders  ( aka the RIPE Legacy services policy )
https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders
  ( Services provided based on the type of contractual agreement with the RIPE 
NCC )


From: address-policy-wg  on behalf of Taiwo 
Oyewande 
Date: Friday 16 October 2020 at 13:35
To: "address-policy-wg@ripe.net" 
Cc: Anthony Ubah 
Subject: [address-policy-wg] Policy Reciprocity

Hello,

I am a co-author of the Resource Transfer Policy, which is the inter-RIR 
transfer proposal that has just reached consensus within Afrinic, and we are 
reaching out to you so as to inquire about its reciprocity with RIPE.

Your assessment and analysis about this matter would highly be appreciated.

Please find below the proposal for your reference.

[

Resource Transfer Policy
Authors: Anthony Ubah & Taiwo Oyewande
Submission date: 21/09/2020
Version: 2.0
Amends: CPM 5.7

1. Summary of the problem being addressed by this proposal
The current policy fails to support a two-way Inter-RIR policy, thereby 
hindering smooth business operation, development, and growth in the region. 
This proposal aims to establish an efficient and business-friendly mechanism to 
allow number resources to be transferred from/to other regions. This proposal 
outlines a model in which AFRINIC can freely transfer number resources to/from 
other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 
addresses and AS numbers.

2. Summary of how this proposal addresses the problem
With the exhaustion of IPv4, several regions have adopted a transfer policy to 
accommodate the shortage of resources. Number resources are allowed to transfer 
within the region itself, as well as with other regions.
Such practice is effective and necessary when we are facing a shortage of 
resources. This helps facilitate business operations while reducing prices.
Such Inter-RIR transfer, however, is not yet established in AFRINIC. This 
hinders business operation and development within the African region. The 
current proposal aims to establish an efficient and business-friendly mechanism 
to allow number resources to be transferred from/to other regions. Before 
moving to illustrate how this new mechanism works, let’s take a quick look at 
the situation of the current Consolidated Policy Manual:
In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources 
transfer within the AFRINIC region” is mentioned.
Regarding resource transfer to other regions, only the following is mentioned:
5

[address-policy-wg] Draft Agenda RIPE81 - virtual AP-WG

[Erik Bais]

Dear working group, dear RIPE meeting folks,
 
Below you can find a draft for the RIPE address policy WG meeting's agenda,
which will take place in online on the following time slot:
 
Wednesday, Oct 28, 10:00 - 10:45
 
As we only have 1 time slot, we have a packed agenda.
We don’t have any open policy discussions atm, however if you have any
Address Policy related policy suggestions, feel free to reach out to us.
 
Besides the usual PDO/RIR & Registration services updates, we will also have a
presentation from the RIPE NCC legal team about the topic: Seizure of the 
“Right to Registration of IPv4 Addresses” for the Recovery of Money.
As WG Chairs we thought it would be a good topic to discuss in the AP-WG.
 
So make sure you are present for the session.
 
Regards,
 
Gert Döring & Erik Bais,
APWG chairs
 
 
--
Wednesday, 10:00-10:45
--
 
A. Administrative Matters  
   (welcome, thanking the scribe, approving the minutes, etc.)
 
B. Current Policy Topics – Petrit Hasani – RIPE NCC PDO
 
   - global policy overview
 "what's going on?"
 
   - common policy topics in all regions
 (end of IPv4, transfers, ...)  

   - overview over concluded proposals in the RIPE region
 since RIPE 80
 
   - brief overview of new proposals
 (if any)
 
C. Feedback from NCC Registration Service - Nikolas Pediaditis
(+ discussion with the group)
 
D.   Presentation about the Seizure of the “Right to Registration of IPv4 
Addresses” - Ciaran Byrne
( Legal Counsel of the RIPE NCC )
 
Z. AOB 

Re: [address-policy-wg] IPv4 status hierarchies

[Erik Bais]

Dear WG,  

I want to bring the following email and questions of our PDO - Petrit Hasani to 
your attention that might have slipped over the vacation period.  

Please have a look at this discussion again and provide input if you can.  

Regards,
Erik Bais
Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) 

On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" 
 wrote:

Dear colleagues,

Thank you to everyone who responded to our earlier questions on the intent 
of the policy regarding IPv4 status hierarchies.

While this was helpful, it would be great if we could have input from a 
wider group of people:

- Should inetnums with these statuses be allowed to be created inside one 
another?
- Should there be a limit on the minimum size of a sub-allocation?
- Do we need a policy update?


https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html

We look forward to hearing from you.

Cheers,
--
Petrit Hasani
Policy Officer
RIPE NCC





> On 16 Jun 2020, at 15:36, Petrit Hasani  wrote:
> 
> Dear colleagues,
> 
> We are reviewing IPv4 status hierarchies in the RIPE Database (looking at 
objects with the same status as their less-specifics).
> 
> Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED 
PA", for example. Other statuses might need a closer look and we would like 
guidance from this working group.
> 
> The RIPE Database does not currently have any limitations on creating 
inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under 
inetnums with the same status. This often results in chains of inetnums that 
have the same status, sometimes ending with the sub-allocation of a single IP 
address.
> 
> Although this might not seem useful at first glance, there might be 
practical uses for a few levels of sub-allocation. For example, a global 
company could give sub-allocations to its national branches, which make smaller 
sub-allocations to their multiple daughter companies. These daughter companies 
could then create and maintain assignments for their actual networks.
> 
> However, this is not allowed under a strict reading of the policy, as 
only the LIR itself can make sub-allocations, and these must be used for 
assignments.
> 
> Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and 
Assignment Policies (ripe-733) states:
> 
> "Sub-allocations are intended to aid the goal of routing aggregation and 
can only be made from allocations with a status of "ALLOCATED PA".
> 
> [...]
> 
> LIRs may make sub-allocations to multiple downstream network operators."
> 
> https://www.ripe.net/publications/docs/ripe-733#54
> 
> Before making any changes, we want to be sure that we understand the 
intent of the policy and what the community wants us to do. Thus, we would like 
to hear from the Address Policy Working Group:
> 
> - Should inetnums with these statuses be allowed to be created inside one 
another?
> - Should there be a limit on the minimum size of a sub-allocation?
> - Do we need a policy update?
> 
> We look forward to your guidance.
> 
> Kind regards,
> --
> Petrit Hasani
> Policy Officer
> RIPE NCC
> 
> 
> 
> 
> 

Re: [address-policy-wg] My response to Ronald Guilmette

[Erik Bais]

Elad,

You have been moderated in other RIPE ML’s already.

See this as a final warning, if you can’t stop off-topic posts on this ML or 
keep posting with personal attacks, I’ll ask the NCC to filter all emails to 
this list from you as well.

And to the other AP-WG ML subscribers, please stop sending replies to this.

Regards,
Erik Bais
Co-Chair AP-WG




Op 3 mei 2020 om 00:09 heeft Elad Cohen  het volgende 
geschreven:


Cynthia,

The coconut was called an antisemitic person and a racist person not by me, but 
by many other people in Nanog.

I didn't call him a coconut because he criticized me, he never criticized me, 
he defamed me for many months without a single proof and he called me in 
antisemitic names.

That coconut person, the same as you are, are both connected to the illegal 
anonymous organization "The Spamhaus Project".

My response was to Gert regarding his post about me, why do you keep spamming 
the list ? go play with your cat.


I would like to repeat the last part in my response:

-

And last but not least, because you are obviously interested that our Chairman 
will be re-elected and that is the only reason that you want to show to the 
readers why they shouldn't elect me, it is important to me to write the 
following lines to the readers:

On 14th of April our Chairman supported the nomination of Maria Hall and 
another candidate in the following two links:
https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000690.html
https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000691.html

Then 15 minutes after it, Maria Hall supported the nomination of our Chairman 
in the following link:
https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html

But there is something strange in the description that Maria Hall wrote:

The line "Reason for nominating the candidate:" appear twice right below each 
other:


Reason for nominating the candidate:
 Reason for nominating the candidate:
Christian is very active in the RIPE community, where he has attended every 
meeting for several years and is Co-Chair of the RIPE MAT WG.
In the last four years, Christian served on the RIPE NCC Executive Board as 
Secretary and since 2018 is the Executive Board Chairman. Christian has shown 
very strong and positive leadership in his role as chair of the board and I 
know that, both in the present situation and in upcoming times, Christians 
leadership, dedication and passion will be absolutely necessary for RIPE NCC.

This is because she did copy-paste, she did copy paste for the whole paragraph 
that was sent to her (including the title) from our respected Chairman that 
wrote it on himself, and all she did was copy-paste, is this what we want ? a 
fake Chairman ? look what he wrote on himself. Look how Gert is pushing that no 
change in the Board will be made. You are being manipulated dear readers.

Please allow me repeat what our Chairman wrote on himself:

"Christian has shown very strong and positive leadership in his role as chair 
of the board and I know that, both in the present situation and in upcoming 
times, Christians leadership, dedication and passion will be absolutely 
necessary for RIPE NCC"

Is this the board that you want ? a fake board ?

Who knows what is going on with the expenses, to where they are flowing, any 
request for detailed information of RIPE expenses is being redirected to these 
people in the Board that say that NDA is signed with all the suppliers. Can we 
trust them when they are cheating the community in such a way ?

Gert, I'm asking from you not to take part in it and to cheat the community as 
well.

Now Gert will probably moderate me so I will not write any other truth which is 
against his interests.


-

Respectfully,
Elad

From: Cynthia Revström 
Sent: Sunday, May 3, 2020 1:02 AM
To: Elad Cohen 
Cc: Gert Doering ; address-policy-wg@ripe.net 

Subject: Re: [address-policy-wg] My response to Ronald Guilmette

Elad, "coconut" is not an "honorary title" for crying out loud, please just 
stop posting.

And please stop calling people antisemitic, racist, and spamhaus employees just 
for criticizing you...

- Cynthia

On Sat, May 2, 2020 at 11:57 PM Elad Cohen 
mailto:e...@netstyle.io>> wrote:
Cynthia, all I did was to respond.

A coconut is an honorary title to that person that was called, not by me, but 
by many other people which are not related to me in Nanog - a racist and an 
antisemitic, because of his many online expressions.

Respectfully,
Elad

From: Cynthia Revström mailto:m...@cynthia.re>>
Sent: Sunday, May 3, 2020 12:52 AM
To: Elad Cohen mailto:e...@netstyle.io>>
Cc: Gert Doering mailto:g...@space.net>>; 
address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net> 
mailto:address-policy-wg@ripe.net>>
Subject: Re: [address-policy-wg] My respo

[address-policy-wg] Draft agenda for the RIPE80 virtual AP-WG session.

[Erik Bais]

Hi APWG folks,

Below you can find a draft for the RIPE address policy WG meeting's agenda,
which will be virtual at RIPE80 with the following time slot:

Wednesday, May 13, 11:00 - 11:45

As there are currently no active policy proposals and the discussion should be 
done on the mailinglist anyway,
we don’t have any presentations scheduled on new policy proposals.

If you have anything else you want to see on the agenda, or if we need
to change anything, please let us know.

Regards,

Gert Döring & Erik Bais,
APWG chairs


--
Wednesday, 11:00-11:45
--

A. Administrative Matters
   (welcome, thanking the scribe, approving the minutes, etc.)

B. Re-Selection of co-chair
  -  Erik Bais completed a term.

C. Current Policy Topics - Petrit Hasani - NCC PDO

   - global policy overview
 "what's going on?"

   - common policy topics in all regions
 (end of IPv4, transfers, ...)

   - overview over concluded proposals in the RIPE region
 since RIPE 79

   - brief overview of new proposals
 (if any)

D. Feedback From NCC Registration Service - Nikolas Pediaditis

   - IPv4 runout status, initial waiting list experience

Z. AOB

[address-policy-wg] 2019-06 Extended Review Period has ended (Multiple Editorial Changes in IPv6 Policy)

[Erik Bais]

Dear Workingroup,

After the extended review we received enough support (and no objections or 
voices against the policy proposal. )

As the AP-WG chairs, we think that the policy proposal should go to Last Call.

If there is something in the policy that you don’t agree with, please let it 
know after the formal announcement for Last Call by Petrit.

And if you do agree with the policy moving forward, please let it know in the 
Last Call phase as well, as it is easier for us as Chairs to call consensus or 
not, if we have some response.

Regards,
Erik Bais
On behalf of the AP-WG Chair collective

[address-policy-wg] Co-Chair re-election - Address policy WG

[Erik Bais]

Dear WG,  

As time flies while we are having fun, it is almost the time to re-do the chair 
dance again.  
And this time it will be my seat that is up for a re-election.  

If the WG is willing to put up with me as a co-chair, that I'm more than 
willing to go for another 2 years.  

If someone would like to become co-chair of AP-WG, it is possible to send Gert 
an email and we can have an actual election ... 
If we don't have multiple candidates 1 month before the next RIPE meeting in 
Berlin, it will be a step down - step up process.  ( most likely ) ...  

It would be nice if we would get a (third?) young WG chair, someone who has 
been to a couple meetings, but doesn't fall in the category ..  old-white male 
.. that has been longer around than the initial IPv4 runout .. 
Both Gert and myself tend to fall in that category .. or are getting close to 
it .. and a young padiwan that we can help settle into the WG collective would 
be highly appreciated.  

Kind regards, 
Erik Bais
Co-chair for Address Policy WG - RIPE 

Re: [address-policy-wg] [policy-announce] 2019-05 Proposal Accepted (Revised IPv4 assignment policy for IXPs)

[Erik Bais]

Thanks for the update Marco. 

And thanks to all the WG members and the proposal authors for making this 
happen for the community. 

Regards,
Erik Bais
Co-chair AP-WG. 

On 10/10/2019, 12:01, "policy-announce on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

Consensus has been reached on 2019-05, "Revised IPv4 assignment policy 
for IXPs".

This proposal aimed to increase the reserved IPv4 pool for IXPs to a /15 
and finetune assignment criteria.

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2019-05

The new RIPE Document is called ripe-730 and is available at:
https://www.ripe.net/publications/docs/ripe-730

We have already implemented the pool management part of this proposal 
(185.0.0.0/16 and the IPv4 fragments smaller than /24 have been added to 
the reserved IPv4 pool for IXPs). We estimate that this proposal will 
take around two months to fully implement.

We will send another announcement once the implementation is complete 
and the new procedures are in place.

Thank you to everyone who provided us with your input.

Kind regards,
Marco Schmidt
Policy Officer
RIPE NCC

[address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call

[Erik Bais]

Dear WG, 

The AP WG Chairs have seen more than sufficient support to get the policy to 
the next phase.  
The policy proposal is about extending the IXP pool with an additional /16 from 
the current IP Pool at the NCC. 

The next phase is Last Call. 

The discussion about the default allocation size wasn't part of this policy 
proposal, but with the response on the subject by Remco, we do think that this 
is properly addressed. 
If it is required, he is more than willing to address that in a new proposal 
after RIPE79. 

The RIPE NCC will reserve the /16 already for the actual implementation of 
2019-05, making sure that we are not left empty handed when the last call ends. 

For now, we will wait for Marco to do the formal announcement of the start of 
Last Call and I wish you, on behalf of the AP-WG Chair collective, a nice 
weekend. 

Regards,
Erik Bais
Co-Chair AP-WG 

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Erik Bais]

Thank you for the insight Hans Petter.

Accuracy of the registry is the key goal for the community and should be the 
goal of all proposals.

We (AP-WG chairs) don’t see a clear problem description nor sufficient support 
to proceed with the discussion into a formal PDP process.

We like to thank all participants for their input and view in this discussion.

Kind regards (on behalf of the AP-WG chair collective)

Erik Bais

From: address-policy-wg  on behalf of Hans 
Petter Holen 
Reply-To: "h...@oslo.net" 
Date: Sunday 21 July 2019 at 23:20
To: JORDI PALET MARTINEZ 
Cc: "address-policy-wg@ripe.net" 
Subject: Re: [address-policy-wg] question about IPv4 legacy and transfers - 
should we convert legacy to non-legacy with transfers?

On Sun, 14 Jul 2019 at 17:56, JORDI PALET MARTINEZ via address-policy-wg 
mailto:address-policy-wg@ripe.net>> wrote:
What I’m saying is that we force the change of status from non-legacy to legacy 
if addresses are transferred to a new member or an existing member, as both of 
them will have all the legal bindings already with RIPE NCC.

If the goal is to have a correct and updated registry adding criteria by force 
to transfers is counter productive.

For larger address space transactions this will simply lead to transfer of 
legal entities, or other legal constructs to circumvent the policies.

I belive the community should focus strongly on an accurate registry as the 
main principle.

Hans Petter

--
-- Hans Petter Holen Mobile +47 45 06 60 54 | 
h...@oslo.net<mailto:h...@oslo.net> | http://hph.oslo.net

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Erik Bais]

Hi Jordi,  

Please keep the lingo correct.. you keep referring to non-legacy .. but your 
intention and this complete discussion is about Legacy space.
Typically we are talking about inter-rir transfers from ARIN to RIPE if I read 
it correctly. As most Legacy space that comes into RIPE has an ARIN origin. 
There is APNIC as well, but just less transfers from APNIC to RIPE with legacy 
.. 

While I've done 'some' Legacy inter-rir transfers .. is there a problem with 
how it is being transferred ? 
There is the option currently for legacy resource holders to move IP space 
between RIR's (ARIN to RIPE for instance) for cost, policy, tools or rights 
acceptance reasons .. or just because their HQ is moving from the ARIN region 
to RIPE region.  
Why should they be stripped of their current status ? what is the intention 
here ? 

Regards,
Erik Bais 


On 15/07/2019, 11:39, "address-policy-wg on behalf of JORDI PALET MARTINEZ via 
address-policy-wg"  wrote:

Hi Tore,

I think my previus email just explained it.

The motivation is my personal view that we have a problem (as a community) 
by not bringing into the system the legacy resources.

I'm alone with that view? I don't know, and that's why I'm asking.

What is clear to me is that, according to existing policies, I share this 
view with 4/5 of the RIR communities.

What is the effect of that? Simple, an unbalance of transfers among 
regions, because if someone for whatever reason want to get resources and keep 
them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't 
think so, we could keep growing the non-legacy resources, while other regions 
get "cleaned".

Regards,
Jordi
@jordipalet
 

El 15/7/19 10:05, "address-policy-wg en nombre de Tore Anderson" 
 escribió:

* Gert Doering

> On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
>> I keep thinking that ripe-682 (RIPE resource transfer policies), 
should have a provision (as it is the case in all the other RIRs), in order to 
"convert" the legacy resources to non-legacy, when they got transferred.
> 
> What is it that you want to achieve with this?

+1

I've read this entire thread and I still have no idea what the 
motivation for this (pre-)proposal actually is. Is it a solution in search of a 
problem?

Maybe if you could explain by example, Jordi?

Were you involved in a transfer of legacy resources and stumbled across 
some kind of obstacle caused by current policies (that this proposal addresses)?

Tore





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

[Erik Bais]

Hi Jordy,

Legacy resources don’t fall under the contractual obligations that we as a 
community have setup. Financial or policy, unless decided/afreed upon by legacy 
resources themselves.
That is described in the policy document RIPE NCC services for legacy resource 
holders.  ( https://www.ripe.net/publications/docs/ripe-639 )

If you would view the RIPE NCC as a holder of IP space, that provides resources 
when a membership is present. If a member would not pay, the resources could be 
revoked. Legacy holders didn’t receive the resources from RIPE NCC and their 
resources can’t be revoked. As the RIPE NCC isn’t the top holder of the 
resource. If legacy is handed back, it would ( should ) go to IANA ..

With the legacy services policy it was decided that the historic rights of 
legacy holders are honored and only if they decide that they want to include 
themselves in the community and services, it is possible. But only by their own 
decision.

Stripping the legacy resource status after a transfer, would change the holder 
of the resource from the seller to the rir instead of the seller to the buyer.

The RIPE NCC is providing an administrative service to maintain an accurate 
registry, also including Legacy resources..

Changing the legal status of legacy resources by force, will open up the RIPE 
NCC for liability charges and due to its monopoly in the RIPE region, that is 
not a good plan ... and knowing some Legacy holders, that is going to be a huge 
no-go.

Your last email stated that non-legacy holder to non-legacy holder transfers 
are outside the system .. if we regard the RIPE policies inside the system ... 
non-legacy resources are ‘IN’ the system.. because you would say that they 
would be PI holders or RIPE NCC members ( LIR’s ) ...
Legacy holder can be outside ( no contract ) the rir status .. or by their own 
choice inside the system ..

Hope this explains a bit.

Regards,
Erik Bais



Verstuurd vanaf mijn iPhone
Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg 
mailto:address-policy-wg@ripe.net>> het volgende 
geschreven:

Hi Gert,

If the received of the transfer is already bound by contracts with RIPE, he is 
the one that will "convert" the resources to non-legacy accepting that transfer.

Of course, transfers from non-legacy holders to non-legacy holders are outside 
of the system.

Regards,
Jordi
@jordipalet



El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" 
mailto:address-policy-wg-boun...@ripe.net> 
en nombre de g...@space.net<mailto:g...@space.net>> escribió:

   Hi,

   On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
If legacy holders, want to transfers those resources and escape from fulfilling 
the policies and contractual requirements, now they can do it in RIPE, but not 
in other regions.

   Repeat with me: there is no contract of any sort that the RIPE community
   can use to make legacy resource holders do *anything* unless they want
   it themselves.

   (And if they *want* to bring their space under the RIPE umbrella, they
   can do it today already).

   Gert Doering
   -- NetMaster
   --
   have you enabled IPv6 on something today...?

   SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael 
Emmer
   Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
   D-80807 Muenchen HRB: 136055 (AG Muenchen)
   Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation)

[Erik Bais]

Dear working group,  

The review phase has ended and the AP-WG Chairs have declared rough consensus 
on the feedback received, during the Review Phase.   

We like to thank Randy, Tore, Christoffer and Peter Hessler for their support 
and Kai for his remark. ( which was addressed by the author Sander.) 

Marco,

If you could push this into last call, that would be great.  

On behalf of the AP-WG Chair collective,

Erik Bais
Co-Chair of AP-WG  


On 06/05/2019, 13:10, "address-policy-wg on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the 
Review Phase.

This proposal aims at creating a waiting list based on an allocation size 
of /24 once the RIPE NCC’s free IPv4 pool is exhausted.

The proposal has been updated following the last round of discussion and is 
now at version v2.0. Some of the differences from version v1.0 include:
- New proposal title
- Focus on waiting list requirements
- Adjusting the moment of policy activation

The RIPE NCC has prepared an impact analysis on this latest proposal 
version to support the community’s discussion. You can find the full proposal 
and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-02

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-02/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four 
week Review Phase is to continue discussion of the proposal, taking the impact 
analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG 
has reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document 
and send any comments to  before 4 June 2019.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] FW: 2019-02 Review Phase (IPv4 Waiting List Implementation)

[Erik Bais]

Dear WG members,  

As you might have seen, there is a v2 uploaded on the RIPE website and this 
will be discussed tomorrow during the AP-WG meeting. 

Please pre-read the updated version in order to make sure you can participate 
in the discussion about the latest version of the policy text. 

Kind regards,  

Erik Bais 
Co-Chair AP-WG 


On 06/05/2019, 13:10, "address-policy-wg on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the 
Review Phase.

This proposal aims at creating a waiting list based on an allocation size 
of /24 once the RIPE NCC’s free IPv4 pool is exhausted.

The proposal has been updated following the last round of discussion and is 
now at version v2.0. Some of the differences from version v1.0 include:
- New proposal title
- Focus on waiting list requirements
- Adjusting the moment of policy activation

The RIPE NCC has prepared an impact analysis on this latest proposal 
version to support the community’s discussion. You can find the full proposal 
and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-02 



And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-02/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four 
week Review Phase is to continue discussion of the proposal, taking the impact 
analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the WG Chairs will determine whether the WG 
has reached rough consensus. It is therefore important to provide your opinion, 
even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document 
and send any comments to  before 4 June 2019.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] AP WG co-chair selection - call for volunteers

[Erik Bais]

Dear working group, 

Let's try that again ( 

We have received one reply to the call for volunteers for the election. 

I proudly present to you Gert Döring. For those that are new to the working 
group, see below his introduction :  

-   Gert Doering

* age 47
* shoe size 47, preferrably wearing sandals
* university diploma in physics, but into networking since about 26 years

* the ISP I work for is SpaceNet, AS5539 - a regional ISP in Munich, DE,
   who provides mostly "datacenter" and "managed hosting" services these
   days (but used to provide access, so I know both sides of the medal)

* hands-on-geek - network, peering, unix admin - and long-time LIR contact,
   so I know both the operational side of "IP networks" and the bureaucracy
   side of "I want a Class C network!" - "here's a /29" haggling.

* attending RIPE meetings since RIPE 24 in Berlin, 1996
   (missing two since then, Dublin I and Prague II)

* address policy working group co-chair since RIPE 44 in Amsterdam, 2003
   (https://www.ripe.net/ripe/meetings/ripe-meetings/ripe-44/meeting-report)
   - then still called the "LIR working group".


My plans for the WG are mostly the same as I did in the previous years -
help shape address policies for the RIPE region that are workable for
all affected users, and do so in a hopefully neutral and constructive way.

Further, facilitate a constructive dialogue between the RIPE NCC and the
RIPE community regarding address policy issues.

(I *still* do expect the WG to eventually wind down, as we seem to have
reached the point where IPv4 policies do not succeed anymore due to too
vastly conflicting interests, and IPv6 policies seem to be "good enough"
for most cases, so the occasional tweak here and there...  we'll see :-) )

Gert Doering
---

By procedure: 

The actual appointment will be discussed and decided at the next AP 
session at the RIPE meeting in Reykjavik, Iceland.

The remaining chair will determine whether consensus has been reached.
And if that isn't somehow possible, a secret ballot will be done by 
attendees IN the room and counted by the RIPE NCC staff.

There will be an agenda topic for the topic on the next AP-WG meeting in 
Iceland. 

Kind regards,
Erik Bais 
Address Policy Working Group Chair 





On 04/04/2019, 20:06, "Erik Bais"  wrote:

Dear working group,

Introduction

We will be starting the selection process for the RIPE Address Policy 
working group co-chair soon.

This mail provides information about the process and the call for 
volunteers.


Current Address Policy Working Group Chair Selection Process
-
The AP working group chair selection process is documented here:


https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process

We have 2 co-chairs and each chair's term is 2 years.


About the Process

Typically until last year, Sander and Gert did this dance together and 
it was never an actual selection process..

That is, until Sander decided to step down and not run again.

To avoid people start on the ML about who they like to support at the 
beginning with the initial volunteers only, we will do a short call for 
volunteers of 10 days, by asking the volunteers to send their motivation and 
intro to the AP-WG Chair email address. ( ap-wg-cha...@ripe.net ) 

Please submit an intro / bio plus motivation, that you understand the 
impact of being selected as Co-Chair and your intention to be present at the 
next RIPE meetings before : April 15, 2019

We will then release the names and statements of all applicants after 
the call for co-chair volunteers closes.

And at that time the WG can provide input on the Mailing list on who 
they like to support as their co-chair.
Or if there is specific opposition to a participant, that can also be 
voiced.

For full transparency, it is possible that Gert's name will be added to 
the list in random order.

The actual appointment will be discussed and decided at the next AP 
session at the RIPE meeting in Reykjavik, Iceland.

The remaining chair will determine whether consensus has been reached.
And if that isn't somehow possible, a secret ballot will be done by 
attendees IN the room and counted by the RIPE NCC staff.

As always, please feel free to reach out to any of the chairs directly, 
to us as a group at mailto:ap-wg-cha...@ripe.net, or discuss this or any other 
any relevant topic on this mailing list.

On behalf of your co-chairs Gert Doering and Erik Bais,  

Kind regards,
Erik Bais

Re: [address-policy-wg] AP WG co-chair selection - call for volunteers

[Erik Bais]

Dear working group, 

We have received one reply to the call for volunteers for the election. 

I proudly present to you Gert Döring. For those that are new to the working 
group :  



On 04/04/2019, 20:06, "Erik Bais"  wrote:

Dear working group,

Introduction

We will be starting the selection process for the RIPE Address Policy 
working group co-chair soon.

This mail provides information about the process and the call for 
volunteers.


Current Address Policy Working Group Chair Selection Process
-
The AP working group chair selection process is documented here:


https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process

We have 2 co-chairs and each chair's term is 2 years.


About the Process

Typically until last year, Sander and Gert did this dance together and it 
was never an actual selection process..

That is, until Sander decided to step down and not run again.

To avoid people start on the ML about who they like to support at the 
beginning with the initial volunteers only, we will do a short call for 
volunteers of 10 days, by asking the volunteers to send their motivation and 
intro to the AP-WG Chair email address. ( ap-wg-cha...@ripe.net ) 

Please submit an intro / bio plus motivation, that you understand the 
impact of being selected as Co-Chair and your intention to be present at the 
next RIPE meetings before : April 15, 2019

We will then release the names and statements of all applicants after the 
call for co-chair volunteers closes.

And at that time the WG can provide input on the Mailing list on who they 
like to support as their co-chair.
Or if there is specific opposition to a participant, that can also be 
voiced.

For full transparency, it is possible that Gert's name will be added to the 
list in random order.

The actual appointment will be discussed and decided at the next AP session 
at the RIPE meeting in Reykjavik, Iceland.

The remaining chair will determine whether consensus has been reached.
And if that isn't somehow possible, a secret ballot will be done by 
attendees IN the room and counted by the RIPE NCC staff.

As always, please feel free to reach out to any of the chairs directly, to 
us as a group at mailto:ap-wg-cha...@ripe.net, or discuss this or any other any 
relevant topic on this mailing list.

On behalf of your co-chairs Gert Doering and Erik Bais,  

Kind regards,
    Erik Bais

Re: [address-policy-wg] Contact details for End Users in the RIPE Database

[Erik Bais]

In line with this question …

The RIPE NCC still has a working fax machine that prints the SSA’s for those 
that want to speed up their processing of the membership sign-up process.

I hope that the articles of association gets updated soon for this to include a 
scanned version as well.

Erik Bais

From: address-policy-wg  on behalf of Elvis 
Daniel Velea 
Reply-To: "el...@velea.eu" 
Date: Thursday 18 April 2019 at 00:35
To: "ripede...@yahoo.co.uk" , 
"address-policy-wg@ripe.net" 
Subject: Re: [address-policy-wg] Contact details for End Users in the RIPE 
Database


- fax - who is still using fax, will you even think you will need a fax sent to 
a holder of internet resources?

[address-policy-wg] AP WG co-chair selection - call for volunteers

[Erik Bais]

Dear working group,

Introduction

We will be starting the selection process for the RIPE Address Policy working 
group co-chair soon.

This mail provides information about the process and the call for volunteers.


Current Address Policy Working Group Chair Selection Process
-
The AP working group chair selection process is documented here:

https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process

We have 2 co-chairs and each chair's term is 2 years.


About the Process

Typically until last year, Sander and Gert did this dance together and it was 
never an actual selection process..

That is, until Sander decided to step down and not run again.

To avoid people start on the ML about who they like to support at the beginning 
with the initial volunteers only, we will do a short call for volunteers of 10 
days, by asking the volunteers to send their motivation and intro to the AP-WG 
Chair email address. ( ap-wg-cha...@ripe.net ) 

Please submit an intro / bio plus motivation, that you understand the impact of 
being selected as Co-Chair and your intention to be present at the next RIPE 
meetings before : April 15, 2019

We will then release the names and statements of all applicants after the call 
for co-chair volunteers closes.

And at that time the WG can provide input on the Mailing list on who they like 
to support as their co-chair.
Or if there is specific opposition to a participant, that can also be voiced.

For full transparency, it is possible that Gert's name will be added to the 
list in random order.

The actual appointment will be discussed and decided at the next AP session at 
the RIPE meeting in Reykjavik, Iceland.

The remaining chair will determine whether consensus has been reached.
And if that isn't somehow possible, a secret ballot will be done by attendees 
IN the room and counted by the RIPE NCC staff.

As always, please feel free to reach out to any of the chairs directly, to us 
as a group at mailto:ap-wg-cha...@ripe.net, or discuss this or any other any 
relevant topic on this mailing list.

On behalf of your co-chairs Gert Doering and Erik Bais,  

Kind regards,
Erik Bais

Re: [address-policy-wg] Policy violation

[Erik Bais]

Aleksey,  

You do as if this was a surprise, but this is clearly documented and discussed. 
And you have been on the mailinglist for long enough to know that up front as 
well.  

If you have 3 LIR accounts this year, and want to put the resources in a single 
LIR, you MUST wait for 2 years before you can do so.  

All LIR accounts that are in either entity should be paid in FULL for the hole 
year once you start transferring resources. 

This means you pay per LIR :  

2000 euro setup fee. 
1400 euro first year
1400 euro second year 

Times 3 ... 

After that, you can request for a transfer of the resources in to a single 
account and close the 2 other LIR's. 

After which, you have a single LIR account with 3 resources in it and a future 
cost of 1400 euro per year.  

What you want to do has nothing to do with a Policy violation ... the policy is 
clear, RIPE NCC is executing the policy as documented. 

Regards,
Erik Bais



On 17/12/2018, 19:22, "address-policy-wg on behalf of Aleksey Bulgakov" 
 wrote:

Hi.

Regarding our situation. We have 3 accounts opened this year (for
different legal entities). We provided the oficial government
documents that confirm M procedure. But the NCC doesn't want to
merge 2 accounts (of closed organizations) into the 1st account due to
it is necessary to convert such accounts into additional account of
receiving party, regarding
https://www.ripe.net/publications/docs/ripe-709#transfer36.

But there is restriction to transfer the resources during 24 month
between accounts of the same member. So we should pay for additional 2
years fees.
пн, 17 дек. 2018 г. в 21:12, Jens Ott - Opteamax GmbH :
>
>
> > Which is kind of the point.  The 24 month restriction holds, unless
> >  one LIR gets bought/merged, and the latter needs to be proved by
> > official documents.
>
> This is also not correct! At least from my experience, the restriction
> also persists on being bought!
>
> The difference between being bought and merged is, at least from
> German legal point of view, that in a merge (=Verschmelzung) the $OLD
> company does not exist any longer but becomes fully integrated into
> $NEW company, while in buying a company, $OLD stays it's own legal entit
> y.
>
> From my experience ONLY A MERGE IS accepted by RIPE to not apply
> 24month restriction, while being bought does not shorten this restrictio
> n.
>
> BR
>
> --
> Jens Ott
> Geschäftsführer
>
> Opteamax GmbH
>
> Simrockstr. 4b
> 53619 Rheinbreitbach
>
> Tel.:  +49 2224 969500
> Fax:   +49 2224 97691059
> Email: j...@opteamax.de
>
> HRB: 23144, Amtsgericht Montabaur
> Geschäftsführer: Jens Ott
> Umsatzsteuer-ID.: DE264133989
>


-- 
--
Best regards,
Alexey Bulgakov
Tel.: +7 (926)690-87-29

Re: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy

[Erik Bais]

Hi Martin,

If you think it would make sense, feel free to submit a policy proposal.

Please let Gert and myself know if you want to do that and we or Marco can 
assist if needed.

Regards,
Erik Bais
Co-chair for the AP-WG

From: Martin Tonusoo 
Date: Monday 17 December 2018 at 16:20
To: Erik Bais 
Cc: "address-policy-wg@ripe.net" 
Subject: Re: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address 
allocation and assignment policy

Hi Erik,

sorry for the late reply.

> If you look at the text, would the LIR who assigned IP space to their own 
> infra-structure not also be an End-User ?

I guess this depends on the definition of the "End User". Simply stating that 
in the "ASSIGNED PA" definition would make this in my opinion less ambiguous.



Best regards,
Martin Tonusoo
IP Network Engineer
--
 CITIC Telecom CPC
   www.citictel-cpc.com
--
Direct: +372 622 3321
NOC 24/7: +372 622 3300
NOC 24/7: +7 495 9815670

____
From: "Erik Bais" 
To: "Martin Tonusoo" 
Cc: "address-policy-wg" 
Sent: Friday, November 30, 2018 1:33:13 PM
Subject: Re: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address 
allocation and assignment policy

Hi Martin,

If you look at the text, would the LIR who assigned IP space to their own 
infra-structure not also be an End-User ?
In the past, the LIR would describe IP space for themselves as Infra or 
INFRA-AW, but still give it the status Assigned PA.

Something along the lines of this example : 
https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe=178.249.152.0%20-%20178.249.152.127=inetnum

Regards,
Erik Bais


From: address-policy-wg  on behalf of 
Martin Tonusoo 
Date: Tuesday 13 November 2018 at 13:42
To: "address-policy-wg@ripe.net" 
Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address 
allocation and assignment policy

Hello,

according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC 
Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" 
has a definition of "This address space has been assigned to an End User for 
use with services provided by the issuing LIR". As "ASSIGNED PA" should also be 
used for assignments for LIR own infrastructure, then isn't the definition of 
"This address space has been assigned to the issuing LIR infrastructure or End 
User for use with services provided by the issuing LIR." bit more accurate?



Best regards,
Martin Tonusoo
IP Network Engineer
--
 CITIC Telecom CPC
   www.citictel-cpc.com
--
Direct: +372 622 3321
NOC 24/7: +372 622 3300
NOC 24/7: +7 495 9815670

Re: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address allocation and assignment policy

[Erik Bais]

Hi Martin,

If you look at the text, would the LIR who assigned IP space to their own 
infra-structure not also be an End-User ?
In the past, the LIR would describe IP space for themselves as Infra or 
INFRA-AW, but still give it the status Assigned PA.

Something along the lines of this example : 
https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe=178.249.152.0%20-%20178.249.152.127=inetnum

Regards,
Erik Bais


From: address-policy-wg  on behalf of 
Martin Tonusoo 
Date: Tuesday 13 November 2018 at 13:42
To: "address-policy-wg@ripe.net" 
Subject: [address-policy-wg] definition of "ASSIGNED PA" in IPv4 address 
allocation and assignment policy

Hello,

according to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC 
Service Region"(ripe-708) document, the "status" attribute value "ASSIGNED PA" 
has a definition of "This address space has been assigned to an End User for 
use with services provided by the issuing LIR". As "ASSIGNED PA" should also be 
used for assignments for LIR own infrastructure, then isn't the definition of 
"This address space has been assigned to the issuing LIR infrastructure or End 
User for use with services provided by the issuing LIR." bit more accurate?



Best regards,
Martin Tonusoo
IP Network Engineer
--
 CITIC Telecom CPC
   www.citictel-cpc.com
--
Direct: +372 622 3321
NOC 24/7: +372 622 3300
NOC 24/7: +7 495 9815670

[address-policy-wg] Draft Agenda RIPE77 - Address Policy

[Erik Bais]

Hi APWG folks,

Below you can find a draft for the RIPE address policy WG meeting's agenda,
which will take place in Amsterdam in the side-room in the following time slots:

Wednesday, Oct 17, 09:00 - 10:30
Wednesday, Oct 17, 11:00 - 12:30

If you have anything else you want to see on the agenda, or if we need
to change anything, please let us know.

Regards,

Gert Döring & Erik Bais,
APWG chairs


--
Wednesday, 09:00-10:30
--

A. Administrative Matters
   (welcome, thanking the scribe, approving the minutes, etc.)

B. Update on 2018 - 04 - PDP Clarification to the WG.
( discussion was done on RIPE Discussion list )

C. Current Policy Topics - Marco Schmidt, NCC PDO

   - global policy overview
 "what's going on?"

   - common policy topics in all regions
 (end of IPv4, transfers, ...)  

   - overview over concluded proposals in the RIPE region
 since RIPE 76

   - brief overview of new proposals
 (if any)

D. IPv4 end-game and afterlife - Andrea Cima, RIPE NCC
(+ discussion with the group)

E. Country codes in the extended delegated statistics and RIPE DB.
by Ingrid Wijte, RIPE NCC  

--
Wednesday, 11:00-12:30
--

Welcome back

F.  Discussion of open policy proposals

2018-02 Assignment Clarification in IPv6 Policy
Jordi Palet Martinez

Y. Open Policy Hour

   The Open Policy Hour is a showcase for your policy ideas.
   If you have a policy proposal you'd like to debut, prior
   to formally submitting it, here is your opportunity.


Z. AOB

[address-policy-wg] RIPE77 AP-WG Agenda topics in mind ?

[Erik Bais]

Dear Working Group,  

As we are in the process of sorting out the topics for the AP-WG agenda. 
We would like to ask if there are people who like to see certain topics or 
discuss something that would require some time on the agenda for RIPE77 during 
Address Policy.  

If you are wondering about certain things (Address Policy related) or like to 
present something, please let us know and we will see if and where we can 
reserve some time for it on the agenda.  

We hope that we can put out the agenda itself on this ML before this Friday. 

Kind regards,
Gert Döring & Erik Bais 
APWG chairs

Re: [address-policy-wg] 2018-02 New Version Policy Proposal (Assignment Clarification in IPv6 Policy)

[Erik Bais]

Dear working-group,  

As most of you are probably back from vacation and full in working mode again.. 
I would like to ask you to take some time to review 2018-02 before the Sept. 
27, 2018. 

We didn't hear any voices on the list in support or objection on the topic and 
we like to invite you to have a quick read and provide some feedback on it 
before Thursday.  

On behalf of the AP-WG Chair collective,  

Kind regards,
Erik Bais 



On 29/08/2018, 13:29, "address-policy-wg on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is 
now available for discussion again.

This proposal aims to clarify the definition of "Assign" in ripe-707 
(section 2.6).

This proposal has been updated following the last round of discussion and 
is now at version v2.0. Some of the differences from version v1.0 include:
- Adjusting the scope of what is considered a sub-assignment

You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2018-02 

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 
WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 27 September 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] LACNIC "Proposal to create a Global Internet Registry (GIR)"

[Erik Bais]

The question that came to mind was ... 

Is the IANA transition done yet ?  Good. Let's start another one ... 

/ponder ... 

On 16/03/2018, 12:49, "address-policy-wg on behalf of Marco Schmidt" 
 wrote:

Dear colleagues,

We would like to make you aware of a policy proposal that is being 
discussed in the LACNIC community, called "Proposal to create a Global Internet 
Registry (GIR)". You can find the proposal here: 
https://politicas.lacnic.net/politicas/detail/id/LAC-2018-1?language=en 

This is a global policy proposal, meaning that it would apply to all five 
RIRs. However, each RIR community would first need to ratify an identical 
version of the policy before it could be implemented. 

No such policy proposal has yet been submitted in our service region. We 
will let you know of any further developments. 

You can find more on the global policy development process here: 
https://www.nro.net/policies/global-policies-development-process/

Kind regards

Marco Schmidt
Policy Development Officer
RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

[address-policy-wg] FW: WG chair change

[Erik Bais]

Hi Gert, Sander & AP-WG members, 

Thank you for the email and I would like to formally put my name in the 
hat. 

For those that don't know me personally, my name is Erik Bais, Dutch, I'm 
45, married for 16 year with my wife Wilhelmina and we have 2 sons. 
I'm the owner of a Dutch ISP named A2B Internet and I'm one of the 
co-founders of the IPv4 broker : Prefix Broker. 
I've lived most of my life in The Netherlands and as a family, we lived for 
almost a year in the UAE (Dubai) in 2008/2009, when I worked for a US based 
system integrator and I've worked in Germany for a US based company in the 90's 
for a year.  
I have a been working in the ISP community since the 2000. And started A2B 
Internet in 2010 in The Netherlands. 

In our work as a connectivity ISP, we started to request AS numbers and IP 
space for customers in order to get them migrated to our network and while 
doing so, we noticed some things that needed improvement in the AP policies.  
That is how it all got started ...

I've been the author of the following proposals that have been accepted by 
the community:  

https://www.ripe.net/participate/policies/proposals/2011-02 : Removal of 
multihomed requirement for IPv6 PI # co-author together 
with Jordi
https://www.ripe.net/participate/policies/proposals/2013-04 : Resource 
Certification for non-RIPE NCC Members # Services 
WG - allowing PI space holders and Legacy space holders the option for RPKI 
certification. 
https://www.ripe.net/participate/policies/proposals/2014-02 : Allow IPv4 PI 
transfer
https://www.ripe.net/participate/policies/proposals/2014-12 : Allow IPv6 
Transfers
https://www.ripe.net/participate/policies/proposals/2014-13 : Allow AS 
Number Transfers
https://www.ripe.net/participate/policies/proposals/2015-04 : RIPE Resource 
Transfer Policies 

And I've been quite active on the discussions on the mailinglist and in the 
GM's.  

Besides the various presentations about the policies, I've also done some 
presentations in the plenary of the RIPE meetings and different WG's about 
various topics..  

Examples are:  
https://ripe72.ripe.net/archives/video/116/ : Naughty Port project about a 
different way of making a peering decision based on Network Naughty-ness using 
a rating system against DDOS's. 
https://ripe74.ripe.net/archives/video/119/ : IRR Filtering at IXP Route 
Servers 
https://ripe75.ripe.net/archives/video/165/ : Pre-Transfer Clean-Up of 
Abused Prefixes  

I really like the RIPE community and as an active policy proposer, I think 
I can say that I have been around the block on the PDP and can work with the 
sometimes harsh way of communication that a co-chair role has need to deal with 
in the heat of some discussions.   
I understand what it requires in effort from time to time and as I'm living 
in the Netherlands, it makes it easy to visit the Amsterdam RIPE office for me 
if needed. 

I hope that the community appreciates the transparent way of communicating 
and knowledge sharing that I like and that I will be selected as the co-chair 
for the AP-WG.  

Regards,
Erik Bais

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

[Erik Bais]

Hi Gert, Nick & Jordi,  

I don’t think that the fear from past times is something that we should keep in 
this discussion these days..  

If you have a look at which speed hosters / ISP are opening up new LIR’s for 
the /22 IPv4 … and are able to get their own v6 /29, just because they need the 
v4 anyway .… I have serious doubt if someone would even consider to get a 
‘cheap’  /48 PI just to game the system.  

It would have my vote to remove as much of the IPv6 PI restrictions as 
possible, but keep the /48 PI limit without documentation …  

The goal of aggregation is noble for the DFZ, but if you have a look at the 
current v6 space and what people are de-aggregating their v6 prefixes into .. 
you would probably have to agree with me that this discussion doesn’t apply to 
the real world anymore.  

The discussion of financial cost for v6 space is nothing if you look at the 
cost for getting v4 .. and if someone wants to do the documentation for PI 
space .. rather than becoming a LIR.. where you can get a /29 without any 
questions or documentation .. Go for it ..  

If you have that amount of customers .. I think you would be an LIR already ..  

Just have a look how certain companies are doing more specific announcements of 
their /32 in /48’s .. or even smaller…  

If customers want to implement v6 .. using PI space for their internal infra .. 
or even host a server or 200 on that /48 .. let them have fun with it..  
The reality is that is not where the pollution in the routing table will come 
from imho .. 

I do think that a proposal to change the PI v6 requirements should be a 
separate discussion and policy proposal. 

Regards,
Erik Bais 



On 08/11/2017, 17:14, "address-policy-wg on behalf of Gert Doering" 
<address-policy-wg-boun...@ripe.net on behalf of g...@space.net> wrote:

Hi,

On Wed, Nov 08, 2017 at 03:54:42PM +, Nick Hilliard wrote:
> JORDI PALET MARTINEZ wrote:
> > I don???t think reaching consensus in the PI/PA change will be so easy
> > in the ???near future??? (considering that it may require a long
> > implementation time), and a middle way proposal looks feasible to
> > me.
> 
> but it's not a middle way: it's removing the block on sub-assigning to
> other parties, which is the thing that distinguishes PI from PA.

Which is one of the things.  Other things are "how big will that bag
of numbers be" and "what costs are attached to it".

Especially the "how big will that bag of numbers be" will certainly be
something we'll have to discuss next, shall we decide to open up PI
for "more liberate use" (like, will "I want to assing a million /64
to DSL users" be a sufficient reason to get "larger than a /48"?).

Consequences to all we do...

Gert Doering
-- APWG chair
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

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

[Erik Bais]

> Now everyone will have to figure out if that's enough or not. :)

That is clearly not enough... you are asking the obvious here Jan...  ;-)  

Erik 

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens Jan 
Zorz - Go6
Verzonden: dinsdag 26 september 2017 10:27
Aan: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing 
Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

On 24/09/2017 00:38, Sander Steffann wrote:
> ...or change the /22 to /24 and keep giving newcomers a tiny bit of
> addresses for a while longer (what is currently being proposed).

Hey,

A quick math what a /24 can give you if you use if for
translation/transition purposes only (NAT64 or A+P like MAP-E/T)

If you connect to your upstream with *their* IP addresses and not break
your /24 into smaller bits and connect your NAT64 or A+P PRR box
directly to that BGP router, use first usable address as a gateway,
second address as an interface address for your translation/transition
box, then you are left with 252 usable addresses for your purpose. That
means 65.535 ports per address, giving you 16.514.820 usable ports.
Usually sane people predicts between 700 and 1000 ports per user, and
that gives you between 16.514 and 23.592 possible users that you can
serve at the same time and connect them to legacy IPv4 world.

Now everyone will have to figure out if that's enough or not. :)

Cheers, Jan

Re: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)

[Erik Bais]

Hi Elvis,  

 

I've read the proposal and I’m not sure I see what you are trying to solve
here ...  besides the obvious …  

 

Because if you look at the following URL:  

 

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran
sfers/inter-rir-transfers/inter-rir-ipv4-transfer-statistics 

 

There is a specific section for Inter-RIR transfers .. with a to RIPE and
>From RIPE tab..  

 

And in the To tab, you will see the following (as an example.. )  

 

157.97.0.0/16   ARIN  A Networks B.V.
17/03/2016

147.28.0.0/16   ARIN  RGnet, LLC
16/03/2016

192.83.230.0/24   ARIN  RGnet, LLC
16/03/2016

198.133.206.0/24 ARIN  RGnet, LLC
16/03/2016

 

And these are all Legacy Prefixes inter-rir transfers done .. and
published.. 

 

So if the RIPE NCC is already registering the prefixes as part of the Inter
RIR transfers .. even before they are marked as a Legacy prefix.. in the
RIPE DB ..  

How will this policy make a difference ?  

 

And the change in the transfer document that the RIPE NCC is currently still
implementing ..  it clearly states the following :  

 

https://www.ripe.net/publications/docs/ripe-682#4-0-transfer-statistics

 

*4.0 Transfer Statistics

 

*The RIPE NCC will publish a list of all transfers. This publication
shall occur on a monthly basis or more frequently if the RIPE NCC so
chooses.

*This list will contain information about approved changes. The
following information will be published:

*The name of the offering party

*The resource originally held by the offering party

*The name(s) of the receiving party or parties

*Each subdivided prefix (each partial block derived from that
original block) or resource received

*The date each resource was transferred

*Whether it was a transfer according to this policy or a transfer
due to changes to an organisation's business structure (such as a merger or
acquisition)

 

And I like to put the emphasis on :  

 

*The RIPE NCC will publish a list of all transfers.

And 

*Whether it was a transfer according to this policy or a transfer
due to changes to an organisation's business structure (such as a merger or
acquisition)

 

This paragraph 4 isn’t a part of the paragraph 3.. (3.0 Inter-RIR Transfers
)  … or the limitations in paragraph 2 (2.0 Transfers within the RIPE NCC
Service Region)  

 

And there is also no difference between RIPE PA or Legacy space in that
section …  

 

So how I read (and wrote) the policy is that the Transfer statistics should
be published on all transfers.  

*A transfer can be a change of resources from company name A to
company name B .. (via the M process)  

*Or via the actual Transfer procedure …  

*Or a company name change .. ( company A is now known as company B,
but same company, same owners etc.  ) This is the least
interesting one imho.  

 

There is no limitation for legacy resources .. and it doesn’t affect their
legacy status .. under this policy.  

 

There is a difference between the RIPE DB and the RIPE registry.. if you
want to update the DB, the LRH can do that themselves.. 

But if the LRH wants to update the registry (the RIPE NCC internal system),
they should provide the proper documentation.  And that is already in place
in procedures..  

 

So the actual change that you are asking is :  

 

In the Services to Legacy Resource Holder policy
(https://www.ripe.net/publications/docs/ripe-639)  .. 

 

Have Legacy Holders to agree to sign a document, that the RIPE NCC already
has in the operational procedure.  

 

In which case the name of the policy is incorrect .. as it isn’t about
Inter-RIR legacy updates .. or transfers .. but about the Services to LRH’s
.. 

 

Perhaps we should see first what the RIPE NCC will implement with the
2015-04 … before we go look into additional policy … 

 

Regards,

Erik Bais 

A2B Internet 

 

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
Marco Schmidt
Verzonden: dinsdag 25 april 2017 14:40
Aan: address-policy-wg@ripe.net
Onderwerp: [address-policy-wg] 2017-01 New Policy Proposal (Publish
statistics on Intra-RIR Legacy updates)

 

Dear colleagues,

 

A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy
updates" is now available for discussion.

 

The goal of this proposal is to require the RIPE NCC to publish all changes
to the holdership of legacy resources in the existing transfer statistics.

 

You can find the full proposal at:

 <https://www.ripe.net/participate/policies/proposals/2017-01>
https://www.ripe.net/participate/policies/proposals/2017-01

 

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
propo

Re: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)

[Erik Bais]

Hi Leo,  

Let me provide some insight on how Inter-RIR legacy  transfer go from, for 
instance ARIN to RIPE.  

Once a ticket has been submitted via the ARIN system for a transfer, by the 
originating party, ARIN will process the transfer, verify the legitimacy of the 
holdership etc.  and they will forward the ticket to RIPE NCC.  

The RIPE NCC will do the check with the receiving party if they are eligible 
for the transfer and can justify the needs assessment that is required.  

The RIPE NCC will request the parties (received and originating party) to 
indemnify the RIPE NCC for any changes in the RIPE DB .. the word is that it 
isn't a contract, but there are legal words involved and signatures required on 
paper and the RIPE NCC is the third party beneficiary of the paper that isn't a 
contract.  ( the indemnification .. )  

And then they will also request a copy of the company registration of the 
receiving party and the originating party for the correct documentation in the 
Registry (the RIPE NCC internal system).  
The RIPE NCC has a very strict verification system in place for transfers, so 
your assumption that they don't verify or approve transfers ... ( Specifically 
Legacy resources.. ) is not correct. They do verify and check . . . and check 
.. and check again ..  
And I rather have them do this once to many times. And this is almost similar 
for regular Legacy transfers if a parent prefix needs to be split .. as that 
can only be done by the RIPE NCC and the updating of the registry of the RIPE 
NCC for holdership changes must also be documented properly.. So if you ask the 
RIPE NCC to update the registry after a legacy transfer, they will ask you for 
some documents to proof who you are and to indemnify the RIPE NCC for any 
mistakes in the updating of the info if needed.. 

I never had ANY LHR ask me why they are not listed in the RIPE stats for 
transfer as a Legacy holder. Most of the sending and receiving parties would 
rather not be listed instead of being published on the transfer stats page.  

However for completion of the data about transfers, it could be interesting for 
some (mostly researchers and probably brokers.. )  to get an idea about the 
current market..  

However if you maintain your own versioning of the RIPE database, you can also 
do this yourself internally and just diff the DB between last week and today if 
needed. 

As on your remark on the services WG as the Go-To WG for LHR .. that might 
swing both ways.. as most Transfer policy discussions have been done here.  But 
I'm not arguing that you are incorrect on the point. 

Regards,
Erik Bais
A2B Internet & Prefix Broker 


-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens Leo 
Vegoda
Verzonden: vrijdag 28 april 2017 18:21
Aan: el...@v4escrow.net; Carlos Friacas <cfria...@fccn.pt>
CC: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal 
(Publish statistics on Intra-RIR Legacy updates)

Hi Elvis,

Elvis Daniel Velea wrote:

[...]

> Is there a need for that...? How many LRH have expressed concerns
> about such a gap?
It is not a gap in the policies. Transfers of legacy space are currently
not verified and/or approved by the RIPE NCC. Any update of a LR in the
database object does not require the RIPE NCC to update the registry.

If there is no gap in the policies and what you are proposing is service, why 
was this introduced to the Address Policy WG? The charter for the RIPE NCC 
Services Working Group makes it clear that it is the home for discussions 
about the introduction of new services and tools 
(https://www.ripe.net/participate/ripe/wg/services).

Kind regards,

Leo Vegoda

Re: [address-policy-wg] Password

[Erik Bais - A2B Internet]

Pick one in the list : 
https://www.random.org/passwords/?num=5=18=html=new 

Verstuurd vanaf mijn iPad

> Op 9 apr. 2017 om 18:00 heeft Stephen Balogh  het 
> volgende geschreven:
> 
> Need password 
> 

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais - A2B Internet]

Hi Gert, 

I know you well enough to not take this personal and if you are not responding 
to me on a couple nudges, you must have a good reason for it. 

Thank you for the work and lets get started on the last call on this. 

Regards,
Erik Bais

> Op 7 feb. 2017 om 17:02 heeft Gert Doering <g...@space.net> het volgende 
> geschreven:
> 
> Dear Address Policy WG,
> 
>> On Tue, Sep 27, 2016 at 03:08:32PM +0200, Marco Schmidt wrote:
>> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE 
>> Resource Transfer Policies" have now been published, along with an impact 
>> analysis conducted by the RIPE NCC.
>> 
>> The goal of this proposal is to create a single document with all relevant 
>> information regarding the transfer of Internet number resources.
>> 
>> Some of the differences from version 3.0 include:
>> 
>> - Adding a reference in all related allocation and assignment policies to 
>> the new transfer policy document
>> - Clarification in the policy text and policy summary regarding transfers 
>> due to a change in the organisation???s business (such as a merger or 
>> acquisition)
> [..]
> 
> 
> first of all, my most sincere apologies for dragging my feet on this
> for such a long time (and special apologies to Erik Bais as the proposer,
> who is not known as a very patient man but showed extraordinary patience).
> 
> 
> Evaluating consensus on this was a bit complicated.
> 
> - there were a few clear voices of support for this fourth version
>   (but since this has been going on for a while, I'm inclined to 
>   consider supporting voices from the last rounds as "still supportive"
>   for this version)
> 
> - there was a fairly long discussion on whether M should be included
>   in this or not - my co-chair Sander Steffann got involved in that 
>   discussion, and thus completely abstained in judging the outcome.
>   Reading through it again, I consider the opposing argument to be
>   *addressed* - especially since these parts were included right from
>   version 1, have been openly communicated at multiple RIPE meetings,
>   and are not "something new and unexpected" in version 4 (Sascha 
>   Luck indeed did oppose this earlier on).
> 
> - there was even more discussion about items unrelated to the proposal
>   itself, more of a whishlist what other bits could be in there (like,
>   listing the broker in the transfer statistics) - changes that are
>   independent on this proposal, which for "normal" transfers does not
>   change policy, just reorganizes text.
> 
> 
> Thus, I declare that we have rough consensus - more rough than in many
> cases, but still rough consensus according to PDP.
> 
> With that, we move 2015-04 to Last Call.  Marco will send the formal 
> announcement for that in the next days.
> 
> For reference, a list of people that voiced support or opposition (or 
> something else) in the previous review phase is appended below.  This is
> what I have based my decision on.
> 
> If you disagree with my interpretation of what has been said and the
> conclusion I have drawn from it, please let us know.
> 
> Gert Doering,
>Address Policy WG Chair
> 
> 
> Review Phase for V4.0, starting September 07, 2016
> 
> 
> During the last Review Phase five persons stated their support for this latest
> version of 2015-04:
> 
> Tore Anderson
> Stefan van Westering
> Remco van Mook
> Havard Eidnes
> Riccardo Gori
> 
> The following people opposed the proposal with the argument that organisations
> should be allowed to transfer resources after they have freed them after a
> company merger and network consolidation process:
> 
> Plesa Niculae
> Ciprian Nica
> Marius Cristea
> Yuri NTX
> Palumbio Flavia
> Sascha Luck repeated his opposition that he don't want anything M related in
> the policy text.
> 
> Havard Eidnes, Radu Adrian and Sander Steffann tried to address this
> opposition by clarifying that the intention of this proposal is to prevent the
> abuse of the merger loophole. Also it was said that a 24 month holding period
> is not really business impacting as a network consolidation needs time anyhow
> and also IP resources could be transferred before the merger takes place in
> the registry. Sander also highlighted that freed 16-bit ASN can always be
> returned to the RIPE NCC if not longer needed.
> 
> There were some side threads, for example Ciprian Nica asking to list the
> broker in the transfer statistic and to remove the date from the allocation
> netname. Erik responded that this should be done in another proposal and that
> he is not taking this on board of his 

Re: [address-policy-wg] Migration Datacenter

[Erik Bais]

Hi Angel,  

Typically the route objects are being used to create daily filters at
certain upstream / backbone providers..  

As long as you delete the old RIPE Route object (let's say 12 hrs before the
migration ) and create a new one for the new transit provider to allow them
to notify their transit provider to update their filters and announce the
new route.. you should be ok.  

You could also ... ( during the migration ) ask the new transit provider to
announce in /24's, so that if the old provider hasn't stopped their
announcement yet, you can still use the IP's in your new location.  As a
more specific route has preference above a larger announcement.  And once
the old provider stopped the announcement of the /22, you can start to
announce the /22 on the new location and stop with the /24's to be
announced.  ( Aggregation back to a /22 is nice to do.. )  

Good luck on the migration.  

Kind regards,
Erik Bais
A2B Internet 

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
ANGEL MARTINEZ SANCHEZ
Verzonden: donderdag 24 november 2016 1:07
Aan: address-policy-wg@ripe.net
Onderwerp: [address-policy-wg] Migration Datacenter

Hello,

We are going to migrate from our actually datacenter to another one. We have
/22 IPs block and not have AS number, our datacenter announce them.

Our plan is as follows:

- We already add new route objects before migration and will remove old
after migration.
- At dawn on Sunday, November 27 about 3:00 AM, we will shut down all our
servers from the current data center.
- At that point we will delete the current route AS  in RIPE DB from
inetnum XXX.XXX.XX.0/22 and only the route object corresponding to new
datacenter will remain.
- We will contact new datacenter to activate our IP block on their router
and configure the requested gateway.
- We will dismantle the entire rack from old datacenter and move it to the
new datacenter where we will start up all our servers again.

We need to know if the procedure is correct and very important, the time it
takes to propagate the new route of our IP block since we delete the current
ASX and the new AS is activated by new datacenter.

We also need to know if we depend on any action by the current data center
to complete this procedure. For example, if they have to remove our block
from their AS or their router and that would happen in case they refused to
do so on the date indicated for the migration.



Thanks and regards.
Angel


Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

I’ll entertain your question here, although the question isn’t in relation to 
the policy proposal, but more about how transfers work ..  

If a company splits… it is actually very simple … you setup a second LIR .. ( 
Provided that we are talking about RIPE PA space.. )  …  

And you transfer the space out that needs to go to the business that is split 
off, to the new LIR … 
The new entity / LIR would also receive a free /22 IPv4 and have the right to a 
/29 IPv6 and request an AS number, if they like, in the process … 

And also get 2 free access tickets to the next RIPE meeting … and may send 
employees to a new LIR training.  

In case you are talking about RIPE PI space .. it is even easier .. 
You decide who the sponsoring LIR is going to be for the new entity.. ( the 
split off business.. ) Sign an End-User Agreement with the Sponsoring LIR of 
choice .. 
Initiate a transfer to split the original prefix into multiple smaller 
prefixes.. and divide them between the 2 companies.. 

Send a signed Transfer agreement document and a copy of the End-User Agreement 
to the RIPE NCC or upload it through the portal …  
The new entity doesn’t have any additional rights to an extra /22 or other 
stuff or free tickets or trainings. 

Similar as with Legacy space .. only a Confirmation of Transfer to the RIPE NCC 
Service Region ( no RIPE NCC or Sponsoring LIR contract required even .. )  

I’m not saying that there might be corner cases out there that one might bump 
into however I think that with all the different versions that we worked on, we 
addressed the ones that are common in normal business practices. 

The policy proposal doesn’t limit companies from doing M’s …  and if you 
would read point 2.2, it clearly points that out in the text.. 

The text states : 

> Scarce resources, which are understood as those resources that are allocated 
> or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit 
> ASNs), 
> cannot be transferred for 24 months from the date the resource was received 
> by the resource holder. 
> This restriction also applies if the resource was received due to a change in 
> the organisation’s business (such as a merger or acquisition).

> This restriction does not prevent the resources from being transferred due to 
> further mergers or acquisitions within the 24-month period.

So it doesn't prevent future M's .. as that is not possible to restrict and 
not the intention ... 
The intention is to avoid speculation by hoarding and combining LIR's and 
transferring IP space out.  

Regards, 
Erik Bais 

---


Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens 
Ciprian Nica
Verzonden: zaterdag 22 oktober 2016 22:39
Aan: Radu-Adrian FEURDEAN ripe-...@radu-adrian.feurdean.net 
CC: RIPE Address Policy WG List <address-policy-wg@ripe.net>
Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis 
Published (RIPE Resource Transfer Policies)

That's a good point, what would happen when a business splits ?  I think there 
are many situations that need to be discussed and if we want to do something 
good we'd need to cover all situations. And yes, there is definitely the need 
for better policies in order for NCC to do exactly what the community wants and 
not leave room for interpretation.

Ciprian

On Sat, Oct 22, 2016 at 11:33 PM, Radu-Adrian FEURDEAN 
<ripe-...@radu-adrian.feurdean.net> wrote:
On Fri, Oct 21, 2016, at 13:42, Sascha Luck [ml] wrote:

> RIPE NCC recognises that and puts M firmly outside policy.
> Where it should remain unless the desire is that every transfer
> application or M notification start with filing suit against
> the NCC.

On the other hand, since RIPE NCC *DOES* allow multiple LIRs per single
legal entity, it would make some sense that the M procedure (the one
outside the policy scope) is limited to only changing the name of the
LIR.
Of course that would mean that all movements of  IP addresses between
LIRs, even those related to mergers, acquisition, restructuring,
consolidation, . would fall under transfer policy. Could someone
detail what would be the problem in this case (except a limited amount
of money of up to 4200 EUR).
Unfortunately this is not where we are, and it doesn't look like it's
where is going.

As for RIPE NCC handling completely on its own the M process this is
exactly what allowed abuse to happen in the first place (and will still
do, even with 2015-01, 2015-04 and 2016-03). And how about a business
split - this doesn't feel like handled by the M procedure.

--
Radu-Adrian FEURDEAN

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

Hi,

 

Feel free to adjust the policy in a new policy proposal, if you think it is 
vital for the future. 

 

As the author of this policy I’m not going to include it in this one. 

 

The transfer statistics isn’t a contest between brokers/facilitators or a place 
for advertising in my opinion. 

 

But don’t let my opinion on that keep you from writing your own policy 
proposal. 

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens 
Ciprian Nica
Verzonden: zondag 23 oktober 2016 16:40
Aan: Erik Bais <eb...@a2b-internet.com>
CC: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis 
Published (RIPE Resource Transfer Policies)

 

Hi,



On Sunday, October 23, 2016, Erik Bais <eb...@a2b-internet.com 
<mailto:eb...@a2b-internet.com> > wrote:

Hi Ciprian,

> On Monday, October 17, 2016, Ciprian Nica <off...@ip-broker.uk <javascript:;> 
> > wrote:
> Hi,

> I think it would be useful to list on the statistics also the broker that 
> facilitated the transfer.

When we made the parts that needed to be published in the transfer statistics, 
that have crossed my mind, but I failed to see what the benefit is for the 
community.

 

The benefit would be that the community can make an idea about whether a 
broker's info can be reliable or not. There are brokers that never brokered a 
transaction.

 

I can understand from your point why you would ask this, but I'm not going to 
take this suggestion in this policy.

I am also a member of this community, besides being your competitor and 
although you wouldn't like people to see that I've brokered the most transfers, 
it's quite possible you would broker more transfers than me in the future. We 
all do our jobs good and my proposal is not just for advertising, I really 
think people would like to see it.

 

 

The transfers are between offering and receiving parties.. the facilitators are 
not a part in this process, except in the financial agreements.
Price is also not mentioned or what the BGP routing vendor is that is used for 
the new prefix..

I don't know about other brokers but I'm not getting my commission just for 
puttig 2 parties at the table. We are part of the process, we assist both 
seller and buyer and we follow every step of the transaction, although we're 
not allowed by NCC to communicate on behalf of our customers.

 

On the topic of the netname : if you want the netname to be changed, you can 
open a ticket with the Hostmaster during the transfer to make that happen. No 
need to put that in policy.



 

I think the idea would be to have this by default and not request it every 
time. I also think that at least the law enforcement agencies (from my past 
cooperation with them in the past) would benefit of this clarification.

 

Ciprian

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

Hi Ciprian,  

 

The goal of the policy have been discussed on the list and in the RIPE meetings 
… so trying to de-rail the process this late in the game, while you were 
present at the other meetings by saying that it isn’t clear … it’s valid 
anymore.. 

 

Because as you may remember that was already addressed when it was brought up 
by Elvis 2 RIPE meetings ago .. and it was addressed at that point. 

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens 
Ciprian Nica
Verzonden: woensdag 19 oktober 2016 19:10
Aan: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] 2015-04 New Version and Impact Analysis 
Published (RIPE Resource Transfer Policies)

 

Regarding this policy I think it clearly states in the beginning: "The goal of 
this proposal is to create a single document with all relevant information 
regarding the transfer of Internet number resources." 

I congratulate Erik for it and I think it is very useful to have a single 
document that would address all situations. But we have to make it clear. Is 
2015-04's purpose just to better organise information or to change policies ? 

If you would have just done what the goal express I think it would have been 
the first policy that would not get only consensus but unanimity.

But when you slip in some changes, then it's a different thing. I agree that 
many things are not very clear and that there are things that can be improved. 
This however should be debated properly and maybe it should be done one step at 
a time through other policy proposals.

To resume, if you would change the policy text to stick to it's goal you'd have 
my +100 (as I see it's getting more popular these days than the classical +1) :)

But since this text brings changes I can only give a -1 for not sticking to the 
goal and for bringing changes that should be treated more careful, not just 
let's do it quickly however we can and we'll figure out on the way. Why not 
make good, permanent changes which are expected by many of the community.

Ciprian

 

 

 

On Wed, Oct 19, 2016 at 1:33 PM, Ciprian Nica <off...@ip-broker.uk 
<mailto:off...@ip-broker.uk> > wrote:

The policy states how the statistics are presented, therefore I think this 
issue should be addressed by the policy.

 

RIPE NCC implements the policies and if we, the RIPE community, want some 
things to be implemented in a certain way then the only way to "ask" it is 
through the policy, otherwise our voices have no value.

 

Regarding the lack of details at point B., that is in my opinion an insult to 
the community, regardless of what the policy is about. We should not accept 
generic statements like that. If nobody bothered to really make an impact 
analysis then just say it.

 

Ciprian



On Wednesday, October 19, 2016, Radu-Adrian FEURDEAN 
<ripe-...@radu-adrian.feurdean.net <mailto:ripe-...@radu-adrian.feurdean.net> > 
wrote:

Hi,

While I do agree with most of the concerns you present there, I'm
wondering if this is not an issue to be discussed in some other working
group (??? services ??? database ???). They don't seem to be related to
the policy itself, but to the way RIPE NCC implements it and reflects
the changes in the database.

Marco ? Chairs ? anybody else ?

--
Radu-Adrian FEURDEAN

On Wed, Oct 19, 2016, at 11:57, Ciprian Nica wrote:

> > Hi,
> >
> > I think it would be useful to list on the statistics also the broker that
> > facilitated the transfer. That might be of interest to the community and I
> > think the NCC should revise the transfer agreement template in order to be
> > able to mention the broker and also to publish it's name on the transfer
> > statistics page. Also the broker should be allowed to communicate with RIPE
> > and pass information on behalf of the customers during the transfer process.
> >
> > There is also a cosmetic thing that I don't know if it needs be mentioned
> > in policy in order to be implemented. The netname of the allocation keeps
> > the original allocation date in it's name which can be confusing although
> > there's the new "created" attribute.
> >
> > For example, the subnet 128.0.52.0/24 <http://128.0.52.0/24>  was 
> > transferred on 14/10/2016 and
> > it was part of an allocation with netname EU-JM-20120914. The new
> > allocation has netname ES-SISTEC-20120914.
> >
> > If the date is no longer relevant in a netname then I think it should be
> > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014
> >
> > Ciprian
> >
> >
> > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt <mschm...@ripe.net 
> > <mailto:mschm...@ripe.net%0b> 
> > <javascript:_e(%7B%7D,'cvml','mschm...@ripe.net');>> wrote:
> >
> >> Dear colleagues,
> >>
>

Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

[Erik Bais - A2B Internet]

This is also my interpertation... 

If you use DHCP of any kind on the network to randomly provide a number for a 
device to connect to the network on a temp lease, it isn't an assignment to the 
letter of the policy. That is also not how the intent of the policy was 
written. 

If you assign a number or subnet to a specific device and that is fixed in the 
configuration, so the next time you connect, you will get the same 
number/subnet, you can see that as an assignment. Especially if that is part of 
a contractual agreement / service / subscription.  Most users/devices are 
looking for a single digit number, not a subnet for their connectivity need. 

The difference between the two is in the duration and the expectation. 
Most roaming wifi users won't be asking for a complete subnet or prefix on 
their laptop or hosting services / third party apps on a wifi link ... 

Most wifi users just want to avoid telco charges while listening to spotify, 
skype or watch youtube/twitch/netflix while in a waiting room .. or do some 
whatsapp while in a wiating room of their healthcare provider.. these are not 
permanent roamers lurkers to avoid RIPE charges or trying to scam their infra 
behind some public provided wifi connection.  
If the specific wifi/network implementation required to use a /64 or smaller 
per connecting device/user, for security reasons for instance, it would still 
be the same if those prefixes would be selected dynamically. 

If the situation is as stated above, the usage should be perfectly within the 
current policy.  

Regards,
Erik Bais


> Op 23 okt. 2016 om 10:11 heeft JORDI PALET MARTINEZ 
> <jordi.pa...@consulintel.es> het volgende geschreven:
> 
> If I’ve a PI for my company … and I offer WiFi for the laptops or phones of 
> my employees, and their families and customers when they come to my office … 
> are those assignments? Clearly they are “others”, not the same organization 
> that got the PI.
> 
> That’s why I think we need to consider that assignment is for infrastructure, 
> not end devices, at least this seems to be my reading of the definition.
> 
> Saludos,
> Jordi
> 
> 
> -Mensaje original-
> De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Tore 
> Anderson <t...@fud.no>
> Responder a: <t...@fud.no>
> Fecha: domingo, 23 de octubre de 2016, 10:06
> Para: Kai 'wusel' Siering <wusel...@uu.org>
> CC: "address-policy-wg@ripe.net Working Group" <address-policy-wg@ripe.net>
> Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI 
> Sub-assignment Clarification)
> 
>Hi Kai,
> 
>* Kai 'wusel' Siering
> 
>> (Which, btw, means there's no difference between PA and PI here.
>> Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent
>> interpretation. Eeks.)
>> 
>> [...]
> 
>>> And 3rd party usage of IPv6 PI addresses is currently not allowed.  
>> 
>> Well, if reading the policy that way, neither is it for non-PI space?
> 
>I think you're right. An assignment is an assignment.
> 
>If the policy currently disallows using assignments (PI or PA) for
>things like wireless networks for guests, then I'd say that 2016-04
>doesn't go far enough.
> 
>Tore 
> 
> 
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
> 
> 
> 
> 

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

Hi,  

I would like to ask you to also read the 4th version of the RIPE Resource 
Transfer Policies and ... provide you feedback (even if that is only a +1 ) on 
the list ...  

This phase ends 26 October 2016 (right in the middle of the RIPE73 meeting in 
Madrid )  ... 

> You can find the full proposal and the impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2015-04 

I'm looking forward to see you all in Madrid.  

Regards,
Erik Bais 

Re: [address-policy-wg] opposition to 2015-04

[Erik Bais]

Thanks Remco. 

We'll take your suggestion in mind before moving to last call. 

Regards,
Erik Bais 

-Oorspronkelijk bericht-
Van: Remco van Mook [mailto:remco.vanm...@gmail.com] 
Verzonden: woensdag 25 mei 2016 9:53
Aan: address-policy-wg@ripe.net
CC: Erik Bais <e...@bais.name>
Onderwerp: opposition to 2015-04


Dear all,

as just mentioned during the address policy session, I'm withdrawing my
objection to 2015-04. While I do think a discussion about policy structure
still needs to be held, I don't think it should hold up this proposal any
longer. This can be fixed after adoption - as long as we're aware.

I do maintain my suggestion to put references in place where chapters about
transfers are removed from other sections of policy.

Kind regards,

Remco

Re: [address-policy-wg] opposition to 2015-04

[Erik Bais]

Hi Elvis,  

 

I oppose to your word choice that we are trying to sneak something in, with
this policy. 

 

As stated during the discussion at the AP, a change to the holdership will
to fall under the same restrictions as the transfers currently, that was
pointed out AND discussed since version 1. 

 

If a company is currently doing a M after that particular company has
become a (new) LIR since 6 months, it means it needs to keep the LIR open
for another 18 months.. 

For any M, the cost for a membership fee of 18 months will not be a deal
breaker for an actual business take-over … unless one is trying to game the
system.  

 

To give an indication,  the damage of a diner with 7 people at the MASH
Penthouse at the RIPE72 venue can be more expensive ...  

 

Thanks for the feedback. 

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
Elvis Daniel Velea
Verzonden: woensdag 25 mei 2016 10:28
Aan: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] opposition to 2015-04

 

Dears,

as mentioned during the policy session, I am opposing to this (version of)
the policy proposal.

While I was sure that I did voice this concern over the mailing list, I can
not find the e-mail now. But I am sure I did voice this concern and the
opposition at previous RIPE Meeting(s).
As long as this proposal adds the 2 years holding period of scarce resources
moved through M (which are 'regulated' through a RIPE NCC procedure) I
will oppose to it. 

I am not going to go into examples wars of why some company would want to
transfer/move/merge/etc.. resources within a 2 years period. While I agree
that transfers should have a holding (or call it anti-flip) period and I
even proposed 2015-01 (which is now part of policy), I do not agree that we
should include M in the same bucket.

If a new version of this policy proposal would be only about transfers of IP
addresses, and not try to sneak in M into the same document, I would
agree with it.

my 2 cents,
elvis

On 5/25/16 9:52 AM, Remco van Mook wrote:

 
Dear all,
 
as just mentioned during the address policy session, I'm withdrawing my
objection to 2015-04. While I do think a discussion about policy structure
still needs to be held, I don't think it should hold up this proposal any
longer. This can be fixed after adoption - as long as we're aware.
 
I do maintain my suggestion to put references in place where chapters about
transfers are removed from other sections of policy.
 
Kind regards,
 
Remco

 

-- 


 <http://v4escrow.net> 

 


Elvis Daniel Velea


Chief Executive Officer


E-mail: el...@v4escrow.net <mailto:el...@v4escrow.net> 
Mobile: +1 (702) 970 0921


Recognised IPv4 Broker/Facilitator in:




 

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Erik Bais]

Riccardo,  

 

> with all respect I don't see a "remarkable success" in current last /8 policy.

The fact that you don’t see it, doesn’t make it less true. 

 

RIPE IPv4 is out … the reservation of space for IXP’s and other uses ( like 
future new entrance ) doesn’t change that.  

 

This is not something we have to explain .. this is not something that we will 
change.  

 

The /22 IPv4 is not for new entrance to assign to customers.. it is to enable 
them to communicate via a CGNAT from a v6 world to a v4 world. 

 

If you don’t use the obtained v4 space for the intended use, it will never be 
enough and you will always feel incorrectly treated … 

 

This policy proposal (with all respect to you and Radu and good intentions) 
needs to stop as it gives people hope on something that isn’t there ...  

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens 
Riccardo Gori
Verzonden: vrijdag 15 april 2016 7:49
Aan: address-policy-wg@ripe.net; remco.vanm...@gmail.com
Onderwerp: Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 
May 2016 (Last /8 Allocation Criteria Revision)

 

Good Morning Remco, Good Morning List,

with all respect I don't see a "remarkable success" in current last /8 policy.
We are dealing with the same amount of space as September 2012 that in the 
meanwhile has been abused in several ways and there are really no incentives to 
IPv6 adoption.

There was only one requirement to obtain one IPv4  /22: request and obtain at 
least from /32 IPv6 to a maximum of /29 IPv6.
Am I wrong or this requirement has been removed?!?! Please explain that to a 
new entrant...
What does it mean? "we are running out. here your crumbs, sorry we have no 
solution" ?!?

If for you last /8 policy is a success to me IPv6 incentives policies looks 
absent. We completly failed from this point of view.
If you look at this where IPv4 exhaustion took place IPv6 is strongly gowing: 
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
 
<https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption=per-country-ipv6-adoption>
 =per-country-ipv6-adoption

I think this policy is not for faster exhaustion but for "farier exhaustion" 
and is offering a path to go over IPv4 while still needing it to grow.

kind regards
Riccardo

Il 15/04/2016 00:50, remco van mook ha scritto:

Dear colleagues, 

 

I'd like to reiterate my objection to this proposal. Anyone who thinks another 
block of 1,000 addresses is going to help them float their business is in my 
opinion delusional (because the next step would be an extra 2,000, then 4,000, 
..). The problem is not that you're getting a /22 - the problem is that we're 
out of space, never to come back. I also object to the notion that new entrants 
who joined the game recently have any more entitlement than new entrants 2 
years from now. 

 

The final /8 policy in the RIPE region has been, in my opinion, a remarkable 
success because there's actually still space left to haggle about. What does 
need fixing is the fact that there are a few obvious loopholes that are now 
being used to contravene the intention of the policy, and are being used as a 
rationale for this proposal. 

 

Kind regards,

 

Remco

(no hats)

 

On Thu, Apr 14, 2016 at 2:43 PM Marco Schmidt <mschm...@ripe.net 
<mailto:mschm...@ripe.net> > wrote:

Dear colleagues,

The Discussion Period for the policy proposal 2015-05, "Last /8
Allocation Criteria Revision" has been extended until 13 May 2016.

The goal of this proposal is to allow LIRs to request an additional /22
IPv4 allocation from the RIPE NCC every 18 months.

The text of the proposal has been revised based on mailing list feedback
and we have published a new version (2.0) today. As a result, a new
Discussion Phase has started for the proposal.

Some of the differences from version 1.0 include:
- Additional /22 IPv4 allocations can be only provided from address
space outside 185/8
- Only LIRs with less than a /20 in total are eligible to receive
additional allocations
- LIRs must document their IPv6 deployment as part of the request

You can find the full proposal at:

https://www.ripe.net/participate/policies/proposals/2015-05

We encourage you to review this policy proposal and send your comments
to <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net> >.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC

 

-- 

Ing. Riccardo Gori
e-mail: rg...@wirem.net <mailto:rg...@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 an

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Erik Bais]

Hi Radu and Ricardo (& AP community members),  

I looked at the policy text and also checked if there would  be an option to 
just ‘hand out’ an additional /22 to all current LIR’s.. 
If we currently have about 12.000 members .. and hand out additional /22’s to 
each of them, it will cost 12 milj addresses ( more or less..)   ( as it would 
be more fair than discriminating on current size and age of an LIR … ) 

The current pool is about 16.4 milj addresses left.. and in the last 3 years, 
they have handed out 9 milj. addresses.  
As there probably won’t come more than 32.000 addresses back from IANA .. and 
not much more space to be expected from de-registration of PI space.. The pool 
won’t grow much more than it is currently … 

So handing out 12 milj. addresses in a single gift.. without the hard 
requirement to not allow final /8 policy received IP space to be transferred, 
will most likely only increase the run-out of the IP space and not fix 
anything.. 

The real issue is, this policy change won’t fix anything at all … it will make 
things impossible for the near future. 

The replenishment from IANA will stop, so the actual pool will go down. With 
the actual rate of 9 milj per 3 years.. that means that at the current rate, 
the current pool will last for about 5.3 years.  ( looking at an avg of 3 milj 
per year. ) 

If we hand out 12 milj. Addresses of the 16.4 milj. We have 4.4 milj. addresses 
left.. meaning that we will have a full run-out within 18 months. 

These are the numbers that we are currently looking at. They might change a 
bit, off by a couple months perhaps.. but the difference is an issue of fully 
running out within 18 months or 5.3 years. 

So as we need more time for companies to fully move over to IPv6 .. and we need 
to be able to hand out a /22 IPv4 for CGNAT for new entrance to the market in 
order to be able to compete..  ( As that was the actual reason to implement the 
last /8 policy..) 

So taking all this in mind, this policy change is a bad decision imho.  

Yes I know that you are trying to discriminate in the policy by saying, no 
transfers done in the past, not more than 4k IPv4 etc etc.. but that is just 
semantics.. it won’t fix the overall policy you are trying to implement. 

So perhaps a long answer to say that I won't support it.  

Regards,
Erik Bais

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

Hi, 

As we are almost at the end of the current phase (after today. ) I would
like to ask the AP-WG Chairs if they agree to add at least 2 weeks
additional time to the discussion time to make sure that all pros and cons
are discussed. 

Currently we are looking at an objection from Remco v. Mook ( with no hats )
that there might be some future issue on similar policy changes that might
provide a policy issue as the previous version of the draft had. 

While I understand his line of thinking, I don’t think that we give the
legal team enough credit to spot future issues similar as the one in the
past draft.. I like to think there is a learning curve … 
And I will also invite Remco to keep reading future policy proposals from
myself and others to make sure that there aren’t any un-intentional issues
that might be introduced in future policy. 

Having said that, he also stated that there is currently nothing wrong with
the version at the table.  

On the final remark of Remco, if we need to see if we need to review the
actual current structure of the policies.. I agree and I would like to have
a good discussion on that. 
But that is to me a discussion outside the scope of this policy proposal. 

On the suggestion of Remco and second by Tore (also with no hats), Tore
wrote :  

> Remco suggested adding references to the new policy document in lieu of
> the removed sections in ripe-638, ripe-649, and ripe-655. I would not
> object to that.

This was later also agreed to by a (+1) from Sascha Luck (also without any
hats), Guy Chilton (Again .. no hats..) 

And if we agree that the blunt removal of the transfer text in the current
affected policies and having a single transfer document isn't clear enough,
I'm not against adding a reference to the new proposed transfer policy
document. 

The only response opposing to the current structure is Peter Koch.  

Peter stated that he is :  
> "Generally I'm always nervous when policy/legislation is
> "streamlined" by "just editorial changes", and also recent experience here
> would suggest extreme caution. Things get complicated when they are
> taken out of their respective context (tempus and locus)."

And I agree partially with him. Doing things with caution is something that
we are all part of here.. And I think that we have proven that we are very
careful on making certain changes. 
The biggest change here is indeed the editorial one, however that is to
avoid in doing large changes while also doing editorial changes .. it was
clear to everyone that the editorial changes was desired by the majority of
the community when the initial changes / transfer policy text was written
into the policies.. and this was the 'clean-up and stream-line action.' 

> At least, the work is incomplete as proposed now, simply because the
> affected policies will have to be re-published with a new number and
timestamp,
> so the (outdated) references will have to be adjusted (this includes
> evaluation and thus is more than a simple editorial change) and now
> obsolete text ought to be dealt with accordingly. The necessity to
> add normative references to a new omnibus document has already been
mentioned. 

I'm reading this that Peter could live with the suggestion done by Remco for
the references.. if we are going that route.. 
And from what I've heard, a change like Remco suggested, would not require a
complete rehash into the PDP or redoing any phases again. 

I hope that with the current summary I have given a quick view of where I
think we are ... And if Sander and Gert don't mind, I would like to ask to
extend the discussion period for 2 weeks to allow for additional comments on
this email and perhaps other insights. 

Regards,
Erik Bais
Author of 2015-04 ... aka ...  The mad hatter ... 

Re: [address-policy-wg] Working group chair rotation 2

[Erik Bais]

Hi Sander,  

You have my vote and support as AP-WG Chair :)

+1 

Erik Bais

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens 
Sander Steffann
Verzonden: maandag 8 februari 2016 21:24
Aan: RIPE Address Policy Working Group <address-policy-wg@ripe.net>
Onderwerp: [address-policy-wg] Working group chair rotation 2

Hello working group,

A year has passed since we implemented our working group chair rotation 
mechanism, so it is time for one of the APWG chairs to offer his place in case 
the working group would like to see a change of chair. This time it is my turn 
to step down, and I will do so in the APWG session at RIPE 72 in Copenhagen. So 
this is the time for candidates to volunteer and make themselves known here on 
the list! To be considered candidates must make themselves know before the 
start of RIPE 72.

So, let me start by volunteering again :)  I would love to serve this working 
group for another term as one of its chairs. A short introduction for those who 
don't know me:

* age 39
* shoe size 46, usually not wearing sandals though
* university degree in computer science, master on distributed systems for 
supporting business processes

* self-employed IPv6 consultant, customers include ISPs and enterprises
* run a small LISP based ISP on AS57771

* attending RIPE meetings since RIPE 49 in Manchester, 2004
  (missed none)

* address policy working group co-chair since RIPE 54 in Tallinn, 2007
  (https://www.ripe.net/participate/ripe/wg/ap/minutes/minutes-from-ripe-54)

And now for the future plans

* guide the working group in making good policies

* maintain a good standard of communication on the mailing list
* while also giving space to people with different opinions

* aiming to arrive at simple and fair policies for the benefit of the whole 
community
* and explicitly not having a personal agenda while doing so

I essentially want to use what I have learned in the last 9 years and continue 
to guide the working group in always-improving ways.

Cheers,
Sander Steffann

(and thanks to Gert for providing a template to use when writing messages like 
this: 
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-April/009659.html)
  ;)

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

[Erik Bais]

Hi Sascha & Daniel,  

The reason for using the term "scares resource", is because we can't/shouldn't 
use the term "depleted'.. 

If one would use the term "Depleted' the NCC might say that the pool isn't 
completely empty yet.. so it isn't depleted yet.. 
Which would mean that there is, until it is really empty, no transfer 
restriction.  ( that is a different discussion.. ) 

The community suggested in the last 2 RIPE meetings that the transfer 
restrictions should not apply for 32 bits ASN and IPv6.. 

The policy proposal states :  

> 2.2 Transfer Restrictions
> Scarce resources, which are understood as those resources that are allocated 
> or assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit 
> ASNs), cannot be transferred for 24 months from the date the resource 
> was received by the resource holder.

The Impact Analyses states : 

> Holding Period for Scarce Resources
> The RIPE NCC understands “scarce resources” to include IPv4 PA, IPv4 PI and 
> 16-bit AS Numbers. If the community declares other resources to be scarce, 
> the list of resources for which the holding period will apply will be 
> adjusted accordingly.

The policy proposal dictates what a scares resource is (after community 
discussion in the last 2 RIPE meetings) and it is the policy that is leading 
here.. 

The Impact Analyses of the RIPE NCC, is what the RIPE NCC thinks what is 
written and intended by the policy.. and they are re-hashing what we did and 
how additional 'future' scares resources might need to be defined in the 
future. 

If the community declares other resources to be scarce, the list of resources 
for which the holding period will apply will be adjusted accordingly.. 
And as that is a policy change, it should go through the PDP process.  

I think that what you are asking is what is already in the proposal and what 
you are looking for in a procedure, is already what is the used process ... 

If not, what are we missing ?  

Regards,
Erik Bais 

[address-policy-wg] Update on the policy proposal :

[Erik Bais]

Hi,  

 

As discussed in the AP-WG meeting in Bucharest, we needed to make some
changes in the policy text. 

https://www.ripe.net/participate/policies/proposals/2015-04 

 

The new proposal version will have the following text:  

 

2.0 Transfers within the RIPE NCC Service Region


Any legitimate resource holder is allowed to transfer complete or partial
blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that
were previously allocated or assigned to them by the RIPE NCC or otherwise
through the Regional Internet Registry (RIR) system. Resources are excluded
from transfers when RIPE Policies mandate their return to the RIPE NCC.  

 

Allocated resources may only be transferred to another RIPE NCC member.
Provider independent resources may be transferred to:

*   A RIPE NCC member; or
*   An entity that has a contractual relationship with a RIPE NCC member

in accordance with the RIPE Policy, “Contractual Requirements for Provider
Independent Resource Holders in the RIPE NCC Service Region”.

 

I would like to ask the community to review the text and provide feedback on
it.   


We will upload the new version soon. 

 

Regards,

Erik Bais 

 

Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments)

[Erik Bais]

Hi Peter, 

> Thinking out loud: We could also apply the "last /8 policy" to this.
> After it goes into effect, each LIR can request one and only one 16b ASN.
> 32b ASNs are allocated as normal (with the question asked, but not
> evalutated).

I think that we are already beyond the point of handing out 1* 16b ASn to each 
LIR and there isn't that much left in the free pool I'm guessing .. ( that is 
my gut feeling .. ) 

But the NCC should be able to answer the total number in the RIPE pool ... 

Erik Bais 

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Erik Bais]

> first, i think all LIRs with POCs whose family name begins with B should get 
> a /16

I fully agree on that.. 

Erik

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens Randy 
Bush
Verzonden: dinsdag 20 oktober 2015 16:27
Aan: James Blessing 
CC: Address Policy Working Group 
Onderwerp: Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of 
Last /8 Allocation Criteria)

>> https://www.ripe.net/participate/policies/proposals/2015-05
> Can we limit it this to a /X to see what the impact is before throwing
> the entire remaining v4 space under a bus?

first, i think all LIRs with POCs whose family name begins with B should
get a /16

randy

[address-policy-wg] 2015-05

[Erik Bais]

I strongly disagree with the idea behind this policy. 

One of the reasons is that the current policy allows for future new entrance to 
have an option to register for a /22 IPv4 to be able to implement their own 
infrastructure and be able to use CGNAT... 

If we allowing this policy to be accepted, the last bits of the current pool 
will be handed out and it will deprive future (hosting)companies of any chance 
into the market. 
Although I seriously like the suggestion of Randy to allocate a /16 to me, 
based on the letter B in my family name, in order to just be done with it the 
final scraps, it doesn't do any justice to what is currently in policy. 

There is always a reason to be found why someone could argue that $member with 
certain size .. will require additional (free) IPv4 ... 
But unless we are going to discriminate about 85% of the current members .. or 
100% of the future members ... This is not going to be a fair solution moving 
forward on this path . 

It isn't difficult to come up with a policy that will distribute the remaining 
IPv4 within a month ... 

 Who cares about fair distribution anyway ..   

The difficult part is to plan ahead ... see beyond our own direct need and hope 
that we will not come to a point where we will hand out the IPv4. 
It is the goal of this AP-WG to come up with sustainable policies for our 
service region ... I fail to see this change in policy meet any of the above 
stated points.. 

I think we should stop this policy and this line of thinking asap. 

Regards,
Erik Bais 

Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"

[Erik Bais]

Thanks for the update Nikolas. 

 

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
Nikolas Pediaditis
Verzonden: donderdag 1 oktober 2015 11:16
Aan: Erik Bais - A2B Internet <eb...@a2b-internet.com>
CC: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] Policy Proposal Implemented: 2014-05,
"Policy for Inter-RIR Transfers of Internet Resources"

 

Hi Erik,

The moratorium that the APNIC EC had set for inter-RIR transfers with the
RIPE NCC has been officially lifted as of early September and it was
announced during APNIC 40.

The transcript of the APNIC 40 AMM session is available at:
https://conference.apnic.net/data/40/10-Sept-AMM.txt

Here is the quotation with regard to this matter:

"Inter-RIR transfer policy: it was one of the items which the Executive
Council decided previously. We had a moratorium for the inter-RIR transfer
with RIPE NCC, but at this time in the Executive Council meeting on Monday,
we decided to resolve to lift -- that means discontinue -- the temporary
moratorium on the inter-RIR transfers with RIPE NCC. That is the reaction
that RIPE NCC recently set the new inter-RIR transfer policy to require the
recipient of the transfer from the other RIR region which has the
demonstrated need policy. So that helped us to lift this moratorium. So now
you can transfer the IPv4 address, if you need it, with someone in the RIPE
NCC region."

There is also the video version available (at 58:38):
https://conference.apnic.net/40/program#sessions/amm

Therefore inter-RIR transfers of IPv4 and ASNs are possible between resource
holders in the APNIC and RIPE regions.  Both RIRs will be cooperating in
accordance with their policies.


Kind regards,

Nikolas Pediaditis
RIPE NCC Registration Services 

 





On 30 Sep 2015, at 23:50, Erik Bais - A2B Internet <eb...@a2b-internet.com
<mailto:eb...@a2b-internet.com> > wrote:

I had to look it up in the Apricot APNIC archive of 2015, but the actual bit
that I am referring to is the following :

http://youtu.be/2iKK_8iJU6E  where Andrea Chima from RIPE NCC is explaining
the inter-RIR transfer policy on stage ( around 1:17 ) ... And Paul Wilson
from APNIC is starting at 1:24 upto 1:35 at the mic on the topic. 

Regards,
Erik Bais

Op 30 sep. 2015 om 21:05 heeft Erik Bais - A2B Internet
<eb...@a2b-internet.com <mailto:eb...@a2b-internet.com> > het volgende
geschreven:




Hi Nikolas,

Thank you for the work and this update. 

Could you or Marco perhaps provide a quick update on what the current status
is in the inter-rir transfer status between APNIC and RIPE region, after the
APNIC exec-board announced that it would hold transfers until further notice
earlier this year ... 

Regards,
Erik Bais

Verstuurd vanaf mijn iPad




Op 30 sep. 2015 om 16:51 heeft Nikolas Pediaditis
<nikolas.pediadi...@ripe.net <mailto:nikolas.pediadi...@ripe.net> > het
volgende geschreven:

 

Dear colleagues,

 

We are pleased to announce that we have implemented the policy proposal
2014-05, "Policy for Inter-RIR Transfers of Internet Resources".

 

In accordance with the new policy, Internet number resources can be
transferred between resource holders in the RIPE NCC service region and
resource holders in the service regions of other Regional Internet
Registries (RIRs).

 

Inter-RIR transfers are possible between RIRs with compatible policies.
Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR
transfers with the RIPE NCC:

 

- IPv4 addresses can be transferred to/from the ARIN service region

- IPv4 addresses and AS Numbers can be transferred to/from the APNIC service
region

 

The main web page on inter-RIR transfers with the supporting documentation
and all related information to get you started can be found at:

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran
sfers/inter-rir-transfers

 

The archived policy proposal can be found at:

https://www.ripe.net/participate/policies/proposals/2014-05

 

The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources",
is available at: 

https://www.ripe.net/publications/docs/ripe-644

 

 

Kind regards,

 

Nikolas Pediaditis

RIPE NCC Registration Services

 

 

 

Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"

[Erik Bais - A2B Internet]

Hi Nikolas,

Thank you for the work and this update. 

Could you or Marco perhaps provide a quick update on what the current status is 
in the inter-rir transfer status between APNIC and RIPE region, after the APNIC 
exec-board announced that it would hold transfers until further notice earlier 
this year ... 

Regards,
Erik Bais

Verstuurd vanaf mijn iPad

> Op 30 sep. 2015 om 16:51 heeft Nikolas Pediaditis 
> <nikolas.pediadi...@ripe.net> het volgende geschreven:
> 
> Dear colleagues,
> 
> We are pleased to announce that we have implemented the policy proposal 
> 2014-05, "Policy for Inter-RIR Transfers of Internet Resources".
> 
> In accordance with the new policy, Internet number resources can be 
> transferred between resource holders in the RIPE NCC service region and 
> resource holders in the service regions of other Regional Internet Registries 
> (RIRs).
> 
> Inter-RIR transfers are possible between RIRs with compatible policies. 
> Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR 
> transfers with the RIPE NCC:
> 
> - IPv4 addresses can be transferred to/from the ARIN service region
> - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service 
> region
> 
> The main web page on inter-RIR transfers with the supporting documentation 
> and all related information to get you started can be found at:
> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/inter-rir-transfers
> 
> The archived policy proposal can be found at:
> https://www.ripe.net/participate/policies/proposals/2014-05
> 
> The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is 
> available at: 
> https://www.ripe.net/publications/docs/ripe-644
> 
> 
> Kind regards,
> 
> Nikolas Pediaditis
> RIPE NCC Registration Services
> 

Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"

[Erik Bais - A2B Internet]

I had to look it up in the Apricot APNIC archive of 2015, but the actual bit 
that I am referring to is the following :

http://youtu.be/2iKK_8iJU6E  where Andrea Chima from RIPE NCC is explaining the 
inter-RIR transfer policy on stage ( around 1:17 ) ... And Paul Wilson from 
APNIC is starting at 1:24 upto 1:35 at the mic on the topic. 

Regards,
Erik Bais

> Op 30 sep. 2015 om 21:05 heeft Erik Bais - A2B Internet 
> <eb...@a2b-internet.com> het volgende geschreven:
> 
> Hi Nikolas,
> 
> Thank you for the work and this update. 
> 
> Could you or Marco perhaps provide a quick update on what the current status 
> is in the inter-rir transfer status between APNIC and RIPE region, after the 
> APNIC exec-board announced that it would hold transfers until further notice 
> earlier this year ... 
> 
> Regards,
> Erik Bais
> 
> Verstuurd vanaf mijn iPad
> 
>> Op 30 sep. 2015 om 16:51 heeft Nikolas Pediaditis 
>> <nikolas.pediadi...@ripe.net> het volgende geschreven:
>> 
>> Dear colleagues,
>> 
>> We are pleased to announce that we have implemented the policy proposal 
>> 2014-05, "Policy for Inter-RIR Transfers of Internet Resources".
>> 
>> In accordance with the new policy, Internet number resources can be 
>> transferred between resource holders in the RIPE NCC service region and 
>> resource holders in the service regions of other Regional Internet 
>> Registries (RIRs).
>> 
>> Inter-RIR transfers are possible between RIRs with compatible policies. 
>> Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR 
>> transfers with the RIPE NCC:
>> 
>> - IPv4 addresses can be transferred to/from the ARIN service region
>> - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service 
>> region
>> 
>> The main web page on inter-RIR transfers with the supporting documentation 
>> and all related information to get you started can be found at:
>> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/inter-rir-transfers
>> 
>> The archived policy proposal can be found at:
>> https://www.ripe.net/participate/policies/proposals/2014-05
>> 
>> The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", 
>> is available at: 
>> https://www.ripe.net/publications/docs/ripe-644
>> 
>> 
>> Kind regards,
>> 
>> Nikolas Pediaditis
>> RIPE NCC Registration Services
> 

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Erik Bais]

 situation to not approve transfers,  why publish the number 
that is not going to change ? 
If documents for transfers are not approved, they are not denied transferred, 
the tickets will not be processed because the paperwork isn't correct.  

Btw.. did you see that nr. 4.0 will also implement if a new field in the 
transfer statistics ... 

- Whether it was a transfer or merger/acquisition

As it will also make a slight change in the transfer restrictions .. as it 
closes the 'loophole' to have transfers now also restricted after M's and not 
only after allocation by RIPE NCC or transfers. 

The point 2.2 wording ( cannot be transferred by the resource holder within 24 
months from the date the resource was received. ) is the cause of that.. and as 
such the statistics should reflect that info. 
Hence that update there.. 

Regards,
Erik Bais 

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)

[Erik Bais]

Hi James, 

> Couple of questions/comments...

> From 1.0

> Shouldn't the scope be explicit as to what is/isn't included

It states what is included ... are you missing anything specific ? 

> From 2.1

> "Transfers can be on a permanent or non-permanent basis."

> How is this going to be recorded and managed within the context of
> reflecting it being a non-permanent transfer?

That is taken directly from the current policy text and it is managed by the 
RIPE NCC.  I must admit that I haven't seen non-permanent transfers myself 
(yet), so I would have to ask the NCC on how they are exposing that if at all 
publicly. 
The text itself isn't different to what there is already there.  

> From 2.2

> "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)"

> Rather than "such as" this needs to be a definitive list of what is
> classed as a restricted resource

The part between the round brackets was put there as the current examples to 
what are the almost depleted resources.
As IPv4 isn't completely depleted yet ( due to the final /8 policy ) and 
neither are 16-bit ASN's.. 
That implies that other resources like IPv6 or 32-bit ASN's are not restrictive 
by a 24 month transfer restriction as there is no logical requirement that we 
could find to put it in the policy.   

> From 3.1

> Again a list of conditions or references to policies that impose restrictions 
> needed

You mean other than what is currently in the proposed text ? Currently all 
resources that we have are possible to be transferred ... 

> From 4.0

> M process is mentioned, should there be other references to this?
> Especially as M (as I understand it) allows 2.2 to be overridden

An M is not a transfer ... a M is a change in a business where one company 
or service offering with assets/resources are going from one company to another 
company. 
That can be in the same company ( Look at companies like IBM or Philips or GE 
for instance that are splitting off services to a new business unit .. or 
buying competing companies and incorporating that into their own business / 
service..)  

Sometimes there are stocks being sold, however there are more ways of M's 
within today's business. Typical the goal of M's are not the (number) 
resources, but other services/assets/added value that would create the value 
... 
And with a transfer, the goal is getting or selling the specified resource. 
Also the M is a business (operational) process.. and transfers are a policy. 

> General

> - As this is about transfers should this also cover returning
> resources to ripe NCC so all types of transfers be included 

The text is pretty clear imho on what it covers.. any number resource to and 
from the RIPE NCC service region ... 
Both TO and FROM the RIPE region ... 

> - broadly support the unification of transfer policy into a single
> document, just things bits are missing or muddy

I hope that we made a good start here :)

Erik Bais 

Re: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy

[Erik Bais]

I fully agree with David on this. 

The initial intent of the policy was to remove the multi-homing requirement 
when requesting for an AS number. full stop 

Any stop that the NCC will use in their automated process of provisioning to 
detect that someone is abusing the system and stop further provisioning is all 
up to the NCC to implement.  
For all I care, they stop their automated provisioning after assigning 50 AS's 
within the last 12 months to $LIR.. And do additional requests manually ... 

It should not be at the APWG to dictate how they should implement this in 
software or policy imho.  

The AGM showed that the membership decided there will be no charge for ASn's 
for the near future.  

For a simple policy change like this, it is amazing how much we are looking at 
eachother in order to fluff this up ... 
If someone has a specific requirement for a 16 bit AS number ( yes they are on 
short supply atm .. ) feel free to ask the justification for it, or to ask if 
they can deal with a 32 bit ASn... 
If they can't and they really need a 16 Bit AS and the NCC doesn't have any 
anymore .. 

There is a transfer policy for AS numbers ... but let's not put more clutter in 
the policy than strictly required. 

Erik Bais 

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Erik Bais]

* Marco Schmidt mschm...@ripe.net

 The draft document for the proposal described in 2015-01, Alignment of 
 Transfer 
 Requirements for IPv4 Allocations has been published. 

Support +1

Erik Bais

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published

[Erik Bais]

Hi Arash,

 This policy proposal will not prevent organisations from setting up one or
 more LIRs and hoarding the /22s. It will only add a two-year restriction
 before a /22 from the last /8 can be transferred.

The 24 month period will increase the cost of the 'hoarding' ... which makes it 
a lot less attractive to do it..  
This policy change will make it a lot more expensive for the current 'abusers 
of the intent of the policy' to see this as a viable business model.. 

Regards,
Erik Bais 

Re: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)

[Erik Bais - A2B Internet]

Hi Jens,

As we are talking about AS numbers and implicit about BGP .. Lets take the 
following approach ... 

Ask the NCC to use a max-prefix kind of warning system in the hand-out / 
provisioning software ..

A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking 
questions on what the LIR is doing .. A full stop handing out at the 100% of 
the $arbitrary-number ... And the NCC will have to manually increase the number 
by another $amount. Same as every ISP does on an Internet Exchange with $peer 
that trips their max-prefix number  

That can be implemented in the backend .. And the majority of the LIR's will 
never trip the max-resource level .. But the ones that do .. Can be directed to 
the IPRA's and provide additional insight on what the hell they think they are 
doing ... And if they are not providing a sufficient use case that satisfies 
the IPRA, their request to increase the $arbitraty-number won't be increased 
... So they can't request additional resources. 

This suggested deployment setup doesn't need to be put in stone in the policy, 
but as a request to the NCC in the introduction or rationale .. To keep the 
policy text clear and the NCC can reply to it in their IA ..

Just my 2 cents ... 

Erik Bais. ( now a bit more awake that this morning ) ... 

 Op 16 mei 2015 om 12:26 heeft Opteamax GmbH r...@opteamax.de het volgende 
 geschreven:
 
 Erik and all,
 
 I think your idea to exclude 16Bit ASN from the proposal brings us much
 closer to consensus.
 
 Nevertheless I think we should start discussing about how to enhance
 garbage collection, but this should IMHO not be part of discussion on
 _this_ proposal.
 
 BR Jens
 
 On 16.05.2015 09:11, Erik Bais - A2B Internet wrote:
 Hi Gert,
 
 There are a couple things that I keep reading and hearing in the discussion 
 here.. 
 
 Run-out of 16 bit as's and garbage collection.. 
 
 May I suggest to Job to look into the following to see if that would fit his 
 plan moving forward and is in line with what the community thinks is 
 acceptable. ( personally I don't have a specific preferrence ) 
 
 Exclude the 16 bit AS's from the removal of the multihoming requirement. ( 
 so it stays as it is currently ) and ask the NCC to keep a close look on the 
 number of requested AS's per entity to avoid stockpiling and give them the 
 silent 'right' to question and stop abuse of what we are trying to achieve 
 here.  Also the NCC should include resource garbage collection in the ARC's 
 and if that is not enough, report that to the community during the ripe 
 meeting ncc update. 
 
 The above mentioned suggestion could bring us closer to consensus.. It is 
 not something I have a strong feeling about. It is a suggestion that one can 
 look at. 
 
 Personally I would go for version 1 of the proposal, no limitations and in 
 addition ask the ncc to look close to any abusive behaviour. 
 
 Regards,
 Erik Bais
 
 Verstuurd vanaf mijn iPad
 
 Op 15 mei 2015 om 14:34 heeft Gert Doering g...@space.net het volgende 
 geschreven:
 
 Dear AP WG,
 
 On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote:
 The Review Period for the proposal 2014-03, Remove Multihoming 
 Requirement for 
 AS Number Assignments has been extended until 19 May 2015.
 
 So - we extended this to wait for the AGM decision on charging for AS
 numbers.  The AGM decided, and the clear majority decide to not introduce
 annual charges for AS numbers - my life would be easier otherwise, but
 this is what was decided, so respect it and see how we can achive our
 goals here :-)
 
 Feedback for this proposal so far was, if I simplify a bit
 
 - we want to take care not to exhaust 16bit-ASNs
 - there is unlimited number of 32bit ASNs
   (but there *also* was feedback about N. from I. could go out and
   register all 4 billion 32bit ASNs, and exhaust the system... now what?)
 
 - we might want a garbage collection / reclamation mechanism
 
 - the current policy text is too complicate, arbitrary numbers are bad
 
 but there *is* quite a bit of support for the generic idea of loosen up
 the rules for 32bit ASNs, as the multihoming requirement is often hard
 or impossible to demonstrate or check.
 
 So, what should we (or, more precise, the proposers) do to get there?
 
 Nick, I'm actually looking at you since you threw the most sand into the
 gears here...  some specific suggestions how you'd tackle this would 
 be welcome.
 
 (Technically, I see no other way than to change text and do another round
 of IA/review phase with the feedback we've received until now - if, based
 on the new background from AGM, everybody who has objected so far is now
 accepting this at it stands to go forward - please say so!)
 
 Gert Doering
   -- APWG chair
 -- 
 have you enabled IPv6 on something today...?
 
 SpaceNet AGVorstand: Sebastian v. Bomhard
 Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
 D-80807 Muenchen   HRB

Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations

[Erik Bais - A2B Internet]

Hi Petr,

Besides the fact that all discussion and input on the named policy is currently 
out-side the discusssion phase.. So the input can't be taken into account ... 

Could you provide insight in which universe the RIPE NCC is still allocating 
/20's ? 

I am aware that the IPRA's are trying to aggregate connected prefixes if 
possible .. Is that what you are trying to do in getting a /20 ? ... 
Open 4 or more lir's and issue the tickets for the IPv4 /22's at the same time 
in hope to get them allocated together from the same block ... So you can 
aggregate them after a transfer or MA ? 

What you are saying here  IS the reason why the community is looking at 
this policy proposal ... If you need more than a /22 the only way is to get 
this from the market ... 

I wonder why people still think that they can or will get IPv4 from the Ripe 
NCC ... 

Erik Bais

 Op 25 apr. 2015 om 18:13 heeft Petr Umelov p...@fast-telecom.net het 
 volgende geschreven:
 
 Hi everybody.
 
 Let me tell some words about current proposal.
 
 Many providers (among them is our company) need to get (e.g.) /20 subnet (not 
 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next 
 variants:
 1. /20
 2. 2 x /21 from different subnets
 3. /22, /21, /22
 
 There is only one chance to get /20 100% - make request for 7 x /22 (if the 
 tickets will be processed together). But in this case we will have unwanted 3 
 x /22 which we can transfer to other LIRs to minimize our expenses.
 And also we can get different separate 4 x /22 (the worst case) and we have 
 to transfer such blocks and make new request.
 
 If this proposal will be agreed, many providers (new and old) will have 
 material losses. So I can't support this proposal.
 
 -- 
 Kind regards,
 Techincal Director FastTelecom
 Petr Umelov
 

Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations

[Erik Bais]

Hi Gabriel, 

 

I agree with you that it might satisfy a specific need for a company at a
certain time to open a new LIR.. 

 

I’ve seen LIR’s request for a /22 that didn’t even knew they could still get
a free /22 from the RIPE NCC.  . . . 

 

The goal of this proposal is to stop the abuse of opening a new LIR,
transferring the /22 for profit to another LIR and close the LIR. 

As it is against the original intent of the final /8 last /22 procedure
(https://www.ripe.net/publications/docs/ripe-643#51 ) 

 

And specifically :  

 

Point 3 :  The LIR must confirm it will make assignment(s) from the
allocation.

 

The intention of the current policy and why it was made as it was in the
past, is to give EVERY LIR 1 additional /22 … and also have enough for new
entries in the market ( looking at the new sign-ups of LIR typically in the
market, if you look at how that number grew over the last couple years.. )
for at least 5 to 6 years …  

 

Point 3 doesn’t say .. The LIR must confirm it will make assignment(s) from
the allocation or transfer parts or the complete allocation for profit to
another LIR.  

 

This policy text was never intended to have new LIR’s being setup and closed
just to get cheap IP’s … And I’m pretty sure that if that was foreseen at
the time, that the respective author would have closed that gap at the time
… 

As that is in the past … and this is currently being abused .. It is time to
fix this and close this gap. 

 

Regards,

Erik Bais 

 

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
Infinity Telecom SRL
Verzonden: donderdag 23 april 2015 13:41
Aan: Erik Bais; address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] Transfer Requirements for IPv4
Allocations

 

Hello Erik,


Why someone will come to me to get new IPs,  when they can open a LIR by
them self ? Without extra cost ? 

I think everyone that open a LIR right now its because they dont have any
chance to BUY from sellers.. 


Thank you.


-- 
Cu stima,
Gabriel Voitis | Sales Manager
 mailto:voi...@infinitytelecom.ro voi...@infinitytelecom.ro

INFINITY TELECOM SRL  |  Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2
Mobil: +40 0725 677 477  |  Tel: +40 021 7808805  |  Fax: +40 021 7808806
 mailto:cont...@infinitytelecom.ro cont...@infinitytelecom.ro

Re: [address-policy-wg] Working group chair rotation 1

[Erik Bais]

Hi Gert, 

Are you going to formally introduce yourself to the mailing list for those
that might not know who you are and what your shoe size is ?  

And can we expect the usual election talks / promises on where we are going
in the next period with you at the helm ... 

Personally I would like to know what we are getting ourselves into ... ;) 

Regards,
Erik 

Re: [address-policy-wg] 2014-13 declaration of consensus (Allow AS Number Transfers)

[Erik Bais]

Thanks for the summary Gert. 

Regards,
Erik Bais ( proposer of the policy ) 

-Oorspronkelijk bericht-
Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens
Gert Doering
Verzonden: donderdag 5 februari 2015 21:12
Aan: address-policy-wg@ripe.net
Onderwerp: Re: [address-policy-wg] 2014-13 declaration of consensus (Allow
AS Number Transfers)

Dear AP WG,

the review phase for 2014-13 has ended.  

Given the number of comments in review phase, I can say we have quite 
strong support for the proposal.

There was one discussion item about the requirement to return unused
numbers to the NCC, which is changed from a MUST to a should - this
was answered by the proposer, and no further discussion happend.  So I
assume this is addressed.

So, I declare we have consensus, and move 2014-13 to Last Call.  Marco 
will send the formal announcement for that in the next days.

For reference, a list of people that voiced support or opposition (or 
something else) in the review phase is appended below.  This is what 
I have based my decision on.

If you disagree with my interpretation of what has been said and the
conclusion I have drawn from it, please let us know.

Gert Doering,
Address Policy WG Chair


Review Phase, starting Dec 23, 2014

Support:

Martin Hannigan
Nick Hilliard
Hamed Shafaghi
Luca Cicchelli
Lev V. Cherednikov
NTX NOC  (counted as personal statement)
Tore Anderson
Elvis Daniel Velea
George Giannousopoulos
Daniel Baeza
Mike Burns

Opposing:
nobody

Questions / Discussion items:

Martin Hannigan, answered

Nick Hilliard - discussion about the removal of the requirement 
 to return unused resources to the RIPE NCC
answered by Erik Bais (proposer)
no further discussion by the list members

Comments:

Randy Bush
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

Re: [address-policy-wg] Internet Number Community IANA Stewardship Proposal: Final Call for Comments

[Erik Bais]

Hi Hans Peter,

There is a discussion mailing list for this 
(https://www.nro.net/pipermail/ianaxfer/ ), is the idea to have questions and 
discussion on that particular mailing list for those that want to get a clear 
global reply on questions they might have ?

and the more RIPE RIR point discussion in coop-wg ?

Regards,
Erik Bais

Van: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] Namens Hans 
Petter Holen
Verzonden: donderdag 8 januari 2015 23:02
Aan: address-policy-wg@ripe.net
Onderwerp: [address-policy-wg] Internet Number Community IANA Stewardship 
Proposal: Final Call for Comments


I believe this is also important to this group, as it sets the framework for 
future implementation of global policies.

Please have a look at this proposal and please let us know if you support this.

Hans Petter


 Forwarded Message 
Subject:

[cooperation-wg] Fwd: [NRO-IANAXFER] Internet Number Community IANA Stewardship 
Proposal: Final Call for Comments

Date:

Thu, 8 Jan 2015 17:27:53 +0100

From:

Nurani Nimpuno nur...@netnod.semailto:nur...@netnod.se

To:

RIPE Cooperation Working Group 
cooperation...@ripe.netmailto:cooperation...@ripe.net



Dear colleagues,



Today the Consolidated RIR IANA Stewardship Proposal (CRISP) team publishes the 
second draft of the Internet numbers community proposal on the transition of 
the IANA stewardship. This is intended as a final call for community feedback 
ahead of the submitting the finalised proposal to the IANA Stewardship 
Transition Coordination Group (ICG) on Thursday, 15 January.



We understand that many in the RIPE community have a strong interest in this 
process, and feedback provided in this working group and elsewhere has been 
crucial in reaching the current draft.



While there is still an opportunity to provide comments on the current text, we 
would also like to strongly encourage RIPE community members in favour of this 
proposal to express their support on this list or via the 
ianax...@nro.netmailto:ianax...@nro.net mailing list. A quantifiable level of 
community support may be important in strengthening the Internet numbers 
community’s position later in the IANA stewardship transition process.



As previously, the timeline for responding is quite tight, with a deadline of 
Monday, 12 January, for all comments.



Best regards,



Nurani Nimpuno

on behalf of the RIPE CRISP team





Begin forwarded message:



 From: Izumi Okutani iz...@nic.ad.jpmailto:iz...@nic.ad.jp

 Subject: [NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal: 
 Final Call for Comments

 Date: 8 januari 2015 17:21:08 CET

 To: ianax...@nro.netmailto:ianax...@nro.net 
 ianax...@nro.netmailto:ianax...@nro.net



 Dear colleagues,





 Please find the second draft of the Internet numbers community's

 response to the Request For Proposals issued by the IANA Stewardship

 Coordination Group (ICG).



 This draft has been prepared by the Consolidated RIR IANA Stewardship

 Proposal (CRISP) Team, with considerations of feedback received from the

 global community on ianax...@nro.netmailto:ianax...@nro.net mailing list.



 We have incorporated the following key points in the second draft:



  - Additional description on contract details, review committee and

intellectual property rights

  - Description revised on Section V. NITA Requirements and VI.

Community Process for more clarity

  - No changes are made to key elements of the proposal



 The CRISP Team have considered all comments expressed on

 ianax...@nro.netmailto:ianax...@nro.net mailing list before the deadline 
 of 5th Jan 2015, and

 would now like to make the final call for comments from the global

 community on the draft proposal, before submitting to the ICG.



 Second Draft proposal:

 

 Clean Version  :

 http://www.nro.net/crisp-proposal-second-drafthttp://www.nro.net/crisp-proposal-second-draft



 Redline Version:

 http:/www.nro.net/crisp-proposal-second-draft-change-controlhttp://www.nro.net/crisp-proposal-second-draft-change-control



 The deadline for providing feedback: Mon, 12 January 2015 23:59 UTC

 Feedback should be sent to : 
 ianax...@nro.netmailto:ianax...@nro.net mailing list



 Community Inputs Considered by the CRISP Team:

 --

 You can check the status of the issues raised by the community and

 proposed the CRISP Team positions at:



   
 http://www.nro.net/crisp-iana-xfer-summary-discussion-08012015http://www.nro.net/crisp-iana-xfer-summary-discussion-08012015



 Key dates:

 ---

   Second draft to be published  :  8 Jan 2015

   Second draft comments close   : 12 Jan 2015, 23:59 UTC

   Final proposal to be sent to ICG : 15 Jan 2015



 How to Engage in Discussions:

 -

  All global discussions, for the CRISP team to consider as community

  feedback, will be conducted at ianax

Re: [address-policy-wg] 2014-04 timer update?

[Erik Bais]

Hi Aleksi, 

I haven't seen an updated / new version of the policy text of 2014-04. 
Did you already forwarded that to p...@ripe.net (Marco) and the AP-WG-chairs 
(Gert and Sander) ? 

Regards,
Erik Bais 

-Oorspronkelijk bericht-
Van: address-policy-wg-boun...@ripe.net 
[mailto:address-policy-wg-boun...@ripe.net] Namens Aleksi Suhonen
Verzonden: dinsdag 18 november 2014 8:40
Aan: address-policy Working Group
Onderwerp: [address-policy-wg] 2014-04 timer update?

Hello all,

We recently modified the 2014-04 proposal to drop any and all IPv6 
requirements from the last IPv4 assignment policy. Please indicate your 
support or lack there of for 2014-04 now.

Also, could the chairs publicly declare which timer the 2014-04 proposal 
is on now and how much time is left before it advances?

Yours sincerely,

-- 
Aleksi Suhonen / You say hot potato, I say closest-exit.

Re: [address-policy-wg] [ipv6-wg] FW: [policy-announce] 2014-12 New Policy Proposal (Allow IPv6 Transfers)

[Erik Bais]

Hi Radu, 

Could you provide insight in what you want to review ? 

That particular section is more in line with the policy proposal 2014-04 and
not the proposal to allow IPv6 transfers. 
No problem to discuss it, but we need to change the subject in that case in
order to keep this discussion clean.  

Regards,
Erik Bais

-Oorspronkelijk bericht-
Van: Radu-Adrian Feurdean [mailto:ripe-...@radu-adrian.feurdean.net] 
Verzonden: maandag 10 november 2014 9:44
Aan: Erik Bais; ipv6...@ripe.net
CC: address-policy-wg@ripe.net
Onderwerp: Re: [ipv6-wg] FW: [policy-announce] 2014-12 New Policy Proposal
(Allow IPv6 Transfers)

On Sat, Nov 8, 2014, at 17:00, Erik Bais wrote:
 There is a policy proposal currently in discussion phase to Allow IPv6
 Transfers.  
 
  We encourage you to review this proposal and send your comments to
 address-policy-wg@ripe.net before 28 November 2014.

Hello,

In order to get to the end of the logic (and also be a bit more in-line
with the rationale of 2014-04), Shouldn't we also review the paragraph
7.1 (IPv6 PI Assignments for LIRs) ? Or should this be done in a
separate proposal ?