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

[Sander Steffann]

Hi,

 try to minimize barrier to entry.  
 
 Thanks, those were the words I was looking for.
 
 Limiting entry to 1024 addresses is anti-competitive.
 
 Short enough for you?

And intentionally running out and limiting entry to 0 addresses is ... ?

Cheers,
Sander

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

[Sander Steffann]

Hi Randy,

 try to minimize barrier to entry.  

Thanks, those were the words I was looking for.

Cheers,
Sander

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

[Sander Steffann]

Hi Working Group,

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

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

# Electing a chairperson

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

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

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

# Running for chairperson

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

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

# Removing a chairperson

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

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

Cheers,
Sander  Gert
The current APWG chairs

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

[Sander Steffann]

Hi working group,

As promised here is a slightly modified version of the chair selection text:

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

# Selecting a chairperson

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

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

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

# Running for chairperson

Anybody is allowed to volunteer for a vacant chair position, including former 
chairs. Volunteers make themselves known by introducing themselves as a 
candidate on the working group mailing list before the start of the RIPE 
meeting.

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

# Removing a chairperson

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

# No Chairs

If a working group is left with no chair then they may elect an interim chair 
according to the selection procedures specified above, but with candidates 
nominated at the working group session. An interim chair must step down at the 
next working group session, but may stand for re-selection.
---

The only changes made are to specify that volunteers for a chair position must 
make themselves known on the mailing list before the meeting and to add a 
relaxed version for the special case when the working group finds itself 
without any chairs.

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

Cheers!
Sander

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

[Sander Steffann]

Hi,

 Since global routing table has exceeded 50 prefixes and expected to grow 
 more maybe RIPE community should rethink permitting the exchange of smaller 
 IPv4 blocks with contiguous one.

One thing to keep in mind is that this would make it possible for e.g. spammers 
to exchange two 'dirty' /22s for a 'clean' /21.

Just a thought :)
Sander

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

[Sander Steffann]

Hello Saeed,

 Now, isn't it possible, that RIPE NCC develops a policy ( maybe there one ) 
 to take back these advertised address spaces ?
 because their initial criteria is not valid any more ? ( obviously  those 
 organization, do not need these address spaces. )
 
 I can understand LEASING some IPs for some period of time, but I can't 
 understand selling them.

We (this working group) had that discussion in 2007 when policy proposal 
2007-08 was introduced. At the time it was decided that reallocation 
(transfers) were a better / more viable solution than trying to reclaim unused 
addresses. Please take a look at the mailing list archives to see how the 
discussion went. It was a quite long discussion.

Proposal 2007-08: https://www.ripe.net/ripe/policies/proposals/2007-08
Mailing list archive: 
https://www.ripe.net/search?SearchableText=2007-08portal_type%3Alist=Message

Cheers,
Sander

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Sander Steffann]

Hi Sasha,

 A LIR now joining the RIPE NCC has no way of determining what the
 spirit of a policy is. (bar, perhaps, reading all apwg
 discussions leading to it) The letter of the document is all that
 counts and IPRAs can't make determinations based on the spirit
 either, otherwise this proposal would not be necessary.
 So, yes, an assumption that one can join the NCC now and get a
 /22 with the intent to sell it is reasonable.

The policy actually says that The LIR must confirm it will make assignment(s) 
from the allocation. See https://www.ripe.net/publications/docs/ripe-643#51. 
This is not the case if the intent is to sell the prefix.

Cheers,
Sander

[address-policy-wg] Working group chair rotation 1

[Sander Steffann]

Hello working group,

As we now have a working group chair rotation/selection process in place it is 
time to start that process for the first time! After long deliberation (a.k.a. 
a random number generator) we have decided that Gert is going to be the first 
chair to step down. He will do so at the upcoming RIPE meeting (RIPE 70 in 
Amsterdam). He has also volunteered again and is therefore our first candidate.

If anybody else wants to volunteer then please make yourself known on this 
mailing list before the start of RIPE 70.

Cheers,
Sander  Gert

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

[Sander Steffann]

Hi working group,

The last call for the working group chair selection process has ended and no 
further comments were received. Therefore the working group chairs hereby 
declare consensus for the process.

Cheers,
Sander  Gert

[address-policy-wg] 2014-05 - end of last call (Policy for Inter-RIR Transfers of Internet Resources)

[Sander Steffann]

Hello working group,

The last call period for proposal 2014-05 (Policy for Inter-RIR Transfers of 
Internet Resources) has ended. In this phase no new feedback has been sent to 
the working group and the working group chairs have therefore concluded that 
the consensus as previously announced (see below) still stands.

We ask the RIPE NCC to go ahead and implement this policy.

Cheers,
Your working group chairs
Gert  Sander


 Op 3 mrt. 2015, om 13:39 heeft Gert Doering g...@space.net het volgende 
 geschreven:
 
 Dear AP WG,
 
 the review phase for 2014-05 has ended.  
 
 While this proposal has taken quite a while to come to a conclusion, we 
 seem to have quite strong support and no opposition now - nine persons 
 spoke up in support of the proposal, and no other comments of any sort have
 been received.
 
 So, I declare we have consensus, and move 2014-05 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 V3.0, starting Jan 16, 2015
 
 Support:
 
Mick O'Donovan
Steve Wright (3 times!)
Tore Anderson
  (some editorial gripes, but postponed addressing them in the unified
   transfer policy document showing on the horizon)
Elvis Daniel Velea
Mike Burns
Guy Chilton
Duncan Scotland
Juan P. Cerezo
Hamed Shafaghi
 
 Comments, Opposition:
 
-
 -- 
 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] IPv6 PI assignment policy

[Sander Steffann]

Hi,

 What if the freifunk communities formed an alliance and become a LIR as
 a part of the alliance? It would lower the costs of becoming a LIR and
 at the same time allow communities to get enough independent IPv6
 addreses that could be assigned to customers.

One option is to get 8 freifunk communities together, start one LIR between 
them, get a /29 from RIPE NCC and then let each community use a /32 from that. 
I have a personal LIR that 'donated' a /32 to a community in such a way and it 
works fine. The deaggregation from /29 to /32 is not great, but not something 
that causes much trouble in the DFZ.

Cheers,
Sander

[address-policy-wg] Consensus on 2015-01

[Sander Steffann]

 Stecenko
- Storch Matei
- Vladimir Andreev

The impact analysis by the RIPE NCC however explicitly mentions that 
Considering the overall size of the membership, the RIPE NCC does not 
anticipate a significant impact will be caused if this proposal is 
implemented..

Finally, there were also objections that the final /8 pool was too big and/or 
not running out fast enough. This objection was made by:
- Ciprian Nica
- Storch Matei

In the impact analysis however mentions that the current pool will last 5.5 
years based on the allocation rate of the last 6 months (up to the writing of 
the impact analysis). That lifetime may be reduced significantly however if new 
LIRs continue to join in ever-larger numbers and /22 transfers from last /8 
also gain more popularity. As the remaining lifetime of the IPv4 internet is 
extremely likely to be longer than 5.5 years the lifetime of the final /8 pool 
seems short as it is.

Based on the feedback I see strong support for this policy proposal. All 
objections seem to be addressed as well, so I hereby declare rough consensus on 
policy proposal 2015-01 and ask our friendly RIPE NCC Policy Development 
Officer to move this policy proposal to the Last Call phase.

Sincerely,
Sander Steffann
APWG co-chair

Re: [address-policy-wg] Consensus on 2015-01, Alignment of Transfer Requirements for IPv4 Allocations

[Sander Steffann]

Hi working group,

Lu Heng asked me to rectify my summary. He has also expressed support for the 
policy proposal during the review phase and his name was indeed not listed. 
Please consider him a supporter of this proposal as well.

Cheers,
Sander



 Op 22 jun. 2015 om 14:06 heeft Sander Steffann san...@steffann.nl het 
 volgende geschreven:
 
 And this time with a fixed subject line so that it is clearly visible which 
 policy proposal we are talking about :)
 
 Op 22 jun. 2015, om 12:10 heeft Sander Steffann san...@steffann.nl het 
 volgende geschreven:
 
 Hello working group,
 
 Here is your chair's (singular, Gert has abstained from judging consensus as 
 he became too involved in the discussion on the mailing list and might be 
 seen as non-neutral on this policy proposal) analysis on the review phase of 
 RIPE policy proposal 2015-01.
 
 At the end of the review phase there was a sudden flood of messages both 
 supporting and opposing the policy proposal. Many of these messages were on 
 or after the deadline: the end of the review phase. As those messages didn't 
 bring forward any new arguments they didn't influence my decision making 
 process. I have included them in this overview for completeness' sake.
 
 First the people supporting this policy proposal. There were many people who 
 supported the proposal based on the rationale given in the proposal itself 
 (also known as +1 messages). Others also stated the reasons why they 
 supported the proposal. These included:
 - It aligns with original intent (make assignments) of the final /8 policy
 - It makes it less profitable to overtly act against the original intent of 
 the final /8 policy
 - It is a good step in the right direction, we may need more steps later
 
 Here is a list of people that supported this policy proposal:
 - Andre Keller
 - Andreas Larsen (after deadline)
 - Carsten Brückner (after deadline)
 - Carsten Schiefner
 - Christopher Kunz
 - Daniel Suchy
 - Dimitri I Sidelnikov
 - Erik Bais
 - Florian Bauhaus
 - Garry Glendown
 - Gerald Krause
 - Havard Eidnes
 - Herve Clement
 - Jan Ingvoldstad
 - Jens Ott
 - Marius Catrangiu
 - Martin Millnert (after deadline)
 - Mick O Donovan
 - Ondřej Caletka
 - Radu-Adrian FEURDEAN
 - Riccardo Gori
 - Richard Hartmann
 - Robert Sleigh
 - Sebastian Wiesinger
 - Thomas Schallar
 - Tim Kleefass
 - Tom Smyth (after deadline)
 - Tore Anderson
 - Torunn Narvestad (after deadline)
 - Vladislav Potapov
 
 David Freedman asked for clarifications about the impact on the Mergers and 
 Acquisitions procedure of the RIPE NCC. These were answered by Marco Schmidt.
 
 Daniel Baeza and Richard Hartmann asked for clarifications on how this 
 policy would be applied to allocations made in the past. Marco Schmidt 
 explained that if accepted this policy would only impact transfers happening 
 after the policy was implemented. Transfers that happened in the past would 
 not be impacted. The policy would be applied to existing allocations though. 
 Allocations made in the past would not be transferrable until they were at 
 least 24 month old. For some people this was a problem as they considered it 
 unfair to those LIRs that had started in the last 24 months with the 
 expectation that they would be able to transfer their allocation from the 
 final /8.
 
 The people opposing this policy proposal because they consider it a 
 retroactive change are:
 - Sascha Luck
 - Storch Matei
 - Vladimir Andreev
 
 There were many messages on this topic. We consider this objection handled 
 because this policy doesn't actually change anything that happened in the 
 past. This policy proposal is about the requirements of transfers. If this 
 proposal gets accepted transfers that have already happened stay happened, 
 and transfers that are about to happen will be checked against the current 
 policy at that time. This is how RIPE policies have always been applied and 
 this policy proposal is no different.
 
 There was a message stating opposition to the proposal by Arash Naderpour, 
 but as no reasons against the proposal were given there is not much we can 
 do with this. Consensus based policy development means trying to address 
 objections until the reasons for the objections are taken away. When no 
 reasons are given this is not possible. Therefore this opposition will not 
 have much weight in my analysis.
 
 There was also opposition because people felt that this policy proposal 
 didn't solve a real problem and/or wasn't solving all problems related to 
 abuse of the current final /8 policy. They were:
 - Amir Mohsen (after deadline)
 - Aleksey Bulgakov
 - Arash Naderpour (after deadline)
 - Borhan Habibi
 - Ciprian Nica
 - Olga @ip4market.ru (after deadline)
 - Petr Umelov
 - Sergey Stecenko
 - Storch Matei
 - Yuri @ntx.ru (after deadline)
 
 During the discussion it was shown that the number of transfers from the 
 final /8 pool was increasing, especially for very young prefixes. This 
 shows

Re: [address-policy-wg] Complaint and future of the APWG.

[Sander Steffann]

Hi,

 Gert is one of the few people I know that I trust completely regarding
 integrity. He proved me right again by letting Sander conclude this
 proposal so that neutrality is given.

Indeed. I am staying out of this discussion and I will limit myself to judging 
on consensus or not. I admit that I am very annoyed by what is happening on the 
list at the moment, but I will not let that influence my decision. That will be 
based on arguments for/against the proposal and how they are addressed.

What we look for is support for the proposal and that the objections against 
the proposal have been properly considered. That doesn't mean that every 
objection blocks the proposal. Rough consensus only requires the objections to 
be taken seriously and be considered.

I will let you know the outcome once I analyse every message from the review 
phase about this proposal on this mailing list. This might take a while... 
Please be a bit patient.

Cheers,
Sander

Re: [address-policy-wg] RIPE != RIPE NCC

[Sander Steffann]

Hi Sasha,

 Another thing that may help is to move away from mailing lists as
 the sole tool - email is something that only old farts like
 myself are really comfortable with, not to mention very open to
 abuse as we've seen. There are more modern collaboration tools
 available, something like Etherpad maybe...

See 
https://www.ripe.net/participate/ripe/wg/cc/summaries/ripe-70-working-group-chair-meeting-summary
 item V :)

Cheers,
Sander

Re: [address-policy-wg] Promote the use of IRC

[Sander Steffann]

Hi,

 Op 12 aug. 2015, om 15:24 heeft remco van mook remco.vanm...@gmail.com het 
 volgende geschreven:
 
 +1 on on everything that Jim just said. You're welcome to discuss any policy 
 anywhere - in a pub, on IRC, on Facebook, other industry events, you name it 
 - (and I know almost all of you do) but as long as it's not on the mailing 
 list, it doesn't count for the policy development process. 

Yep, that is how it is going to be. And any argument that sounds like But on 
IRC somebody has said XYZ will be ignored until that somebody posts his/her 
opinion on the mailing list. I am not going to keep IRC logs and search through 
them when somebody refers to an IRC discussion.

In this working group *individuals* discuss address policy. Statements on 
behalf of groups, organisations, companies or some other person on IRC are not 
taken into account in policy discussions. Only statements made by real people 
themselves are taken into account :)

 Also I'd like to echo the sentiment that it's yet another communications 
 channel that I'd need to keep track of - I don't know where any of you finds 
 the time to do so but I certainly don't have it.

Yep. I have trouble enough as it is judging consensus based on mailing list 
data. Adding more sources of data can make my work as working group chair close 
to impossible.

Cheers!
Sander

Re: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations

[Sander Steffann]

Hi Petr,

 I mean the next
 
 Frome: Ingrid Wijte ing...@ripe.net
 Date: 3 March 2015 г. 12:52
 
 Subject: [ncc-announce] [news] RIPE NCC Receives a /13 from IANA's Recovered 
 IPv4 Pool
 To: ncc-annou...@ripe.net
 
 [...]
 
 With the current policy in place, the RIPE NCC will receive one-fifth of
 any recovered addresses in the pool every six months (every March and
 September).

This is not a fixed size. As Leo has already shown you the size RIPE NCC gets 
has been smaller each time.

But to avoid any lengthy discussions on 2015-01: it has been *concluded*. As 
working group chair I have made my decision and I decided that there is 
consensus on 2015-01. If you do not agree with this decision then please use 
the appeals procedure [1]. There is no point in discussing this any further on 
this mailing list as I have thoroughly reviewed everything and I stand by my 
decisions.

Cheers,
Sander

[1] https://www.ripe.net/publications/docs/ripe-642 section 4

Re: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)

[Sander Steffann]

Hello Yuri,

 No consensus was reached.

Yes there was. I declared so a few days ago. If you truly believe that my 
decision to do that was wrong then please follow the Appeals procedure 
described in section 4 of our PDP 
(https://www.ripe.net/publications/docs/ripe-642) but please stop repeating 
yourself on this mailing list.

Cheers,
Sander

PS: my apologies for repeating myself, but I want to make sure that everybody 
understands how this works so that we (the chairs) don't get blamed over and 
over again for not listening to the community. We do listen, and we do make 
honest decisions, and we will fully cooperate with any appeals procedure if 
people feel we wronged them.

PPS: sorry for a PS section that is longer than the main content

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) - “subsequent allocations”

[Sander Steffann]

Hello Annette,

 the LIR-team of de.government supports this current policy proposal “2015-03 
 New Draft Document”. +1
  
 In addition we also made up our mind about the resulting inconsistency to the 
 criteria for subsequent allocations. Therefore we plan to propose a 
 “follow-up” proposal which tries to align the subsequent allocation criteria 
 in case of a successful 2015-03 PDP.

Ok, we'll see how 2015-03 goes and contact you once that has been concluded 
(either withdrawn or accepted). If you have any questions feel free to contact 
the chairs and RIPE NCC PDO at apwg-cha...@ripe.net, or to follow up on this 
list of course.

Cheers,
Sander

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

[Sander Steffann]

Hi,

> Op 20 okt. 2015, om 23:57 heeft Radu-Adrian FEURDEAN 
>  het volgende geschreven:
> 
> On Tue, Oct 20, 2015, at 20:00, Randy Bush wrote:
>> what is it that people do not understand about "gone, no more, we're
>> out, ...?"
> 
> Because it's NOT. Not yet. Not in RIPE-land, not in APNIC-land, not even
> in LACNIC-land. Not to mention AfriNIC-land.

The current policy is "we reserved some address space so that new entrants are 
not blocked from the market". I have seen many people interpret that as "we 
have not yet run out". For all practical purposes we *have* run out. What we 
have left is not normal address distribution anymore but a "special" situation. 
Business-as-usual with IPv4 doesn't exist anymore. To be blunt I think that "we 
haven't run out" is a extremely misguided (a.k.a. delusional) viewpoint...

The point of this policy proposal is to see whether we can optimise this 
special situation by changing some of the parameters. To discuss if the results 
of changing i.e. "one /22" to "one /22 every 18 months" would help people while 
still providing an acceptable timeframe for being able to give addresses to new 
entrants.

But please realise that the normal IPv4 pool has run out and we are only 
discussing the usage of a reservation we made for special circumstances.

Cheers,
Sander

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

[Sander Steffann]

Hello working group,

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

Thanks to Marco and the rest of the RIPE NCC for this extensive impact analysis.

This impact analysis uncovers a very serious issue that has slipped under our 
radar in the "Entities That Can Receive a Transfer". The issue raised from the 
RIPE NCC Executive Board looks completely legitimate to us.

For those of you who haven't read the impact analysis yet, this is the core of 
the issue:

> The RIPE NCC impact analysis notes that acceptance of this proposal could 
> significantly affect the stability of the RIR system as a whole by allowing 
> transfer of any resource (including assigned PA space) to any entity 
> including one that is not a member of the RIPE NCC (or any other RIR).

This is a serious issue that will affect all of us. The chairs take this issue 
into the consensus-reaching process and we ask the authors and working group to 
address this.

Your working group chairs,
Gert and Sander

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)

[Sander Steffann]

Hi Mathew,

 I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold
 an IPv6 /29 allocation each...so assuming the proposal was intended to
 help scratch an itch of their own, so to speak, perhaps this is
 simply an omission?
 
 It was our (uk.mod's) expectation/assumption that it would be possible to 
 return an existing allocation (in an 'unused/as-new' state) and apply for 
 another under the new criteria.

That is correct. If you return your allocation you can then do a new 
first-allocation request. With the current text it won't be possible to grow an 
existing allocation though, as that would use the rules for additional 
allocations.

Cheers,
Sander

Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

[Sander Steffann]

Hi,

> 3. Further allocation(s) (after the first /22)
> 3.1 introduce some minimum delay after the last allocation : 12 months
> (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less
> ? None ?
>3.1.1 Does that mean one can get a new allocation every X months
>(LACNIC-style) while the stock lasts ?

While I like this idea, please do realise that a /8 has 16384 /22s in it. RIPE 
NCC has more than 12000 LIRs at the moment. Many of those would already qualify 
for an additional allocation based on this. That could drain the pool in a very 
short time...

> 3.2 Allocation size : /22 ? /23 ? variable depending on how much is
> available at the time of allocation, max /22, min /24 (which does imply
> a little more policy text in order to detail this) ?

Re-introducing different allocation sizes would also mean going back to a 
needs-based system. I'm not sure we want to add that overhead/bureaucracy 
again. A lot of people were quite happy with 2013-03. Changing the size to a 
/24 for further allocations would extend the lifetime of the pool, but on the 
other hand I'm not sure if handing them a /24 every x months will really help 
many LIRs, and the routing overhead will be a lot more interesting...

So while I am happy to see work being done on this, I am still a bit cautious. 
But I'd love to be shown wrong :)

Cheers,
Sander

Re: [address-policy-wg] An interesting policy question

[Sander Steffann]

Hi Lu,

> Thanks Vladislav for the clear answer.
> 
> And for the list, this is an answer I would like to receive, clear and easy.
> 
> The example was very simple so I was expecting an simple answer as well.

Glad you are happy with that answer. I just want to state for the record that 
any answer on this topic given on this mailing list does not represent any 
official interpretation of the policy and is as such non-authoritative :)  
Official interpretations are only given in the Impact Analysis of a policy 
proposal.

> (I got an feeling that anything I say in the list was wrong, I hope it does 
> not become personal again, I am asking a policy question in a policy 
> discussion mailing list and nothing more than that).

Nothing personal, and both Gert and I have answered your question as well as we 
could. Things are more complex than this answer shows though. For example 
changing the geographical location by itself might not make the 'need' invalid, 
but any changes in who/what the addresses are connected to might etc. These 
things are determined on a case-by-case basis by the hostmasters/IPRAs.

That is why we don't discuss specific cases on the mailing list. A mailing list 
never has the full data, and speculating what hostmasters would decide would 
undermine their work. We have an arbitration system for cases where people 
disagree.

Cheers,
Sander

Re: [address-policy-wg] An interesting policy question

[Sander Steffann]

Hi Lu,

> Because if *need* includes whole package of justification material, then by 
> definition, change any thing in that package(for example, location of the 
> server, upstream provider), would request NCC approval for the assignment 
> again

It depends what the conditions were for getting the assignment in the first 
place. If you were allowed to make an assignment for reason X then you can't 
just change X. You can change Y and Z, as long as they weren't part of the 
condition. What those fictional X, Y and Z might be are completely dependent on 
the actual policy, and for addresses we don't have any needs criteria anymore 
so this is all hypothetical.

> therefore effectively requested NCC to manage all the infrastructure 
> adjustment by it's members(assure the LIR do not have assignment window), 
> because the need has changed.

Are you still talking about RIPE NCC here? You are talking about situations and 
concepts that seem to have nothing to do with our region... Let's stop this 
discussion on hypothetical impact of hypothetical policy.

Cheers,
Sander

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Aled,

> Sorry yes, I was clumsy in my wording.

No apologies required! I just wanted to make sure that everybody reading the 
messages (and archives) understands the difference. Some things are obvious for 
people who have been around for some time but can be confusing to those who 
haven't. I was just making sure that everybody understands what is being 
discussed :)

Cheers!
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] ***CAUTION_Invalid_Signature*** Re: IPv4 reserved space

[Sander Steffann]

Hi Arash,

> As an example in Iran there is only one exit point (AS12880 and AS48159 
> belongs to one organization) from country to global carriers controlled by 
> government and as they have no LI platform yet on IPv6 there is simply no 
> IPv6 service availability or possibility for Iranian service providers.

If your government is making your work impossible there is little the rest of 
the world can do about it.

The world is out of free IPv4 space. The space that is reserved is for new 
entrants that need a tiny bit to connect to the old IPv4-only world. The days 
of running networks on only IPv4 are over. Everybody needs more addresses, and 
IPv6 is the only protocol that can provide them, so everybody needs to move. 
Including your government.

I am sorry. I understand that your personal/business situation sucks in regard 
to this, but your government is the only one who can fix this :(

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] [apwg-chairs] Create FAQ? (was: Re: IPv4 reserved space)

[Sander Steffann]

Hi Nick,

> Is there any possibility of creating a FAQ?   There are a bunch of
> issues which are coming up repeatedly, of which this is one.

I agree. There are many things that the people who have been involved for a 
long time know, but which might not be obvious for others. I'll see if I can 
put something together on ipv6guide.net.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] [apwg-chairs] Create FAQ? (was: Re: IPv4 reserved space)

[Sander Steffann]

> A little while ago, Marla Azinger and I wrote this document to describe some
> of the issues:
> 
> https://www.rfc-editor.org/rfc/rfc6319.txt

Thanks Leo!
Sander 

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

[Sander Steffann]

Hi Sasha,

> RIPE policy has, until recently, explicitly recognised that M (and
> what happens to resources due to those) is not in scope for the
> PDP. It is only since "last /8" that certain elements of the
> "community" have tried, by hook or by crook, to arrogate
> themselves the right to decide what happens to resources in the
> event of M

It has always been in scope, it just hasn't been very interesting to write 
policy about. Until now when people are using it as a way to circumvent policy.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi Sasha,

> The fact remains that policy has no business regulating into the
> business transactions of members (vulgo M) and I oppose it for
> that reason alone.

RIPE policy does regulate IP allocations and under what conditions you are 
allowed to have/transfer/etc them. I agree that RIPE policy cannot regulate an 
organisation's M itself, but what happens to IP allocations when M happens 
definitely is in scope.

Not expressing any opinion in favour or against, just clarifying scope :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Radu,

>>> PI can be converted in PA easily in RIPE
>> 
>> ???
> 
> https://www.ripe.net/manage-ips-and-asns/resource-management/converting-pi-to-pa
> 
> ASSIGNED PI -> ALLOCATED PA on request.

Ah, that one. Thanks for the link-local I was getting confused by the mixed 
arguments about ALLOCATED PI.

Cheers!
Sander

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi,

> Ah, that one. Thanks for the link-local I was getting confused by the mixed 
> arguments about ALLOCATED PI.

My auto-complete is getting too used to IPv6 terminology ;)
s/-local/./

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy

[Sander Steffann]

Hi Mikael,

> I just had a thought.
> 
> What we're trying to do is to make sure there are IPv4 addresses available to 
> new entrants. We're trying to do this by making a LIR get one post-exhaustion 
> /22 each. The LIR fee is the limiting factor in trying to stop people from 
> getting many /22:s. People have been trying to game this, by getting /22 and 
> closing the LIR, thus avoiding the LIR fee. Changes in the policy has been 
> all about trying to limit transfers etc, setting policy from what should 
> happen with /22s, stopping transfers (so people still have to pay LIR fees, 
> one per /22 etc).
> 
> Since it's actually the post-exhaustion /22 we're after why not do this:
> 
> The post-exhaustion /22 comes with a fee that is equivalent to the LIR fee. 
> If a LIR contains one post-exhaustion /22, then this fee is waived.
> 
> Doesn't this just solve the problem everybody is arguing about? Now all of a 
> sudden it's not cheap to get multiple /22s, and we don't care any more if 
> people keep their LIRs open or not, it still costs the same.

We are always very careful with linking policy to charging. We tried that in 
the past and usually ran into some issues. If, however, the RIPE NCC would 
adapt the charging scheme in this way then it would probably make some policy 
proposals less relevant :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Randy,

> i have had an epiphany!  RIR stands for Rinse and Infinite Repeat.  this
> expains it all.  i feel much better now.

Good one ;)
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Patrick,

> What about assignments from the ALLOCATED FINAL? Will it be "ASSIGNED FINAL"? 
> Or partitioned space "LIR-PARTITIONED FINAL"  :-)

Nope, only the allocation will get a different status. The LIR can still use it 
like before, assign from it etc.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Riccardo,

> If we had a proposal that changes the policy behaviour creating a new fantasy 
> example category "ALLOCATED BEFORE FINAL" to all allocation created before 
> 14/09/2012 this would be discriminating anyone received such kind of 
> allocation from who didn't.

Every LIR can receive that allocation.

> PI can be converted in PA easily in RIPE

???

> I invite you to read these from Registration Services update about different 
> colors allocations:
> https://ripe71.ripe.net/presentations/86-FeedbackRS-RIPE71.pdf
> https://ripe72.ripe.net/presentations/112-FeedbackRS-RIPE72_final.pdf

Thank you, I know very well what happened in my own working group.

> [...]
> RIPE NCC encourages:
> - LIRs to strive to convert to ASSIGNED PA
> “Where possible, LIRs should work to make contractual arrangements to convert 
> PI addresses into PA addresses.”
> - LIRs to not create new ASSIGNED PI
> - Where possible to convert to ALLOCATED PA
> [...]

That is from a slide talking about ALLOCATED PI, you seem to be taking it out 
of context and applying it to all PI.

> I am not thinking my arguments are false.

Yeah, that bit is obvious. However, you have repeated your point over and over 
again without providing any convincing data to back it up, so we're stopping 
this argument now. Feel free to discuss other issues you see, but the "class-b 
LIRs" argument has now been discussed, considered and found incorrect.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Payam,

> My point of view is such policies in practice would punish the newcomers 
> rather than those who got plenty of resources in the old days [probably 
> without proper justification]
> I remember the days which our LIR was negotiating with a RIPE NCC IP analyst 
> and he declined our request although we had proved that our need was even 
> more than what we submitted in our application, and eventually the block 
> which he approved was less than what we requested. 
> And at those time, some other western LIRs got their IP blocks.

Please don't make allegations like that. I have worked for western LIRs and we 
had exactly the same process and issues as everybody else.

> These days we are trying to buy new IP blocks, and those LIRs are selling! 
> 
> That funny story is the real story! While the proposed policy looks very 
> rational, but it is not going to solve the issue! 
> The demand is there so the market will find a way to satisfy the demand!

People with demand for a /22 can set up their own LIR. No need to let someone 
else set up an LIR and just sell the space

> If I were the gentleman who proposed this policy, I would have proposed 
> another policy to push the LIRs who had not used their IPs (or pretending to 
> use that) in favor of LIRs in the developing countries who really can't serve 
> new customers due to lack of IP space.
> 
> we should not close our eyes on the approvals which were given to LIRs who 
> got plenty of IPs, and they were supposed to use all the IPs within two years 
> following the allocation, and still they have a lot of un-assigned (and even 
> un-advertised!) ones!
> 
> 
> 
> On 2016-06-17 02:58:20 CET, Arash Naderpour wrote:
>>> I find this inconsistent. Either we do it for *ALL* allocations (including
>> the ones allocated prior to the 2012/09 ipocalipse), effectively banning or
>> heavily >restricting transfers, or we keep it the way it is today, i.e. for
>> *NO* allocations.
>> 
>> Not sure why returning some /22 to RIPE NCC free pool can save the
>> new-comers but other allocations prior 2012 cannot. If returning an
>> allocation is something visible it should be for all allocations not only to
>> the smallest ones, it is not fair.
>> 
>> Regards,
>> 
>> Arash
> 
> 
> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
> 

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Sorry, got bumped into and accidentally hit Send before I was done :)  Here is 
the rest:

Hi Payam,

> My point of view is such policies in practice would punish the newcomers 
> rather than those who got plenty of resources in the old days [probably 
> without proper justification]
> I remember the days which our LIR was negotiating with a RIPE NCC IP analyst 
> and he declined our request although we had proved that our need was even 
> more than what we submitted in our application, and eventually the block 
> which he approved was less than what we requested.
> And at those time, some other western LIRs got their IP blocks.

Please don't make allegations like that. I have worked for western LIRs and we 
had exactly the same process and issues as everybody else.

> These days we are trying to buy new IP blocks, and those LIRs are selling!
> 
> That funny story is the real story! While the proposed policy looks very 
> rational, but it is not going to solve the issue!
> The demand is there so the market will find a way to satisfy the demand!

People with demand for a /22 can set up their own LIR. No need to let someone 
else set up an LIR and just sell the space.

> If I were the gentleman who proposed this policy, I would have proposed 
> another policy to push the LIRs who had not used their IPs (or pretending to 
> use that) in favor of LIRs in the developing countries who really can't serve 
> new customers due to lack of IP space.

That is what the /22s are for: to allow newcomers (from anywhere within the 
region, we don't discriminate on location) access to some free IPv4 addresses.

> we should not close our eyes on the approvals which were given to LIRs who 
> got plenty of IPs, and they were supposed to use all the IPs within two years 
> following the allocation

It happens. Business plans change, market conditions change. Some people may 
even have lied about their needs in such a way that it is impossible to prove. 
Remember: allocations were made based on expected growth. Expectations often 
don't come true exactly the way people planned things. ISP planning often 
happens for 3-to-6-month periods. The 24 month estimates for allocation 
requests have always been difficult to judge.

> , and still they have a lot of un-assigned (and even un-advertised!) ones!

Advertising space in the global routing table has never been a requirement. 
There are use cases where unique addresses are required but don't need to be 
advertised. Think for example about private interconnection networks between 
companies. The companies will already be using all the RFC1918 space 
internally, so to avoid addressing conflicts the interconnect network needs 
unique addresses. Same as IXP space, which is often also not routed.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi,

> Like in "we won't kill you with a bullet in the head, we will kill you
> by letting you slowly bleed to death". Thanks.
> Now you try to regulate how you are allowed (or not) to heal yourself.

I'm sorry, but this policy proposal limits selling the last /22 LIRs get from 
RIPE NCC. How is preventing to sell off your addresses in any way considered 
"healing yourself"?

Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hello Stefan,

> Therefore it seems inconceivable that this proposal is allowed to go forward 
> any longer than it already has

Excuse me, but that is not your call to make.

Sander
APWG co-chair



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Stefan,

> Additionally, as I understand it this is something that needs to be voted on, 
> I would like to lower the initial signup fee of currently 2000,00 Euros down 
> to just 500,00 Euros. In case they request an additional /24 after twelve 
> months they will need to pay an additional instalment of 500,00 Euros which 
> will bring the total amount still to 2000,00 Euros if they requested 4x /24 
> allocations over a period of 4 years. After each allocation the RIPE NCC will 
> aggregate the allocation whenever possible. Subsequently if a new member 
> requests a second /24 the allocation will be enlarged to a /23. In the end he 
> will be left with one /22 if there is sufficient consecutive address space 
> left to do so.
> 
> In cases where the Local Internet Registry does not require any IPv4 address 
> space it should also not be required to pay any fees apart from the 
> membership fees.

Membership fees are out-of-scope for the RIPE Address Policy Working Group. The 
RIPE community makes the policy, the RIPE NCC and its members determine the 
membership fees. This working group is part of the RIPE community and not 
involved in setting membership fees.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Radu,

Thank you for providing concrete cases! This is now something that can be 
discussed.

> Three:
> - That other LIR opens up a second LIR
> - They get their /22 (free)
> - They can no longer apply "M" because the definition of "M"
> changed, and they have to do a regular transfer.
> 
> On a general basis, there may be reasons for which you have to proceed
> with a regular transfer, other than "get IPs from NCC in order to sell
> them".
> 
> It is my understanding, and please someone from RIPE NCC confirm or
> infirm that in public, that M has "slightly" changed recently, and the
> following operations are no longer M:
> - merging several existing LIRs having the same owner.
> - re-organisation of address space between the LIRs of a group.
> - purchasing a company but keeping the purchased company's legal entity
> (you accountant will give you good reasons for this; if you live in
> counties like France, your HR will give a few more reasons).
> - putting together resources of several entities within a group without
> proceeding with heavy legal and administrative paperwork.

So basically what you are worried about is that RIPE NCC will not treat all M 
as M and might apply the transfer policy instead, and that with this proposal 
stopping transfers of the /22 the M would be blocked, causing such members to 
be forced to keep multiple LIRs open.

Let's ask our friendly PDO to ask his colleagues within RIPE NCC how the cases 
you mention would be treated.

>> currently violating the policy by requesting my /22 for the wrong reasons
> 
> Policy-wise, there are no "wrong reasons".

Yes there are. The policy explicitly states "The LIR must confirm it will make 
assignment(s) from the allocation". If you request an allocation without the 
intention of making assignments from it you have lied during your allocation 
request. That is a policy violation.

But anyway: let's wait for the RIPE NCC to get back to this list with more data 
on M!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Riccardo,

>>> A new entrant would see his investments vanified
>>> 
>> Address space is not an investment. The only reasons transfers were allowed 
>> in the first place (and this was not an easy decision back then) is to keep 
>> the database information accurate and to get some unused address space back 
>> in use.
> 
> About investments:
> To set up my ISP I needed networking, infrastructure, IP transit, hosting 
> services, IP addresses.
> I payed a signup fee and that was an investement to be an LIR and do better 
> business as an ISP. I pay annualy a membership fees and this is part of the 
> costs to run the business.
> if I look to my management server (a couple of server hotsed outside my 
> network) I see that I pay 16 € per month for a /29 as part of the contract 
> with my hosting provider... so actually yes IP space is a small part of the 
> investements or costs in any case.

You're taking this out of context. We're talking about 2016-03 here. Everything 
you mention is about the cost of running an ISP. This proposal doesn't change a 
thing for that: you still get your /22. The only thing that changes is that you 
can't sell it.

> About transferts:
> The same is today. Main reasons for a transfert are not renumbering and 
> database consistence or unused IPs? Unused Ips is not my case I have so few.
> This proposal puts the new LIRs in a worse condition even it already is. We 
> are not SICK, we are late entrants. I don't see any reason to create CLASS-E 
> "unusable LIRs"  to keep them far from the IP market old LIRs created.

What are you talking about? The only thing this proposal prevents is from 
selling a single /22. Jumping from there to "unusable LIRs" makes no sense.

> Are you really thinking that I came out with a proposal like 2015-05 to catch 
> more IPs to sell them?

We're not talking about 2015-05 here...

> I am not selling IPs 'cause i need them for assignements to customers

In that case this policy proposal doesn't change anything for you.

> but the first thing my they ask me when I propose consulting for IPv6 
> trasnition is "can I have the assigned space for me one day to keep on 
> running the network"

And the answer to that has always been "no". Please read section 7 of 
https://www.ripe.net/publications/docs/ripe-649. It contains this text:

"""
Clear contractual arrangements are mandatory for PA space. End Users requesting 
PA space must be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original 
assignment are met and only for the duration of the service agreement between 
yourself and us. We have the right to reassign the address space to another 
user upon termination of this agreement or an agreed period thereafter. This 
means that you will have to re-configure the addresses of all equipment using 
this IP space if you continue to require global uniqueness of those addresses.
"""

>> We still have M for cases where businesses split up, merge, get sold etc. 
>> That is not affected by this policy proposal.
> The evidence of a disvantage of newcomers is still there.

How? All that this proposal limits is them selling their /22, which you keep 
telling me is not your intention.

> Black market will substitute normal transfers regulations

Please read my reply to Nick Hilliard two days ago, we were discussing the same 
issue and I am not yet sure that this is true.

> and creative implementations of M will come to overcome the policy,

M are explicitly allowed, based on feedback from the working group.

> transparency will go far from database and statistics and transfert evidence.
> You want all of this?

I wouldn't want that, but I cannot see how you reach that conclusion...

>>> We were in Bucarest when celebrating Romania as the biggest transfert 
>>> country were JUMP Management choosed to sell to its customers their 
>>> allocation making them able to keep their business running!
>>> 
>> An LIR assigns addresses to its customers. That is how the 
>> allocation/assignment model works. Selling PA addresses isn't part of that. 
>> And besides: you can only sell allocations to other LIRs, so those 
>> "customers" have to be LIRs anyway, so they can get their own /22.
> 
> Again, selling PA is out there and there are many here on the list proud of 
> it.
> We were in Bucarest celebrating this good manner of JUMP Management making 
> space available to their end users signin up as new members.
> 
> Second: avoid my customers to sign up and waste a /22 while needing only a 
> /24 was exacly the purpose of 2015-05
> I tried to explain everyone (with Radu who shared the same point about this) 
> that many customers are signin up wasting space just for the needing of a /24.

Then assign /24s, or even smaller, to your customers from your PA allocation. 
That is what it is for!

> This customer is mine not yours. And what you want me to have no address 
> space to serve him so we can let him create his own 

Re: [address-policy-wg] Support for 2016-03 v2.0

[Sander Steffann]

Hi Yuri,

> If you will look into the future - all last 185 will be FINAL.
> And all LIRs will have to return the space or use it and pay to RIPE for
> usage even they work as with PIs as PI.
> reserved space also will be FINAL.
> 
> But then after some due to space exchange under ripe more and more space
> will become FINAL. So transfer policy will conflict with the space.

You seem to be under the false impression that all space transferred will also 
be marked ALLOCATED FINAL. This is incorrect, this policy only marks the /22s 
handed out by RIPE NCC as such.

> My opinion - just make easier for new companies to get IPs until RIPE
> has it and RIPE has enough. So I don't understand why to make life
> harder but not easier.

This is out of scope. We already discussed a policy that tried that and it 
didn't get consensus.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Riccardo,

> Teorically not, but practically creates class-b LIRs. I am against 
> speculators but I would not like discrimination between old and new LIRs.

There is none, please stop repeating that.

> I wouldn't like to be discriminated. You would like to be?

This is a ridiculous statement. Enough.

Every LIR is the same with the same rights. Under the proposed policy every LIR 
gets a /22, and no LIR can sell that /22. 

What you keep complaining about is that new LIRs can't get as many IPv4 
addresses for free as LIRs that started before September 2012. That is just the 
way it is. Policy changes over time, and things that were possible in the past 
are no longer possible today. Circumstances change. If we (the community) 
hadn't changed the policy like that then there would be no addresses to give 
out at all anymore.

But all of that has nothing to do with this policy discussion. In your previous 
message you spoke about the bottom up process, that it means that everybody has 
to be listened to. That is almost correct.

What it means is that everybody is allowed to speak and have their arguments 
considered seriously. If those arguments are found to be false then they can be 
put aside, and nobody is required to keep listening to endless repeats of those 
same rejected arguments.

Cheers,
Sander

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Nick,

Not speaking in favour or against this proposal, just thinking about the 
possible effects:

> I'm against this because it conflicts with the core purpose of the RIPE
> registry, which is to ensure accurate registration of resources.
> Formally banning transfers will not stop transfers; it will only stop
> those transfers from being registered which will lead to inaccurate
> registry information.

I had the same feeling in the beginning, but after thinking about it a bit more 
I am not so sure anymore.

Not transferring the resources means keeping the LIR running to hold them. If 
the LIR closes then the resources go back to the NCC and the unregistered new 
holder will end up with empty hands. Both the cost of keeping the LIR open 
(which will rise beyond the cost of "legally" buying space after a few years) 
and the risk for the receiver to lose their address space if the seller stops 
paying the NCC membership fee are strong incentives to just stop trading in 
ALLOCATED FINAL space.

And M is still possible if people really want to move this address space 
around, and that will make sure the registration is updated.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Aleksey,

> And will lose his money

The money is a membership fee that allowed them to hold resources while they 
were a member. Stop being a member = stop holding resources. Allocations are 
for running networks with, not making money...

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi,

> My suggesting is instead of removing the main problem (i.e. "lack of IPv4
> for those who need"), please bring policies on the table which help those
> who really require IP, can get IP.

I wish we could, but IPv4 has run out. If we went back to the previous 
allocation policy and would hand out addresses from the pool based on bed then 
that pool would be empty in a month or two, and then we would be in a worse 
situation than we are now because then even handing out a /22 to a new LIR 
would be impossible.

We allowed transfers to get unused allocations back in use. If you need more 
than your /22 then that is where you need to go. RIPE NCC doesn't have enough 
addresses to give everybody what they want.

Cheers,
Sander

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

[Sander Steffann]

Hi Ricardo,

> If your read again 2015-05 you can easily find out that is not so silly.
> Currently the only reasonable objection about 2015-05 is that may  (I 
> underline may) speed up the allocation rate.
> Please note that this ojection is based on the insinuation [...]

Ok, this is enough. This is not an insinuation. There have been plenty of 
numbers that show the effects that 2015-05 will have. They have been discussed, 
and there is clearly no consensus.

Let's stop this right here. It is clear that 2015-05 doesn't have consensus and 
never will get consensus. I am sorry, you have done your best to get this 
policy proposal through the process, but you didn't succeed.

We are going to discuss which direction to move in on Thursday at the RIPE 
meeting. We will report to this list based on that.

But don't start saying that the objections to your policy proposal are 
insinuations...

Cheers,
Sander

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

[Sander Steffann]

Hi Tore,

> In order to facilitate growing your business beyond three customers, [...]

Please don't exaggerate like that. I understand what you mean, but please don't 
make it personal.

> In any case, it is inevitable that at some point in time the RIPE NCC will 
> simply not have any IPv4 address space to give you, regardless of what the 
> policy allows. What will you do then, exactly? And why aren't you already 
> doing it today?

Good point, this is what we should focus on. The IPv4 business model used over, 
we need to look at sustainable solutions.

Cheers,
Sander

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

[Sander Steffann]

Hi Ricardo,

> I am not expecting consensum. I just want to be serius about the 
> considerations and the discussion that can come to some costructive for 
> everyone.

We have had that discussion here on the list. Let's finish this with a 
constructive discussion on Thursday.

> Someone choosed to turn it into joke and irony.

After talking about a policy proposal that is not leading to consensus for 
multiple discussion periods, I can't blame them. People seem to want to close 
this discussion. Let's do so on Thursday and discuss where to go from there.

Cheers,
Sander

[address-policy-wg] Agenda for APWG sessions at RIPE 72

[Sander Steffann]

Hi APWG folks,

below you can find a draft for the RIPE address policy WG meeting's
agenda, which will take place in Copenhagen in the following time
slots:

Wednesday, May 25, 09:00 - 10:30
Wednesday, May 25, 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.

The distribution of items to the two timeslot is somewhat subject
to the time spent on discussion - but we'll try to stick to what's
published.

regards,

Sander Steffann,
Gert Döring
APWG chairs


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

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


B. WG Chair Selection   10 min
- longest-serving chair (Sander Steffann) stepping down
- willing to be re-appointed and serve another term


C. Current Policy Topics - Marco Schmidt, NCC PDO   25 min

- 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 71

- brief overview over new proposals

  2016-01 (AAWG) Include Legacy Internet Resource Holders in
 the Abuse-c Policy

  2016-02 Resource Authentication Key ( RAK ) code for third
  party authentication

  2016-03 Locking Down the Final /8 Policy


F. Discussion of open policy proposals  50 min

2015-04 RIPE Resource Transfer Policies
Erik Bais

2015-05 Revision of Last /8 Allocation Criteria
Discussion phase not leading to consensus

2016-03 Locking Down the Final /8 Policy
Remco van Mook

- Discuss the direction of our IPv4 allocation policy in general:
  Is it good enough, do we want it to be more liberal, or do we
  want it to be stricter?


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

Welcome back

G. Market concentration in the transfers of IPv4 space  30 min
Alain Durand and Gabe Fried


D. Feedback From NCC Registration Service - Andrea Cima 45 min
(+ discussion with the group)

- IPv6 /48 potential policy bug
- Update on ALLOCATED PI/ALLOCATED Unspecified
- Legacy transfers straight after Inter-RIR transfer
- Why RIPE NCC asks for prefix to be announced during ASN request
- IPv4 IXP assignments
- LIRs collect multiple IPv6 allocations


Y. Open Policy Hour 15 min

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi everybody,

> We have had that discussion here on the list. Let's finish this with a 
> constructive discussion on Thursday.

The RIPE meeting has just started its second day, and my brain has already 
melted down.
s/Thursday/Wednesday/

Repeat: the session is on WEDNESDAY

Sorry for the confusion

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] agreement

[Sander Steffann]

Hello Ehsan,

> we are agree about the Last /8 Allocation Criteria Revision proposal .
> https://www.ripe.net/participate/policies/proposals/2015-05

thank you for expressing your support. However, at this point in the discussion 
we have seen enough support but not enough work solving the objections that 
have een raised. That is what is needed currently to work towards consensus. 
Without addressing those objections this policy proposal gets stuck.

> RegID: ir.shnt

You don't need to state your RegID in this working group. This working group is 
open to all interested parties, not just RIPE LIRs. Discussions are always 
between people, not organisations.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] agreement

[Sander Steffann]

Hi Peter,

> My main objection to this proposal is simple:  It depletes the available
> pool for _new_ participants faster.  I strongly believe any new actor
> should be able to go from zero to non-zero with the addresses available
> from RIPE.  For an actor with non-zero addresses to get more addresses,
> there is a secondary market.

Indeed. It all comes down to "the needs of those in the next few years with no 
IPv4 addresses" vs "those today who have only one /22".

> Since that is the base of my objection, I do not see any way that a
> middle ground can be met.  Based on my understanding of the other
> objections, I believe this is held by at least a few others from the
> objection side.

Well, to make a useful discussion possible I think it's important to look at 
the timescales. A policy that changes expected depletion from e.g. 100 years to 
90 years might not be a problem, but other timescales will definitely be a 
problem.

I think the timescale I have heard that people would find acceptable is *at 
least* 5 to 10 years. If you look at the minutes of RIPE 70 
(https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a 
statement from RIPE NCC when discussing this policy proposal that "the RIPE 
NCC’s IPv4 pool was expected to last for around five years.".

> I appreciate the effort put into this proposal, but I do not think any
> solution can be proposed.

The stated expected timescale already seems to be around the bare minimum 
lifetime that is accepted, and much less than what many people would like. I 
therefore have to agree that any proposal that shortens that lifetime even 
further will very probably not get consensus.

Someone would need to come up with a radical new idea to get out of the current 
deadlock. Which is why I urge all new participants in this discussion to read 
the mailing list archives so they can get the full current picture before they 
propose a solution.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi,

> Op 12 mei 2016, om 15:48 heeft Randy Bush  het volgende 
> geschreven:
> 
> it's not just our grandchildren.  if the last /8 policy had not been put
> in place and taken seriously, *today's* new LIRs might not be able to get
> IPv4 space.

True. Without the current policy that started with 185/8 the NCC would have run 
out somewhere between December 2012 and January 2013 (based on an allocation 
rate of ±3.5 /8s per year, which was the rate at the time). Everybody who got 
any address space from the NCC after September 2012 should be happy that their 
predecessors took their needs into account ;)

Cheers!
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

[address-policy-wg] Draft agenda for RIPE 72

[Sander Steffann]

Hi APWG folks,

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

Wednesday, May 25, 09:00 - 10:30
Wednesday, May 25, 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.  So far, the agenda is fairly
light - if you have something you want to address, or that bothers you,
let us know and we make room for you :-)

The distribution of items to the two timeslot is somewhat subject to
the time spent on discussion - but we'll try to stick to what's published.

regards,

Sander Steffann,
Gert Döring,
APWG chairs


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

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

B. WG Chair Selection

C. Current Policy Topics
   Marco Schmidt, NCC PDO

F. Discussion of open policy proposals


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

Welcome back

G. Market concentration in the transfers of IPv4 space
   Alain Durand and Gabe Fried

D. Feedback From NCC Registration Service
   Andrea Cima

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi Riccardo,

> Please explain how the current policy obtained a "success", luck? Why such 
> policy was accepted and reached its consensum at that time?

I can answer that one.

For 2010-02 (https://www.ripe.net/participate/policies/proposals/2010-02) the 
WG started working down from one /8. Then the proposal started RIPE NCC had 
±7540 LIRs. Using a /22 per LIR would allow for 16000 LIRs, so more than double 
the amount at the time. A /16 of address space was set aside for unforeseen 
circumstances, and the policy states that that reservation would become part of 
the main pool if not used for such unforeseen circumstances when the pool runs 
out.

I think Daniel's comment at the time sums it up quite nicely:
> And we have to care about new LIRs, we need to reserve some address space for 
> them - as lots of internet resources will be accessible only over IPv4 for 
> long period after depletion. It's about survivance of free allocatable IPv4 
> address space as long as possible.


2011-03 (https://www.ripe.net/participate/policies/proposals/2011-03) updated 
the policy regarding returned address space. If I remember correctly the 
arguments on the list at the time were that by putting all the returned address 
space in the same pool as 185/8 it was made sure that we wouldn't end up in a 
policy limbo where it was not clear which policy applied to which IPv4 
addresses.

Another good quote, Dave wrote about 2011-03:
> And, frankly, we should take every opportunity remaining to expand the meagre 
> pool of IPv4 addresses we leave to our children.


And that's how we arrived at today's policy.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] I support this policy

[Sander Steffann]

Hello,

Welcome this this working group. Might I ask you to introduce yourself? Your 
info@ email address and the lack of a name in your message make it difficult to 
understand who you are.

> I support this policy

Which policy are you talking about?

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] Disabuse

[Sander Steffann]

Hi Borhan,

> My name is Borhan Habibi and my company name is Rayanravesh Sena, I sent my 
> first email without noticing it has wrong from address field, so thought it 
> would be better to resend it with my own name.

FYI: Your mail client still send mail from Rayanravesh Sena 

> I'm just one person, Hope it is clear to you and any one else got confused,

The number of people doesn't matter that much anyway in the RIPE Policy 
Development Process. Decisions are based on consensus, not on number of "votes".

To help a policy proposal forward the objections to the proposal have to be 
addressed. At this point in time we have many people saying that they like 
2015-05, but also many people objecting to i.e. not leaving enough space for 
newcomers in the years to come. Extra people saying +1 or -1 is not helping us 
forward now, this working group needs to discuss to see if there is a way to 
remove the raised objections.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Elvis,

>> I've had easier discussion to judge, and less repetitive-nonsensical ones.
> 
> it says awaiting decision from proposer and not from WG Chairs. That is why I 
> was asking the proposer.

Just for clarity, this is what the PDP says:

> [RIPE-642 section 2.2]
> At the end of the Discussion Phase, the proposer, with the agreement of the 
> WG chair, decides whether the proposal will move to the next phase (Review 
> Phase) or if it should be withdrawn from the RIPE PDP, depending on the 
> feedback received. This should be done no more than four weeks after the end 
> of the Discussion Phase.


So the chairs need to make up their minds about if they can agree with the 
proposer. This involves a lot of manual work (as Gert said: analysing the 
mailing list archives etc) so this takes time. The discussion phase ended on 15 
July. And the four week period that is common for that type of decision hasn't 
expired yet. And even if it had, it says "should be done" not "must be done", 
so if we stick to the definitions of RFC2119 that timeline may be changed if 
circumstances require.

In short: if you're going to be pedantic please read the relevant documents 
first. The discussion phase has ended. The microphones are closed. And give 
your chairs some breathing room to do their (volunteer) jobs properly.

Cheers,
Sander

PS: because I got involved in the discussion and questioned some people's 
statements to keep the discussion honest I am abstaining on any decisions 
regarding this proposal to avoid any semblance of conflict of interest. This 
means Gert is doing all the hard work all by himself...



signature.asc
Description: Message signed with OpenPGP using GPGMail

[address-policy-wg] 2016-05 going to last-call (Synchronising the Initial and Subsequent IPv6 Allocation Policies)

[Sander Steffann]

Hello Working Group,

The last review phase of 2016-05 (Synchronising the Initial and Subsequent IPv6 
Allocation Policies) has just ended, and for this policy proposal a quick 
decision of the working group chairs was easy. There has only been positive 
feedback from you so we have declared consensus and asked the RIPE NCC to move 
the proposal to the Last Call phase.

The positive feedback to the current version was from:
- John Collins
- Ian Dickinson
- Sascha Knabe
- Martin Krengel
- Frank Meyer
- Mathew Newton

Thanks to the working group for working on this proposal,
Sander Steffann
RIPE APWG co-chair



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

[Sander Steffann]

Hi Ingrid,

> If there is a /16 “ALLOCATED UNSPECIFIED” block that contains "real" Provider 
> Independent assignments, that /16 would indeed be split in order to carve out 
> that assignment. The LIR would end up with multiple PA allocations instead of 
> one /16. The PI resource holder would be able to decide who their sponsoring 
> LIR should be. It is possible that they would remain with that same LIR, or 
> they could move to another sponsoring LIR and take their PI assignment with 
> them. If the resource holder is an LIR themselves, the PI assignment could be 
> registered under their own LIR account.

So in the current situation such a PI resource holder has "Provider 
Independent" space, but only if they stay with the LIR that holds the ALLOCATED 
UNSPECIFIED. After the change the PI holder will have a normal PI assignment 
that they can register with any sponsoring LIR they want.

So I guess that PI holders will be happy about this, it turns their "kind-of" 
PI into "real" PI.
And the affected LIRs might be less happy because they lose some grip on their 
customers.

And then there seem to be cases where the ALLOCATED PI/UNSPECIFIED is used more 
like PA space (managed, aggregated and routed by the LIR) in which case 
converting it to ALLOCATED PA might be more reasonable (for route objects, ROAs 
etc) but that might make the "PI" holder less happy. Although in such a case it 
seems to me that the address space isn't really independent to begin with, so 
in reality things will probably remain the same for them, just better formally 
documented.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] Idea for aggregating IP addresses

[Sander Steffann]

Hi,

> "non-continuous IPv4 blocks be exchanged for the equivalent size in a single 
> continuous IPv4 block"

I think the problem with this is that it let's spammers exchange dirty blocks 
for clean blocks.

Cheers,
Sander



smime.p7s
Description: S/MIME cryptographic signature

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi,

> Op 19 okt. 2016, om 14:59 heeft Peter Hessler  het 
> volgende geschreven:
> 
> Ciprian
> 
> You have invoked Nazis and Hitler in two different emails to this list.
> 
> This is incredibly offensive, for so many reasons.

Ok, this is indeed going too far. Time for an official warning from the chairs.

Ciprian: your language and analogies are unacceptable on this mailing list 
(well, any mailing list as far as I'm concerned, but I only chair this one). As 
Peter said:

> You need to calm down, and think very serious thoughts about your behaviour 
> on this list.

On the positive side: I didn't know about Godwin's Law, so I learned something 
today :)

Thank you,
Sander
RIPE APWG co-chair



signature.asc
Description: Message signed with OpenPGP using GPGMail

[address-policy-wg] ALLOCATED PI / UNSPECIFIED next action

[Sander Steffann]

Hello working group,

The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED 
UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is 
time to draw conclusions.

A total of 16 people and the working group chairs participated in the 
discussion following Ingrid’s proposal on how to handle the situation of PI 
assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, 
Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created 
side-threads without expressing an explicit opinion on the proposal.

The remaining 11 people were:
−Patrick Velder
−Larisa Yurkina
−Randy Bush
−Enno Rey
−Herve Clement
−Stefan Schiele
−Markus Weber
−Carlos Friacas
−Leo Vegoda
−Andre Chapuis
−Daniel Stolpe
−Oliver Bartels

Four participants stated that they represent organisations holding such 
allocations (Larisa, Markus, Andre and Daniel).
Three people indicate that they are related to PI assignments within such 
allocations (Enno, Stefan and Oliver).

Five people stated their clear support for the proposal (Enno, Stefan, Oliver, 
Patrick and Herve), mainly to increase clarity for PI assignment user and to 
support correct registration.

While there was no explicit opposition, Larisa and Andre stated that it would 
create extra workload for their organisations while they don’t really see the 
gains of such change. Larisa suggested to introduce alternative RIPE database 
statuses instead.

The other participants had mixed opinions:
Markus understands the advantages for PI assignment users, but was concerned 
about the extra workload for his organisation. He suggested to somehow lock 
PI’s within the allocations and force the PI holders to sign contracts, but 
recognized that this idea might be not practicable.
Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed 
with Larisa and Andre that there is actually no issue to be fixed.
Randy supported the aim of correct registration but also stated his concerns 
about the routing table and that some PI holders might not be happy to pay a 
fee for the sponsoring LIR.
Carlos also stated his concerns for the routing table.

Conclusion:
Five people supported the proposed approach, four people saw some advantages 
but also were concerned about side effects, while two people didn’t see the 
need to take action.

There were three opposing arguments:
- big workload compared to the gain
- increase of the routing table
- PI holders might not like to pay a fee for the sponsorship

The first opposing argument can be considered as addressed as three PI users 
confirmed that a clarification of that issue would be very important to them. 
And the RIPE NCC can support the LIRs, for example making bulk updates on route 
and domain objects.

The second opposing argument, could be considered that this is not directly 
related to the fixing of the registration. Already now all but one of the 
allocations in question contain more specific route advertisements. Also in the 
extem case that all ASSIGNED PI within the allocations would be carved out, we 
would talk few thousand new entries in regards to 628K total routing entries 
(normal growth of the routing table is around 2K per week).

The third opposing argument was addressed by Gert, stating that PI holders 
appreciate to pay a small fee to be sure that their resources are correctly 
registered.

Based on all of this I feel we have a strong enough mandate for the RIPE NCC to 
move forward, but some concerns about the amount of work involved. I therefore 
would like to ask the RIPE NCC on behalf of this working group to move forward 
with their plan, but to extend the proposed deadline of the end of January 2017 
by a few months (the end of Q1 2017) to give LIRs a little bit more time if 
needed.

Cheers,
Sander
APWG co-chair



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

[Sander Steffann]

Hello Elvis,

> Therefore, I think that the RIPE NCC should talk to every single company
> holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give
> them the option to give up on the maintenance of the IPs (and the right
> to transfer/sell) and transform them into ASSIGNED PA, or become a PI
> user - like all the others in the world - and sign a maintenance
> agreement with a LIR (and have the €50/year associated cost).

The message Ingrid sent on the 4th of August already stated: "The WG agreed 
that, where the LIR can document a mutual agreement that they administer the 
address space, a conversion from PI to PA should take place. In all other 
cases, assignments with the status ASSIGNED PI should be treated as being 
assigned by the RIPE NCC."

So no need to talk to each and every resource holder. The responsibility is 
with the LIR to show documentation, and the default is to convert the 
assignment to normal PI. And that is as far as we need to go here. The rest are 
implementation details and should be left to the RIPE NCC. Let's not 
micro-manage who exactly they should talk to.

So to summarise: I think what you want is already part of what the RIPE NCC 
proposed, modulo implementation details. So the previous message holds: RIPE 
NCC, please move ahead.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi Erik,

> Going into that kind of thinking would be similar to not allowing external 
> voice calls to IPv6 PI assigned phones, because some third party should be 
> able to make use of it..
> 
> This discussion is different if we are actually (commercially) hosting 
> services on a (semi)permanent basis on the PI assigned space... like if a 
> third party is actually offering webservice hosting or voip services over 
> that WIFI ..

And there is where it gets complicated :)

A bit of history:

The IPv4 policy had the text "IP addresses used solely for the connection of an 
End User to a service provider (e.g. point-to-point links) are considered part 
of the service provider's infrastructure. These addresses do not have to be 
registered with the End User's contact details but can be registered as part of 
the service provider's internal infrastructure."

This "loophole" made it possible for IPv4 service providers to connect users to 
their network without making a separate assignment. Originally the idea was 
that the interconnect wasn't an assignment but the address space routed over 
that interconnect was. Cases where a single 3rd party server was connected were 
also not considered assignments because of this rule.

Then IPv4 NAT came along, and most residential ISPs started to not assign 
addresses to customers at all anymore: they only got the interconnect and were 
expected to NAT using the interconnect's address. That made it possible for 
ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed 
the loophole for (IIRC) two reasons:
- it was considered unfair that some ISPs used cheap PI addresses while others 
paid for running the NCC (this included hosters using PI space as well as 
access ISPs)
- the fear that allowing interconnects on cheap PI space would encourage ISPs 
to force their users to use NAT on IPv6

This of course forced all ISPs to use PA space, but situations where the "ISP" 
vs "End user" boundary wasn't the classical one had problems. This was 
discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf 
starting at slide 9, it took me a lot of effort trying to find that one, I 
couldn't imagine it already being 5 years ago) and because of that an effort 
was started to stop distributing different "colours" of address space and unify 
PA and PI.

Unfortunately that effort failed because it turned out to cause too many 
complications (see 
https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf),
 which is why we are at the current policy and interpretation as presented 5 
years ago:

> - No DSL
> - No Cable
> - VPN
> - No co-location
> - No virtual servers
> - No SSL hosting
> 
> No buts and no exceptions

And that's where we are today, and what this policy proposal is trying to 
change.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Arash,

> I understand your point, but this already happened with other RIRs and they
> have no "cheap" pool to fulfil new requests, what happened them and to the
> prices in their region? Do we have many intra-RIR transfers from RIPE region
> to other RIRs today? 

Good question. I'm sure the NCC will include such numbers I their presentation 
next week. I'm curious about that as well.

> Luckily we still have an /8 in RIPE (and thanks to the old community members
> for that), but 2016-03 cannot make that much change on draining rate. And I
> don't think that the pool is that much drained by traders. Yes there is a
> percentage drained by traders, but comparing to the actual users that's not
> that much to put this kind of restriction. (We also have enough other
> restrictions in place)

Thanks for setting a good example of how to discuss policy proposal effects in 
a civil way. I completely understand your reasoning, and this is useful 
feedback.

Thank you!
Sander

(After all that has happened on this list recently I felt I had to encourage 
good discussions as well. I don't want to sound negative all the time :)

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi,

> Yes, thanks to old members who didn’t care about the future of others and 
> made this mess.

Please read my previous post.

> Thanks to members like http://ipv4.stil.dk and many many more who requested 
> huge amount of IP space without a real need, now selling them for profit.
> 
> Thanks to traders like Elvis and Ciprian the problem evolved, but they just 
> used an open door and following the rules.

No ad hominem attacks on this list

> While some of you are techies in some ISP or even having your own business, 
> working hard for you, family, employees, making money, some company/IP trader 
> made a huge amount of money in a short amount of time ‘selling’ IP’s.
> 
> You, old members, knew before ’90’s and ’00 that the IP Space will exhaust 
> between 2005 and 2011, and you still permitted allocations with almost no 
> real proof of needing from the requester/LIR.

Those statements are false, please see the archives.

> This policy will not slow traders, and I think it will really affect the new 
> members that really needed the IP Spaces.

How? If they need the addresses then a policy that says that they can't sell 
them won't have any effect on them.

> A policy that tightens the allocation procedure with real verifications might 
> be better.
> 
> I do not support this policy

Sorry, for participating in a consensus based discussion you need to come up 
with arguments and valid training that can be discussed. Your message only 
contains ad hominem attacks and wild and inaccurate statements and is therefore 
for useful for the policy development process.

This working group is open to all for discussing policy development, but 
messages like this do not qualify as "discussing".

Cheers,
Sander

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Sorry, bad auto correct:

> [...] need to come up with arguments and valid training

That should be "reasoning"

> that can be discussed. Your message only contains ad hominem attacks and wild 
> and inaccurate statements and is therefore for useful

That should be "not useful"

> for the policy development process.

Sorry for the typos,
Sander

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

[Sander Steffann]

Hi Kai,

> So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by 
> the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as 
> long as each WiFi user only gets less than a /64 »assigned«?

That's what the proposal currently says. 

> Proposal states: »Today, organisation networks usually include some kind of 
> guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to 
> customers’ sites, or anything similar where devices of non-members of the 
> organisation would get assigned an IP out of the organisation’s prefix.«
> 
> These days I configure P2P links as /64 (with ::1 and ::2 being the 
> endpoints), because ... people actually tried to hit me with cluebats when I 
> carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). 

Actually, using a /127 for point to point links is pretty common. There is even 
an RFC about it (https://tools.ietf.org/html/rfc6164). I use it a lot, also I 
the training courses I give. I reserve the whole /64 in the numbering plan just 
in case, but on the link I usually configure ::a/127 and ::b/127. 

> So, even after this proposal, I am not allowed to use my IPv6 PA or PI space 
> to build P2P-links outside my organisation, e. g. for peering, with a netmask 
> of /64? But at least anything above /64 (read: /127) in PI would be ok, which 
> currently isn't, neither for PA nor PI?

Technically, yes. I still have to re-read the PA bit, because I'm not sure 
about that. I'll reply to that later.

Cheers,
Sander

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

[Sander Steffann]

Hi Leo,

> So prefix delegation is OK as long as the prefix is longer than a /64?

Technically that's what the proposal is currently proposing. I'm curious about 
the opinions of working group members about that.

Cheers,
Sander

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Arash,

> If old businesses depend on selling IPv4 address to new comers and now
> looking to put some more value on their old blocks, their strategy should
> not be supported by 2016-03.

I'm sorry, but it's doing the opposite: it will make sure that the remaining 
pool is not drained by traders, keeping it available for longer for new 
companies that need them. If the "cheap" pool for newcomers runs out and 
address transfers become the *only* source for addresses, guess what will 
happen to the prices.

Cheers,
Sander

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Ciprian,

> I've heared this story over and over. Let's protect the pool, let's not waste 
> it and now, after 4 years the pool is almost the same size.

The only reason that the pool is the size it is is because we received some 
last scraps from IANA. The number of addresses coming from IANA are less and 
less each time, so that's not sustainable. Without that the pool would be more 
than half empty by now.

> Again, what is our purpose here ? Where is the imagined abuse ? Bring up some 
> actual statistics not fake scary scenarios.

I have no purpose but to keep discussions on this list productive and honest. 
I'll leave the statistics to the working group session and the authors of the 
policy proposals.

Cheers,
Sander

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

[Sander Steffann]

Hi Radu-Adrian, 

> ... and this is where technical implementation comes and messes things
> up
> If you are functioning in "subscriber management" mode, you equipment
> may impose you that each subscriber has its own subnet for
> interconnection (mine does) - obvious choice being a /64.

I think that that's perfectly in line with the current policy: if you have 
subscribers then you need to get PA addresses. The current policy proposal is 
not trying to change that. But using a /64 for an interconnect is not 
unreasonable in other circumstances such as VPN connections between two 
enterprises etc.

Cheers,
Sander

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

[Sander Steffann]

Hello Ciprian,

> It is also beyond the scope of this policy regulating what can be done with 
> resources and we're still discussing it. Let's stick to the policy's scope 
> and start a new one with proper debates over this issue.

Please leave it to the chairs to determine what is in scope for being discussed 
and what is not.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hi Ciprian,

> There is, though, an important thing which I think the policy needs to 
> address. The broker should be allowed to discuss with ripe on behalf of his 
> customers. It has happened several times that we had customers who don't 
> understand english very well and many times they would just ask us to write 
> the reply and they would simply copy/paste it. It would help if ripe would 
> allow us to directly pass on information and answer ripe's questions.

Your customer can add you as an official contact in the LIR Portal if 
necessary. That is the way LIRs can define who is permitted to speak on their 
behalf. I have done that in the past: got added as a contact, handled the case 
for them, and then was removed as a contact again. I can imagine that not all 
LIRs are comfortable doing that, but in that case the communication should go 
through the LIRs existing contacts anyway. 

As there are already existing authorisation mechanisms for who can speak on 
behalf of an LIR I don't see the need to create a new one specifically for 
brokers.

Cheers,
Sander



smime.p7s
Description: S/MIME cryptographic signature

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

[Sander Steffann]

Hi Ciprian,

> Actually there were cases where we did like that, being put as a contact for 
> the LIR. I don't think this should be the solution as it doesn't seem 
> adequate at least. There were also cases where we would have to "speak" on 
> behalf of both parties so it would be awkward if not unprofessional to be a 
> contact person for both sides.

This sentence does not parse. You have to speak on behalf of parties but you 
cannot be a contact person for them? That doesn't make sense. If you feel that 
is awkward or unprofessional to speak on behalf of both then don't. Get a 
separate broker that represents the other party. But in what you wrote above 
you contradict yourself.

> From our experience the need is just to "translate" (figurative and not) the 
> messages between NCC and LIRs. It is a situation we meet often and I think it 
> should be addressed in a clear procedural way. I don't agree with using 
> tricks.

This is not a trick. If you can speak on behalf of an LIR then you are a 
contact and should be registered as such.

Cheers,
Sander



smime.p7s
Description: S/MIME cryptographic signature

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hello Sergey,

> If I am not wrong, the main idea of the NCC is to switch to IPv6
> networks. But it strongly tries to stretch this process.

You seem to misunderstand how this works. It is the community that sets these 
policies, not the NCC. The RIPE NCC implements what the internet community (us) 
wants it to do. The NCC definitely isn't stretching the process of getting IPv6 
deployed, quite the opposite.

> So I opposite this proposal.

Noted.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Sander Steffann]

Hi Mikael,

> These post-2012 members would have ZERO IPv4 addresses from RIPE NCC if it 
> wasn't for the Last /8 policy, we would have completely exhausted in 2012 
> without this policy.
> 
> So they were only able to get addresses at all because these addresses were 
> saved to be used under different policy, thus under restrictions.
> 
> I was one of the proponents of this. I have subsequently changed my mind and 
> I am now of the opinion that we should not have any /8 policy at all, and 
> just hand out the rest of the IPv4 space to current LIRs and let the market 
> handle the rest. It's obvious from the discussions here that most people do 
> not appreciate the intention behind the last-/8 policy, and our attempts to 
> try to help new entrants into the market has failed.

I share your sentiment. It's tempting to assume that all the new LIRs are 
ungrateful and don't appreciate what this community did for them before their 
companies even existed, and that we therefore failed. I still resist that 
temptation and hope that the silent majority is actually appreciative that we 
didn't leave them in the cold.

> So let's just get it over with and exhaust all the rest of RIPE NCC free 
> addresses immediately by some scheme to divvy up whatever free resources are 
> left to the members and after that, let all restrictions go.
> 
> If we're actually exhausted then some people might get on with deploying 
> IPv6, I hear some people not deploying because they see that RIPE isn't 
> completely exhausted yet.

Yeah, I have heard that repeatedly over the last couple of years. I'm still 
explaining that the remaining IPv4 resources are a special-case so that 
newcomers get a small foothold in the IPv4 world as part of their NCC 
membership and not be left completely to the whims of the market. That there is 
a remaining pool doesn't mean it's business as usual, or that that pool should 
be used as a cheap source of an expensive resource for sale on the market. Some 
people seem to have trouble understanding that.

It's indeed disappointing that not all current participants share the selfless 
principles of the ones that made the policies before them. But those principles 
and fair policies are what I'm still fighting for.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hello Marius,

> Over the last years RIPE NCC has imposed a "rule" that when the last IPs are 
> transferred the transferring LIR has to pay the full annual membership fee 
> (even if the LIR was not a member of RIPE for that entire year). I think that 
> if this is something everybody agrees with, it should be inserted into the 
> policy text to make this very clear. But if not, then maybe it would be 
> useful to add a text which would simply say that RIPE NCC should relate 
> exclusively on this policy when processing transfer requests and is not 
> mandated by the RIPE community in imposing any kind of abusive taxes.

I'm sorry, but RIPE NCC membership related issues are off-topic for this 
working group. That includes calling the RIPE NCC membership fee structure 
"abusive taxes".

> I also have a problem with the 24 months period of keeping the IPv4 addresses 
> after merging 2 companies. It's exactly our case, we want to buy and merge 
> with a telecom company and we will no longer need all their IPv4 addresses 
> since we have more than enough by merging both companies resources. We want 
> to transfer a part of the IP addresses to other Company that really need 
> them. Why to wait 24 months?

Because the community decided that addresses can only be transferred is the 
intention is to actually use them, and to prevent companies from buying and 
selling address space just to make a profit. Your choices are to sell the 
resources before merging so they can be used by someone else who needs them, or 
keep them and use them yourself. First acquiring them only to immediately sell 
them again is explicitly not allowed by RIPE policy.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Sander Steffann]

Hello Marius,

> Thank you for the explanations, but I believe you haven't really addressed 
> the issues I mentioned.
> The first issue is ABOUT Transfer Policies, to pay the annual membership fee 
> after you TRANSFER ALL YOUR RESOURCES and maybe even close your Company, is 
> about Transfer Policies.

No, that is about your contractual agreement with the RIPE NCC.

> Your second answer is very subjective, have you ever buy and merge Companies? 
> I've done that a couple of times, you never sell the company's (you merge) 
> resources before the merge, because that company doesn't belong to you before 
> the merge and is not you to decide regarding selling anything of that Company 
> resources, either that is IP or fiber optic cable. Is NOT AT ALL what you 
> mention:"First acquiring them only to immediately sell them again is 
> explicitly not allowed by RIPE policy". What this have to do with the 
> situation I mention ??? Please refer to the situation I mention, not on other 
> matters that have nothing to do with it.

This is exactly the situation you mention: you buy a company, acquiring all 
their assets. One of those assets is an IPv4 allocation from RIPE NCC. To 
prevent speculation with IPv4 resources it is not allowed to sell those 
resources within 24 months of acquiring them.

So in your case: buy the company, keep it running as a separate company/LIR for 
a little while, sort out where you want to transfer the resources you don't 
need, then merge the companies/LIRs.

So, no problem.
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

[address-policy-wg] Proceeding with proposal 2016-04 (IPv6 PI Sub-assignment clarification)

[Sander Steffann]

Hello working group,

The end of the discussion phase of proposal 2016-04 (IPv6 PI Sub-assignment 
clarification) has been reached. At this point in the PDP the proposer, in 
agreement with the working group chairs, decides whether to move forward.

The chairs have determined that we have general consensus that the use-cases 
described in the proposal are valid ways to use PI space and the policy should 
reflect that. However there has been discussion on the exact way to fix the 
policy.

The proposer has told us that he wants to continue with the current proposal 
and continue to the review phase. We decided to agree with this and go to 
review phase. The RIPE NCC will make an impact analysis and based on that we 
can continue the discussion on the list, review the proposal and where 
necessary adjust the exact wording of the proposal.

Cheers,
Sander & Gert
Your working group chairs



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [address-policy-wg] Agenda for APWG in Dubai (v1)

[Sander Steffann]

Hello Working group!

> ** NOTE FOR SPEAKERS[1] **
> 
> After Dubai had already been chosen as the location for the upcoming RIPE 
> meeting, the authorities there (DTCM) have started to enforce some rules for 
> conferences and speakers. All speakers (including remote speakers) will need 
> to email the following information to meet...@ripe.net before 15 September 
> 2017):
> 
> - Full name, title
> - A colour copy of their passport
> - A copy of their Emirates ID (if a UAE resident)
> - Profile/bio for the speaker (at least 200 characters)
> - Mobile number
> - Email address
> 
> This information will then be forwarded to the DTCM by the RIPE NCC.
> 
> We realise that these requirements go beyond what was expected at previous 
> meetings and that they may be a cause for concern for some people - 
> especially the sharing of colour copies of passports. Unfortunately there is 
> nothing we can do about this - we have to comply with local laws. If you do 
> not wish to comply with these requirements then you will not be allowed to 
> present on stage. You will still be able to join the discussions from the 
> floor.
> 
> [1] "Speakers" includes anyone who is presenting on stage - presenters, WG 
> Chairs, and community members who are chairing or moderating sessions. This 
> also includes policy proposers who are planning to present their policy. 
> Attendees speaking at the microphones during the Q are explicitly not 
> considered as speakers.

The RIPE NCC has negotiated with the authorities in Dubai, and has some good 
news for us. It is now confirmed that a photocopy of speakers' passports is 
*not* required. Residents of the UAE are still required to upload a copy of 
their Emirates ID (in jpeg format).

The information on https://ripe75.ripe.net/attend/dtcm-requirements/ has been 
updated. All attendees, and especially speakers, should take a look at that 
page to avoid surprises.

Speakers will be asked to upload the above data via a secure webform provided 
by the RIPE NCC, who will then pass it on to the DTCM. The data will be 
permanently deleted from the RIPE NCC
infrastructure one week after the RIPE 75 Meeting.

Cheers,
Sander Steffann
APWG co-chair



signature.asc
Description: Message signed with OpenPGP

[address-policy-wg] Agenda for APWG in Dubai (v1)

[Sander Steffann]

Hi APWG folks,

below you can find a draft for the RIPE address policy WG meeting's agenda,
which will take place in Dubai in the following time slots:

Tuesday, October 24, 09:00 - 10:30
Tuesday, October 24, 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.

Depending on the amount of "not yet known" things that show up on the
agenda, we might only need one time slot.  In which case, we can all
join the Connect WG for a change :-)

** NOTE FOR SPEAKERS[1] **

After Dubai had already been chosen as the location for the upcoming RIPE 
meeting, the authorities there (DTCM) have started to enforce some rules for 
conferences and speakers. All speakers (including remote speakers) will need to 
email the following information to meet...@ripe.net before 15 September 2017):

- Full name, title
- A colour copy of their passport
- A copy of their Emirates ID (if a UAE resident)
- Profile/bio for the speaker (at least 200 characters)
- Mobile number
- Email address

This information will then be forwarded to the DTCM by the RIPE NCC.

We realise that these requirements go beyond what was expected at previous 
meetings and that they may be a cause for concern for some people - especially 
the sharing of colour copies of passports. Unfortunately there is nothing we 
can do about this - we have to comply with local laws. If you do not wish to 
comply with these requirements then you will not be allowed to present on 
stage. You will still be able to join the discussions from the floor.

[1] "Speakers" includes anyone who is presenting on stage - presenters, WG 
Chairs, and community members who are chairing or moderating sessions. This 
also includes policy proposers who are planning to present their policy. 
Attendees speaking at the microphones during the Q are explicitly not 
considered as speakers.


Regards,

Gert Doering & Sander Steffann,
APWG chairs


--
Tuesday, 09:00-10:30
--

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


C. Current Policy Topics - Marco Schmidt, NCC PDO   20 min

- 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 74

- brief overview over new proposals
  (if any)


D. Feedback From NCC Registration Service - Andrea Cima 25 min
(+ discussion with the group)


F. Discussion of open policy proposals  30 min

2016-04 IPv6 PI Sub-assignment Clarification
   Maximilian Wilhelm

2017-01 Publish statistics on Intra-RIR Legacy updates
Elvis Daniel Velea


Y. Open Policy Hour 10 min

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

--
Tuesday, 12:00-13:30
--

Welcome back

F|Y|Z. If we overrun the first slot we continue here.



signature.asc
Description: Message signed with OpenPGP

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

[Sander Steffann]

Hi,

> So again, why do they rely on v4 (only) ? I really want to understand
> hurdles on european continent.

I think the hurdles are roughly the same in all regions. Relying on only IPv4 
is insanity, and those that do so deserve no sympathy. But as you have 
personally experienced IPv6 isn't available everywhere and for everything yet. 
Therefore everybody still needs some IPv4 to communicate with those laggards. 

This community has so far considered it its responsibility (statement based on 
current policy) to make sure new entrants can do so without having to rely on 
getting IPv4 addresses through/from third parties. For almost all participants 
on the internet having at least some IPv4 space is vital for at least the next 
decade. 

What they get is a tiny amount of IPv4 space from RIPE NCC when they sign up as 
LIR. So far that tiny amount has been a /22. Now that the end of those /22s is 
in sight this community has to choose. Either keep the current policy and let 
it run out completely and let newcomers fend for themselves (if possible, 
32-bit space is finite and at some point the market will dry up and IPv4 space 
will become unavailable/unaffordable) or change the /22 to /24 and keep giving 
newcomers a tiny bit of addresses for a while longer (what is currently being 
proposed).

This community doesn't face an easy choice: keeping some IPv4 addresses 
available for newcomers can send the wrong message, that IPv4 hasn't "really" 
run out. Letting RIPE NCC run out completely will definitely fix that. On the 
other hand that will also send the message that the current internet 
participants want to keep newcomers out, or at last dependent on the 
willingness of current participant to part with some of their address space. 
That can be seen as anti-competitive and unfair. I really understand both sides 
of that argument (as I should, being a chair!).

In both scenarios relying on only IPv4 is insanity, and I have a strong feeling 
that this community does not have the slightest bit of sympathy for those 
planning to do so. They are beyond help, so let them spend their own money on a 
failing technology. Any sympathy is for those who come to the party late but 
still have to deal with the laggards (and idiots) already present.

> Assuming those who request v4 addresses have a transition plan (what I deeply 
> hope ... )

One would indeed hope so.

> P.S : This time I use my v6 smtp server even though at home I cannot still 
> use a v6 prefix ;)

:)

Cheers!
Sander

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

[Sander Steffann]

Hi,

> Op 24 sep. 2017, om 20:42 heeft Randy Bush  het volgende 
> geschreven:
> 
 They are beyond help
>>> 
>>> not at all.  the vendors are more than happy to sell them CGNs, and
>>> other NATs of many flavors.
>> 
>> Sorry, I should have specified "from a IPv4 allocation policy point of
>> view" :)
> 
> sorry.  but having spent blood and tears on ipv6 deployment for over 20
> years, watching ipv6 zealots create a massive NAT market really really
> hurts.

Indeed :(
Sander



signature.asc
Description: Message signed with OpenPGP

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

[Sander Steffann]

Hi,

> Op 24 sep. 2017, om 04:55 heeft Randy Bush  het volgende 
> geschreven:
> 
>> They are beyond help
> 
> not at all.  the vendors are more than happy to sell them CGNs, and
> other NATs of many flavors.

Sorry, I should have specified "from a IPv4 allocation policy point of view" :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] Agenda for APWG in Dubai (v1)

[Sander Steffann]

Noted, we'll refer people to anti abuse when discussing open policy proposals. 
Marco: I assume this is already on your list, but please double check :)

Cheers,
Sander 

> Op 25 sep. 2017 om 14:02 heeft Malcolm Hutty  het volgende 
> geschreven:
> 
> Dear WG Chairs,
> 
> This is a request for a short agenda item for Dubai, or matter arising.
> 
> I would like the WG to be aware of policy proposal 2017-02 that has been
> tabled in abuse-wg, for the RIPE NCC to conduct validation of abuse-cc.
> 
> https://www.ripe.net/participate/policies/proposals/2017-02
> 
> No insult intended to abuse-wg, but it's not the most well attended WG.
> I'm not trying to start a debate in address-policy, but I think you
> could help by giving just a moment's "advertising" that this is going
> on, so that more people can consider whether this is a good idea.
> 
> Malcolm.
> -- 
>Malcolm Hutty | tel: +44 20 7645 3523
>   Head of Public Affairs | Read the LINX Public Affairs blog
> London Internet Exchange | http://publicaffairs.linx.net/
> 
> London Internet Exchange Ltd
>   Monument Place, 24 Monument Street London EC3R 8AJ
> 
> Company Registered in England No. 3137929
>   Trinity Court, Trinity Street, Peterborough PE1 1DA

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

[Sander Steffann]

Hi Jordi,

> I think Jan comments (in the meeting, hopefully he can repeat here) are very 
> relevant, and I’ve a draft policy proposal in that direction, I’m waiting for 
> my co-author review to submit it.

If you are talking about a RIPE policy proposal: please don't. Having multiple 
"competing" policy proposals on the same subject active at the same time tends 
to make it impossible to get consensus on anything. If you want to contribute 
please work with the current policy proposer. The end goal should be working 
group consensus, so getting consensus with the current proposer on the next 
version should only be a small effort in that direction :)

Cheers,
Sander

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

[Sander Steffann]

Hi Sean,

> In the interest of easing consensus in the address policy community, I would 
> like to withdraw my candidacy for WG chair.  I strongly encourage everyone to 
> support Erik as the future WG chair based on the significant work he has done 
> for the community over the last several years.  I have complete confidence in 
> his stewardship of the group in the future.  Thank you.

I understand. Thank you for volunteering in the first place! I know you as a 
level-headed person and I'm convinced that you are more than capable of being a 
good working group chair. Please keep volunteering for other chair positions in 
the future :)

Cheers,
Sander

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

Hi Jordi,

> The point is not only the PDP, as I believe we are still on time to correct 
> the policy proposal, which I think is broken and contradicting itself.
> 
> See my last email on the details, and a proposed text to resolve it, which 
> according to the PDP, we can still apply I think

We don't make any substantial changes in/after last call. Any "final changes" 
would be typo's. clearing up language etc. This is not the time to make changes 
to the core of the policy proposal.

And besides: you're not coming up with new arguments. These are the same 
arguments that you have voiced before. You have been heard in previous phases 
of the PDP, we seriously considered their merit, extended the review phase (and 
please stop complaining about not making any textual changes for the extended 
review phase, as I explained that is the discretion of the working group 
chairs) to see if there was support for your approach, and reached the 
conclusion that there wasn't. Your ideas have been heard and seriously 
considered, but despite that we determined that there is rough consensus to 
continue with the current version and leave the changes you want for a future 
policy proposal.

In the language of the RFC: we have addressed your objections, but not 
accommodated them.

> , without the need to wait for the concluding phase and then the appeal.

No need to wait. You can appeal the decision to declare consensus right now if 
you think our judgement was wrong. Feel free to do so. I'm confident we made 
the right decision, but we're human so if you think we made a mistake then 
let's ask the Working Group Chairs Collective what they decide.

As far as I'm concerned reviewing the policy proposal is done. We have rough 
consensus on the content and have moved to last call. If new objections come up 
with supporting arguments and they can't be addressed then we will declare lack 
of consensus at the end of last call. Raising the same objections as before is 
not going to block consensus in this phase: we already consider those 
objections addressed.

Cheers,
Sander

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

Hi,

> My reading of PDP 2.4 is [..]

Please stop being a lawyer. I have told you how we do things in this working 
group. Please listen to what the chairs are telling you.

> My reason to re-raise those now, is because they become evident when you 
> compare the proposed 2.6 change with the policy proposal arguments AND 
> specially the impact analysis, contradictions which for some reason, I didn’t 
> discover before (so disagree with you, those points aren’t the same I raised 
> before, may be similar, but the reason now is the contradictory text), and 
> this seems to be in the scope of PDP 2.4.

I think you are mis-interpreting the policy proposal. I see no such 
contradiction.

> The author of the proposal and the NCC could confirm their intent:
> 1) Is the proposal looking for disallowing a /64 ? If so, then the impact 
> analysis is broken and NCC is looking to implement something different than 
> what the proposal is asking for.

The policy is explicitly not mentioning prefix lengths but clarifying 
intentions. Delegating a prefix is still not allowed. The NCC explains in the 
impact analysis that having only a single device/user/etc on a subnet (i.e. 
RFC8273) is treated the same as having multiple users on a subnet: both are not 
considered assignments and are therefore permitted.

> 2) The proposal clearly is NOT intended for “permanent” broadband services, 
> but his is NOT stated in the proposed text change. I doubt that the NCC can 
> enforce a policy that don’t have that stated in the policy text. Can the NCC 
> confirm that?

The proposal adds a one-paragraph extension to the existing policy to allow 
connecting devices to a network: "Providing another entity with separate 
addresses (not prefixes) from a subnet used on a link operated by the 
assignment holder is not considered a sub-assignment. [...and some 
examples...]". There are more use-cases than you and I can think of, and trying 
to enumerate which ones are allowed and which ones aren't is bad 
overengineering. This has been discussed before. And these days it's not viable 
to provision broadband customers without delegating (DHCPv6-PD) address space 
to them anyway.

> 3) I also believe that the policy isn’t pretending to be used in data 
> centers. Can this be clarified?

Where did you get that idea? "connecting a server or appliance to an assignment 
holder's network" is one of the explicit examples of what is allowed.

> Regarding a possible appeal. The procedure talks about “unless there are 
> exceptional extenuating circumstances”.
> 
> I think it is the case for an impact analysis contradicting the proposal.

I think you are reading more into this proposal that what is actually there, 
and based on that have misinterpreted it.

> Is up the chairs to decide that, of course and I understand that you may need 
> to wait until the end of the last call to decide on that (this is the reason 
> why I understand that the appeal doesn’t make sense now, unless you have 
> already taken a decision).

You're misunderstanding what we are suggesting you appeal to. We're suggesting 
you appeal the decision that there was consensus at the end of the review phase 
and that the proposal was ready to go to last-call. If you don't agree with 
that decision then you can appeal it.

At the end of last-call there will be another decision about whether we have 
consensus or not, based on the feedback received during last-call. That 
decision has (of course) not been made yet, but as I said in my previous email 
I so far haven't seen any reasons that block that consensus *yet*. We'll have 
to wait for the end of last-call to make a final judgement :)

> If you believe is not the case, then, please let me know how to send the 
> appeal to the “Working Group Chairs Collective (WGCC)”, I guess there is a 
> mailing list for that?

Sure: RIPE WG Chairs 

Cheers,
Sander

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

Hi Jordi,

> “Providing another entity with separate addresses (up to /64) from a subnet 
> used on a link operated by the assignment holder is not considered a 
> sub-assignment. This includes for example, letting visitors and/or employees 
> (BYOD) connect to the assignment holder's network, connecting a server or 
> appliance to an assignment holder's network and setting up point-to-point 
> links with 3rd parties.”

An explicit choice was made in this version that specifying fixed boundaries 
(like a /64) should be avoided to avoid dependencies on specific technology. 
Please compare version 1 and version 2 of this proposal. Your suggested change 
would therefore be a partial reversion to a version that didn't have consensus, 
which would not be appropriate at this point in the process.

Cheers,
Sander

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

Hi Jordi,

> [Jordi] I think we are in-sync, but your response clearly demonstrates that 
> there is a need for clarifying the text.
> -> Policy proposal “Providing another entity with separate addresses (not 
> prefixes)”
> -> a /64 is a prefix

Technically, because the router is the PI holder's, you're not delegating a 
/64. You're allowing a customer to do i.e. SLAAC on a /64 of the PI holder. And 
Max is correct: when in doubt the RIPE NCC will check the rationale behind a 
policy proposal to make decisions, and they have clearly and explicitly stated 
that this is how they will interpret and implement it. Therefore there is no 
discrepancy between the text and the impact.

> The text is not concrete enough so to be enforced in the evaluation (again, 
> unless the NCC read the arguments and not the policy text).

The NCC reads both. This has explicitly been discussed before, and both the NCC 
and the working group confirmed that we don't want policy text that is too 
specific because reality is more complex than policy, and if we would try to 
make the policy complexity match that of reality then we would end up with 
horrible policy. The community has agreed not to micro-manage the NCC, and the 
NCC has promised to apply common sense when implementing policy. We also have a 
dedicated slot in the working group session where the NCC gives feedback on how 
things are going, where they have encountered any issues and where reality has 
changed so much that maybe the working group might want to look into changing 
policy.

There have been many cycles of micromanaging the NCC to writing vague policy 
and letting the NCC sort out the details. In both cases the NCC was blamed for 
everything. After many years of hard work we have reached a balance where the 
working group and the NCC work together to make policy that is one the one hand 
giving guidance to the NCC about what the community wants, but also leaves some 
room for the NCC (along with the accompanying responsibility) to adapt to 
changes and to apply some common sense.

Other organisations in the internet constellation have moved to a more legalese 
mindset, but I think as the RIPE community we are proud that we have evolved 
enough that we don't need that anymore and can actually work together 
pleasantly without setting everything in stone.

Cheers,
Sander

Re: [address-policy-wg] what does consensus mean

[Sander Steffann]

Hi,

> 1) Temporary always ? clearly not for point-to-point links, no-sense for data 
> centers?

Indeed, this is what I asked Marco.

> 2) Single address (/128) for a single device (so the device can't use 
> privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses 
> multiple addresses out of that prefix (so we allow VMs in the device also)

The policy talks about single-address increments. It doesn't say "one address", 
it says "separate addresses" (plural), which allows for privacy extensions etc.

> 3) Can the device use any technology (such as prefix sharing, eg. RFC7278), 
> to also use addresses from a single prefix for other devices (same user)

Technology used is out of scope here.

Cheers,
Sander

Re: [address-policy-wg] inconsistency in 2016-04 (was: what does consensus mean)

[Sander Steffann]

Hi Jim,

> PLEASE put those comments in a different thread which makes it clear you're 
> discussing detail about 2016-4 (or whatever). Thanks.
> 
> This thread's supposed to be about an entirely different topic.

Indeed, my apologies. There were so many things going on that I lost track as 
well :)

Cheers,
Sander

Re: [address-policy-wg] inconsistency in 2016-04

[Sander Steffann]

Hi,

> Below in-line.

Please use normal quoting, I have trouble reading your emails.

> Right, but 6) IA say: "... There are cases where a /64 is needed per customer 
> to provide a separate address ..." and 8) IA say: "... by using single IPv6 
> addresses for End User devices and services ..." furthermore it say "... 
> provided no prefixes will be provided to other entities ..." I think this can 
> be sorted out replacing in the IA "provided no more than a single prefix will 
> be provided to other entities."

No, that would drastically change the policy, and that has been looked at 
before. It was then decided that that is not the right approach.

> I used the technology as an example, what I'm referring is if the single 
> prefix can be shared by other devices of the user of a hot-spot (example, the 
> hotel gives me a single /64 in the WiFi, but I've several devices). The point 
> here is, clarification 2 above will solve the problem for multiple addresses 
> in a single prefix, 3) may solve the problem for multiple devices with the 
> same prefix. For both of them we may need to clarify if Max "not prefixes" is 
> meaning also a single prefix or "not multiple prefixes", which is I think the 
> major contradiction with the IA or NCC interpretation according to mail 
> exchange with Marco.

Sorry, what someone does with addresses is completely out of scope here.

Cheers,
Sander