Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Sander Steffann]

Hi,

> On 15 Dec 2023, at 15:32, Maximilian Wilhelm  wrote:
> 
> Hi folks,
> 
> Anno domini 2023 Peter Hessler scripsit:
> 
>> I still support the proposal as-is.  The proposed change does not
>> weaken any data that is in the database, and in fact may allow it to be
>> more obvious that these address ranges are used by end users rather than
>> be unclear what their status is.
>> 
>> Furthermore, I will state that Denis' objections are not relevant to the
>> proposal.  The proposers, various people on the lists (including myself),
>> and the RIPE NCC themselves all state the opposite of what Denis is
>> saying.  In addition the proposers have, in my opinion, addressed the
>> concerns stated.
> 
> +1 to what Peter said.
> 
> Cheers,
> Max

I’ll add my +1 as well. I think this discussion has brought the issue to the 
attention of this community extensively. After reading the history on this 
mailing list and looking at the impact analysis, I think we have reached the 
point in rough consensus where Denis’ concerns have been addressed, but not 
accommodated. This is a valid outcome: "Rough consensus is achieved when all 
issues are addressed, but not necessarily accommodated”

Cheers,
Sander


-- 

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

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

[Sander Steffann]

Hi!

> On Tue, Nov 28, 2023 at 02:23:30PM +, Erik Bais wrote:
>> We like to introduce Alex le Heux as a new Co-Chair introduce for
>> the following period, so he can see what is involved in the role
>> as a Co-chair.
> 
> Support!
> 
> (Wrote longer paragraph on "lots of experience, good understanding of
> the working of the NCC/PDO side of things, well-known in the community, 
> ..." and decided a single word is sufficient :-) )

What Gert said :)
Sander

-- 

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

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

[Sander Steffann]

>   - realise that the current internet is not the internet that this DB was 
> designed for
> 
> Might as well stop issuing policy at all, then.

The thought did cross my mind ;)

Cheers!
Sander


-- 

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

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

[Sander Steffann]

Hi,

> I think I mostly agree with Nick here and I feel like Tore is a bit
> dismissive of the concerns raised by denis.
> 
> I don't really feel that strongly about this policy proposal in itself
> but I do now see that it is a significantly larger change than Tore
> suggests that it is.
> I wouldn't be surprised if more people who have said "+1" to this
> proposal did so without realizing that it's not such a minor change.

+1 to that! Guilty person right here :)

> As such, I really think that there needs to be more discussion about
> this in the context of changing a meaningful part of the policy.

I totally agree. This is a change that we have to take consciously, not as a 
side-effect of a different idea.

I personally have no problem with this change. I recognise the importance of 
documenting every end-user’s contact details, as end-users were often actively 
involved in running their network. But in this day and age of outsourcing, the 
value of the information is much lower than it used to be.

I’m not saying that there is no value anymore! There are many cases where 
resource holders are actually network operators with relevant information in 
the DB, but I don’t think that changing the policy will cause them to suddenly 
stop creating DB objects. And for those who don’t *want* to document things, 
they have already found ways around that in the current implementation of the 
policy.

I think the best way forward would be:
- encourage operators to document *useful* contact info (a SHOULD)
- don’t require what we don’t/won’t/can’t enforce (no MUST)
- realise that the current internet is not the internet that this DB was 
designed for
- align IPv4 and IPv6 requirements/standards where possible

So:
- the ALLOCATION objects will always have validated information enforced by the 
RIPE NCC
- objects below that are for delegating responsibility and contact points
- if an LIR wants to keep/assume responsibility, very few additional DB objects 
are needed

I realise there are quite a few potentially controversial statements here, 
please use this as a thought provoking discussion point ;)

Cheers!
Sander


-- 

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

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Sander Steffann]

Hi,

> A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 
> PA assignments"
> is now available for discussion.
> 
> This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA 
> assignments to reduce LIR efforts in registration and maintenance.

I agree with this proposal. I have used the AGGREGATED-BY-LIR status for IPv6, 
and I'd love to be able to do the same for IPv4. I am only a small LIR, so I 
won't have many objects with AGGREGATED-BY-LIR status, but nonetheless it will 
allow me to express the way I use my allocated IP addresses better. And I hope 
it will encourage others to do the same :)

Cheers,
Sander


-- 

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

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

[Sander Steffann]

Hi,

> Silence is consent, in other words. I have therefore intentionally not
> commented on this proposal during Last Call.

+1 to this, that’s how Gert and I always implemented it, and how I would like 
it to remain. Last call is a “speak now, or forever hold your peace” phase :)

Cheers!
Sander


-- 

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

Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

[Sander Steffann]

Hi WG,

At some point in the past we had a discussion about making it easier to request 
ASNs, basically removing the multihoming requirement. This working group at the 
time decided to not do this because it *might* cause someone to ask for an 
insane number of ASNs and overload the RIPE NCC. A recurring (or even a 
one-time) cost for ASNs would automatically solve this issue, because going 
insane would become financially unfeasible :)

Now that the RIPE NCC’s membership has decided that they don’t care about this, 
I think it’s time to reopen this discussion on our side. There are many reasons 
someone might want to have an (extra) ASN: lab use, education (I’d love to set 
up BGP training course where students can actually announce a real IPv6 prefix 
to the world with a real ASN and see the results), internal use (while still 
needing a globally unique one), not YET being multi homed but going to in the 
future etc.

I’d like to propose to remove the multi homing requirement from our ASN policy, 
as the main reason why we decided not to last time doesn’t seem to hold anymore.

Cheers,
Sander


-- 

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

[address-policy-wg] RIR Policy Proposal overview

[Sander Steffann]

Hi everybody,

I created a quick overview page of all the policy proposals in the different 
RIRs: https://proposals.nogalliance.org/

Hope you find this useful!

Cheers!
Sander


-- 

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

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

[Sander Steffann]

Hi,

>>> Assignments strictly larger than a /24 will only be made to IXPs that
>>> offer the exchange of IPv4 routing information over IPv6 at their
>>> route servers
>> 
>> As far as I understand, this protocol is not widely deployed in IXPs,
>> nor is it widely tested in inter-AS production environments. It would be
>> concerning if an untested protocol were mandated as a production
>> requirement in a RIR addressing policy document.
>> 
>> Before continuing down this path, could the authors provide information
>> on how this protocol works in production environments?
> 
> This part of the proposal is intended to foster the adoption of the 
> technology.
> IXPs may offer it as beta or experimental while still doing the actual 
> exchange
> of traffic via standard BGP over IPv4.

Doesn’t the way this policy is written defeat the purpose of using IPv6 to 
exchange IPv4 routing information? Only those who can use IPv6 (and arguable 
therefore don’t need IPv4 anymore) can get more IPv4 space…

> We are aware this is part controversial; we can remove it if the community 
> thinks
> this is a bad idea.

Putting controversial stuff is address policy is usually not a good idea. In my 
opinion address policy has to provide what is needed for a super stable 
environment. Enforcing the use of less tested or experimental protocols doesn’t 
fit with that.

Now, I totally understand the chicken and egg problem here: as long as IXPs get 
IPv4 addresses there will be no need to exchange IPv4 routing information over 
IPv6. But until that has been properly tested we continue to give them IPv4 
space. But let’s not put in artificial restrictions to make them test it. If 
the real reason is that we don’t have enough IPv4 space to give to IXPs in the 
future, then let’s make *that* clear.

Like: “From  IXPs will no longer be able to grow their 
IPv4 assignment beyond . IXPs that anticipate needing 
to grow larger than this are strongly encouraged to start testing with 
exchanging IPv4 routing information over IPv6”.

The cutoff date may be a little arbitrary (I’m sure the NCC can give reasonable 
predictions to base it on) but at least it matches with reality :)

Cheers,
Sander


-- 

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

Re: [address-policy-wg] IXP pool lower boundary of assignments

[Sander Steffann]

Hi,

> Marco pointed out in the WG session, that we should probably start a 
> discussion on the lower boundary of assignments from the IXP pool. I would 
> like to kick off this discussion with this post.

To add to this discussion: I took this to the Connect WG, and the initial 
feedback I got from there is that they have no problem with reevaluating this 
every 8 or so years (what seems to be the current rate of use of the IXP pool), 
and that they would be perfectly happy with not doing anything right now and 
reevaluating this in 2027 or so. This will be taken to the Connect WG mailing 
list, so let's keep an eye on that to see whether action is necessary at all.

Cheers!
Sander


-- 

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

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine

[Sander Steffann]

Hi Hans Petter!

> I would encourage you to have a look at the article outlining some of the 
> alternatives:
> https://labs.ripe.net/author/athina/protecting-resource-holders-in-distressed-areas/
>  

Yeah, I did read that. I just don’t agree with the arguments. 

> While this might seem like an easy solution on the surface, we cannot help 
> but anticipate situations where this could be abused. For example, we can 
> imagine cases where malicious employees want to prevent an upcoming transfer. 
> Such a solution would also have some administrative challenges, because who 
> is authorised to activate this freeze would need to be specified.

Make it the same person who is authorised to open/close an LIR. The NCC already 
has those contracts. To prevent abuse make it a paper form with signatures over 
registered mail, or whatever the NCC has in place already. I’d put the 
authorisation level at the same one as closing the LIR. 

> Also, we wouldn't be able to adhere to such a requested freeze when companies 
> are bankrupt, liquidated or in case of a legitimate merger and acquisition.

Yeah, I agree there is little you can do about those in any circumstance. 

> In any case, if the period of time for the lock is longer than a couple of 
> days, we would again be very reluctant in implementing this solution without 
> a policy proposal.

Why? An LIR explicitly and voluntarily giving up some rights they have under 
the service agreement is surely a matter between the member and the NCC? The 
policy stays exactly the same. 

> I can assure you that we have taken the measures we believe we can within the 
> existing policy.

I think adding a disclaimer that allows for making transfers null and void 
retroactively is a much bigger risk to all involved than a transfer lock would 
have been. I don’t see how on one hand the NCC can’t verify whether a transfer 
lock is valid, but can verify with absolute certainty that existing paperwork 
is null and void.

To me it feels more like a “let someone else figure this out in court” attitude 
than an actively helpful one.

> Looking forward to hearing what the community thinks here at the list or the 
> meeting next week.

Me too! I’m only a single voice here, and this is a community!

Cheers,
Sander

-- 

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

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine

[Sander Steffann]

Hi Hans Petter,

> Today we responded to a request from the Committee of the Verkhovna Rada of 
> Ukraine on Matters of National Security, Defense and Intelligence to discuss 
> measures to protect Internet number resources in Ukraine. We have published 
> this on our website: 
> https://www.ripe.net/publications/news/announcements/ripe-ncc-response-to-committee-of-the-verkhovna-rada-of-ukraine
> 
> As we note in our response, we will be presenting on this topic in the RIPE 
> NCC Services Working Group at RIPE 85 next week. We encourage anyone with an 
> interest in this topic to join that session. 

In your response you refer them to the Address Policy Working Group ("On the 
same day, from 09:00-11:30 UTC+2, the Address Policy Working Group will meet to 
discuss matters of policy, and we suggest that this would be a good forum to 
raise these matters.”). I am not sure I agree with that.

I think the current situation requires something like a transfer lock that LIRs 
can voluntarily activate. I remember already talking about that with NCC staff 
at the Berlin meeting, so the issue was known and a possible solution discussed 
a long time ago. To be honest I expected that the NCC had long since 
implemented something like this as an operational procedure. I do not consider 
something like that a matter for policy. The address policies stay exactly the 
same, only the operational procedures should change.

My personal feeling is that the NCC is taking much too long here, sending the 
poor ISPs in Ukraine into a lengthy process of having to write a policy that 
will take even longer to implement, for something that is an operational 
matter, not a policy one. I urge you to solve this inside the NCC as soon as 
possible. You do not need this community to write policy on how to protect the 
RIPE database’s contents from clear and present operational dangers.

I’m sure there will be many in this community scrutinising whatever you come up 
with, and there will be much debate on whether the solution the NCC implemented 
contains bike sheds in all the right colours, and I guess that is unavoidable 
in a bottom-up community. But a fast response (which IMHO should have been done 
months ago) is more important than perfection right now. Please go for “good 
enough for now” first.

Thank you
Sander


-- 

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

Re: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies

[Sander Steffann]

Hi,

> On 12 Oct 2022, at 12:36, Nick Hilliard  wrote:
> 
> Marco Schmidt wrote on 11/10/2022 11:49:
>> One possible solution would be to review the current policy and propose a 
>> policy change, for example the introduction of a minimum IPv4 assignment 
>> size.
>> Does the working group agree that this is an issue that should be discussed 
>> and that might require a policy change?
> 
> seems reasonable.

+1
Sander


-- 

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

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Sander Steffann]

> Op 4 okt. 2022 om 17:46 heeft Randy Bush  het volgende 
> geschreven:
> 
> 
>> 
>> Again we are back to asking the question, "What is the purpose of the
>> RIPE Database in 2022?".
> 
> in this case, same as it ever was.  same as it ever was.

And you may ask yourself “what is this RIPE database?”

;)
Sander



-- 

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

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Sander Steffann]

Hi,

>> To break it down by rationale:
>> 
>> "One of the main reasons for registering IPv4 PA assignments was that LIRs 
>> could show their use of IPv4 and thus justify the request for an additional 
>> IPv4 allocation from the RIPE NCC. However, this requirement has become 
>> obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."
> 
> This merely means that this particular reason is no longer relevant for IPv4 
> addresses.

Justifying getting more PA Allocations was never the reason to document PA 
Assignments in the RIPE database. Its purpose is to document who to contact for 
administrative and technical issues concerning the IP addresses. Being able to 
use that data to verify that IP addresses are actually in use before allocating 
more was just a useful side effect.

I therefore oppose this rationale. I know that organisations are lazy and only 
properly document assignments when they want the benefits for themselves (i.e. 
getting another allocation). I think there is a more important decision to make 
here: do we still want this level of documentation for operational purposes?

If we don’t want/need this level of documentation anymore then sure, remove the 
mandatory PA assignment registration in the RIPE DB. But in that case rewrite 
the proposal to make that very explicit. Removing the requirement using the 
wrong arguments is misleading. Call it what it is.

Cheers,
Sander


-- 

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

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

[Sander Steffann]

> Given that there seem to be people that actually get work done in their
> research, using IPv4 because not all vantage points have IPv6 yet, and 
> that the existance of this policy seems to do little harm, I'd strongly
> object to such a proposal.
> 
> This is not the place and time to go on an anti-IPv4 crusade.

+many

Cheers,
Sander


-- 

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

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

[Sander Steffann]

Hi Mathias,

> I will be quite frank about this and say that it feel very disheartening to 
> essentially miss the 0 day queue allocations by 5 days. end up in a one month 
> long quque that just grows with no more allocations and on top of that it is 
> VERY obvious that these organisations uses the members list as a "To be 
> customers" base because about 4 hours after we became members we got mails 
> and phonecalls from about 5 different companies stating they want to sell us 
> IP adresses.
> 
> It just feels like this is not what RIPE was intended for but obviously is 
> being used for.
> 
> I apologize if i am sounding too salty or if my mail is not according to well 
> established RIPE etiquette, and dont get me wrong. we are VERY happy about 
> being a new member with a single LIR and getting our own IPv6 and insight 
> into the future of the internet, just felt that i should give the point of 
> view of exactly one of those "Small new one lir members" that many here 
> reffer to and exactly how our experience with this issue has been..

Don't worry, you talk about your frustration quite politely :)  And it is 
totally justified. This is why I think something needs to be done now. Yes, 
it's rearranging deckchairs on the Titanic, but some people are still trying to 
survive.

As a new member, what do you think about these ideas? Would it be good to make 
addresses untransferable? Or keep them transferable but ask the NCC to impose a 
one-time merger fee? Or any other way? What would be ok for your 
real internet business but not for address sellers?

Cheers,
Sander


-- 

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

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

[Sander Steffann]

Hi Denis,

> What is going to stop people selling these 'never to be
> transferred' allocations and not recording the transfer in the RIPE
> Database?

The fact that the LIR can’t be closed. Having to remain a member and pay the 
membership fee for as long as you want to use the allocation is business as 
usual for people who actually want to run a network, but not for people who 
want to sell the space and then close the LIR.

Cheers,
Sander



-- 

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

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

[Sander Steffann]

Hi,

>> On 7 Dec 2021, at 14:56, Gert Doering  wrote:
>> 
>> My suggestion would be along the lines what was proposed on the APWG
>> meeting already - earmark these /24s as non-transferrable, ever.
> 
> +1 WFM

+1 from me as well. This would have very little (if any) impact on the 
newcomers for whom this policy was created.

Transfers that have already happened should not be affected of course, but we 
can make a policy that stops new transfers being made in the future. I would 
prefer to disallow any new transfers, independent of when the assignment was 
made, to avoid a rush on the NCC for new memberships.

Cheers,
Sander


-- 

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

Re: [address-policy-wg] IPv6 Stockpiling

[Sander Steffann]

Hi,

> One reason for a LIR to have multiple /29 is when a lir (ISP in this case) 
> buys smaller operators and consolidates them.
> Since all of these blocks had some use before consolidation and its tedious 
> to renumber
> 
> I don’t see this as stockpiling, they will be even more in use in the future 
> anyway, and we need to have enough use before being able to obtain more 
> space...

If this is indeed the reason I see no problem with it. That's just operational 
reality.

If there is some misunderstanding causing LIRs to accumulate many IPv6 
allocations then we can look at better education.
And if there is some malign reason for it, then we can look at changing the 
policy.

I think we need to understand the symptoms better to be able work on the cure :)
Sander

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

[Sander Steffann]

Hi chairs!

On Mon, 2021-04-26 at 10:50 +, Erik Bais wrote:
> Second this is going to be last WG session with our faithful Gert as
> co-Chair of the WG, as he is going to step down.
> And because he started RIPE 44 in Amsterdam, 2003 as chair for the
> LIR-WG (now AP-WG), he is probably one of the longest serving Chairs
> in our community.

We should plan something nice for him at the next physical RIPE meeting

 
> So, on the agenda, we have the following planned.  We will be
> publishing a couple presentations in pre-recording, so that we can
> have more time for discussions.
> The publication of those pre-recordings is planned for the weekend
> before the WG session.

So just to be 101% clear: we are watching those video's in our own time
before the session, and the session itself will be DISCUSSION ONLY,
right?

Cheers!
Sander



signature.asc
Description: This is a digitally signed message part

Re: [address-policy-wg] a third WG co-chair

[Sander Steffann]

Hi Jim,

On Fri, 2021-04-09 at 15:55 +0100, Jim Reid wrote:
> Please remember that 10+ years ago -- when tinkering with IPv4
> allocation policy was at its peak -- Gert ran the WG all by himself. 

That is actually not true. I volunteered to become co-chair immediately
after the APWG session where Hans Petter resigned, and was accepted as
co-chair by the working group at the next RIPE meeting.

Cheers,
Sander



signature.asc
Description: This is a digitally signed message part

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

[Sander Steffann]

Hi Erik and Gert,

On Fri, 2021-04-09 at 12:20 +, Erik Bais wrote:
> Me and Gert had the pleasure on working with Leo and James in the
> last 6 months on topics in relation on the AP-WG related stuff. 
> And I would suggest to the working group to extend, if the WG agrees,
> to accept both applicants, so that we are going to a 3 chair WG. 

I have no problem with that. It'll complicate the rotation process in
the future, but that'll be a luxury problem 

> I think they have a solid understanding of the policy making and
> background which is relevant for the AP-WG and a good addition to the
> position. 
> 
> During RIPE82 we will have the time in the agenda for the rotation
> process.  

Thanks for all the hard work!
Sander



signature.asc
Description: This is a digitally signed message part

Re: [address-policy-wg] [policy-announce] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

[Sander Steffann]

Hi,

> This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 
> for all unallocated and unassigned address space under its control.
> 
> You can find the full proposal at:
> 
> https://www.ripe.net/participate/policies/proposals/2019-08

I have read the policy and I don't see any downside to doing this. Creating 
those ROAs reflects the intention correctly, so let's do this.

Cheers,
Sander

Re: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy)

[Sander Steffann]

Hi,

> A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 
> Policy"
> is now available for discussion.
> 
> This proposal aims to remove obsoleted text and simplify the IPv6 policy.

I think this is a sensible update. Support.

Cheers,
Sander

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

[Sander Steffann]

Hi,

> Op 11 aug. 2019, om 22:16 heeft Randy Bush  het volgende 
> geschreven:
> 
>> I strongly agree with Nick and support version 2.0. No need to produce
>> a revision changing the default away from /24.
> 
> how about /24.5?  :)

Brilliant idea ;)

> enough already.  ship it.

I agree, it's a good proposal.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

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

[Sander Steffann]

Hi,

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

This ^^^
Sander



signature.asc
Description: Message signed with OpenPGP

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

[Sander Steffann]

Hi Jordi.

> I know about ripe-639.
> 
> What I’m saying is that we force the change of status from non-legacy to 
> legacy if addresses are transferred to a new member or an existing member, as 
> both of them will have all the legal bindings already with RIPE NCC.

A legal entity can have zero, one or more LIRs. You are saying that we can 
abuse the contract that we have with those with one or more LIRs to force them 
into a position that we don't apply to those with zero LIRs? Also: when I have 
multiple LIRs, which LIR should get the legacy resources? And if I can choose 
which LIR, then I choose "none".

> 639 was defined a couple of years before the transfers policy. It may be 
> perfectly possible that at that time it was not considered this aspect.

This is incorrect. We have had transfers since RIPE-441 from December 2008. The 
choices around transfers were very consciously made.

> I know that every region is different, but we live in a global Internet, and 
> it is surprising to me that we are the only out of 5 RIRs, that has not done 
> this already.

RIPE has respect for the rights of the people who came before it :)
Sander



signature.asc
Description: Message signed with OpenPGP

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

[Sander Steffann]

Hi Kai,

> I don't see this either, hence, while I agree that there should be some 
> wording about the way the (already implicit) waiting list will be 
> implemented/handled, I reject the proposal as-is due to the reduction of the 
> assignment size.
> 
> Reducing the assignment for new LIRs from /22 to /24 neither helps the 
> community, nor the late-coming LIR in question.

This presentation from RIPE NCC at RIPE77 shows that changing the allocation 
size does help significantly: 
https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14.

> IPv4 is gone, we pray every other minute, so we should act accordingly.

Unfortunately the world is not as simple as that :'(

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

[address-policy-wg] Prefix size

[Sander Steffann]

Hi,

Yesterday in the APWG session I promised to go to the routing WG and notify 
them of the possibility of IPv4 prefix lengths growing longer than /24 in the 
future. I think Geoff Huston just already made an excellent presentation that 
included that point, so thank you Geoff!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] Application for AS number

[Sander Steffann]

Hi Paul,

> I personally have no problem with making it easier to obtain an AS if you 
> intend to multihome at some point in the future (measured in years if 
> necessary - let people who want to do the Right Thing from day one do that).  
> There are plenty of 32 bit AS numbers available, they are not a scarce 
> resource and we as a community should probably not treat them as such.

This!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] PA – life after death

[Sander Steffann]

> We did not convert to PA. But unfortunately they did not know that it was 
> necessary to keep Sponsoring with a third party.

I'm a bit confused. What exactly are you doing?

- Is the legal entity that was an LIR stopping? If the legal entity disappears 
then the resources go back to the NCC
- Is the legal entity cancelling its RIPE NCC membership? In that case the 
resources can still be assigned to the legal entity and you should be able to 
find another sponsoring LIR
- Did the NCC end the membership for violation of policies or non-payment? In 
that case: yes, you don't have any rights to those resources anymore
- Something else?

Without any mor information we're just guessing, which isn't very useful. I 
urge you to talk to the NCC to work this out, and if you can't work it out 
there is always the arbitration procedure... I don't think this is something 
that can be solved on APWG though.

Full disclosure: I'm an arbiter on the NCC arbitration panel

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] IPv6 PI justification requirements

[Sander Steffann]

Hi,

> As I attempted to explain this was 3 separate uses that required separate 
> announcements.

To keep things more clear, maybe it's easier to send three separate requests. 
Each for a /48 with the description where/how that one is going to be used. 
Combining things into one request might seem easier, but it tends to obfuscate 
things :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] IPv6 PI justification requirements

[Sander Steffann]

Hi Cynthia,

> I have also been informed that this might be a rather unique case in regards 
> to having multiple physical locations requiring PI space.

Not unique at all. That is why the explicit "different routing requirements" 
rule was included in the policy :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] IPv6 PI justification requirements

[Sander Steffann]

Hi Cynthia,

> I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what 
> confuses me is that the NCC requires way more justification for 3x /48 of PI 
> than for 2x /29 of PA.
> 
> I do think that saying something like net1 will be used in the Netherlands, 
> net2 in London, and net3 in New York should be enough. I mean after all, any 
> LIR can get 512K /48s and unlike ASNs, PI space does have a small fee 
> attached with it.
> 
> I can't think of a good reason why this is the case.

The policy says:

"""
The minimum size of the assignment is a /48. Organisations requesting a larger 
assignment (shorter prefix) must provide documentation justifying the need for 
additional subnets.

Additional assignments may also be made when the need is demonstrated and 
documented based on address usage, or because different routing requirements 
exist for additional assignments.
"""

Your case seems to fit the "different routing requirements" rule. I would ask 
the NCC why they think that rule doesn't apply. They may have a reason. Without 
further data I can't judge their decision.

> Once again to make it clear, if you are a member it is easier to get 1 
> million /48s than it is for a non member to get 3 /48s.

Aggregatable addresses are indeed strongly preferred :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi,

> I oppose this proposal, unless at least RIPE NCC will charge members based on 
> how much IPv4 space they have.

Sorry, membership fee structure is out of scope there. The NCC members decided 
years ago to adopt a membership-based-fee instead of a resource-based-fee. It's 
not up to this working group to decide on that.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Michiel,

> Just another point for discussion: what to do when this /24-only policy is in 
> effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and 
> is able to hand-out multiple /22's again?

The policy explicitly states that once the waiting list policy is in effect the 
old policy is removed. So the large block would be used to process requests 
from the waiting list.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hello working group,

The first comments I got back on this proposal all seemed to miss the point of 
it. Let me explicitly state what this policy is NOT about:
- it is NOT about conserving IPv4 addresses
- it is NOT about postponing the runout date
- it is NOT about extending the lifetime of IPv4

It's purpose is solely about:
- dealing with the returned address space the NCC will get over the years

Under the current policy:
- the waiting list will grow indefinitely
- the allocations given out will consist of tiny fragments
- it will therefore not be of any practical use

This proposal proposes:
- keeping /22 until we run out of /22s
- give out /24s only after that
- this helps to keep the waiting list manageable [1]
- declare everything smaller (longer prefix) than a /24 unusable
- this helps against people getting unusable dust

[1]: see https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf 
slide 14

Please forget about previous attempts to change allocation sizes. Those were 
about changing the current allocation policy. This proposal only looks forward 
to what to do after the current policy becomes unusable. Please focus on that.

Cheers,
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Martin,

> I don't think that we have to change current policy at all.
> 
> Current policy allows to get /22 divided to smaller blocks, so it doesn't 
> have to be changed just because of this.
> 
> My personal opinion on IPv4 exhaustion is that it would be better to come 
> sooner than later. Any means of slowing exhaustion down would just prolong 
> the IPv4 agony. Reaching zero free pool is the only way.

Please look at the presentation I linked to and Daniel's comment.

> Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a 
> dead-end, let it die peacefully.

This is not about conserving IPv4 addresses.
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Jim,

> A policy to deal with whatever /24s the NCC might find stuffed down the back 
> of the sofa will be more bother than its worth. Unless someone can provide 
> compelling arguments -- ie there’s still a lot of v4 for the NCC to allocate 
> -- I just don’t see the point. Sorry.
> 
> How much of this hypothetical /24 space does the NCC hold anyway? How long 
> might it last?

It's more about that the NCC does with returned address space. The current 
pools will indeed run out very quickly, no point trying to extend those.

The usefulness of this policy can be seen in 
https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14. 
When we use the returned space in /22 chunks there is not much point in having 
a waiting list. If we use /24 there is.

That's all :)
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Raymond,

> The current policy does not become useless:
> 
> "In case an allocation of a single /22 as per clause 1 can no longer be made, 
> multiple allocations up to an equivalent of a /22 in address space will be 
> made to fulfill a request." is in the current proposal.

Ok, that will extend the lifetime of the /22 policy with a little bit (causing 
a large amount of fragments to end up in the routing table), and *then* it 
becomes useless...

How do you see the policy after that, when there is a waiting list? Keep 
pushing lots of fragments to the last LIRs?

Cheers,
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hello Francis and Jim,

> We do not agree with this proposal. 
> 
> Sooner or later RIPE IPv4 address space will run out. Moving from /22
> to /24 will not change that, which is the essence of the question, but
> doing so will create more fragmentation (BGP, smaller LIRS, cost
> unfairness between members...). 
> 
> In practical terms, we believe this will also boost IP broker market
> (the smaller the blocks, the stronger IP brokers will get).
> 
> Current policy is a good compromise: it focus on allocating to LIRs
> that assign and use address space ...until no more allocation can be
> done.

It seems you misunderstand the proposal. This policy agrees with you that /22s 
should be allocated until RIPE NCC runs out. It is about what happens 
afterwards. We create a waiting list with either /22 or /24 allocation size.

- Choosing /22 means that the waiting list is unmanageable and therefore 
(mostly) useless.
- Choosing /24 means that the waiting list is manageable and a bit less useless.

We're not suggesting to change the allocation size now, only for the waiting 
list.

Cheers,
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Raymond,

> To make it more clear what I mean, a /24 will not be enough to connect a say 
> /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in 
> size ) is not enough either. Therefore I support the current policy, and am 
> against the new proposal.

Can you please explain how you see that? This proposal only deals with the 
situation *after* the current policy becomes useless...

Cheers,
Sander

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Sander Steffann]

Hi Denis,

> This sounds reasonable to me.
> Newcomers can still get a share while transitionning to IPv6 :)
> 
> Is there an incentive to make ops accept longer-than-/24 as a next step ?

No, at the last RIPE meeting consensus was that longer-than-/24 was not worth 
it.

Cheers,
Sander

Re: [address-policy-wg] Policy violation

[Sander Steffann]

Hi Aleksey,

> On the 7th of September the NCC implemeted the document 
> https://www.ripe.net/publications/docs/ripe-709#transfer35 (The document is 
> published on the 21th of September). The support clarify it that you cannot 
> merge one LIR into the second LIR in case of M procedure because of the 24 
> month resource transfer restriction.

That section doesn't seem to be about M It talks about normal transfers 
between LIRs that belong to the same member.

> However there is another document 
> https://www.ripe.net/publications/docs/ripe-682#2-2-transfer…
> where you can read the next:
> 
> 2.2 Transfer Restrictions
> This restriction does not prevent the resources from being transferred due to 
> further mergers or acquisitions within the 24-month period.

M is a different thing. It involves changes in legal business structures. 
Take a look at https://www.ripe.net/publications/docs/ripe-709#transfer31 item 
ii:

"""
If the transfer is taking place due to a change in the structure of the 
organisation(s) involved (e.g., merger, acquisition), a description of the 
changes among these organisation(s) is necessary. This description must be 
accompanied by the official legal documents issued by the relevant national 
authorities proving/supporting the changes the request is based on.

If the change in the structure of the organisation(s) involved cannot be 
proven/supported by official documentation from national authorities describing 
this change (e.g., a network acquisition from one member to another), then 
these cases will fall within the scope of RIPE Policy "RIPE Resource Transfer 
Policies".
"""

If it is not M then the normal policies apply, even when transferring between 
LIRs belonging to the same member. That includes the 24 month waiting period.

> In this case the NCC doesn't follow own policies. Or am I wrong?

As far as I can see the NCC is following the policy.

Cheers,
Sander

Re: [address-policy-wg] country code in ORGANISATION object

[Sander Steffann]

Hi Denis,

> The DB part is simply to add an attribute. The mechanics of that is pretty 
> straight forward. The reason for adding it and its strict definition and 
> perhaps status as a 'fixed' attribute value are more address policy or 
> services.

I don't think it fits in APWG. It doesn't change the allocation/assignment 
policy, only the bookkeeping. I think this policy proposal belongs in DBWG.

Cheers,
Sander

Re: [address-policy-wg] [CFP] ACM/IEEE IPSN 2019 in CPSWeek

[Sander Steffann]

Hi Nick,

> Could the chairs please be more proactive about ensuring that APWG's 
> anti-spam policy is applied?
> 
> IEEE conference spam in particular seems to be a problem going back many 
> years.

As an ex-chair I can assure you no such message goes unanswered. Every single 
one of them gets told not to do this, they get added to blacklists, and they 
keep finding other ways to annoy us. It's frustrating, but please don't blame 
the chairs for this. They are responding (off-list, to keep the noise down) 
every single time.

Cheers,
Sander

Re: [address-policy-wg] Feedback needed for 2018-03 (Fixing Outdated Information in the IPv4 Policy)

[Sander Steffann]

Hi Andrea,

> Policy proposal 2018-03 aims at fixing outdated information in IPv4 Policy, 
> like outdated references or values of inetnum objects in the RIPE Database.
> 
> While I am aware this is not the most exciting of the current policy 
> proposals, it is important to keep the content of the IPv4 policy up-to-date.
> The review phase for this proposed policy change will end this week, and in 
> order to proceed with the PDP this proposal needs your input, whether you 
> support or oppose the changes.

Strong support, keeping our policy documents clean and relevant is important. 
Outdated information needs to go or be fixed. Otherwise newcomers will have a 
hard time (ok, an even harder time) making sense of it all.

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] Agenda for APWG at RIPE 76 in Marseille v2

[Sander Steffann]

Hi,

> What is 2018-03 Fixing Outdated Information in the IPv4 Policy?
> 
> I cannot find it in the NCC website.

We gave the RIPE NCC an action item to look at outdated 
information/references/etc in the policy. This proposal will be their suggested 
fix. It's not published yet, but we know it will be published before RIPE 76 so 
we already tentatively added it to the agenda.

Cheers!
Sander



signature.asc
Description: Message signed with OpenPGP

[address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2

[Sander Steffann]

Hi APWG folks,

There were a few typos in the agenda so here is an updated version:

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

Wednesday, May 16, 09:00 - 10:30
Wednesday, May 16, 11:00 - 12:30

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

Regards,

Gert Döring & Sander Steffann,
APWG chairs


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

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


B. WG Chair Selection
   - longest-serving chair (Sander Steffann) stepping down
   - Sander is not volunteering for another term, so we'll select
 a new co-chair


C. The role and function of the ASO within ICANN
   Public consultation, Axel Pawlik


D. Current Policy Topics - Marco Schmidt, NCC PDO

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

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

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

   - brief overview of new proposals
 (if any)


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

Welcome back

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


F. Discussion of open policy proposals

   2018-01 Organisation-LIR Clarification in IPv6 Policy
   Jordi Palet Martinez / Erik Bais / Juri Bogdanov

   2018-02 Assignment Clarification in IPv6 Policy
   Jordi Palet Martinez

   2018-03 Fixing Outdated Information in the IPv4 Policy
   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

[address-policy-wg] Agenda for APWG at RIPE 76 in Marseille

[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 Marseille in the following time slots:

Wednesday, May 16, 09:00 - 10:30
Wednesday, May 16, 11:00 - 12:30

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

Regards,

Gert Döring & Sander Steffann,
APWG chairs


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

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


B. WG Chair Selection
- longest-serving chair (Sander Steffann) stepping down
- Sander is not volunteering for another term, so we'll select
  a new co-chair


C. The role and function of the ASO within ICANN
Public consultation, Axel Pawlik


D. Current Policy Topics - Marco Schmidt, NCC PDO

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

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

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

- brief overview of new proposals
  (if any)


--
Wednesday, 12:00-13:30
--

Welcome back

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


F. Discussion of open policy proposals

2018-01 Organisation-LIR Clarification in IPv6 Policy
Jordi Palet Martinez / Erik Bais / Juri Bogdanov

2018-02 "Assignment Clarification in IPv6 Policy"
Jordi Palet Martinez / Erik Bais

2018-03 Fixing Outdated Information in the IPv4 Policy
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

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

[Sander Steffann]

Hello working group!

As Gert has announced last month: I'm stepping down as co-chair of APWG at the 
next RIPE meeting in Marseille. So far we have two candidates who have 
volunteered to serve you all as new co-chair:
- Erik Bais
- Sean Stuart

If there are more people willing to volunteer: please speak up!


Our selection process consists of trying to get consensus during the working 
group session on who this working group would like to appoint. To avoid 
spending a long time debating this in Marseille I would like to ask you to 
start working towards consensus here on the list.

If we can't get consensus because all candidates are equally awesome then we 
can still fall back to the secret ballot procedure, but in the spirit of our 
bottom up consensus based tradition I would prefer it if we can do this by 
cooperation and consensus instead of voting.

Cheers!
Sander



signature.asc
Description: Message signed with OpenPGP

Re: [address-policy-wg] [CFP] 2nd Asia-Pacific Workshop on Networking (APNet 2018)

[Sander Steffann]

Hello,

The RIPE Address Policy working group mailing list is for discussions regarding 
policy proposals for the RIPE region. Please refrain from posting CFPs to this 
list.

Sincerely,
Sander Steffann
Address Policy WG co-chair


> Op 21 feb. 2018, om 18:31 heeft ap net <apne...@gmail.com> het volgende 
> geschreven:
> 
> **
>CALL FOR PAPERS
>APNet 2018
>   The Second Asia-Pacific Workshop on Networking
>  Beijing, China, August 2--3, 2018
>   https://conferences.sigcomm.org/events/apnet2018/index.html
> **
> Overview
> 
> The Second Asia-Pacific Workshop on Networking (APNet’18) aims to bring 
> together the very best researchers in computer networking and systems across 
> the Asia-Pacific region and the global community to a live forum discussing 
> and debating innovative ideas at their early stages. The mission of APNet is 
> that promising but not-yet-mature ideas can receive timely feedback from 
> experienced researchers, shaping them into major conferences such as SIGCOMM, 
> NSDI, SOSP, OSDI, MobiCom, CoNEXT and so on.
> 
> Program Committee
> General Chairs
> Dan Li (Tsinghua University, China)
> K. K. Ramakrishnan (University of California, Riverside, USA)
> 
> PC Co-Chairs
> Mosharaf Chowdhury (University of Michigan, USA)
> Kun Tan (Huawei, China)
> 
> Steering Committee
> Suman Banerjee (University of Wisconsin, USA)
> Kai Chen (HKUST, Hong Kong SAR), Co-Chair
> Albert Greenberg (Microsoft, USA)
> Jitu Padhye (Microsoft, USA)
> KyoungSoo Park (KAIST, South Korea)
> Kun Tan (Huawei, China), Co-Chair
> Minlan Yu (Yale University, USA)
> Lin Zhong (Rice University, USA)
> 
> **
> We invite submissions of short papers (up to 6 pages, including references) 
> on a wide range of networking research, including, but not limited to:
> •   Network architectures and algorithms
> •   Cloud and wide-area networking systems & infrastructure
> •   Networking support for applications
> •   Operating system support for networking
> •   Kernel-bypass and RDMA networking and applications
> •   Enterprise, datacenter, and storage area networks
> •   SDN, NFV, and network programming
> •   Networking hardware design
> •   Network measurement, monitoring, diagnosis, and operations
> •   Formal methods and network verification
> •   Network security and privacy, censorship, transparency
> •   Network, transport, and application-layer protocols
> •   Resource management, QoS, and signaling
> •   Routing, traffic engineering, switching, and addressing
> •   Wireless, mobile, and sensor networking
> 
> The APNet Program Committee will select papers based on novelty, 
> significance, and technical merit, rather than completeness. Innovative 
> well-reasoned ideas with preliminary evaluations will suffice for APNet. 
> Accepted papers will be published in the ACM Digital Library. We hope that 
> the extension of APNet papers, when substantiated by solid implementation and 
> experimentation, can be published at the aforementioned premier conferences.
> 
> Important Dates
> Abstract registration:   April 6, 2018 (11:59 GMT)
> Paper submission: April 13, 2018 (11:59 PM GMT)
> Notification of decision:   June 11, 2018
> Camera-ready date:  June 25, 2018
> 
> 
> We apologize if you receive multiple copies of this CFPs.
> We appreciate your help to forward this CFPs to your friends & email lists.
> 
> 
> __
> Publicity Co-Chair
> 
> Chen Qian
> Assistant Professor
> Department of Computer Engineering
> Jack Baskin School of Engineering
> University of California Santa Cruz
> 
> 



signature.asc
Description: Message signed with OpenPGP

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

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] 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] what does consensus mean

[Sander Steffann]

Hi Jordi,

> 1) Policy text say: "... separate addresses (not prefixes) ...".
> 2) Max proposal say: "... or anything alike where devices of non-members of 
> the organisation would get assigned an IP out of the organisation’s prefix 
> ..."
> 3) Max proposal say: "... Explicitly allowing another entity to be provided 
> with addresses from a subnet ..."
> 4) Max proposal say: "... A subnet in the spirit of this policy is a prefix 
> from the PI/PA assignment with a prefix length of /64 or longer ..."
> 5) Max proposal say: "... or for housing/hosting for servers in data centres 
> ..."
> 6) IA say: "... There are cases where a /64 is needed per customer to provide 
> a separate address ..."
> 7) IA say: "... It is the RIPE NCCs understanding that assignments as 
> described above are dynamic in nature, either by varying the prefix or 
> interface identifier (IID) over time. Any permanent and static assignments of 
> a prefix would still be considered a sub-assignment ..."
> 8) IA say: "... by using single IPv6 addresses for End User devices and 
> services ..."
> 
> [...]
> 
> 5 seem to indicate that this is acceptable in data centres, but 7 says 
> permanent and static ... I don't see how a data centre can do temporary 
> addresses?

Now that is indeed a contradiction that I agree with. Here the NCC's 
interpretation is more strict than what the policy says, and that should be 
corrected. Marco, can you look at this again from the NCC's perspective?

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] 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,

> 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 Jordi,

> I participate on IETF, and I know RFC7282, however I fail to see in our PDP 
> that we are bound to that RFC?

As Jim has said, the definition of consensus is determined by consensus :)  And 
for this working group the chairs apply consensus roughly based on that RFC.

> I also just read again the PDP, and my understanding is that we are doing 
> something different than what the process say, following
> 
> https://www.ripe.net/publications/docs/ripe-642
> 
> I don’t see how a policy proposal that at the end of the review phase 
> (maximum 4 weeks), has not reached consensus, as the only alternative is a 
> “new” review phase, with a new version of the proposal:
> 
> From the PDP:
> “The WG chair can also decide to have the draft RIPE Document edited and 
> start a new Review Phase with a new version of the proposal.”

In RIPE the chairs are allowed to use common sense and their own judgement when 
chairing a working group. Please don't try to make rules for everything, we're 
not lawyers, we're people trying to get work done in the best interests of this 
community.

Cheers,
Sander

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

[Sander Steffann]

Hi Jordi,

> I agree that is not “unanimity”, but I don’t think there is consensus on this 
> proposal, and even less I think is fair to extend the review period “because” 
> a proposal has been brought in the last minute to another fora, when the 
> chairs already declared “that we don’t have consensus”.
> 
> See this message:
> 
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2017-November/012271.html
> 
> Is something that we should do for every policy proposal that don’t reach 
> consensus?

Definitely not. As you can see from the history of APWG we have had plenty 
proposals that never reach consensus, and this is fine.

> Is this meaning that we will always “extend” the PDP timeline *until* we 
> reach consensus?

Nope. The extension was because you suggested a new approach (going further 
than what the current proposal was addressing) and we wanted to see if there 
was support in the community for your approach. It turned out that solving the 
current need with a good-enough solution was seen as more important than 
getting a perfect solution some time in the future.

Short summary:
- a problem was discovered in the IPv6 policy
- we see consensus that this policy proposal solves that problem
- we recognise that you would like an even better solution
- and we'll happily work with you to achieve that!
- but because this proposal solves the original problem we don't want to delay 
it

> Then, my reading is that EVERY policy proposal can always reach consensus, is 
> just a matter of finding enough folks (or virtual voices) that register into 
> the mailing list and support the proposal vs non-supporters.
> 
> Not sure if you see my point?

I see what you are saying, and I disagree with it. Please see the mailing list 
archives to check the history of this working group.

Cheers,
Sander

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

[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

[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] 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] 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] 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] 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-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]

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

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

[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] 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

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

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

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