Re: [address-policy-wg] Review of IPv6 policy goals

[JORDI PALET MARTINEZ via address-policy-wg]

Of course, nobody can force others to work with anyone, however this means:

1) We can't call this community anymore open, transparent and inclusive.
2) Several people not willing to work with others will create a number of 
groups of people working on the same or very similar things, and they we will 
have funny discussions when we have competing policy proposals.

I don't think this is right neither good at all. Of course, in that case, the 
chairs will need to avoid discrimination and accept all the possible different 
proposals from different people, which is smarter than having a single one.

And by the way, if you don't want to work with other community member(s), you 
should openly tell that.

Also, the chairs should have made explicit that the call for volunteers was 
done to create different groups of people not willing to work with others, as 
clearly the chairs knew that some "small" group was working already on that, 
and they didn't even provide the opportunity to the other volunteers to 
participate.

Regards,
Jordi
@jordipalet
 
 

El 16/3/22, 13:04, "Gert Doering"  escribió:

Hi,

On Wed, Mar 16, 2022 at 12:25:27PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> We have already seen several samples of discrimination in the RIPE 
community since some months ago. Is this one more? Should we change the 
principles of openness and inclusivity?

You can not force random volunteer people (with no formal power or mandate)
to work with you.

This has nothing to do with "inclusivity" but with "it's my choice who
I spend my time with".  

It's also only discrimination if there is a process for joining and you 
are rejected because you are "Jordi", instead of generic reasoning, like
"we have enough people already".  (OTOH, with all these accusations being
thrown around by you, I'm sure all volunteer groups will all be totally 
happy to have you on board, and will be making exceptions to their rules,
 just for you.  Which would not be discriminating, of course.)


Now, for everything relevant to policy decisions, this happens on the
public list.  If you haven't seen anything, this is because nothing has
happened yet.

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

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



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

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




-- 

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] Review of IPv6 policy goals

[JORDI PALET MARTINEZ via address-policy-wg]

Hi James,

 

I was among the 3-4 volunteers that spoke up in the meeting and I knew nothing 
about this “small” group. So now is the group just 2 people and how this people 
were “selected”?

 

Anyway, I don’t think it could be a problem if instead of 2, 3 or 4 we have 5 
or even 10 people.

 

We have already seen several samples of discrimination in the RIPE community 
since some months ago. Is this one more? Should we change the principles of 
openness and inclusivity?

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:57, "address-policy-wg en nombre de James Kennedy" 
 
escribió:

 

Hi, 

 

An intentionally small group of community members - in order to be agile, work 
efficiently, and avoid too many cooks, etc. - have already started work on the 
IPv6 policy review. 

 

They will provide a status update over the coming days. Other community members 
are encouraged and warmly welcomed to actively contribute to the review by 
providing their feedback and input on the mailing list. 

 

Regards, 

James 

 

On Wed, Mar 16, 2022 at 11:51 AM JORDI PALET MARTINEZ via address-policy-wg 
 wrote:

Not too much, was a short presentation:

 

 

https://ripe83.ripe.net/archives/video/644/

 

 

Saludos,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:43, "address-policy-wg en nombre de mathias.westerlund" 
 
escribió:

 

Alright!

 

Good to know.

Do you perhaps have a pointer to the meeting notes so i can read deeper on the 
discussion and see what i could contribute with in more details? Or if you feel 
you have the time to help me catch up what has been said.

 

Either is perfectly fine to me.

 

 

 

 

 

On 2022-03-16 11:23, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:

Hi Mathias,

 

Sorry if I didn’t make it clear: of course, is NOT restricted to any specific 
group or set of “original” volunteers, anyone willing to participate must be 
allowed to.

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:06, "mathias.westerlund"  escribió:

 

Heya. while i know and understand this is a call for the original volunteers to 
speak up, if there is a need for more people then i would personally like to 
volunteer, This was something discussed before we became members but as we are 
an ISP and MSP aiming to be 100% IPv6 native for all our customers this lies 
close to my heart and i hope that if you do need more people that you could 
accept someone very green to RIPE but very weilling to contribute.

 

Regards, Mathias W.

 

 

 

 

On 2022-03-16 10:54, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
Hi all,

In the last WG meeting (at the RIPE 83), there was a brief presentation from 
the chairs about the possible review of IPv6 policy goals.

I recall there was at least 3-4 people that volunteered (included myself), but 
after that we didn't get any discussion in the list or among the people that 
volunteered.

I've not seen any discussion in the list, neither the volunteers being in touch 
to start working on this, so I think we must move on somehow to get the work 
done. Could the volunteers confirm they are still willing to participate and we 
can find a way to organize the work together?


Regards,
Jordi
@jordipalet
 
 



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

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




-- 

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

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

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

Re: [address-policy-wg] Review of IPv6 policy goals

[JORDI PALET MARTINEZ via address-policy-wg]

Not too much, was a short presentation:

 

 

https://ripe83.ripe.net/archives/video/644/

 

 

Saludos,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:43, "address-policy-wg en nombre de mathias.westerlund" 
 
escribió:

 

Alright!

 

Good to know.

Do you perhaps have a pointer to the meeting notes so i can read deeper on the 
discussion and see what i could contribute with in more details? Or if you feel 
you have the time to help me catch up what has been said.

 

Either is perfectly fine to me.

 

 

 

 

 

On 2022-03-16 11:23, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:

Hi Mathias,

 

Sorry if I didn’t make it clear: of course, is NOT restricted to any specific 
group or set of “original” volunteers, anyone willing to participate must be 
allowed to.

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:06, "mathias.westerlund"  escribió:

 

Heya. while i know and understand this is a call for the original volunteers to 
speak up, if there is a need for more people then i would personally like to 
volunteer, This was something discussed before we became members but as we are 
an ISP and MSP aiming to be 100% IPv6 native for all our customers this lies 
close to my heart and i hope that if you do need more people that you could 
accept someone very green to RIPE but very weilling to contribute.

 

Regards, Mathias W.

 

 

 

 

On 2022-03-16 10:54, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
Hi all,

In the last WG meeting (at the RIPE 83), there was a brief presentation from 
the chairs about the possible review of IPv6 policy goals.

I recall there was at least 3-4 people that volunteered (included myself), but 
after that we didn't get any discussion in the list or among the people that 
volunteered.

I've not seen any discussion in the list, neither the volunteers being in touch 
to start working on this, so I think we must move on somehow to get the work 
done. Could the volunteers confirm they are still willing to participate and we 
can find a way to organize the work together?


Regards,
Jordi
@jordipalet
 
 



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

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




-- 

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

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

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

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

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



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

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you 

Re: [address-policy-wg] Review of IPv6 policy goals

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Mathias,

 

Sorry if I didn’t make it clear: of course, is NOT restricted to any specific 
group or set of “original” volunteers, anyone willing to participate must be 
allowed to.

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/22, 11:06, "mathias.westerlund"  escribió:

 

Heya. while i know and understand this is a call for the original volunteers to 
speak up, if there is a need for more people then i would personally like to 
volunteer, This was something discussed before we became members but as we are 
an ISP and MSP aiming to be 100% IPv6 native for all our customers this lies 
close to my heart and i hope that if you do need more people that you could 
accept someone very green to RIPE but very weilling to contribute.

 

Regards, Mathias W.

 

 

 

 

On 2022-03-16 10:54, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
Hi all,

In the last WG meeting (at the RIPE 83), there was a brief presentation from 
the chairs about the possible review of IPv6 policy goals.

I recall there was at least 3-4 people that volunteered (included myself), but 
after that we didn't get any discussion in the list or among the people that 
volunteered.

I've not seen any discussion in the list, neither the volunteers being in touch 
to start working on this, so I think we must move on somehow to get the work 
done. Could the volunteers confirm they are still willing to participate and we 
can find a way to organize the work together?


Regards,
Jordi
@jordipalet
 
 



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

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




-- 

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



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

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

-- 

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] Review of IPv6 policy goals

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

In the last WG meeting (at the RIPE 83), there was a brief presentation from 
the chairs about the possible review of IPv6 policy goals.

I recall there was at least 3-4 people that volunteered (included myself), but 
after that we didn't get any discussion in the list or among the people that 
volunteered.

I've not seen any discussion in the list, neither the volunteers being in touch 
to start working on this, so I think we must move on somehow to get the work 
done. Could the volunteers confirm they are still willing to participate and we 
can find a way to organize the work together?


Regards,
Jordi
@jordipalet
 
 



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

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




-- 

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Marcus,

I don't think any RIR is in a position to reserve space for a conference/event 
with thousands of participants bringing their own multiple devices and allowing 
public addresses for each one. Even many ISPs will not be able to do that!

With 464XLAT you don't really need that, and the effect "for the participant 
devices" is the same as having NAT or CGN, with the advantage that they will 
also get global IPv6 addresses (as many as they want for every device if they 
deliver /64 per host as per RFC8273).

In section 3.4 (IPv4 Pool Size Considerations) of 
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/ (which 
has been already submitted to the IESG for publication), you can find a simple 
calculation that demonstrates that a /22 (IPv4) can server, for example, over 
275.000 subscribers (devices in a conference), in the worst case.
 
Saludos,
Jordi
@jordipalet
 
 

El 7/3/22 12:32, "address-policy-wg en nombre de Marcus Stoegbauer" 
 escribió:

Apologies for the late reply, I'm just catching up with my mailing lists..

On 27 Jan 2022, at 16:44, JORDI PALET MARTINEZ via address-policy-wg wrote:

> I'm not convinced that we should "today", provide IPv4 temporary 
assignments, neither for conferences or experiments.
>
> A conference can perfectly survive today with a single IPv4 public 
address (or very few of them) from the ISP providing the link (even if running 
BGP), using 464XLAT, so the participants get dual-stack in the same way they 
are used to (private IPv4 addresses) and they also have global IPv6 addresses. 
This can be made with pure open source in a VM (if the provider doesn't have a 
NAT64, it can be also in the VM, in addition to the CLAT support, both using 
Jool, or other choices), etc. It is very well proven.

A conference is not a very well defined term. I agree with your assessment 
for conferences like RIPE meetings, NOGs and so on.
However, also events like Chaos Communication Congresses 
(https://events.ccc.de/congress/2019/wiki/index.php/Main_Page as an example) 
have the word conference in it. And those are events with >15,000 users, 
stretching over almost a week, where each participant is bringing multiple 
devices. Here you won't simply use one or even a handful of public IPv4 
addresses for translation, but rather want a public IPv4 address per device. In 
short: I still see a need, also for shorter temporary assignments for 
conferences like this.

   Marcus-- 

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



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

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




-- 

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] RU goverment IP revoke

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Leo,

I fully agree with you, however I didn't start it, and it's funny to see one 
more discrimination in this community, by warning only one of the participants 
in the discussion. Very illustrative.

Saludos,
Jordi
@jordipalet
 
 

El 25/2/22 20:27, "address-policy-wg en nombre de Leo Vegoda" 
 escribió:

Jordi,

RIPE Working Groups are forums for professional discussion. They are
not forums for advocating political policies.

This is a difficult time. Emotions are understandably high. But please
keep posts to the Address Policy WG list on the subject of Address
Policy and avoid broader political policies.

A discussion about the impact of decisions made by governments or
others on our Address Policy work is fine as long as we remain
professional.

Kind regards,

Leo Vegoda
Address Policy WG Co-Chair

On Fri, Feb 25, 2022 at 10:41 AM JORDI PALET MARTINEZ via
address-policy-wg  wrote:
>
> The problem is that Russia is under the control of a criminal dictator 
and a crazy one. He is just looking for a worldwide nuclear conflict, clearly. 
According to the news, now he just threatened Finland and Sweden.
>
> If the rest of the world keeps surrendering to his wishes, as we did many 
times, many governments, even when he perpetrated criminal actions outside his 
own territory (for example, poisoning in UK, invasion of Crimea, etc.), he will 
never stop.
>
> The Russian population has "accepted" him; they are somehow responsible. 
If they really wished hard to take him down, there are 150 million of people in 
the country to take an action and they had many years to do so. I know is very 
easy to say, not so easy to act, but I'm not talking about a single person 
acting.
>
> He is precisely knowing that we will think "we can't do this because the 
poor population".
>
> People from Russia has been connected to Internet and they know 
sufficiently how their dictator is acting inside their country and towards the 
rest of the world. Situation has not changed across the years, and they haven´t 
reacted.
>
> Is time for a strong action from all the possible sides. We have a new 
"Bin Laden", which is million times much more powerful and if the rest of the 
world is not acting, we will suffer it sooner or later.
>
> If we think twice, economic sanctions will also be bad for the 
population, and just dust for the dictator. Those economic sanctions will also 
be bad for the rest of the world. I agree with them.
>
> I disagree with offensive military actions, but at the same time we must 
find as many possible ways to isolate the country and unless in his craziness 
he pushes the nuclear buttons first (as an offensive action), sooner or later 
that will create sufficient internal country reactions to topple him.
>
> Unfortunately, I don't think there is any other path forward and it will 
be ideal that voluntarily, until governments that the decision, carriers and 
ISPs, filter all their traffic, which also could at least in some %, avoid some 
of the cyber-attacks that are coming from there, which can target not just 
Ukraine, but any other country.
>
>
> Hi,
>
> On Fri, Feb 25, 2022 at 06:07:32PM +0100, Kurt Kayser wrote:
> > Internet is the fasted and most efficient way to show what happens and
> > who is responsible for it.
> >
> > Let's all work together that this stay this way.
>
> My initial toughts were similar to what was proposed ("let's just cut
> off ALL Internet to .RU!  That will hurt them!") I have reconsidered,
> and now share the opinion that Kurt voiced - cutting off Internet access
> will hurt the russian people more, and benefit the spreading of
> misinformation.
>
> So, make sure Information can flow.
>
> Gert Doering
> -- just a concerned user
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael 
Emmer
> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use

[address-policy-wg] RU goverment IP revoke

[JORDI PALET MARTINEZ via address-policy-wg]

The problem is that Russia is under the control of a criminal dictator and a 
crazy one. He is just looking for a worldwide nuclear conflict, clearly. 
According to the news, now he just threatened Finland and Sweden.

If the rest of the world keeps surrendering to his wishes, as we did many 
times, many governments, even when he perpetrated criminal actions outside his 
own territory (for example, poisoning in UK, invasion of Crimea, etc.), he will 
never stop.

The Russian population has "accepted" him; they are somehow responsible. If 
they really wished hard to take him down, there are 150 million of people in 
the country to take an action and they had many years to do so. I know is very 
easy to say, not so easy to act, but I'm not talking about a single person 
acting.

He is precisely knowing that we will think "we can't do this because the poor 
population".

People from Russia has been connected to Internet and they know sufficiently 
how their dictator is acting inside their country and towards the rest of the 
world. Situation has not changed across the years, and they haven´t reacted.

Is time for a strong action from all the possible sides. We have a new "Bin 
Laden", which is million times much more powerful and if the rest of the world 
is not acting, we will suffer it sooner or later.

If we think twice, economic sanctions will also be bad for the population, and 
just dust for the dictator. Those economic sanctions will also be bad for the 
rest of the world. I agree with them.

I disagree with offensive military actions, but at the same time we must find 
as many possible ways to isolate the country and unless in his craziness he 
pushes the nuclear buttons first (as an offensive action), sooner or later that 
will create sufficient internal country reactions to topple him.

Unfortunately, I don't think there is any other path forward and it will be 
ideal that voluntarily, until governments that the decision, carriers and ISPs, 
filter all their traffic, which also could at least in some %, avoid some of 
the cyber-attacks that are coming from there, which can target not just 
Ukraine, but any other country.


Hi,

On Fri, Feb 25, 2022 at 06:07:32PM +0100, Kurt Kayser wrote:
> Internet is the fasted and most efficient way to show what happens and 
> who is responsible for it.
> 
> Let's all work together that this stay this way.

My initial toughts were similar to what was proposed ("let's just cut
off ALL Internet to .RU!  That will hurt them!") I have reconsidered, 
and now share the opinion that Kurt voiced - cutting off Internet access 
will hurt the russian people more, and benefit the spreading of 
misinformation.

So, make sure Information can flow.

Gert Doering
-- just a concerned user
-- 
have you enabled IPv6 on something today...?

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



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

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




-- 

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] RU goverment IP revoke

[JORDI PALET MARTINEZ via address-policy-wg]

While I will applaud something like that, I don't think we can do it as RIPE 
community, unless there is any specific legal section in the RSA against 
countries taking over other countries and then the NCC can make it happen ...

I think such kind of actions, including ordering all the transit providers to 
shut down links with Russia, can only be taken by the EU, or individual 
countries at government levels, as part of the sanctions that are being 
organized. Probably will be the only way to isolate Russia from the rest of the 
world and avoiding them using also Internet for cyber-criminal actions. They 
could still try to escape from that using other transit providers, but they 
will need to hide the ASNs, etc. not so easy from any of the sides that you 
look at it. May be filtering specific IP ranges, ordered as part of the 
sanctions against Russia by all the ISPs in each country supporting that ...

Regards,
Jordi
@jordipalet
 
 

El 25/2/22 17:24, "address-policy-wg en nombre de Max Tulyev" 
 escribió:

Hello All,

let's think about sanctions against Russia. What do you think about 
revoking all IPs/ASNs used by Russian goverment?

-- 

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



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

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




-- 

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

[JORDI PALET MARTINEZ via address-policy-wg]

That look to me as a good approach.

That will be a good way to handle "really needed" IPv4 experiments, which I 
don't think are relevant anymore, but I'm happy to support if there are good 
and needed cases considering the good of the overall community.

The negative part is the overhead of the panel selection, etc.

In any case, I'm still for not having temporary delegations of IPv4 for 
conference, I don't think there is a excuse for that today.

May be the NCC can tell us, in the last 10 years or so, how many IPv4 temporary 
assignments have been provided for both, conferences, experiments, and "other" 
cases (if there have been)?
 
Regards,
Jordi
@jordipalet
 
 

El 28/1/22 12:21, "address-policy-wg en nombre de Daniel Karrenberg" 
 escribió:



I have the strong suspicion that this is another example of trying to 
codify special/corner cases. Doing this takes disproportionate amounts 
of energy and causes an ever increasing amount of undesired side 
effects.



How about giving the RIPE NCC discretion to make sensible decisions 
about the corner case ‘scientific experiment’ after getting advice 
from a panel of scientists?
Or delegating the decisions to such a panel?

This way we could avoid spending energy on codification and avoid the 
undesired side effects. We would just need to find a couple of credible 
people to review the requests. I expect this to be less work than 
codification and re-codification …

Daniel

-- 

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



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

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




-- 

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

[JORDI PALET MARTINEZ via address-policy-wg]

I'm not convinced that we should "today", provide IPv4 temporary assignments, 
neither for conferences or experiments.

A conference can perfectly survive today with a single IPv4 public address (or 
very few of them) from the ISP providing the link (even if running BGP), using 
464XLAT, so the participants get dual-stack in the same way they are used to 
(private IPv4 addresses) and they also have global IPv6 addresses. This can be 
made with pure open source in a VM (if the provider doesn't have a NAT64, it 
can be also in the VM, in addition to the CLAT support, both using Jool, or 
other choices), etc. It is very well proven.

Now, regarding to experiments, I don't think we should keep doing IPv4 
experiments anymore and in the case it is really needed, I think it should be 
possible to obtain the required addresses from the DCs where the experiment 
will be co-located.

So, in short, I think if work is done, it makes more sense to send this policy 
to "historic", at least deprecating the IPv4 part.

I'm happy to work on that with a proposal, which seems to be very simple to do.

Regards,
Jordi
@jordipalet
 
 

El 27/1/22 15:45, "address-policy-wg en nombre de Angela Dall'Ara" 
 escribió:

Hi Gert, Randy and Leo,

Thank you for dedicating attention and time to ripe-587, as this policy 
became more topical since the IPv4 run-out.

The requests for temporary assignments are always evaluated by the RIPE 
NCC on a case-by-case basis, and the current text of the policy presents 
some challenging aspects for the approval.

Requests related to conferences and events generally include a 
documentation that can easily show the utilisation of the addresses and 
the time of the assignment. Sometimes there is some time pressure due to 
last-minute submissions and there were few occasions when organisers 
would have preferred more than the policy limit of two months, but 
overall this part of the policy is sufficiently clear for the RIPE NCC.

The requests for research and testing are posing challenges for the 
approval against the required address utilisation (50%) stated in the 
policy, when this cannot be reached due to the nature of the 
research/experiment/test.

We also receive requests where the temporary assignment purpose appears 
to be part of a standard network setup as the test/experiment/research 
is motivated with the need of configuring and testing a protocol or a 
feature that is new to the requester's network while being already 
widely used in other ones. Many of these requests come from the 
requester's interpretation of the policy.

While the policy cannot cover all cases, a review of the technical 
requirements, time limits and address utilisation would be beneficial to 
facilitate the RIPE NCC’s assessment of different requests.

Kind regards,
Angela

-- 
Angela Dall'Ara
RIPE NCC Policy Officer



On 26/01/2022 18:32, Gert Doering wrote:
> Hi,
>
> On Tue, Jan 25, 2022 at 09:33:40AM -0800, Randy Bush wrote:
>> ok, i did it again, tried to fit a square peg in a round hole.  while
>> the immediate problem is past, thanks to the ncc reg folk, i fear that
>> we could benefit from thinking a bit more about $subject.
>>
>> for a research experiment, we wanted eight or a dozen routable, i.e.
>> /24, prefixes which we would announce from various places in the
>> topology.  each /24 would have one pingable address, let's assume .42.
> This is a tough nut.
>
> I can totally see what you do, and understand what space you need, and
> for which times.
>
> OTOH, I can totally see the NCC being worried about people claiming
> "experiments!  and I need a review!" and running their ISP for a year
> on temporary space - and with the argument "I want a dozen routable
> /24s", you can get quite some ISP work done.
>
> [..]
>> i am considering a policy proposal in this space; but want to learn what
>> others see and think, and to see if it is worth the time and effort.
> I want research and conferences and all these things to be possible,
> with temporary address space, and policies to be fairly liberal for
> "those good things".
>
> The NCC needs checklist-able items to say "this is okay" and "that is
> way too much space, you do not need a /16 for 6 months to run a
> conference with 1000 attendees for a week.
>
> How to codify this?  Dunno.
>
> Marco, Angela - what's your take on this ("feedback from RS" time)?
>
> Gert Doering
>


-- 

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



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

Re: [address-policy-wg] Suggestion to replace IPv4 waiting list with auctions

[JORDI PALET MARTINEZ via address-policy-wg]

If it is a new company and "not related" to the previous one, no way to verify 
the "cheating". If it is "subsidiary", the constitution document say it.

Yes, it can be bypassed, but the staff can confirm if it is being done that way 
in most of the cases or if it is different business units or subsidiaries of 
the same "original" LIR.


Regards,
Jordi
@jordipalet
 
 

El 24/11/21 11:45, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

    On Wed, Nov 24, 2021 at 11:38:48AM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> Yes, the people can try to cheat, but that's why the NCC verify 
documents, etc., right?

So, instead of opening a new LIR under "SpaceNet AG", I register a new
UK umbrella company under the name of "My New LIR Ltd".

This one would then apply for a new RIPE membership.

How do you know it's "SpaceNet AG" trying to sneak in and get more space?


I've said that before: we've been there before - the "restrict multiple
LIR accounts" approach leads to "those people that are in for the easy
monay and do not care for anything else" will just register new companies
with a new name for every new LIR.  Nothing won, but database accuracy
suffers, because you can't see the real owner anymore.

Thus, having a checkbox on the application form might actually do more
good - people will still cheat, but it won't harm the registry.

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

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



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

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




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] Suggestion to replace IPv4 waiting list with auctions

[JORDI PALET MARTINEZ via address-policy-wg]

Yes, the people can try to cheat, but that's why the NCC verify documents, 
etc., right?


El 24/11/21 11:35, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

On Wed, Nov 24, 2021 at 11:30:06AM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> I don't think this will work and it not fair.
> 
> Those resources should be provided only to new-entrants not new-LIRs from 
exisiting members.

That's a nice solution.  Just have a checkmark on the "new LIR" form that
says

  [ ] this is a new LIR and not related to any other LIR having IPv4 space

and people would certainly fill this in correctly.

Surely?

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

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



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

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




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] Suggestion to replace IPv4 waiting list with auctions

[JORDI PALET MARTINEZ via address-policy-wg]

I don't think this will work and it not fair.

Those resources should be provided only to new-entrants not new-LIRs from 
exisiting members.

 
 
Regards,
Jordi
@jordipalet
 
 

El 23/11/21 21:53, "address-policy-wg en nombre de Wolfgang Zenker" 
 escribió:

Greetings,

in todays WG session Marco Schmidt pointed out that more than half of
the /24s allocated from the waiting list pool go to members with
multiple LIRs. The number of newly created LIRs eligible for a /24 has
increased a lot in recent months, to the point where requests can no
longer be filled from the available pool but new LIRs have to wait for
blocks coming out of quarantine. This change appears to be due to market
value for IPv4 blocks being now significantly larger than the cost for
creating a new LIR and maintaining it for the two year holding period.
The result of this is that newcomers have no easy access to a first IPv4
block but have to wait in line together with multi-LIR address hoarders,
defeating the purpose of the waiting list policy.

I suggest to replace the waiting list with the following system:
- /24s becoming available are put to an auction.
- every interested member organisation (NOT: LIR) can make a bid of an
  amount that is not visible to the other bidders.
- highest bid wins.

Expected result would be less requests from address hoarders because
they could get address blocks for a similar price on the open market
without the additional overhead of creating a new member. Newcomers on
the other hand would have to become members to be able to hold addresses
in the first place, and can use the auction to get access to a properly
quarantined address block to start their business.


Regards,
Wolfgang Zenker
-- 
punkt.de GmbH   Tel. +49 721 9109-500   Fax: 
-100
.infrastructure i...@punkt.de
https://infrastructure.punkt.de/
Kaiserallee 13a CEO: Jürgen Egeling, Daniel Lienert, Fabian 
Stein
D-76133 Karlsruhe   AG Mannheim HRB 108285


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



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

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




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

[JORDI PALET MARTINEZ via address-policy-wg]

+1

 

We may need to consider if it is right that the remains of IPv4 can be 
allocated to new LIRs from existing members instead to only new-entrants. I 
think the community must be fairer. This is the way handled in other RIRs as 
well (not all them).

 

If the problem with IPv6 is that the justification is harder to get more than 
/29, one possible approach is to clarify it, not neccesarilly with a policy 
change but guidelines, etc.  Note that I don’t think that’s the case, I really 
believe if you need more than /29, it is possible to justify it, but may be 
people believe that it is easier to artificially create multiple LIRs and get a 
/29 for each one. This is something that only the staff can tell. As much info 
as we have about why this happens, easier to find possible avenues for a better 
solution.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/11/21 13:26, "address-policy-wg en nombre de James Kennedy" 
 
escribió:

 

[changed mail client alias\author to my name, apologies for duplication] 

 

Hi, 

 

Re: 'who does IPv6 hoarding really hurt' or 'what's the danger', we should 
learn from some very harsh real-life lessons that happened with IPv4 
stockpiling. 

 

- when IPv4 was plentiful, a number of RIPE members we able to hoard vast 
volumes of IPv4 and distribute large IPv4 network prefixes (e.g. full /18s) to 
their customers but provide little to no technical services (became de facto 
local RIRs) 

- this was attractive to their customers at the time - often network operators 
- because the RIPE members would lease the address space for a much lower price 
than a RIPE NCC membership fee 

- as their customers became increasingly dependant on those IPv4 network 
prefixes over time to run their operations, the RIPE members abused their power 
and raised the lease costs to absolute extortionate and unaffordable amounts - 
often to sell the parent allocation on the IPv4 market 

 

This is in addition to conflicting with RIPE IPv6 goals and policy, and 
reducing the RIPE NCC's ability to check and verify that the address space is 
being used in line with RIPE IPv6 goals and policy. 

 

Do we really want to sleepwalk into a similar situation with IPv6? If not, how 
can we proactively safeguard IPv6 from such abuse while ensuring easy access to 
IPv6 for real deployments? Change IPv6 transfer policy, and/or lower the RIPE 
NCC membership fee (e.g. a cheaper IPv6-only membership category)? 

 

 

Regards, 

James 

apwg co-chair 

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 



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

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

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] do we need a policy for avoiding "multiple unjustified LIRs"?

[JORDI PALET MARTINEZ via address-policy-wg]

Not acting is a path for abuse and stockpiling. Not fair and we must resolve it 
avoiding it as much as possible.

 
Regards,
Jordi
@jordipalet
 
 

El 23/11/21 11:59, "address-policy-wg en nombre de Staff" 
 escribió:

Hello everybody,

Of cause no.

That will not help. always possible to avoid.
Doing more complex polices is not good way. NCC had already lot of 
issues with that.
Does any body remember how they asked to use email with the name to use 
in their database and people should change emails lot of times to 
sutisfy NCC We did  a lot of noise and NCC canceled it. Brr...

If people request space - then they need it and they select this way to 
get it with NCC.

This is normal process. No rush here. NCC should work as usual.

Yury


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



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

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




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] do we need a policy for avoiding "multiple unjustified LIRs"?

[JORDI PALET MARTINEZ via address-policy-wg]

Exactly, that's why a policy may be needed if I understood correctly Marco 
response, but anyway, happy to get further inputs from staff about that.

The question is "may it be handled only via a contractual change" or we need a 
policy to "implement that contractual change"?
 
Regards,
Jordi
@jordipalet
 
 

El 23/11/21 11:46, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

On Tue, Nov 23, 2021 at 11:43:09AM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> After looking at the video from Marco, today presentation/discussion and 
the recent discussions on this, as I just mention, should we work in a policy 
proposal to amend the internal procedure so the justification for additional 
LIRs is stronger?

There is no "justification for additional LIR" policy, as that's a
contractual matter...

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

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



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

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




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] do we need a policy for avoiding "multiple unjustified LIRs"?

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

After looking at the video from Marco, today presentation/discussion and the 
recent discussions on this, as I just mention, should we work in a policy 
proposal to amend the internal procedure so the justification for additional 
LIRs is stronger?

I understand many cases for the need of an additional LIR, but doing valid for 
*any artificial case* is not good.

Any though on that? Possible ideas about how we define the border line?

As usual, I'm happy to work on this myself, or together with other folks.

 
Regards,
Jordi
@jordipalet
 
 



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

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




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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Marco, all,

I think we need to better understand the reasons/background on those multiple 
allocations.

If the justification for a larger allocation is too "heavy" (I personally don't 
think so), we need to amend the language or the internal NCC procedure to 
facilitate larger allocations.

I can also understand that some "bad" actors are actually doing this for 
stockpiling, but I fail to see how they could take advantage of that even in 
the medium/long term. I don't think they will be able to make business out of 
those addressed in the next hundred years or even more ... because I can't see 
how exhaustion can happen earlier.

Definitively if they are trying to use this for other ISPs, it makes no sense, 
and it is bad for IPv6 deployment.

So again, I'm convinced that we need to better understand the reasons why this 
is happening before taking concrete actions, unless I'm missing something else.
 
Now, I've another question here. Once there are no more IPv4 addresses to give 
out ... there is any real business to allow "multiple LIRs" without a 
"stronger" justification? Because that will also resolve this problem ...

Regards,
Jordi
@jordipalet
 
 

El 29/10/21 12:03, "address-policy-wg en nombre de Marco Schmidt" 
 escribió:

Dear colleagues,

During RIPE 82, we provided you with an update on our observation of 
IPv6 stockpiling [1]. Based on the feedback we received and in 
preparation for the coming RIPE meeting, we would like to give you 
another update on that issue.

According to the IPv6 Address Allocation and Assignment Policy, an LIR 
can receive up to a /29 IPv6 allocation without needing to supply any 
additional information. The RIPE community considered this size 
sufficient for most organisations for long-term IPv6 deployment. 
Additionally, LIRs may qualify allocations greater than /29 by 
submitting documentation that reasonably justifies this request [2].

However, over the past few years we have noticed that some organisations 
are collecting multiple IPv6 allocations in ways that are permitted by 
current RIPE policies but might conflict with the above-mentioned intent 
of the IPv6 policy. For example, it is possible for a single RIPE NCC 
member to receive a /29 allocation for each of the multiple LIR accounts 
that it holds. This is the result of a policy change in 2018 [3]. LIRs 
can also receive multiple IPv6 allocations via policy transfers without 
needing any further justification. However, when the IPv6 transfer 
policy was discussed in 2014, it was assumed that there wouldn't be an 
active transfer market [4].

We have gathered data showing the significant development of the 
collection of IPv6:
- Almost 700 IPv6 allocations have been transferred in 2021 so far (and 
there have been more than 3,900 transfers since policy implementation in 
2015)
- About 60% all IPv6 allocations ever handed out by the RIPE NCC are now 
held as multiple allocations
- In the last three months, more than 75% of all new allocations were 
given to members that already hold at least one IPv6 allocation
- More than 1,500 members hold multiple IPv6 allocations, exceeding the 
size /29
- Almost 100 members hold more than 10 IPv6 allocations (the maximum is 
102 IPv6 allocations held by one member)

It is the RIPE NCC’s understanding that some of these situations are 
within the intent of previous policy changes, for example, to avoid 
renumbering of deployed IPv6 networks during holdership changes, or if a 
large company has multiple network departments that prefer to manage 
their own allocation.
However, the huge volume indicates that most are for other reasons. 
While members can collect multiple IPv6 allocations without evaluation 
by the RIPE NCC, we still were able to gather some feedback how members 
plan to use their allocations. Many members simply stockpile them for an 
undefined future use, others plan to use them for activities which 
temporarily require a vast amount of IPs, and some plan to offer IPv6 on 
a large scale to other ISPs in their country.

We believe that this situation could create several issues:
- IPv6 might be deployed in conflict with RIPE policies, underlying RFCs 
and other best practices, resulting in challenges to that IPv6 
deployment once the policy violation is discovered during an audit
- There could be a negative impact on the quality of the registry if 
large parts of allocations were given to third parties without clear 
registration requirements
- The policy requirement to justify larger IPv6 allocations would then 
be rendered useless

If you agree that this is a problem, we would like to initiate a 
discussion in this Working Group about possible solutions. We see at 
least two potential paths forward.

Firstly, if 

Re: [address-policy-wg] stockpiling IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Cynthia,

 

Exactly, that’s the point, there is no incentive – the only incentive is 
stockpiling, just in case IPv6 becomes scarse and may create a problem like the 
lack of IPv4, even if this takes 30 years, or 100 years, and you want to secure 
the funding of the kids of your kids by having a resource that then, will be 
subjected to market price and transfers.

 

If I understood correctly from Nikolas presentation (please, correct me if I’m 
wrong), the bigger ISPs, typically have a single LIR with a big allocation, but 
they don’t have (because they aren’t typically interested in games, just 
justified need), multiple LIRs with multiple IPv6 allocations (or at least not 
big ones).

 

Regards,

Jordi

 

 

El 28/10/20 13:47, "address-policy-wg en nombre de Cynthia Revström via 
address-policy-wg"  escribió:

 

Hi,

 

While I will admit it's a bit odd to allocate that much v6 space to a single 
entity, I don't see how this is going to cause issues based on what is 
currently happening, like this is not happening at scale.

 

Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who already 
had a /29. but there are many large ISPs who alone have more space than this. 
Telia has a /20, China Telecom has a /16.

 

Additionally there is no real incentive to request multiple /29s other than 
very rare cases. unless LIRs requesting like 16x /29s are a common occurrence, 
this is a non issue imo.

 

disclaimer: I do have 3x /29 for a reason that may seem like a waste to some 
people and my specific issue could probably be solved by RIPE allowing me to 
split my /29 into /32s.

 

-Cynthia

 

On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, 
 wrote:

Hi all,

After Nikolas presentation today, I've been thinking on possible ways to 
resolve this, so before sending a possible policy proposal, I think it deserves 
some discussion.

The intent of the proposal 2018-01 
(https://www.ripe.net/participate/policies/proposals/2018-01), was to align the 
IPv4 and IPv6 policies in the matter of an LIR vs organization.

We must remind that the allocation/assignment of resources is based on 
justified need. And yes, we have a lot of IPv6 space, but it is really 
justified and the same organization, having different LIRs, can use it as a 
trick for stockpiling if there is not such justified need?

In IPv4 this is not "a problem" because we don't have more space. Well ... not 
exactly true ... some organizations could have used "the trick" to get more 
IPv4 space by creating multiple LIRs.

In other regions, I think this is not a problem because the cost of the 
membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of 
the allocation/assignment. So, because IPv6 is not a scarce resource, it seems 
there is no incentive to pay more for getting more if you're not really using 
it.

However, in RIPE NCC, if you created several LIRs for getting more IPv4 
allocations, *even if you don't use/need it* you can get (and thus stockpile) 
IPv6 *at no extra cost*.

I clearly think this is not a good thing.

It seems to me that the problem lies in section 5.1.1. Initial allocation 
criteria, and exactly here:
b) have a plan for making sub-allocations to other organisations and/or End 
Site assignments within two years.

So, is the problem that "a plan" is not sufficient if it is not "verified" and 
the "bad guys" know that the chances for having it verified are too small?

Do we need some text about "recovery if not announced and used" ?

Other ideas?

Remember that the problem is not only about scarcity. This extra space may be 
used "intermittently" for bad or even criminal activities and we have a 
responsibility on that as a community.

Regards,
Jordi
@jordipalet




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

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







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

This electronic message contains information which may be privileged or 
confidential.

Re: [address-policy-wg] stockpiling IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Elvis & Aleksey (to avoid one extra email),

As said, it is a matter of responsibility. I'm not the NCC, neither work for 
them. I think it is a community matter and there is a clear principle here: 
"justified need".

I also agree that the justification can't be too strict, but there is always a 
right balance point.

If an organization has 20 LIRs and they can *justify the need* even for a /12 
for each LIR, I'm *perfectly fine* with that.

What I don't think is right is that we bypass the justified need. If we want to 
do that, let's remove it from all the policies.
 
Regards,
Jordi
@jordipalet
 
 

El 28/10/20 13:32, "address-policy-wg en nombre de Elvis Daniel Velea" 
 escribió:

Hi Jordi,

what is the problem you want to solve? 

Is the ‘IPv6 stockpiling’ creating any issues?

As far as I know, we have plenty of IPv6 available and by forcing return or 
imposing conditions on mergers/transfers you only create hurdles for the people 
that actually use IPv6.

I’d say this is a non problem and actually advise RIPE NCC RS to stop 
tracking/presenting on this unless this issue causes them complications in 
justifying additional allocation requests from the IANA.

Elvis 

Excuse the briefness of this mail, it was sent from a mobile device.

> On Oct 28, 2020, at 05:26, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> Hi Sergey,
> 
> Note that I'm not intending to change anything on IPv4 ...
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 28/10/20 13:20, "address-policy-wg en nombre de Sergey Myasoedov via 
address-policy-wg"  escribió:
> 
>Hi Jordi,
> 
>> Otherwise, do you have other suggestions, or do you think the we should 
ignore the stockpiling?
> 
>A 'stockpiling' on the obsoleted resource is a result of semi-free 
market. Just let the IPv4 go, and market and technology will do the rest.
> 
>And yes, I am the market player.
> 
>    --
    >    Kind regards,
>Sergey Myasoedov
> 
> 
>> On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
>> 
>> Hi Nick,
>> 
>> Could you explain why not?
>> 
>> Clearly it is something that should part of the NCC verification duties, 
but we have been told several times, in other policy proposals, that we need to 
make it explicit so they can "act".
>> 
>> Otherwise, do you have other suggestions, or do you think the we should 
ignore the stockpiling?
    >> 
>> Regards,
>> Jordi
>> @jordipalet
>> 
>> 
>> 
>> El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" 
 escribió:
>> 
>>   JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05:
>>> However, in RIPE NCC, if you created several LIRs for getting more
>>> IPv4 allocations, *even if you don't use/need it* you can get (and
>>> thus stockpile) IPv6 *at no extra cost*.
>>   [...]
>>> Do we need some text about "recovery if not announced and used" ?
>> 
>>   tl;dr: no.
>> 
>>   Nick
>> 
>> 
>> 
>> 
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 

Re: [address-policy-wg] stockpiling IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Sergey,

Note that I'm not intending to change anything on IPv4 ...

Regards,
Jordi
@jordipalet
 
 

El 28/10/20 13:20, "address-policy-wg en nombre de Sergey Myasoedov via 
address-policy-wg"  escribió:

Hi Jordi,

> Otherwise, do you have other suggestions, or do you think the we should 
ignore the stockpiling?

A 'stockpiling' on the obsoleted resource is a result of semi-free market. 
Just let the IPv4 go, and market and technology will do the rest.

And yes, I am the market player.

--
Kind regards,
Sergey Myasoedov


> On 28 Oct 2020, at 13:13, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> Hi Nick,
> 
> Could you explain why not?
> 
> Clearly it is something that should part of the NCC verification duties, 
but we have been told several times, in other policy proposals, that we need to 
make it explicit so they can "act".
> 
> Otherwise, do you have other suggestions, or do you think the we should 
ignore the stockpiling?
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" 
 escribió:
> 
>JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05:
>> However, in RIPE NCC, if you created several LIRs for getting more
>> IPv4 allocations, *even if you don't use/need it* you can get (and
>> thus stockpile) IPv6 *at no extra cost*.
>[...]
>> Do we need some text about "recovery if not announced and used" ?
> 
>tl;dr: no.
> 
>Nick
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 
> 
> 





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

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

Re: [address-policy-wg] stockpiling IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Nick,

Could you explain why not?

Clearly it is something that should part of the NCC verification duties, but we 
have been told several times, in other policy proposals, that we need to make 
it explicit so they can "act".

Otherwise, do you have other suggestions, or do you think the we should ignore 
the stockpiling?

Regards,
Jordi
@jordipalet
 
 

El 28/10/20 13:09, "address-policy-wg en nombre de Nick Hilliard" 
 escribió:

JORDI PALET MARTINEZ via address-policy-wg wrote on 28/10/2020 12:05:
> However, in RIPE NCC, if you created several LIRs for getting more
> IPv4 allocations, *even if you don't use/need it* you can get (and
> thus stockpile) IPv6 *at no extra cost*.
[...]
> Do we need some text about "recovery if not announced and used" ?

tl;dr: no.

Nick




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

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

[address-policy-wg] stockpiling IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,
 
After Nikolas presentation today, I've been thinking on possible ways to 
resolve this, so before sending a possible policy proposal, I think it deserves 
some discussion.

The intent of the proposal 2018-01 
(https://www.ripe.net/participate/policies/proposals/2018-01), was to align the 
IPv4 and IPv6 policies in the matter of an LIR vs organization.

We must remind that the allocation/assignment of resources is based on 
justified need. And yes, we have a lot of IPv6 space, but it is really 
justified and the same organization, having different LIRs, can use it as a 
trick for stockpiling if there is not such justified need?

In IPv4 this is not "a problem" because we don't have more space. Well ... not 
exactly true ... some organizations could have used "the trick" to get more 
IPv4 space by creating multiple LIRs.

In other regions, I think this is not a problem because the cost of the 
membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of 
the allocation/assignment. So, because IPv6 is not a scarce resource, it seems 
there is no incentive to pay more for getting more if you're not really using 
it.

However, in RIPE NCC, if you created several LIRs for getting more IPv4 
allocations, *even if you don't use/need it* you can get (and thus stockpile) 
IPv6 *at no extra cost*.

I clearly think this is not a good thing.

It seems to me that the problem lies in section 5.1.1. Initial allocation 
criteria, and exactly here:
b) have a plan for making sub-allocations to other organisations and/or End 
Site assignments within two years.

So, is the problem that "a plan" is not sufficient if it is not "verified" and 
the "bad guys" know that the chances for having it verified are too small?

Do we need some text about "recovery if not announced and used" ?

Other ideas?

Remember that the problem is not only about scarcity. This extra space may be 
used "intermittently" for bad or even criminal activities and we have a 
responsibility on that as a community.

Regards,
Jordi
@jordipalet




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

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

Re: [address-policy-wg] fairness and legacy resources

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Hans,

 

I was talking in general, not just in this region.

 

Also, they need be bound to the policies, which is not the case in all the 
regions.

 

As said, those are separate problems, not the same in all the RIRs, but closely 
related and also related to the transfers as a possible way to avoid the 
“continuity” of all those differential situations.

 

Regards,

Jordi

@jordipalet

 

 

 

El 21/10/20 16:06, "address-policy-wg en nombre de Hank Nussbacher" 
 escribió:

 

On 21/10/2020 13:16, Jim Reid wrote:
If you think legacy holders should pay something, I maybe agree with that in 
principle. [But definitely not signing a service agreement which forces a 
legacy holder to become an LIR.] And maybe that’s a discussion that could be 
had once there was some hard data.
 
...
 
If you want legacy holders to pay, both the RIPE and NCC policy making 
machinery is open to you.
 
Legacy holders already pay.  See screenshot from my LIR bill for 2020.  Been 
like that since our 2016 bill.

 

Regards,
Hank

 

Caveat: The views expressed above are solely my own and do not express the 
views or opinions of my employer 



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

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

Re: [address-policy-wg] Assignments have legacy status, not IP addresses themselves

[JORDI PALET MARTINEZ via address-policy-wg]

Hi David,

 

I never though on this from your perspective, and I think you’re right.

 

However, the point about M it is a bit more complex. If it is just a pure 
“renaming” of the company I will agree with you, but there are cases, where is 
not really a new “version of the organization”, in fact it may be just a way 
for a business to obtain IP addresses, or an ISP join/buy smaller ones to 
become bigger, etc. I think trying to differentiate those cases will make it 
very difficult.

 

However, there is an independent problem, which is getting services for free, 
which are being covered by the rest of the membership.

 

Regards,

Jordi

@jordipalet

 

 

 

El 21/10/20 13:57, "address-policy-wg en nombre de David Farmer via 
address-policy-wg"  escribió:

 

The concept that the legacy status applies independently to resources or IP 
addresses, separate from their assignment to a resource holder, seems 
incorrect. The legacy status applies to the assignment of resources to a 
resource holder before the creation of the RIRs, but not to the resources or 
the IP addresses themselves. 

 

All IPv4 addresses were created at the same time. When they were assigned for 
use differs; therefore, when they were assigned for use and to whom they are 
assigned for use is what matters.

When addresses are transferred to a different organization, a new assignment is 
made, or in other words, they are reassigned. And it seems proper that the new 
assignment no longer has the legacy status, as they are now assigned to a 
different organization.

When a merger or acquisition occurs, we also call that a transfer, but it is a 
transfer to a new version of the same organization, not to a different 
organization. In this case, it seems propers that the assignment maintains its 
legacy status, as the same organization, just a different version of the same 
organization, continues to hold the assignment.  

 

The legacy status is important and is not a mistake because, as a community, we 
believe it is important to maintain the uniqueness of the assignments made 
before the creation of the RIRs. However, at least in my opinion, it is a 
mistake to believe that the legacy status applies to IP addresses independent 
of who holds the assignment.

 

Thank you.
-- 

===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
=== 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

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

Regards,
Jordi
@jordipalet
 
 

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

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

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

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

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

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

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



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

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

Re: [address-policy-wg] fairness and legacy resources

[JORDI PALET MARTINEZ via address-policy-wg]

El 21/10/20 12:16, "address-policy-wg en nombre de Jim Reid" 
 escribió:


> On 21 Oct 2020, at 10:07, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> It is not fair that legacy holders are not bind to policies and services 
(and their cost) from the RIRs the same way as non-legacy.

Maybe, maybe not. There are plenty of other far more expensive cost centres 
in the NCC’s budget that are not fairly shared across the membership and 
nobody’s whining about them. Just look at all those cheapskates who get DNS and 
whois lookups from the NCC for free. Many of them aren’t even from the RIPE 
community. They should be paying. :-)

[Jordi] Not saying not to that. It is a community/membership decision to keep 
offering those services, and do it for free or find a way to only offer for 
free to members and a subscription fee for others, etc.

> We "rewind history" in real life all the time. There are laws (and 
customs) that as time passes, we discover that were wrong or broken or need to 
be adapted to new times

That’s not rewriting history Jordi. You should know better.

Whenever customs and laws change, the new measures do not apply to whatever 
had happened in the past. They apply to the present and future. For instance, 
suppose a government changes increases income tax. They don’t make you pay the 
increased rate for all the preceding years before the rate went up.

[Jordi] No, is not always like that. If there is a new tax for something, of 
course typically you will not pay for the past years, but you will pay for the 
new years since the tax is established. If you don't want to pay that tax, then 
you can release the "resource" that is covered by that tax. In Spain there are 
many examples of that, and I'm sure this is true for many other countries 
worldwide.

> Transfers are a way to correct that, as it has been said (and done in 
other regions). And every day it has less sense to keep the resources legacy: 
you need other resources from the RIR (like IPv6, other ASN, etc.), so then you 
sign the service agreement.

I’ve already explained why that’s utterly wrong.

If you think legacy holders should pay something, I maybe agree with that 
in principle. [But definitely not signing a service agreement which forces a 
legacy holder to become an LIR.] And maybe that’s a discussion that could be 
had once there was some hard data.

My gut feel is the cost to the NCC of looking after legacy space is 
negligible and not worth worrying about. It’ll barely be a rounding error in 
the Registry Services budget. Setting up and running a system to recover that 
insignificant amount of money from legacy holders will cost far more: 
contracts, invoicing, staff time, etc. Assuming there was a legal basis for 
imposing those charges. Which there almost certainly isn’t.

[Jordi] The point is that, as I said, RIPE region is somehow "special" on that, 
so even if here could be negligible, it not in other regions.

OTOH devising such a system will provide endless opportunities for the 
shed-painting and rat-holing that some members of our community *love*. Who 
cares about the underlying issue? Just think of all the months we can waste 
bickering over the policy and process minutiae.

In any case, the RIPE community and the NCC membership simply shouldn’t 
attempt this sort of micro-management. That’s the path to madness: “I want X 
EUR off my fee because I didn’t use any of the training courses last year. Or 
RIPEstat. Or take part in a hackathon. Or update my database entries. Or”.

[Jordi] No discussion on this point, fully agree!

It may well be reasonable to say something’s not fair. For some definition 
of fair. But it can sometimes be even more unreasonable to attempt to correct 
that -- extra costs, more complexity, higher administrative overheads, -- etc 
it simply isn’t worth the effort. Or addressing that unfairness creates other 
unfairnesses elsewhere. Sometimes pragmatic decisions have to be made because 
these are the least-worst solutions for the perceived level of unfairness.

[Jordi] Agree as well ... however, sometimes is not a matter of how much is the 
cost, but about is or looks as simply unfair. And yes, resolving an unfairness 
here may create an unbalance in the other side, but this is real life, nothing 
different.

> RIPE region is a bit special on that, in the sense that we have a single 
fee for everything, but in other regions is not the same way, and it is somehow 
proportional to the "amount" of resources you hold. I also think that's unfair. 
Of course, that's a different discussion ... 

Indeed. And a discussion to be had somewhere else, perhaps at the NCC’s 
AGM. The NCC used to have a byzantine charging scheme for setting membership 
fees based (roughly) on the member’s allocation of NCC-issued resources. 
Broadly speaking, the biggest LIR

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

[JORDI PALET MARTINEZ via address-policy-wg]

I agree with Shane here.

We shall correct mistakes ASAP. Legacy was a mistake, just because we didn't 
have the RIR system before, nothing else. It was not a conscious decision, 
nobody understood at that time that Internet as a "global" thing will need 
those resources and will become scarce.

It is not fair that legacy holders are not bind to policies and services (and 
their cost) from the RIRs the same way as non-legacy.

We "rewind history" in real life all the time. There are laws (and customs) 
that as time passes, we discover that were wrong or broken or need to be 
adapted to new times, and we change them, sometimes we need to compensate for 
the law change, or give some "timeout" before making the new law in-force, but 
we do it. Yes, somebody can say it is not fair, but it is also not fair the 
other way around (it is even more unfair).

Transfers are a way to correct that, as it has been said (and done in other 
regions). And every day it has less sense to keep the resources legacy: you 
need other resources from the RIR (like IPv6, other ASN, etc.), so then you 
sign the service agreement.

RIPE region is a bit special on that, in the sense that we have a single fee 
for everything, but in other regions is not the same way, and it is somehow 
proportional to the "amount" of resources you hold. I also think that's unfair. 
Of course, that's a different discussion ... Could you imagine a country that 
charges the same "single flat-rate tax" to every "family" or "citizen" 
regardless of having different income?

Regards,
Jordi
@jordipalet
 
 

El 21/10/20 10:33, "address-policy-wg en nombre de Jim Reid" 
 escribió:



> On 21 Oct 2020, at 08:17, Shane Kerr  wrote:
> 
> If there is a rationale for any of the RIPE policies, then that rationale 
should apply uniformly.

ONLY to the resources that were issued under those policies.

Frankly, it’s about time to stop obsessing about policies (for IPv4?? 
sheesh!!) and pay attention to outcomes.

> I thought it was a mistake to treat legacy space differently when I first 
I learned about it 22 years ago, and I still think that it is a mistake.

Fair enough Shane. [Though I don’t agree legacy space is/was a mistake.] 
However nobody can rewind history. So until someone invents time travel, we 
just have to live with what you think was a mistake.





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Erik,

 

Regarding your response on reciprocity: If we do that in AFRINIC, then, there 
is no reciprocity with ARIN, which is the bigger “donor”.

 

I already tried several models, for both LACNIC and AFRINIC, and they didn’t 
work out. Finally, making a full reciprocal proposal in LACNIC worked and it 
was implemented already since last July.

 

I also included a “security belt” in the AFRINIC proposal so the board can 
“control” if anything is going wrong by six consecutive months, to stop the 
policy … the community was happy initially with that, but later on, there were 
to other competitive proposals that make the people unhappy again …

 

Point 5.7.4.3 is broken, the idea was “incoming transferred legacy resources 
will no longer be regarded as legacy”, because that’s what we have now already 
for intra-RIR (and this policy motifies that to become intra and inter).

 

Regards,

Jordi

@jordipalet

 

 

 

El 19/10/20 15:52, "address-policy-wg en nombre de Erik Bais" 
 
escribió:

 

Hi Petrit & Taiwo,

 

Petrit, 

 

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

 

To Taiwo, 

 

 

Personally I would argue if reciprocity should be desired for the Afrinic 
region, as long as AFRINIC still holds IP numbers to be handed out. 

I personally would prefer the AFRINIC inter-rir transfer policy to be incoming 
from other RIR’s only, to avoid the AFRINIC space to be removed from the 
region.  ( As I think Afrinic would need them more to develop its own inter 
regional growth. ) 

Am I correct to assume that Afrinic at the current distribution rate would have 
about 30 months of IP space left ?  So perhaps opening the bi-directional 
inter-rir transfers, could start once the AFRINIC region actually has no space 
left in its free pool. 

 

 

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

 

On the point : 

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

 

The AFRINIC legal team might have to look if this is phrased correctly, as you 
can’t (shouldn’t be able ) to move Afrinic Allocated space to a Legacy space 
holder.. Afrinic allocated space should only be able to move to any of the 
other RIR members. Not directly to a Legacy holder.  

Legacy space registered in the Afrinic region could go to any organisation, 
regardless if they are a RIR member. There might be other contractual 
requirements required in the receiving RIR.. as the RIPE legacy policy would 
explain for the RIPE region.  

 

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

 

And on point : 

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

 

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

 

Regards,

Erik Bais

 

Co-chair of AP-WG 

 

https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer 
policy ( including intra and inter-rir transfers ) 

https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services 
to Legacy Internet Resource Holders  ( aka the RIPE Legacy services policy ) 

https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders
  ( Services provided based on the type of contractual agreement with the RIPE 
NCC ) 

 

 

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

 

Hello,

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

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

Please find below the proposal for your reference. 

[

 

Resource Transfer Policy

Authors: Anthony Ubah & Taiwo Oyewande

Submission date: 21/09/2020

Version: 2.0

Amends: CPM 5.7

 

1. Summary of the problem being addressed by this proposal

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

[address-policy-wg] policy compliance dashboard

[JORDI PALET MARTINEZ via address-policy-wg]

After my comment in the Addressing Policy meeting, I decided to go ahead with 
this email, maybe it can a provocation for some inputs in the open mic ...

Note that this text is from my AFRINIC proposal (to make it quick now), so 
disregard parts that may not correctly matches the RIPE NCC situation and may 
be some of the things are already done here.

Text:

*

"The Policy Compliance Dashboard” shows to each member its status of policy 
compliance, collected by means of a periodical review, automated as much as 
possible. The dashboard will show all possible details to match the policies 
and RSA, such as:

* Contractual obligations (such as status of payments or documents).
* Lack of response from the member.
* Unused or unannounced resources (where mandatory).
* Unavailable or outdated Whois information.
* Lack of maintenance of the reverse delegation.
* Forbidden sub-assignments (from PI assignments).
* Unauthorized transfers.
* Tracking of repeated and/or continued policy violations. 

The dashboard automation will need to be accommodated along policies evolves 
thru the PDP, in order to display new details.

The dashboard will automatically send notifications of the status of compliance 
to members, after each review or dashboard update. 

Reminders will be periodically sent in case of any lack of compliance. In this 
case, warnings will be also sent to the staff.

*

I've also the feeling that it may be more appropriate for Services WG, so 
copied as well.

Any thoughts?

Regards,
Jordi
@jordipalet
 
 



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

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

Re: [address-policy-wg] RIPE 79 Address Policy WG Draft Minutes

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Petrit, all,

I just read them and look fine to me.

Thanks!

Regards,
Jordi
@jordipalet
 
 

El 12/5/20 15:12, "address-policy-wg en nombre de Petrit Hasani" 
 escribió:

Dear colleagues,

The draft minutes from the Address Policy Working Group sessions at RIPE 79 
have now been published:


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


Please let us know of any corrections or amendments.

Kind regards,
--
Petrit Hasani
Policy Officer
RIPE NCC








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

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

Re: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Petrit,

My reading of the sentence is a bit different. Of course, I may be wrong ...

It comes from the original IPv6 policy that was developed jointly by folks from 
APNIC, ARIN and RIPE NCC.

It was there just so each RIR make their own changes (in other RIRs, this was 
removed) and we forgot about it ... just copy and paste.

If anything, change in any RIR that affects this definitions section, we will 
need to use the PDP to amend it in our own policy. So, this sentence doesn't 
fix that at all, and consequently I don't think the analysis impact should be 
different.

However, as said, I'm fine keeping it, just wondering if we all agree without 
the need to restart the process (which I believe, unless chairs think 
otherwise, is not good at this stage).

Regards,
Jordi
@jordipalet
 
 

El 14/1/20 12:25, "address-policy-wg en nombre de Petrit Hasani" 
 escribió:

Hello Jordi,

The sentence below makes it easier to do changes to the definitions 
sections in this document in case there are changes in other RIRs. (Example: If 
the NIR system is removed in APNIC, we would update the hierarchical structure):

“[Note: some of these definitions will be replaced by definitions from 
other RIR documents in order to be more consistent.]”

Considering that removing the sentence creates an impact, it would have to 
be mentioned in the impact analysis which would mean that we need to start the 
review phase again.

Kind regards,
--
Petrit Hasani
Policy Officer
RIPE NCC





> On 13 Jan 2020, at 22:18, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> Hi Abdullah,
> 
> I don’t think that will be good. In fact, in many cases, we have a hard 
time to understand the text of the rest of the policy text if we don’t rely in 
a very good set of definitions.
> 
> However, I just noticed something that could be removed:
> 
> “[Note: some of these definitions will be replaced by definitions from 
other RIR documents in order to be more consistent.]”
> 
> 
> But at this stage of the proposal, I’m not sure how feasible is it, 
without restarting everything … (and in that case, if we need to restart 
everything, it’s probably better to keep it for any future proposal that needs 
to change anything else).
> 
> Or it can be considered an editorial change? What the chairs believe, and 
also Marco/Petrit?
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
> 
> 
> 
> El 13/1/20 18:08, "address-policy-wg en nombre de Abdullah Cemil AKÇAM" 
 escribió:
> 
> Dear
> I liked the simplified version of this document. Just a small feedback: 
section titled "Definitions" can be shortened further by eliminating well known 
jargon.
> Best
> From: address-policy-wg  on behalf of 
Marco Schmidt 
> Sent: Wednesday, January 8, 2020 2:20:53 PM
> To: address-policy-wg@ripe.net 
> Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple 
Editorial Changes in IPv6 Policy)
> 
> Dear colleagues,
> 
> Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is
> now in the extended Review Phase.
> 
> This proposal aims to remove obsoleted text and simplify the IPv6 policy.
> 
> You can find the full proposal and the RIPE NCC impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2019-06
> 
> And the draft documents at:
> https://www.ripe.net/participate/policies/proposals/2019-06/draft
> 
> As per the RIPE Policy Development Process (PDP), the purpose of this
> four week extended Review Phase is to continue discussing the proposal,
> taking the impact analysis into consideration, and to review the full
> draft RIPE Policy Document.
> 
> At the end of the Review Phase, the Working Group (WG) Chairs will
> determine whether the WG has reached rough consensus. It is therefore
> important to provide your opinion, even if it is simply a restatement of
> your input from the previous phase.
> 
> We encourage you to read the proposal, impact analysis and draft
> document and send any comments to  before 6
> February 2020.
> 
> Kind regards,
> 
> Marco Schmidt
> Registration Services and Policy Development Assistant Manager
> RIPE NCC
> 
> 
> 
> 
> 
> Abdullah Cemil AKÇAM
> Bilişim Uzmanı
> Bilgi Teknolojileri Dairesi Başkanlığı
> 
> Tel: +90 312 586 52 82
> Adres: Eskişehir Yolu 10.Km No: 276 Posta Kodu: 06530 Çankaya/Ankara
> 
> www.btk.gov.tr
> _ 

Re: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Abdullah,

 

I don’t think that will be good. In fact, in many cases, we have a hard time to 
understand the text of the rest of the policy text if we don’t rely in a very 
good set of definitions.

 

However, I just noticed something that could be removed:

 

“[Note: some of these definitions will be replaced by definitions from other 
RIR documents in order to be more consistent.]”

 

 

But at this stage of the proposal, I’m not sure how feasible is it, without 
restarting everything … (and in that case, if we need to restart everything, 
it’s probably better to keep it for any future proposal that needs to change 
anything else).

 

Or it can be considered an editorial change? What the chairs believe, and also 
Marco/Petrit?

 

Regards,

Jordi

@jordipalet

 

 

 

El 13/1/20 18:08, "address-policy-wg en nombre de Abdullah Cemil AKÇAM" 
 escribió:

 

Dear

I liked the simplified version of this document. Just a small feedback: section 
titled "Definitions" can be shortened further by eliminating well known jargon.

Best

From: address-policy-wg  on behalf of Marco 
Schmidt 
Sent: Wednesday, January 8, 2020 2:20:53 PM
To: address-policy-wg@ripe.net 
Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial 
Changes in IPv6 Policy) 

 

Dear colleagues,

Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is 
now in the extended Review Phase.

This proposal aims to remove obsoleted text and simplify the IPv6 policy.

You can find the full proposal and the RIPE NCC impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-06

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

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

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

We encourage you to read the proposal, impact analysis and draft 
document and send any comments to  before 6 
February 2020.

Kind regards,

Marco Schmidt
Registration Services and Policy Development Assistant Manager
RIPE NCC

 

Abdullah Cemil AKÇAM 
Bilişim Uzmanı 
Bilgi Teknolojileri Dairesi Başkanlığı

Tel: +90 312 586 52 82 
Adres: Eskişehir Yolu 10.Km No: 276 Posta Kodu: 06530 Çankaya/Ankara

www.btk.gov.tr
_ _ _ __ _ _ _


YASAL UYARI:
Bu e-postada yer alan bilgiler, beraberinde iletilen tüm bilgi, onay ve her 
türlü formattaki dosyalar, gizlidir ve kişiye özel olabilir ve sadece 
gönderildiği kişi ya da kuruma ya da bu bilgileri kullanmaya ya da almaya 
yetkili diğer kişilere özeldir. Eğer siz doğru kişi değilseniz, bu e-postayı 
açıklamak, kopyalamak, dağıtmak ya da içeriğine istinaden işlem yapmak tümüyle 
yasaktır ve kanuna aykırı olabilir. Bu nedenle bu e-postayı yanlışlıkla 
aldıysanız, bu durumu derhal gönderene haber veriniz ve e-postayı siliniz. Bu 
e-postanın tarafınıza yanlışlıkla iletilmiş olması yüzünden e-postanın gizli ve 
kişiye özel niteliği kaybolmaz ya da bu niteliğinden vazgeçilmez. BTK, bu 
e-postada yer alan bilgilerin ya da e-postanın kendisinin usulüne göre ve/veya 
tam iletiminden ya da e-postanın alınmasında yaşanan herhangi bir gecikmeden 
sorumlu değildir. BTK bu e-postanın içeriği ile ilgili olarak hiç bir hukuksal 
sorumluluğu kabul etmez. BTK, virüs filtreleme uygulamakla birlikte, e-postanın 
virüs içermediğini garanti ya da temin etmez. 

DISCLAIMER:
The information, consent and file attached thereto, contained in this e-mail is 
confidential and may be legally privileged, and is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
use it or receive it. If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or taking action in 
reliance of the contents of this e-mail is strictly prohibited and may be 
unlawful. If therefore you have received this e-mail in error, please notify 
the sender immediately and then delete it. Confidentiality and legal privileges 
are not waived or lost even if you have been accidentally transmitted by this 
e-mail. ICTA is not responsible for the proper and/or complete transmission of 
the information contained in this e-mail or of the e-mail itself nor in any 
delay in its receipt. ICTA does not accept any form of legal responsibility for 
the content of this e-mail. Whilst ICTA does apply virus filtering, it provides 
no guarantee or warranty that the e-mail is virus-free. 






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

This electronic message contains 

Re: [address-policy-wg] cultural idioms in RIPE discussions

[JORDI PALET MARTINEZ via address-policy-wg]

Diversity?


(in copy)
 

El 1/11/19 13:50, "address-policy-wg en nombre de Brian Nisbet" 
 
escribió:

I'm sure it will shock absolutely nobody if I say that I think this 
conversation is very important.

Maybe AP-WG isn't the best place, but I'm not sure where is?

I think it is useful to all of us to realise that our cultural references 
are not everyone else's, because of language or country or age or one of many 
other things. We can no longer just assume a shared set of references and we 
should look to inform (and hopefully share the awesomeness that is Monthy 
Python, for instance) and expand. I mean, how long will it be before WG Chairs 
start to talk about yeeting proposals into or out of WGs? 

I'm not, for one second, suggesting people shouldn't use references, I use 
them all the time, but I am saying that those who use them should be 
understanding when others don't get them.

Thanks,

Brian

Brian Nisbet 
Service Operations Manager
HEAnet CLG, Ireland's National Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland
+35316609040 brian.nis...@heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270

> -Original Message-
> From: address-policy-wg  On Behalf
> Of JORDI PALET MARTINEZ via address-policy-wg
> Sent: Friday 1 November 2019 12:38
> To: Jim Reid 
> Cc: RIPE Address Policy WG List 
> Subject: Re: [address-policy-wg] cultural idioms in RIPE discussions
> 
> Hi Jim,
> 
> Despite how many years I've been participating, I still have (sometimes)
> difficulties, and often talking with other non-native English speakers 
they tell
> me the same. We know that not everybody is happy to express that in a 
list.
> 
> I'm not convinced "common-sense" is such simple thing! Otherwise, either
> I'm really stupid, or I should have cached the reference in a more 
humoristic
> way.
> 
> I don't think we can compare our technical jargon with such kind of
> references, especially because not everybody (as it is my case) follows
> "Monty Python, Star Wars, Star Trek, H2G2, etc.". Precisely because I 
often
> heard those references, I decided today, to ask for a clarification! I've 
missed
> a lot of fun, I guess!
> 
> I didn't respond to the first email because, sometimes, when a thread is
> moving fast in the list, you just respond to the last email that you 
read. Not
> sure if that's a broken way, but I do sometimes.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 1/11/19 13:27, "address-policy-wg en nombre de Jim Reid"  policy-wg-boun...@ripe.net en nombre de j...@rfc1035.com> escribió:
> 
> 
> 
> > On 1 Nov 2019, at 11:14, JORDI PALET MARTINEZ via address-policy-wg
>  wrote:
> >
> > My point was also a general observation (not something against any
> specific participant, just taking advantage of this specific example, as a
> mention to "Spanish inquisition" and "routing police" could be 
interpreted in
> between lines as something different, even if not intended).
> 
> Jordi, your comment is a reasonable one. But it misses the point. In 
this
> case, your common sense should have told you the earlier remark wasn't a
> literal reference to the Spanish Inquisition.
> 
> The RIPE/tech community habitually uses references to a variety of 
idioms
> from popular culture in films, TV, books and songs. Using catchphrases 
from
> Monty Python, Star Wars, Star Trek, H2G2, etc. are very common. That's
> gone on for decades. These phrases might well confuse non-native English
> speakers at first. Or (say) an English speaker who haven't seen Star Wars.
> However people soon pick up these references, just like we all learn the
> industry jargon -- route flapping, prefix filtering, trust anchors, ROA, 
PI
> address space, etc -- that probably doesn't translate well into other
> languages. That sort of understanding becomes almost automatic for those
> who have been active in these communities for a while.
> 
> To be honest Jordi, I'm surprised you said you were confused. Since 
you've
> been coming to RIPE/IETF/ICANN meetings for longer than I can remember,
> this couldn't possibly have been the first time you've come across a Monty
> Python reference.
> 
> And if you were confused, you could have said so at the time and asked
> the original poster to explain. I think that's a far better way to hand

Re: [address-policy-wg] cultural idioms in RIPE discussions

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Jim,

Despite how many years I've been participating, I still have (sometimes) 
difficulties, and often talking with other non-native English speakers they 
tell me the same. We know that not everybody is happy to express that in a list.

I'm not convinced "common-sense" is such simple thing! Otherwise, either I'm 
really stupid, or I should have cached the reference in a more humoristic way.

I don't think we can compare our technical jargon with such kind of references, 
especially because not everybody (as it is my case) follows "Monty Python, Star 
Wars, Star Trek, H2G2, etc.". Precisely because I often heard those references, 
I decided today, to ask for a clarification! I've missed a lot of fun, I guess!

I didn't respond to the first email because, sometimes, when a thread is moving 
fast in the list, you just respond to the last email that you read. Not sure if 
that's a broken way, but I do sometimes.

Regards,
Jordi
@jordipalet
 
 

El 1/11/19 13:27, "address-policy-wg en nombre de Jim Reid" 
 escribió:



    > On 1 Nov 2019, at 11:14, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> My point was also a general observation (not something against any 
specific participant, just taking advantage of this specific example, as a 
mention to "Spanish inquisition" and "routing police" could be interpreted in 
between lines as something different, even if not intended).

Jordi, your comment is a reasonable one. But it misses the point. In this 
case, your common sense should have told you the earlier remark wasn't a 
literal reference to the Spanish Inquisition.

The RIPE/tech community habitually uses references to a variety of idioms 
from popular culture in films, TV, books and songs. Using catchphrases from 
Monty Python, Star Wars, Star Trek, H2G2, etc. are very common. That's gone on 
for decades. These phrases might well confuse non-native English speakers at 
first. Or (say) an English speaker who haven't seen Star Wars. However people 
soon pick up these references, just like we all learn the industry jargon -- 
route flapping, prefix filtering, trust anchors, ROA, PI address space, etc -- 
that probably doesn't translate well into other languages. That sort of 
understanding becomes almost automatic for those who have been active in these 
communities for a while.

To be honest Jordi, I'm surprised you said you were confused. Since you've 
been coming to RIPE/IETF/ICANN meetings for longer than I can remember, this 
couldn't possibly have been the first time you've come across a Monty Python 
reference.

And if you were confused, you could have said so at the time and asked the 
original poster to explain. I think that's a far better way to handle things. 
It's certainly far more productive than starting this meta-discussion or 
telling others how they should express themselves.








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

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

Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Nick,

My point was also a general observation (not something against any specific 
participant, just taking advantage of this specific example, as a mention to 
"Spanish inquisition" and "routing police" could be interpreted in between 
lines as something different, even if not intended).

There are many non-native English speakers in the RIR communities (at it 
happens in IETF, ICANN, etc.), however, often the native ones forget about that 
and keep using those jargons.

Doing so, you as asking the non-native speakers to spend 4-5 more times to read 
each message, to google around, looking at Wikipedia, youtube, etc.

Note that I fully understand that for those that are native-speakers, you are 
just using your natural language and expression, but being considerate to 
others may be much easier for you than for non-native to waste their time.

Should then we, non-native speakers, start using in the list our own languages 
and expressions that even using google translator, you will not catch? Are we 
discriminating part of the community otherwise?

Clearly, this doesn't belong to this thread/WG, but it doesn't help to the 
community to use those expressions. Some folks go away from the thread doing 
so, instead of facilitating participation, or if I can say, even inclusiveness.

Regards,
Jordi
@jordipalet
 
 

El 1/11/19 12:04, "Nick Hilliard"  escribió:

JORDI PALET MARTINEZ via address-policy-wg wrote on 01/11/2019 10:52:
> I guess I don't have sufficient time to see enough films of TV shows ...

https://www.youtube.com/watch?v=FAxkcPoLYcQ

It's a metaphor about how we start off with incremental additions that 
seem innocent, but they end up with an appalling outcome.

See also: "boiling the frog" and "creeping featuritis".

Nick






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

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

Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

[JORDI PALET MARTINEZ via address-policy-wg]

I guess I don't have sufficient time to see enough films of TV shows ...

Regards,
Jordi
@jordipalet
 
 

El 1/11/19 11:52, "address-policy-wg en nombre de Brian Nisbet" 
 
escribió:

Jordi,

Ah, the Spanish Inquisition reference is a Month Python reference.

https://en.wikipedia.org/wiki/The_Spanish_Inquisition_(Monty_Python)

Brian

Brian Nisbet 
Service Operations Manager
HEAnet CLG, Ireland's National Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland
+35316609040 brian.nis...@heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270

> -Original Message-
> From: JORDI PALET MARTINEZ 
> Sent: Friday 1 November 2019 10:44
> To: Brian Nisbet ; Randy Bush 
> Cc: address-policy-wg@ripe.net
> Subject: Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs 
for
> Unallocated and Unassigned RIPE NCC Address Space) to be discussed on
> Routing Working Group Mailing List
> 
> Mmmm ... often those conversations are really difficult to catch for non-
> native English speakers.
> 
> And just in case ... I was not there during the Inquisition, neither, of 
course,
> agree which all the barbarities done at that time.
> 
> Also don't agree that any RIR should be the police, is only about the
> community setting up our own rules and avoiding governments enforcing
> that for us.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 1/11/19 11:36, "address-policy-wg en nombre de Brian Nisbet"  policy-wg-boun...@ripe.net en nombre de brian.nis...@heanet.ie>
> escribió:
> 
> Randy,
> 
> > -Original Message-
> > From: Randy Bush 
> > Sent: Friday 1 November 2019 10:04
> > To: Brian Nisbet 
> > Cc: Petrit Hasani ; address-policy-wg@ripe.net
> > Subject: Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI 
ROAs
> for
> > Unallocated and Unassigned RIPE NCC Address Space) to be discussed 
on
> > Routing Working Group Mailing List
> >
> > brian,
> >
> > >> i support this proposal, but would oppose it in the anti-abuse 
wg.
> > > I have to ask, out of personal interest and with no hats on at 
all,
> > > why?
> >
> > i am only in mild support of it.  i am in strong unsupport of 
everything
> being
> > recast as an abuse and prosecuted as such.  We are not the net 
police
> and
> > should resist inclinations to be come such.
> 
> I would, perhaps unsurprisingly, argue that putting a proposal 
through AA-
> WG doesn't mean the community is trying to police things, rather the
> proposer feels that it is network abuse they are trying to stop, but that 
is
> perhaps a point better discussed over a beverage or perhaps a jam doughnut
> at RIPE 80.
> 
> Thank you for explaining, much appreciated.
> 
> > Nobody expects the Spanish Inquisition!
> 
> But we... er... I mean they have such comfy chairs!
> 
> Brian
> 
> Brian Nisbet
> Service Operations Manager
> HEAnet CLG, Ireland's National Education and Research Network
> 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland
> +35316609040 brian.nis...@heanet.ie www.heanet.ie
> Registered in Ireland, No. 275301. CRA No. 20036270
> 
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of 
the
> individual(s) named above and further non-explicilty authorized 
disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be 
considered a
> criminal offense. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this 
information,
> even if partially, including attached files, is strictly prohibited, will 
be
> considered a criminal offense, so you must reply to the original sender to
> inform about this communication and delete it.
> 
> 





*

Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

[JORDI PALET MARTINEZ via address-policy-wg]

Mmmm ... often those conversations are really difficult to catch for non-native 
English speakers.

And just in case ... I was not there during the Inquisition, neither, of 
course, agree which all the barbarities done at that time.

Also don't agree that any RIR should be the police, is only about the community 
setting up our own rules and avoiding governments enforcing that for us. 

Regards,
Jordi
@jordipalet
 
 

El 1/11/19 11:36, "address-policy-wg en nombre de Brian Nisbet" 
 
escribió:

Randy,

> -Original Message-
> From: Randy Bush 
> Sent: Friday 1 November 2019 10:04
> To: Brian Nisbet 
> Cc: Petrit Hasani ; address-policy-wg@ripe.net
> Subject: Re: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs 
for
> Unallocated and Unassigned RIPE NCC Address Space) to be discussed on
> Routing Working Group Mailing List
> 
> brian,
> 
> >> i support this proposal, but would oppose it in the anti-abuse wg.
> > I have to ask, out of personal interest and with no hats on at all,
> > why?
> 
> i am only in mild support of it.  i am in strong unsupport of everything 
being
> recast as an abuse and prosecuted as such.  We are not the net police and
> should resist inclinations to be come such.

I would, perhaps unsurprisingly, argue that putting a proposal through 
AA-WG doesn't mean the community is trying to police things, rather the 
proposer feels that it is network abuse they are trying to stop, but that is 
perhaps a point better discussed over a beverage or perhaps a jam doughnut at 
RIPE 80.

Thank you for explaining, much appreciated.
 
> Nobody expects the Spanish Inquisition!

But we... er... I mean they have such comfy chairs!

Brian

Brian Nisbet 
Service Operations Manager
HEAnet CLG, Ireland's National Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland
+35316609040 brian.nis...@heanet.ie www.heanet.ie
Registered in Ireland, No. 275301. CRA No. 20036270





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi David,

 

Responding below, in-line.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 10/10/19 7:01, "address-policy-wg en nombre de David Farmer" 
 escribió:

 

 

On Tue, Oct 8, 2019 at 9:01 AM Sander Steffann  wrote:

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

 

I support the update, but have a question that I hope leads to a possible 
further clarification;

 

In section 5.4.2 is an end site intended to be an end-user at a single physical 
location, or the entirety of an end-user organization, that may exist in many 
locations or on a large multi-building campus, and therefore might easily 
justify an assignment shorter than /48.  

 

My intent is to support both cases.

 

I agree it is difficult to imagine a single physical location needing more than 
a /48.  On the other hand, a large multi-site organization, say with hundreds 
of locations or hundreds of buildings on a single campus can easily need a 
prefix significantly shorter than /48. Further, it seems like a waste of 
resources to have RIPE or a NIR review shorter prefix assignments when made for 
multi-site organizations or large campuses. 

 

Exactly, the point is that LIR must be able to do that by themselves, and only 
have it reviewed in case they request a further allocation or there is an 
explicit audit.

 

Further, the definition of "End Site" doesn't really add much clarity to this 
question. 

 

2.9. End Site

 

An End Site is defined as an End User (subscriber) who has a business or legal 
relationship (same or associated entities) with a service provider that 
involves:

 

that service provider assigning address space to the End User

that service provider providing transit service for the End User to other sites

that service provider carrying the End User's traffic

that service provider advertising an aggregate prefix route that contains the 
End User's assignment

 

So, as currently written it seems a little ambiguous whether an end site is 
intended to refer to a single location or a single organization.

 

My Reading of “An End Site is defined as an End User (subscriber) who has a 
business or legal relationship”, is that it applies the same to a single 
end-site or an end-user having multiple end-sites.

 

If we believe that this is not correct, maybe we need to re-word that text as 
well?


Thanks.

 

-- 

===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
=== 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert,

I just sent an email with the clarification of the proposals in the other RIRs.

The point here is that what I consider a valid argument (fairness for as much 
overall community as possible and a bad thing otherwise, so a problem), you 
think is not. This is a valid disagreement, of course and this is just part of 
the process to improve our policies.
 
 

El 17/7/19 20:15, "Gert Doering"  escribió:

Hi,

On Wed, Jul 17, 2019 at 08:01:44PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> We, as a community, should look for the benefit of the community.

You still fail to bring forward a clear reasoning this would be so.

If you argue "the buyer wants this!" it's not an argument why this
would be "beneficial for the community" - but more an argument for
why no change is needed.

> I've already said this, but let me to repeat it: This is my opinion, and 
it looks was the opinion of the other 4 RIR communities.

From what I've heard so far, this was not an explicit change but more
a "it happened somewhere along the historic evolution of things".  So,
"the opinion of the other 4 RIR communities" might be exaggerating a
slight bit

> You opinion can be diverse, of course, but it is clear that I'm not alone.

I fail to see much support for your well-formulated problem statement.

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Michiel,

I think the email from Mike (yesterday) responded to this together with my 
previous links to each RIR. Anyway, I've contacted to all the RIR policy 
officers, and even if not all them have responded yet with new information, 
this is a summary of the situation.

1) In ARIN, they ask for signing the RSA. This is the literal response I got 
from them:

ARIN Policy 2009-1 does indeed require specified transfer resources to 
“receive” the resources under RSA. This policy was implemented in June 2009 and 
that version of the NRPM may be viewed at 
https://www.arin.net/vault/policy/archive/nrpm_20090601.pdf.

Subsequent policy changes impacted NRPM section 8.3, and went on to add 8.4 and 
8.5, clarifying that the requirement applies to both intra- and inter-RIR 
transfers with ARIN recipients.

The Inter-RIR language specifically came about via ARIN Policy 2012-1 
(https://www.arin.net/vault/policy/proposals/2012_1.html), which was 
implemented in July 2012 
(https://www.arin.net/vault/policy/archive/nrpm_20120731.pdf).

Since that time, other changes have occurred within Section 8, but none to my 
knowledge have impacted the requirement that recipients must “receive” the 
resources under RSA.

2) AFRINIC. There was a wrong link in their web page when I looked at this and 
provided the link here. After I checked that and observed the mismatch, they 
corrected it. So the correct link to the proposal is:
https://www.afrinic.net/policy/archive/ipv4-resources-transfer-within-the-afrinic-region-v3

3) LACNIC and APNIC, as explained in previous email.

Even if I've asked them for explicit arguments when the discussion of each 
proposal was carried out I didn't get those responses, so again I think Mike 
email has the clearest view. Alternatively, there will be a chance if we 
investigate the mail archive discussion for each policy proposal in each RIR.

Regards,
Jordi
@jordipalet
 
 

El 16/7/19 11:05, "Michiel Klaver"  escribió:

Hi Jordi,

Maybe you can provide any documentation available from the other RIRs 
about their rationale why they implemented this kind of policy? Maybe 
they have some strong arguments we are missing here?


Gert Doering wrote at 2019-07-16 10:46:
> Hi,
> 
> On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via
> address-policy-wg wrote:
>> Again, please consider, if it is good that we are the only RIR not 
>> doing so. I don't think that's good.
> 
> If this is the main argument ("I changed this in all the other RIRs,
> and now *you* are the only ones stubbornly refusing to follow my
> all-the-others-are-doing-this argument") - it's a somewhat weak one.
> 
> You have failed to bring forward any reason for changing things, except
> 
>  "it is unfair that there is a difference"
> 
> (without detailing what exactly the unfairness would be, who would
> be disadvantaged by this, exactly, and why they would be affected
> positively by this proposal) - and
> 
>  "all the other RIRs have changed this!"
> 
> which is both not very compelling.
> 
> 
> I could also not see anyone speak up in a supportive way, so I'd 
> consider
> this "sufficiently discussed, and no support to go for a formal 
> proposal".
> 
> Gert Doering
> -- APWG chair




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

We, as a community, should look for the benefit of the community.

With that in mind, in that case we should have that to be the *only choice*.

Alternatively the buyer can still do the process outside the policy process, 
because he is opting to not convert the resources to non-legacy.

I've already said this, but let me to repeat it: This is my opinion, and it 
looks was the opinion of the other 4 RIR communities.

You opinion can be diverse, of course, but it is clear that I'm not alone.
 

El 17/7/19 19:54, "Gert Doering"  escribió:

Hi,

On Wed, Jul 17, 2019 at 06:48:46PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> -> I don't think this is "delicate" at all. Nobody is being *forced* to 
do that. If you have legacy, you can do transfers outside the system and nobody 
can oppose to that. However, please read the complete email from Mike 
(yesterday), I don't think nobody noticed it ... and they key think here is the 
protection of the "buyer", which is secured if the addresses are converted to 
non-legacy.

If the buyer sees a benefit in coverting legacy space to non-legacy,
they can do this today.

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi,

El 17/7/19 18:08, "address-policy-wg en nombre de Radu-Adrian FEURDEAN" 
 escribió:

On Mon, Jul 15, 2019, at 14:02, Tore Anderson wrote:
> In any case, and to be perfectly honest, this rationale reads to like 
> petty jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I 
> don't want others to be able to do X either».

Hi,

I see the situation a little differently:
 - if my understanding is correct, you can benefit from pretty much same 
(or most of) services with you legacy space as with your PI/PA space, however 
you don't really have the same obligations. Correct me if/where I'm wrong.
 - do you consider something normal that somebody "owns" numbers, just 
because somebody, someday told them "those are yours" ? I don't. For the moment 
I have to live with the fact that in many cases (not all) this is what is 
happening, but I would pretty much appreciate a change.

However, pushing for a conversion from legacy to "RIR system" looks very 
delicate. Not sure that legally it can be forced (probably in some countries 
the regulator may be able to do something, but I wouldn't count on that). As 
for "do it for you own good", while this may not work today, some day everybody 
would better get into the RPKI bandwagon, at which point the RIRs would be in a 
strong position to "kindly" ask holders to convert the legacy resources to "RIR 
system". If the will id there, which is an entirely different issue.

-> I don't think this is "delicate" at all. Nobody is being *forced* to do 
that. If you have legacy, you can do transfers outside the system and nobody 
can oppose to that. However, please read the complete email from Mike 
(yesterday), I don't think nobody noticed it ... and they key think here is the 
protection of the "buyer", which is secured if the addresses are converted to 
non-legacy.


-- 
Radu-Adrian FEURDEAN





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Carlos,

Not sure if the specific proposals bring value, I think we need to understand 
"the whys", anyway, I found:

LACNIC:
https://www.lacnic.net/innovaportal/file/556/1/lac-2009-04v3-propuesta-sp.pdf 
(sorry Spanish)

ARIN:
https://www.arin.net/vault/policy/proposals/2009_1.html

However, it doesn't mention legacy, so it should have modified afterwards, and 
I was unable to find it.

AFRINIC:
https://www.afrinic.net/policy/archive/ipv4-resources-transfer-within-the-afrinic-region-2

Same problem as in ARIN, it has been modified afterwards, but can't find it.

APNIC:
http://archive.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-prop-wilson-historical-transfer.doc
https://www.apnic.net/community/policy/proposals/prop-006/
https://www.apnic.net/community/policy/proposals/prop-050/


I'm going to check with the policy officers of each RIR.

Regards,
Jordi
@jordipalet
 
 

El 16/7/19 11:39, "address-policy-wg en nombre de Carlos Friaças via 
address-policy-wg"  escribió:



Hi Jordi, All,


I was doing some googling and easily found the references on 
ARIN/LACNIC/AFRINIC websites...


https://www.lacnic.net/1022/2/lacnic/legacy-resources

"Transferred legacy resources will no longer be considered as such"


https://www.arin.net/resources/guide/legacy/services/

"When legacy number resources are transferred to another organization
through a specified transfer (NRPM 8.3 and 8.4), the recipient organization
is required to sign an RSA/LRSA, and the resources being transferred will
not retain their legacy status."


https://afrinic.net/resources/transfers

"Applicable to Transfer Recipient Transferred IPv4 legacy resources will 
no longer be regarded as legacy resources."




However, regarding APNIC, from what i read on


https://www.apnic.net/community/policy/resources#8.3.-Transfer-of-Historical-Internet-resources

it is not 100% clear to me that the transferred blocks lose their 
legacy/historical status.


Can you list which policy proposals within each RIR that resulted in the 
above...?
...so we may have some clue about the timeline of such changes -- which 
may have been passed under the legacy holders radar...

Additionally, maybe someone involved with transfers on a daily basis can 
comment if a block with legacy status has less/equal/more value than 
non-legacy blocks???


Cheers,
Carlos





On Tue, 16 Jul 2019, Michiel Klaver via address-policy-wg wrote:

> Hi Jordi,
>
> Maybe you can provide any documentation available from the other RIRs 
about 
> their rationale why they implemented this kind of policy? Maybe they have 
> some strong arguments we are missing here?
>
>
> Gert Doering wrote at 2019-07-16 10:46:
>> Hi,
>> 
>> On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via
>> address-policy-wg wrote:
>>> Again, please consider, if it is good that we are the only RIR not 
doing 
>>> so. I don't think that's good.
>> 
>> If this is the main argument ("I changed this in all the other RIRs,
>> and now *you* are the only ones stubbornly refusing to follow my
>> all-the-others-are-doing-this argument") - it's a somewhat weak one.
>> 
>> You have failed to bring forward any reason for changing things, except
>>
>>  "it is unfair that there is a difference"
>> 
>> (without detailing what exactly the unfairness would be, who would
>> be disadvantaged by this, exactly, and why they would be affected
>> positively by this proposal) - and
>>
>>  "all the other RIRs have changed this!"
>> 
>> which is both not very compelling.
>> 
>> 
>> I could also not see anyone speak up in a supportive way, so I'd consider
>> this "sufficiently discussed, and no support to go for a formal 
proposal".
>> 
>> Gert Doering
>> -- APWG chair
>





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

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If yo

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert,

Just to be clear: I didn't change this in any RIR.

I've proposed Inter-RIR transfers in LACNIC and AFRINIC, following their 
existing intra-RIR policies, which already had this legacy to non-legacy with 
the transfer, so I just kept it.

I still think it is unfair to have a legacy status, and for me this is a good 
reason. As Jim said, it is about diversity, in this case of opinions.

I'm going to investigate the reasons to have this in the other RIRs and come 
back to the list.

Regards,
Jordi
@jordipalet


El 16/7/19 10:46, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> Again, please consider, if it is good that we are the only RIR not doing 
so. I don't think that's good.

If this is the main argument ("I changed this in all the other RIRs, 
and now *you* are the only ones stubbornly refusing to follow my 
all-the-others-are-doing-this argument") - it's a somewhat weak one.

You have failed to bring forward any reason for changing things, except

 "it is unfair that there is a difference"

(without detailing what exactly the unfairness would be, who would
be disadvantaged by this, exactly, and why they would be affected 
positively by this proposal) - and

 "all the other RIRs have changed this!"

which is both not very compelling.


I could also not see anyone speak up in a supportive way, so I'd consider
this "sufficiently discussed, and no support to go for a formal proposal".

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

I didn't said anything about retroactivity:

- Holders of legacy that don't transfer them, aren't affected.
- Transfers already done (from legacy resources) aren't affected

The only affected ones are "new" transfers (if the policy reach consensus), and 
is only affecting the ones that get the resources, not the original holder.

Again, please consider, if it is good that we are the only RIR not doing so. I 
don't think that's good.

Regards,
Jordi
@jordipalet
 
 

El 15/7/19 14:17, "address-policy-wg en nombre de Havard Eidnes via 
address-policy-wg"  escribió:

>> It might be self-evident to you how this is problematic. It
>> is not to me.
>
> Because I think when there is an unfair situation (some folks
> bound to rules/policies, others not), there is a problem.

You cannot change history, and the fact that some assignments were
made under different rules and prior to the RIRs coming into
existence.  Retroactively and forecfully from the RIR side changing
the rules for these assignments, *that* would be unfair.

Regards,

- Håvard





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Tore,
 

El 15/7/19 14:02, "Tore Anderson"  escribió:

    * JORDI PALET MARTINEZ via address-policy-wg

> -> Because I think when there is an unfair situation (some folks bound to 
rules/policies, others not), there is a problem.
...
> -> Because is not subjected to the same rules (policies) as the 
non-legacy one. That's unfair.

Thank you for clarifying. I don't believe this «unfairness» rationale had 
been mentioned before.

Others have explained how the legacy resources were given out with no RIR 
policy strings attached. You could make the opposite argument too, i.e., that 
it would be unfair behaviour by the RIPE community to try and retroactively 
annex legacy space in this way by unilaterally applying terms and conditions 
that were never agreed to in the first place.

-> We agree here. It may be considered unfair in one direction or the other 
one. It depends on the perspective.

In any case, and to be perfectly honest, this rationale reads to like petty 
jealousy to me - «I can't do X with my RIPE ALLOCATED PA, so I don't want 
others to be able to do X either».

-> I don't have resources of any type (legacy neither non-legacy) in any RIR, 
so my view is trying to be as objective as possible and looking for the 
fairness of the more global community.

I don't believe this kind of policy making is good for the community. I 
suspect the opposite is true, by turning legacy holders off from engaging with 
us. Keep in mind that they are under no obligation to do so.

-> I guess it is not still clear enoght. This doesn't affect legacy holders. It 
is only affecting the resources once they got transferred.

A more positive way to approach this perceived unfairness would be to focus 
on what X is, and see if the RIPE policy can be changed to permit it.

Tore




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

The intention is that we bring into the community rules (policies) as many 
addresses as possible.

I think it is unfair to have some addresses bound to our policies (in whatever 
region), and others not.

I know we can't mandate for the legacy holders, but we can, if as a community, 
we decide that for the beneficiaries of legacy transfers, by amending our 
policy to state that those addresses lose the legacy status with that transfer.

Now is optional in RIPE, mandatory in all the other regions.

To be clear, when I mention the other regions status:
1) In LACNIC the proposal, which I authored as well, passed consensus a month 
ago (now in implementation stage). It is also based in the existing intra-RIR 
policy, where the legacy status is lost once they get transferred.
2) In AFRINIC, at the moment, there is an inter-RIR proposal, which I'm the 
author. It is based in the existing intra-RIR policy, where the legacy status 
is lost once they get transferred. So right now, intra-RIR already lost the 
legacy status.

Regards,
Jordi
@jordipalet
 
 

El 15/7/19 12:32, "address-policy-wg en nombre de Erik Bais" 
 
escribió:

Hi Jordi,  

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

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

Regards,
Erik Bais 


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

Hi Tore,

I think my previus email just explained it.

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

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

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

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

Regards,
Jordi
@jordipalet
 

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

* Gert Doering

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

+1

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

Maybe if you could explain by example, Jordi?

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

Tore





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Tore, 

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

    * JORDI PALET MARTINEZ via address-policy-wg

> I think my previus email just explained it.

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

I understand that you have that view. What I fail to understand is *why* 
you have that view.

It might be self-evident to you how this is problematic. It is not to me.

-> Because I think when there is an unfair situation (some folks bound to 
rules/policies, others not), there is a problem.

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

I'm a firm believer of the «if it ain't broke, don't fix it» approach, and 
I am yet to be convinced that the current policy is indeed «broke».

Do the parties directly impacted by this policy in question, i.e., the 
legacy resource holders themselves (or would-be recipients of legacy resource 
transfers), share your view that there is a problem here that needs fixing?

-> If you're a legacy holder, doesn't on you. If you're going to transfer, 
doesn't impact on you. The impact is only for the one that receive the transfer.

(It is unclear to me whether or not you represent such a directly impacted 
party yourself.)

-> To be clear, I don't have addresses to transfer, neither I'm looking for 
addresses to get transferred.

> What is clear to me is that, according to existing policies, I share this 
view with 4/5 of the RIR communities.
> 
> What is the effect of that? Simple, an unbalance of transfers among 
regions, because if someone for whatever reason want to get resources and keep 
them non-legacy, can just come to RIPE for that. This is good for RIPE? I don't 
think so, we could keep growing the non-legacy resources, while other regions 
get "cleaned".

How is it *bad* for the RIPE community, though?

You seem to imply that legacy space is «dirty» and in need of «cleaning» 
but offer no explanation why.

-> Because is not subjected to the same rules (policies) as the non-legacy one. 
That's unfair.

I understand that RPKI is not available for legacy resources in some other 
regions. Providing legacy holders with the option of moving their resources 
into the RIPE region might therefore be a net benefit for the Internet 
community at large (which obviously includes the RIPE community), as it might 
contribute to better routing security.

Tore





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Tore,

I think my previus email just explained it.

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

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

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

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

Regards,
Jordi
@jordipalet
 

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

* Gert Doering

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

+1

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

Maybe if you could explain by example, Jordi?

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

Tore





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Jim,
 

El 15/7/19 2:16, "Jim Reid"  escribió:



> On 14 Jul 2019, at 22:54, JORDI PALET MARTINEZ via address-policy-wg 
 wrote:
> 
> 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.

Embrace diversity!

I'm fine with diversity, or course!


"Because the other RIRs do it" isn't by itself a strong enough 
justification for the RIPE region to copy them.

My point here is that I disagree with not turning non-legacy into legacy. I 
think this is bad for the community. So as part of the diversity, my point of 
view is "divergent" with the actual policy, but is the same as the other 4 
RIRs. I'm sure in RIPE we have people in one side, the other side, and the 
middle one.

In this particular case, I am not convinced the proposal has any merit.

Forcing legacy space to be subject to RIR policy on transfer is just wrong. 
The holders got that space before the RIRs existed. Which means it's grossly 
unfair and unreasonable to retroactively make that space subject to RIR policy, 
even when that space gets transferred. If the legacy holder chooses to do that, 
fine. However they cannot and must not be compelled to do so.

Here is where we disagree. I'm looking for what is best of the overall 
community, not the best of the legacy owners. I'm very honest here. It was just 
wrong we got legacy allocations, but it was no other way as the RIRs didn't 
existed. I think we can try to correct as much as possible past mistakes. 
Nobody is forcing the existing holders to do the transfers, they can just keep 
their resources and avoid that. I think is fair that destination holders are 
in-the-systems mandatorily.

Such a policy may also be counter-productive since it (a) could discourage 
legacy holders from releasing unused space; (b) make such space unattractive to 
recipients because it would be subject to RIR policies, RIR fees might be 
payable, etc. (c) introduce uncertainty in the transfer market because donors 
and recipients get concerned that future transfers of legacy space could get 
singled out for yet more Bad Ideas.

I think it has been demonstrated by the stats of the last 2 years, that (a) is 
not the reality. (b) this is a community decision, and my personal view is that 
it should be that way. (c) this will not be retroactive: transfers already done 
with the exiting policy will not turn into non-legacy (unless they get 
transferred again).

Let's assume your hypothetical proposal became policy Jordi. Would it apply 
to transfers of legacy space that took place before this policy came into 
effect? If no, why not? If yes, it would imply all RIR policies have to be 
retroactively be imposed on legacy holders.

I just responded to this (c) above. I'm not considering retroactivity. They 
will if they become transferred again.

I think it's time to introduce a new policy proposal which brings about a 
moratorium on v4 address policy proposals.

> I think this is a benefit for the global community, because ... increase 
the transparency and community control.

Your comment about increased control is deeply troubling. Are you trying to 
turn the RIR system into the IP address police or the ITU? Do you want to bring 
about an investigation by the competition authorities? Be careful what you wish 
for -- you just might get it!

You know may answer already: not at all. I meant control by *this* community, 
by our policy system. Sorry if I was not clear.




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Sander,

I was referring to inter-RIR transfers, sorry not having been more explicit.

I understand that the previous policies were only intra-RIR. The actual ones 
are both intra and inter.

I don't think it is a matter of respect previous rights, because in that case, 
when we do *any* policy change, we may be not respecting the "previous rights" 
(conceded by the previous policy), of some members.

The PDP is about the good of the overall community even if some times, some 
decisions aren't the best for the 100%.

Regards,
Jordi
@jordipalet
 
 

El 15/7/19 0:50, "Sander Steffann"  escribió:

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





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Erik,

 

I’m not sure if I’m being able to explain myself …

 

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.

 

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.

 

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.

 

Regards,

Jordi

@jordipalet

 

 

 

El 14/7/19 14:40, "address-policy-wg en nombre de Erik Bais" 
 
escribió:

 

Hi Jordy,  

 

Legacy resources don’t fall under the contractual obligations that we as a 
community have setup. Financial or policy, unless decided/afreed upon by legacy 
resources themselves. 

That is described in the policy document RIPE NCC services for legacy resource 
holders.  ( https://www.ripe.net/publications/docs/ripe-639 ) 

 

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

 

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

 

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

 

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

 

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


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

Legacy holder can be outside ( no contract ) the rir status .. or by their own 
choice inside the system .. 

 

Hope this explains a bit. 

 

Regards,

Erik Bais 



Verstuurd vanaf mijn iPhone

Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg 
 het volgende geschreven:

Hi Gert,

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

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

Regards,
Jordi
@jordipalet



El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" 
 escribió:

   Hi,

   On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:


If legacy holders, want to transfers those resources and escape from fulfilling 
the policies and contractual requirements, now they can do it in RIPE, but not 
in other regions.


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

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

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert,

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

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

Regards,
Jordi
@jordipalet
 
 

El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

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

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

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

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

You're right for addresses not being transferred. This is the same in other 
RIRs if those resources aren't transferred.

What I'm suggesting will only be useful for those addresses that want to be 
transferred (within or to RIPE), but that's still sufficiently useful, in my 
opinion.

If legacy holders, want to transfers those resources and escape from fulfilling 
the policies and contractual requirements, now they can do it in RIPE, but not 
in other regions.

In my opinion this is bad for RIPE, because it means we may end up having here 
more and more non-policy/contractual-bound resources than the other regions 
that have this provision.

In only see good thing doing that, and nothing bad, if we as a community want 
to have as much as possible everybody engaged with the same rules.

Regards,
Jordi
@jordipalet
 
 

El 13/7/19 14:21, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

On Sat, Jul 13, 2019 at 02:04:11PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> My personal view but looking for the good of the community is that it is 
better to get rid ASAP of the "legacy" status for as much resources we can, so 
they are fully part of the policy system.

We have no contractual leverance to do anything to "legacy" addresses.

These are addresses that were assigned outside the RIR system, so there
exists no contracts with any RIR, and no way we can use our policies to 
make the holders do something "we want them to do".

We can entice them to bring their space into the umbrella of RIPE DB
documentation (by offering ROAs, for example) - and this is what we do
today.

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert,

I know we aren't ARIN and I've used that only as an example of the results of 
that provision.

My personal view but looking for the good of the community is that it is better 
to get rid ASAP of the "legacy" status for as much resources we can, so they 
are fully part of the policy system.

I think it is difficult to have a better opinion on this without understanding 
if I'm missing something from the original proposal discussion on this aspect.

Regards,
Jordi
@jordipalet
 
 

El 13/7/19 13:56, "address-policy-wg en nombre de Gert Doering" 
 escribió:

Hi,

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

What is it that you want to achieve with this?

Legacy resources can be converted to PA today, if the holder wants that,
but this is orthogonal to whether or not a transfer happened.

> I think this is a benefit for the global community, because with that, we 
bring into the RIR system more and more legacy IPv4 resources, which increase 
the transparency and community control.

Legacy resources that are documented in the RIPE database *are* 
transparently
documented today.  Those get updated in a transfer, even if still "legacy".

For legacy resources that are transferred outside RIPE NCC control, there
is no lever to force the holders to do anything.

> In a presentation from ARIN for the 2016-2018 period it has been mention:
> - Overall space managed by ARIN decreased by ~14 million IPv4 addresses, 
due to Inter-RIR transfers
> - Overall ARIN issued space increased by ~30 million IPv4 addresses, due 
primarily to conversion of legacy space via in-region transfers
> 
> Opinions?

We're not ARIN :-) - we have our own set of "how to deal with legacy 
addresses and address holders" policies, and they seem to serve us 
reasonably well.

So: what is the problem that you want to address?

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

I keep thinking that ripe-682 (RIPE resource transfer policies), should have a 
provision (as it is the case in all the other RIRs), in order to "convert" the 
legacy resources to non-legacy, when they got transferred.

I don't really recall if this was discussed during the relevant proposal 
discussion, and it will be great if someone can summarize it (I guess the 
author or chairs, or even the staff).

I think we should consider amend that, unless the reasons it was not done at 
that time, persist today, or even if those reasons persist, may be the 
community has a different view.

I think the text should be something such as:
IPv4 legacy resources will no longer be regarded as legacy resources:
- In the case of intra-RIR transfers.
- In the case of inter-RIR, when incoming to RIPE service region.

I think this is a benefit for the global community, because with that, we bring 
into the RIR system more and more legacy IPv4 resources, which increase the 
transparency and community control.

In a presentation from ARIN for the 2016-2018 period it has been mention:
- Overall space managed by ARIN decreased by ~14 million IPv4 addresses, due to 
Inter-RIR transfers
- Overall ARIN issued space increased by ~30 million IPv4 addresses, due 
primarily to conversion of legacy space via in-region transfers

Opinions?

Regards,
Jordi
@jordipalet
 
 



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

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

[address-policy-wg] informal discussion about removing 5.4.2. Assignments shorter than a /48 to a single End Site

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

As commented this morning at the end of the WG meeting, I've been thinking 
about this issue many times and in fact, in AFRINIC, APNIC and LACNIC, as part 
of *other* more complex IPv6 policy proposals, we successfully achieved 
consensus on removing the equivalent text.

ARIN has also changed this. In my opinion, the way they handle it, is too 
complex and not needed, but if someone want to read: 
https://www.arin.net/participate/policy/nrpm/#6-5-8-2-2-extra-large-sites

I've not (yet) done this in RIPE because I thought it is a so small change that 
doesn't make sense to tackle alone, but this morning I heard otherwise.

So ... here we are. By the way, as I always state, I will love some other folks 
that are willing to contribute, if so let me know in private so we can even 
organize an on-site meeting. However, in this case I think this policy proposal 
is just an "empty" one (only remove text, so nothing to draft ...) ... see 
below.

This is our actual text 
(https://www.ripe.net/publications/docs/ripe-707#assignments_shorter):
***
5.4.2. Assignments shorter than a /48 to a single End Site
When a single End Site requires an assignment shorter than a /48, it must 
request the assignment with documentation or materials that justify the 
request. Requests for multiple or additional prefixes exceeding a /48 
assignment for a single End Site will be processed and reviewed (i.e., 
evaluation of justification) at the RIR/NIR level.

Note: There is no experience at the present time with the assignment of 
multiple network prefixes to the same End Site. Having the RIR review all such 
assignments is intended to be a temporary measure until some experience has 
been gained and some common policies can be developed. In addition, additional 
work at defining policies in this space will likely be carried out in the near 
future.
***

In my opinion (as I've done in other RIRs), we should just *remove* the 
complete section.

Extreme example case. If an LIR decides to assign /47 to all their customers, 
and in the future,  they need to come back to the NCC for more space, they will 
need to justify it according to the existing policy at that time.

I may understand (even if I don't agree) that somebody want to have the NCC 
keep doing some evaluation on this. If we want to go this way, we will need to 
define with a short text what we want.

So, opinions? 

Regards,
Jordi
 
 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

I've already drafted a policy proposal to make a change on this, but if I got 
it correctly, the chairs were believing that it was not needed, so I never 
officially submitted it.

I'm happy to submit it again.

It may be interesting for all the list participants to read my policy proposal 
about this exact same point in AfriNIC:

https://www.afrinic.net/policy/proposals/2019-asn-001-d2#proposal


Regards,
Jordi
 
 

El 7/5/19 10:54, "address-policy-wg en nombre de Sander Steffann" 
 escribió:

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





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Same here, sorry, I've not participated in the discussion, a bit overloaded 
with daily work, but just read all the thread, and I'm supporting it.

Further I can add some data. I've participated in APNIC 47, and prop-127, which 
is mention in this proposal, reached consensus.

I've also discussed the same topic in the LACNIC mailing list, and I'm 
considering a similar proposal there. To be clear, I'm talking about the same 
as APNIC prop-127, which is moving the maximum allocation from /22 to /23.

Regards,
Jordi
 
 



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

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

[address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")

[JORDI PALET MARTINEZ via address-policy-wg]

Sorry, I've not participated in the discussion, but just read all the thread 
and the impact analysis, and I'm supporting as well.

Regards,
Jordi
 
 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Even very low-cost chipsets for CEs, such as Mediatek, Broadcom, 
Cavium/Marvell, etc., can offload IPv6 as well.

 

Sometimes is not the hardware, but the firmware not taking advantage of it.

 

For IPv6, unless you want pure dual-stack, not the right transition for what is 
needed now (IPv6-only with IPv4-as-a-Service), Mikrotik is the worst example, 
definitely.


Regards,

Jordi

 

 

 

De: address-policy-wg  en nombre de Dominik 
Nowacki 
Fecha: viernes, 8 de marzo de 2019, 14:45
Para: Stary Bezpiek 
CC: "address-policy-wg@ripe.net" 
Asunto: Re: [address-policy-wg] PA ??? life after death

 

That’s only if you run on soho (Mikrotik) or prehistoric gear. It’s hard to 
find Cisco/Juniper Datacentre router manufactured in the last 5 years that 
wouldn’t have full support for IPv6.  

 

There’s absolutely zero reason not to deploy it yet!

 

With Kind Regards, 

Dominik Nowacki 
 
Clouvider Limited is a limited company registered in England and Wales. 
Registered number: 08750969. Registered office: 88 Wood Street, London, United 
Kingdom, EC2V 7RS. 


On 8 Mar 2019, at 13:02, Stary Bezpiek  wrote:

W dniu 08.03.2019 o 13:19, Martin Huněk pisze:


Post scriptum: IPv6 is not harder or slower to deploy than IPv4. If you would

like to make IPv6-only network without transition mechanisms from scratch, it

would be easier to make than IPv4-only. You wouldn't need CGN and also HA

would be much easier (multiple routers on segment and so on). Technically the

IPv6 should be faster, allows more freedom in network architecture and should

require less logic in the network itself. It is mainly political problem, not

technical.

 


Do not mix politics to IPv6, please.

It's still lot of technical problems with IPv6 - the main one is dealing IPv6 
by software (processors) instead of hardware.
The first-hand example: Mikrotik. Lot of HW offload functions are only for 
IPv4. Same is with some Cisco's, or other randomly pointed devices. Amen.

-- 
stary.bezpiek



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

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

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai,

 

Actually, yes and not.

 

I’m talking about the clarification of 2.6 in the scope of 7 (PI) not in the 
scope of PA.


Regards,

Jordi

 

 

 

De: address-policy-wg  en nombre de Kai 
'wusel' Siering 
Organización: Unseen University, Department of Magic Mails
Fecha: jueves, 17 de enero de 2019, 20:58
Para: 
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

 

Hi Jordi,

you're mixing things up. This is not about 2016-04, which was approved long 
time ago. This is about ripe-707 [1], titled "IPv6 Address Allocation and 
Assignment Policy" — the current policy in question you want to be modified.

Regards,
-kai


[1] https://www.ripe.net/publications/docs/ripe-707#assign

Am 17.01.2019 um 20:34 schrieb JORDI PALET MARTINEZ:

Hi Kai,

 

You’re missing that 2016-04 is for the clarification of IPv6 PI, not PA.

 

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


Regards,

Jordi

 

 

 

De: address-policy-wg  en nombre de Kai 
'wusel' Siering 
Organización: Unseen University, Department of Magic Mails
Fecha: jueves, 17 de enero de 2019, 20:16
Para: 
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

 

On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote:
We need to consider as well, as I depicted already before, that if you have a 
physical sever, you probably need also multiple addresses for that server, 
that's why, I think the policy should allow that (this is clearly now allowed 
now).

Let's consult ripe-707:



2.6. Assign
To “assign” means to delegate address space to an ISP or End User for specific 
use within the Internet infrastructure they operate. Assignments must only be 
made for specific purposes documented by specific organisations and are not to 
be sub-assigned to other parties.

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. This includes for example letting visitors 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.
2.9. End Site
An End Site is defined as an End User (subscriber) who has a business or legal 
relationship (same or associated entities) with a service provider that 
involves:

· that service provider assigning address space to the End User

· that service provider providing transit service for the End User to 
other sites

· that service provider carrying the End User's traffic

· that service provider advertising an aggregate prefix route that 
contains the End User's assignment


By these definitions, only an IR ("2.1. Internet Registry (IR)")  can "assign" 
allocated address space to non-IRs, i. e. ISPs or End Users, in the context of 
ripe-707.
The term "ISP" is not wll defined within ripe-707 except for "LIRs are 
generally ISPs whose customers are primarily End Users and possibly other ISPs" 
in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests 
that ISPs are the entities that are actually creating the Internet, whereas 
(L)IRs are involved in distributing IP space only. Since, following 2.6., only 
an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" 
address space, 2.9. should therefore receive a friendly "s/service 
provider/ISP/g" and have the first bullet point removed.

On the other hand, 2.6. in it's current form – except for the "separate 
addresses (not prefixes)" issue, as any singke address IS technically also a 
/128 prefix – seems rather clear to me: if it's for the documented "specific 
use within the Internet infrastructure they operate", it's fine. Otherwise, a 
separate assignment is needed for either a new specific use _or a different End 
User_, so the ISP or End User (or the ISP for it's End User) will have to 
request that from an (L)IR (which it may be itself, if the ISP or End User is 
an LIR as well).

Thus, if you need "multiple addresses" for your "physical server" and you 
received an assignment for your infrastructure including your server(s), I 
cannot see a conflict with ripe-707. If you want to add a dedicated server for 
a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less 
than a /64 as per 5.4.1.) for this different End User from your LIR of choice 
(or have that End User apply for a /48 PIv6 via your cooperative LIR).

Regards,
-kai




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

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai,

 

You’re missing that 2016-04 is for the clarification of IPv6 PI, not PA.

 

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


Regards,

Jordi

 

 

 

De: address-policy-wg  en nombre de Kai 
'wusel' Siering 
Organización: Unseen University, Department of Magic Mails
Fecha: jueves, 17 de enero de 2019, 20:16
Para: 
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

 

On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote:
We need to consider as well, as I depicted already before, that if you have a 
physical sever, you probably need also multiple addresses for that server, 
that's why, I think the policy should allow that (this is clearly now allowed 
now).

Let's consult ripe-707:


2.6. Assign
To “assign” means to delegate address space to an ISP or End User for specific 
use within the Internet infrastructure they operate. Assignments must only be 
made for specific purposes documented by specific organisations and are not to 
be sub-assigned to other parties.

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. This includes for example letting visitors 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.
2.9. End Site
An End Site is defined as an End User (subscriber) who has a business or legal 
relationship (same or associated entities) with a service provider that 
involves:

· that service provider assigning address space to the End User

· that service provider providing transit service for the End User to 
other sites

· that service provider carrying the End User's traffic

· that service provider advertising an aggregate prefix route that 
contains the End User's assignment


By these definitions, only an IR ("2.1. Internet Registry (IR)")  can "assign" 
allocated address space to non-IRs, i. e. ISPs or End Users, in the context of 
ripe-707.
The term "ISP" is not wll defined within ripe-707 except for "LIRs are 
generally ISPs whose customers are primarily End Users and possibly other ISPs" 
in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions" suggests 
that ISPs are the entities that are actually creating the Internet, whereas 
(L)IRs are involved in distributing IP space only. Since, following 2.6., only 
an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role, "assign" 
address space, 2.9. should therefore receive a friendly "s/service 
provider/ISP/g" and have the first bullet point removed.

On the other hand, 2.6. in it's current form – except for the "separate 
addresses (not prefixes)" issue, as any singke address IS technically also a 
/128 prefix – seems rather clear to me: if it's for the documented "specific 
use within the Internet infrastructure they operate", it's fine. Otherwise, a 
separate assignment is needed for either a new specific use _or a different End 
User_, so the ISP or End User (or the ISP for it's End User) will have to 
request that from an (L)IR (which it may be itself, if the ISP or End User is 
an LIR as well).

Thus, if you need "multiple addresses" for your "physical server" and you 
received an assignment for your infrastructure including your server(s), I 
cannot see a conflict with ripe-707. If you want to add a dedicated server for 
a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e. no less 
than a /64 as per 5.4.1.) for this different End User from your LIR of choice 
(or have that End User apply for a /48 PIv6 via your cooperative LIR).

Regards,
-kai




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

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

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[JORDI PALET MARTINEZ via address-policy-wg]

And I agree with all what you said!

I just want to make sure that we all are in the same page.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg  en nombre de Kai 
'wusel' Siering 
Fecha: jueves, 17 de enero de 2019, 15:10
Para: JORDI PALET MARTINEZ via address-policy-wg 
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification



Am 17. Januar 2019 14:21:38 MEZ schrieb JORDI PALET MARTINEZ via 
address-policy-wg :

>I think this must be allowed, even if static/persistent, because I may 
need a service company coming to my network with their own devices, for 
example, installing IP video-cameras for surveillance. It doesn't make sense 
that they can't use my addresses, because that increase the complexity of the 
infrastructure, etc., even may force to have different networks.

Nicely constructed, but ... usually you will not have them come to your 
site, let them install their gear out of blue sky, and just leave. You'll have 
some kind of contractual relationship in place to have them do something for 
you, making the devices part of your network for the time being, so assigning 
them PIv6 addresses is ok (they are part of End User's infrastructure at that 
time — if you are the receiving End User of the PIv6 in question).

Regards,
-kai





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

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

Re: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Ray,

The question of the DC is much more complex. I think.

For example, is the same if the "hardware" (the real servers) are from the 
assignment holder or from third parties? (hosting vs housing).

I think hosting will be ok from the perspective of both the original IPv6 PI 
policy and the actual one. However, housing is at least, "in the limit" of what 
was intended originally ("not to be sub-assigned to other parties ").

With the actual policy both are allowed, but housing seems to be allowed only 
if dynamic ("connecting a server or appliance to an assignment holder's 
network") according to the impact analysis. This doesn't make sense, because if 
I'm setting up a server or appliance, it is not (in most of the cases) a 
"temporary" thing.

Also, the use of dynamic, may be confusing vs "persistent" (as we used in 
RIPE-690), as it may confuse regarding the usage of DHCP or something else, etc.

I think this must be allowed, even if static/persistent, because I may need a 
service company coming to my network with their own devices, for example, 
installing IP video-cameras for surveillance. It doesn't make sense that they 
can't use my addresses, because that increase the complexity of the 
infrastructure, etc., even may force to have different networks.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg  en nombre de Jetten 
Raymond 
Fecha: jueves, 17 de enero de 2019, 14:03
Para: JORDI PALET MARTINEZ 
CC: "address-policy-wg@ripe.net" 
Asunto: Re: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

Hello All,

I have a maybe very strange opinion on this, so i'll share it with you.

I agree with Jordi that the current situation is confusing and could be 
clearer...

IPv6 PI should be used as very originally was intended, and it should not 
be subnetted or subdelegations should be made of it to other instances than the 
obtainer at all.

Before you turn on the grill, what should be changed or made allowed or 
understood as intention, compared to the very original intention of PI IPv6 is 
that the temporary use as in f.ex your guest wlan, (the enduser will not get 
these ip:s with him/her when leaving the building, it’s a WLAN infrastructure 
that can be used as a "client" in this case even temporary).

In a DC, as long as the infra and servers are used or more precisely 
accessed by clients, they also do not get the ip:s assigned, but use them to 
access these platforms. In these cases the ip subnets belong to the provider, 
not to the customer. (VPN is a service right?)

If a customer of a  DC needs an assigned block for whatever reason, they 
can obtain a normal v6 block , or if PI v6 is needed, its still available, 
apply for a PI v6 subnet from Ripe. (or even become a member).

I hope this helps

Rgds,

Ray

-----Original Message-
From: address-policy-wg  On Behalf Of 
JORDI PALET MARTINEZ via address-policy-wg
Sent: 17. tammikuuta 2019 14:13
To: address-policy-wg 
Subject: [address-policy-wg] suggestions from the list about IPv6 
sub-assignment clarification

Hi all,

As you know, I've been working on different versions of a clarification to 
2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04).

This proposal allows a single IP to be sub-assigned, and the author 
explained (not just in the policy proposal text, but also in the justification 
and in different emails), that the case they have is to make sure that the 
policy allows it for:
1) Datacenter services.
2) Interconnections (VPN, PNI, p2p, etc.).
3) Guess visitors (employees, hotspot users, etc.).

The policy text doesn't mention those examples, but the summary talks about 
them:
"Intended use cases for IPv6 PI space in the spirit of this policy proposal 
are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as 
transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for 
housing/hosting for servers in data centres. The use of IPv6 PI space for 
DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this 
policy proposal."

On the other side, the impact analysis indicates:
"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 as per clause 2.6, “Assign” of the IPv6 address 
allocation and assignment policy. Consequently the RIPE NCC will not provide 
IPv6 PI assignments for such deployment plans."

I don't think this is very clear, because
1) DC addresses usually are static.
2) Interconnections usually are static (p2p links at l

[address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

As you know, I've been working on different versions of a clarification to 
2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04).

This proposal allows a single IP to be sub-assigned, and the author explained 
(not just in the policy proposal text, but also in the justification and in 
different emails), that the case they have is to make sure that the policy 
allows it for:
1) Datacenter services.
2) Interconnections (VPN, PNI, p2p, etc.).
3) Guess visitors (employees, hotspot users, etc.).

The policy text doesn't mention those examples, but the summary talks about 
them:
"Intended use cases for IPv6 PI space in the spirit of this policy proposal are 
the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer 
networks on PNIs or other PTP-links/VPNs to users or customers, or for 
housing/hosting for servers in data centres. The use of IPv6 PI space for 
DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this 
policy proposal."

On the other side, the impact analysis indicates:
"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 as per clause 2.6, “Assign” of the IPv6 address 
allocation and assignment policy. Consequently the RIPE NCC will not provide 
IPv6 PI assignments for such deployment plans."

I don't think this is very clear, because
1) DC addresses usually are static.
2) Interconnections usually are static (p2p links at least).

On the other side, as explained in my previous versions, I think that it is a 
valid case (in a hotspot, DC, etc.), instead of providing a single address, 
provide a full prefix (for example /64), so the host can have Virtual Machines 
running on different addresses of the same prefix.

So, in my understanding we really need to clarify this text and for that, we 
need to decide what we want to be allowed and what not.

So my questions are:
1) Do we agree that only dynamic should be allowed, or static is also ok?
2) According to 1 above, should the DataCenter case be alllowed?

Thanks!

Regards,
Jordi
 
 



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

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

[address-policy-wg] proposed text for Assignment Clarification in IPv6 Policy (policy proposal 2018-02)

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

Unfortunately, I've not received inputs on my question about what we want to be 
allowed in IPv6 PI, but as I'm working on this in other regions, got inputs in 
another region, which I think I can translate to this text:

**
2.6. Assign
To "assign" means to delegate address space to an ISP or End User,
for exclusive use within the infrastructure they operate,
as well as for interconnection purposes.

The address space assignment is only for use by the original holder
of said assignment, as well as for third-party devices,
as long as they are operating within the original holder infrastructure.

PI space will provide typically, a small number of subnets, so it is not 
intended
or desired to use PI space for access networks or commercial hosting and it 
is
strongly recommended instead, using PA space for such purposes.
**

This allows us to be "liberal" on using PI for data centers, which I think is 
the main issue of my previous version 
(https://www.ripe.net/participate/policies/proposals/2018-02), and also allow 
what somebody said is a "garage ISP" (a small ISP or DC that can start with 
very small cost o PI, and grow later on to PA).

This will also align us with the goal of facilitating IPv6 deployment.

Opinions?

Regards,
Jordi
 
 



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

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

[address-policy-wg] What we want to be acceptable in IPv4 PI and IPv6 PI?

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

Trying to look into my presentation today from a higher-level perspective ...

What is the expected usage of IPv4 and IPv6 PI?

It should be the same or different?

Do we want to use IPv6 PI as an entry point for people, without any 
restrictions, to start providing services and then they can grow up to become 
an LIR?

That means that an IPv6 PI can be used to provide hosting/housing services?

What about broadband services to end-users?

Peter, maybe you have a different perspective about how to approach this. Can 
you share it in the list?

Regards,
Jordi
 
 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

May be talking directly with ACM/IEEE, so they tell their members to respect 
the AUP, and if they don't react, just block any message that has IEEE (telling 
IEEE that we will be forced to do so).

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg  en nombre de Gert 
Doering 
Fecha: jueves, 27 de septiembre de 2018, 15:25
Para: Nick Hilliard 
CC: 
Asunto: Re: [address-policy-wg] [CFP] ACM/IEEE IPSN 2019 in CPSWeek

Hi,

On Thu, Sep 27, 2018 at 05:54:28PM +0100, Nick Hilliard wrote:
> 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.

After the previous case, I've asked RIPE ops to block the sender in
question from sending to the APWG list again (which they did).  Before
that, I tried to actually talk to the sender, who seemed to have no
interest in doing so, just spammed again.

> Vijay Rao wrote on 27/09/2018 10:39:
> > The 18th ACM/IEEE The International Conference on Information 
Processing 
> > in Sensor Networks (IPSN)

Now they found a new sender, which I'm going to ask ops again to block...
(for whatever reason, it seems my local spam filter ate that mail - I
didn't see it before you complained)

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

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




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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Once more ... this is not the point. I mention it as one possible choice 
(change fees or not, change contract or not). Even if this is not up to the WG, 
is something that we need to explore as well.

However, we can change the policy so that both PA and PI are "allocations" and 
there is no artificial differences in between and consequently, restrictions 
which are difficult to define "border lines".

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Peter 
Hessler <phess...@theapt.org>
Fecha: sábado, 19 de mayo de 2018, 18:17
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

On 2018 May 19 (Sat) at 18:11:39 +0200 (+0200), Kai 'wusel' Siering wrote:
    :Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg:
:> My proposal is NOT to stop IPv6 PI,
:
:Alternative facts? The title says "to remove IPv6 PI".
:
:> As I explained already, the intent is not to increase the end-user fees 
so they pay the same as an LIR, but to have some "proportionality" and to pay 
for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know 
that, it is something that the NCC should calculate).
:
:I've read multiple times that costs are out of scope for the APWG. So 
without a change towards a per resource fee structure – which is out of scope 
here –, the proposed change forces PIv6 holders to either become a LIR at 
1400,-- EUR/year or abandon their assignment.
:
:Regards,
:-kai
:
:

If my choices are to pay 28x my current fee or abandon using IPv6, I
will abandon using IPv6.  Quite simply, I can't afford it and **it isn't
worth it**.

Since I would like to use IPv6, I am very strongly against this proposal.


-- 
Law of the Perversity of Nature:
You cannot successfully determine beforehand which side of the
bread to butter.





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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai, below.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Kai 
'wusel' Siering <wusel...@uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: sábado, 19 de mayo de 2018, 18:11
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg:
> My proposal is NOT to stop IPv6 PI,

Alternative facts? The title says "to remove IPv6 PI".

[Jordi] You're taking the tittle literally. If this is a problem I will find a 
better one "remove differentiation between PI and PA" or whatever. I think 
across the emails it has been clear. What I think is needed is to remove the 
fact that PI is assignment and PA is allocation and the "consequences of that". 
Both should be the same, regardless of fees, contract type, etc.

> As I explained already, the intent is not to increase the end-user fees 
so they pay the same as an LIR, but to have some "proportionality" and to pay 
for the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know 
that, it is something that the NCC should calculate).

I've read multiple times that costs are out of scope for the APWG. So 
without a change towards a per resource fee structure – which is out of scope 
here –, the proposed change forces PIv6 holders to either become a LIR at 
1400,-- EUR/year or abandon their assignment.


[Jordi] Please read the other emails. Not an issue if that's the difficulty. 
The goal is that everything is "allocation". There are many possible ways to do 
that from the AGM perspective, and even if we don't decide that here, we must 
discuss it here because it provide "light" on the possible avenues.

Regards,
-kai






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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

I think it has been proven that lack of IPv6 PI was not an obstacle, just lazy 
people and no "immediate" incentives, and we are still with the same situation.

Regarding the "conversion" of the end-user contracts into LIR contracts, there 
are two choices:
1) The same way as NCC did to convert the "previous" non-contractual IPv4 PI 
holders to the end-user contract
2) We could decide to keep the end-user contract, but still "merge" the PI and 
PA policies (end-users get *allocated* one /48 for each end-site and sign end 
user, LIRs get allocated from /32 and sign LIR contract).


Regards,
Jordi
 
 

-Mensaje original-
De: Nick Hilliard <n...@foobar.org>
Fecha: sábado, 19 de mayo de 2018, 14:21
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

JORDI PALET MARTINEZ via address-policy-wg wrote:
> But, I think it is clear now that the main reason (1), was not
> really an obstacle for the IPv6 deployment, and in fact, where we
> are lacking "more" IPv6 deployment is in enterprises, so it didn't
> worked to resolve that problem.

You're misremembering the problem.  The reason for the IPv6 PI policy
was not that it was going to help deployment of IPv6, but instead that
the lack of easily available, provider-portable IPv6 address space would
create unnecessary obstacles to deployment.  This hasn't changed.

> Beard in mind, that having a *single* member contract, means
> simplicity for both the NCC and the members, which means somehow a
> (marginal) administrative cost decrease, but also simplification for
> the policies, less interpretation errors, less people trying to bend
> the policies to the limit, etc., etc.
There are ~2600 IPv6 PI assignments associated with ~2450 individual 
organisations.  Your proposal seems to require that these 
end-user-to-LIR contracts are replaced with end-user-to-RIPENCC contracts.

Can you elaborate on how you see this being handled? And what would the 
RIPE NCC do if an end-user declined to change?

Nick




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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert,

This sounds strange to me, specially the "laws" bit.

Unless I'm wrong on this, the other RIRs don't have that "special end-user 
contract", the membership agreement is the same, and never heard about a single 
case which it was a trouble at all.

Having somebody that do the paperwork for becoming an LIR and any associated 
work, is something that is being done already today for many companies, so I 
don't think there is no reason for that being a showstopper. In fact, this is 
something very common in many business activities (and just for our sector).

Last, but not least, we could keep the "end-user" agreement if this is a real 
problem, but still unify PI and PA.

Basically the policy text will say "If you have a need for end-site addressing, 
such as /48, you will get it *allocated* under the end-user agreement. If you 
have a need for /32 ... etc ... you will get it *allocated* under the LIR 
agreement".

I think the point that need to be clear is that by removing IPv6 PI, my intent 
is not to create troubles to anyone, but on the other way around, to simplify 
and to avoid complex policy text that disallows (because it is assigment 
instead of allocation), things that *allocations* allows ... which create 
artificial barriers and bending the rules or their interpretation.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert 
Doering <g...@space.net>
Fecha: sábado, 19 de mayo de 2018, 12:17
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

    Hi,

    On Sat, May 19, 2018 at 12:07:50PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> My proposal is NOT to stop IPv6 PI, it is only to make a *single*
> category of LIRs for both that accommodate real IPv6 addressing
> size needs, because PI and PA are the same, it is just an artificial
> name.

Speaking for my PI-holding (IPv4 and IPv6) customers, most of them do
not *want* to be a LIR.  They have a nice contract with a local company
(us) that does all the paperwork for them, speaks their local language,
they can visit our office if needed, we handle the international money
transfer bit, etc.

Some *cannot* become a LIR due to governing laws that disallow them 
to join any sort of association.

So "doing away with end-users that have their own space and are not 
a RIPE member" is not going to fly.

Gert Doering
-- speaking as sponsoring LIR admin
-- 
have you enabled IPv6 on something today...?

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




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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Jan,

We introduced IPv6 PI (I was the author of that policy proposal), because (in 
this order):
1) There was a claim for it considering that this will help the deployment of 
IPv6 (your claim for multihoming)
2) It existed in IPv4, so people wanted the same ...
3) It was a way to avoid creating an IPv6 NAT (somehow your mention about 
internal addresses)
4) ... there were many other minor considerations at that time

However, I always stated clearly when I was presenting my own proposal that I 
was "not" personally in favor of that, and I was only doing that because the 
community considered that need.

But, I think it is clear now that the main reason (1), was not really an 
obstacle for the IPv6 deployment, and in fact, where we are lacking "more" IPv6 
deployment is in enterprises, so it didn't worked to resolve that problem.

Now, in your text, you mention "but would never allocate to 3rd party networks 
because they would only use it internally for their own business" ... right, 
and we broke it with the 2016-4 ...

My proposal is NOT to stop IPv6 PI, it is only to make a *single* category of 
LIRs for both that accommodate real IPv6 addressing size needs, because PI and 
PA are the same, it is just an artificial name.

As I explained already, the intent is not to increase the end-user fees so they 
pay the same as an LIR, but to have some "proportionality" and to pay for the 
"real" NCC cost (which maybe still 50 euros, or maybe not, I don't know that, 
it is something that the NCC should calculate).

So, lets thing for a moment that 50 Euros for an ASN, 50 for an IPv4 /22 and 50 
for an IPv6 /48 (which in total is 150 Euros), it is really covering the yearly 
cost of the NCC to maintain those services. Maybe it is fair to just change 
that for 150 Euros (so no change) for LIRs which have a single end-site, but 
now they don't have restrictions and we avoid discussions related to if a 
sub-assignment is correct or not, if it is only a single address or several, 
and so on.

If instead of that, the NCC tell us that the real cost for maintaining those 
services is 200 Euros, it will be fair that the LIRs aren't subsidizing the 
end-users, so there is an LIR category for "end-users" that becomes 200 Euros 
(instead of 150), and then of course, the LIRs cost will drop a bit from 1.400 
Euros to maybe around 1.000 euros or whatever is the calculation that the NCC 
shows is the correct one (this will depend on how many LIRs we have today vs. 
end-users and how much is the expected increase in each category in the coming 
years, etc.).

Beard in mind, that having a *single* member contract, means simplicity for 
both the NCC and the members, which means somehow a (marginal) administrative 
cost decrease, but also simplification for the policies, less interpretation 
errors, less people trying to bend the policies to the limit, etc., etc.

It is up to the NCC to provide possible fee schemes to accommodate several 
possibilities, in order the ensure a long-term sustainability of the system and 
also a *fair* distribution of the real costs.

For example, it may be interesting also to consider if the "setup" fee should 
be really 2.000 euros, or something different (even less than half), if we have 
a double number of LIRs (when putting together a single contract for all), of 
if this one-time setup fee must be much lower to accommodate the "real" 
one-time-setup cost, and then pay just 10 extra (just an example) euros per 
year in the yearly fee, which is probably more interesting in terms of 
"long-term" NCC sustainability.

Last comment. I can't believe that and end-user, even a small company, is 
willing to pay to have a BGP router and capable staff (or external services to 
manage that), and has *an* issue to cover a few extra euros per year in case 
the (to be defined) "LIR fee for end-users" is 200 or even 500 Euros (again 
just examples) instead of 150 Euros.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Jan 
Hugo Prins | BetterBe <jpr...@betterbe.com>
Fecha: viernes, 18 de mayo de 2018, 12:30
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

I think we introduced IPv6 PI because we needed to be able to give
address space to entities that only need internal address space, want to
be multi-homed, but would never allocate to 3rd party networks because
they would only use it internally for their own business (for example a
SAAS provider hosting it's own product inhouse).

When we stop allowing IPv6 PI we would force those entities to, either
become a LIR and pay a lot more for the same IPv6 address space, or they
will probably not start using IPv6 at all. Both would not be a good idea
I think.

Jan Hugo

Re: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai,

Responding below, in-line.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Kai 
'wusel' Siering <wusel...@uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: miércoles, 16 de mayo de 2018, 20:37
Para: <address-policy-wg@ripe.net>
Asunto: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - 
comments from today meeting

Hi there,

on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote:
> So, to make sure I understood your point. You think that a single /128 
prefix is ok to be sub-assigned (as per the current policy), but a single /64 
prefix is not?
> Or you will agree in a change that only fix that?

I think that the current text serves it's purpose and _can_ be understood 
in the way it was intended to (i. e. countering the, non-standard, RIPE NCC 
idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, 
forbidden as per section 2.6).

[Jordi] So there is a contradiction here, because according you, only if you 
use manual setup, then it will not be a sub-assignment?

If you read it while suffering from an overdose of technical writings, a 
normal reaction could be "R U kidding me? Addresses, even plural, but not 
prefixes — does not compute".

I do *not* agree that _that paragraph_ needs another band-aid.

[Jordi] The fact that you and I are interpreting different things, shows 
clearly, that the text is not good.

I think that rough consensus should be sought on what uses by the 
assignment holder of assigned IPv6 space are considered ok. Afterwards, 
amending the policy at least should be more easy — if still considered 
necessary by then.

> Regarding the specific wording, you're totally right and we should decide 
*if* there is a way to re-formulate it.

I think we should keep it as it is, take a step back and consider what 
issue, if any, there is. Frankly, I do not see one ATM; policy texts should not 
try to micromanage the readers mind, IMO.

> That's the reason I initially suggested, even when discussing 2016-04, 
that the text should be only in the IPv6 PI section ... the consensus was in 
the other direction.

Well, the current policy does allow »minor« third-party-usage for any (note 
the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC 
being an act of address assignment, no-one was allowed to run a Guest WiFi or 
similar with RIPE area assigned IPv6 space, PA or PI — as sub-assignments were 
(and are) forbidden and providing a third party with single addresses out of an 
assignment holder's addresses constituted a sub-assignment according to RIPE 
NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree 
with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was 
fine and the issue lay elsewhere.


[Jordi] Again, then because I'm using latest standards which allow me to use 
/64 per hosts, it means I can't use it. We have moved the limit to a single 
address while it was NONE. The community can decide then to move to a single 
prefix, or why not, later to several /64 prefixes ... Thinks about that please.

> This is the big problem in my opinion, and I actually forgot the mention 
it before. I think policy must be as much as possible, a text which has only 
one interpretation, even if that means it is longer. Otherwise, and I explained 
this in emails when discussing 2016-04, people that "follows" the policy 
process has advantage in terms of interpretation vs a newcomer that will read 
only the *policy text*, but not the impact analysis, and all the discussions 
used to clarify the policy text.

I totally disagree with you on this. The more words go into a policy, the 
more loopholes are opened, which then have to backfill with new wordings, 
leading to pages after pages of policy text. A policy text should be easy to 
understand (especially for non-native speakers of the english language ;)), 
give a guideline on what use case it expects to cover and at all costs refrain 
from giving examples. The thing with examples is that, from my experience, they 
invite people to game the rules.

[Jordi] Again, newcomers have a disadvantage if the policy text is not clear 
enough and provides different interpretations vs the impact analysis, because 
the impact analysis is not *referenced* at the policy manual with every policy 
change (which will be way to complex).


Please don't overengineer the policies.
 
[Jordi] On the other way around, I'm trying to make sure that 1) the text is 
more clear or 2) we simplify all the mess by removing IPv6 PI
   
Regards,
-kai






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

I will use [Jordi] to make it clear.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Maximilian Wilhelm <m...@rfc2324.org>
Fecha: jueves, 17 de mayo de 2018, 17:36
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

    Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

> Responding below, in-line.

*PLEASE* use some meaningful way to quote and answer inline so a
reader can distinguish between the original text and your answer. You
current mode of answering is making this really hard.

> > De: address-policy-wg <address-policy-wg-boun...@ripe.net> en 
nombre de Martin Huněk <hun...@gmail.com>
> > Fecha: miércoles, 16 de mayo de 2018, 17:28
    > > Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
> > Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI
> > 
> >> Hi Jordi,
> > 
> >> As I understand it, the PA is only for a LIR and PI is also 
for sponsored organization. Also the PI is solely for the end user 
infrastructure and and PA can be further allocated or assigned.
> > 
> > This is our actual definition. We can change it whenever we want. 
What I'm asking is what is the *real* distinction among them. Forget for a 
minute in contracts, fee structure and so on. There is no need to call the same 
with different names if we don't want. I'm calling here for simplicity. Once we 
remove the sub-assignment obstacle, there is not anymore a difference.
> 
> Discussion should be about, if we want to / should remove such 
*obstacle*. I would personally prefer that policy about PI space would stay the 
same. Just RIPE NCC should be more investigative and restrictive when assigning 
those. 
> 
> Being Internet policy is very difficult. If we have ways to avoid that, 
is an easier way to achieve the same. Policies are for a fair distribution of 
the resources, to make that distribution simpler, not to have complex policies 
and then being unable to track how well anyone is behaving with them.
> 

> > Yes, that's the idea, please see my slides. PI holders will need to 
become members, maybe the fee will get an increase (something on the line of a 
small one-time setup fee and later on a proportion of the cost of a /32 if you 
are getting only a /48, etc., but this is for the membership to decide). What 
we all win with that is a fairer cost distribution and also an easier way to 
make sure that the rules are followed and nobody tricks the rules using a PI as 
PA. Specially for the NCC is much simpler.
> 
> Easy as a flat rate for every LIR. Actually this is the main problem 
problem for me. LIR should by the name work as local internet registry. This 
has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be 
a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. 
Such organization which needs PI have no plans for assigning 
> 
> Is easier, but it is fair?

This is not for the AP-WG to decide.

[Jordi] Agree, but it was not either when we created IPv6 PI, and all the 
needed changes were considered in parallel.

> addresses to third parties, so why they should be LIR when they don't 
plan to act as one?
> 
> The problem is that once we accepted 2016-04, that got broken. End-users 
being assigned a /48 are using that now to sub-assign addresses to other 
end-users (employees, students, users of a hot-spot, etc.).

Well, most people obviously don't consider this "broken" as there has
been a consensus after all. And I think we really made clear that it's
not a sub-assigment, which was the whole point of the last two years.

[Jordi] We aren't going to discuss that over and over again. Different people 
who read that text has a different interpretation than the impact analysis, so 
objectively it is broken.

> This would make IPv6 addresses less accessible. It is like LIR 
saying: "Do you want to have your own addresses or more then I gave you? Go to 
the RIPE NCC and pay them 1400 EUR/y! No matter what you do...". Those PI users 
would either loose protection of their own space or they would had to pay 28x 
more per year plus 2000 EUR sign up fee. What would do company outside of the 
internet business? They would not implement IPv6, that is easy! :-)
>
> As said before, this is fixed in combination with the fee structure 
decision by the AGM. So *no*, on the contrary, will be fairer. I think probably 
a 50 Euros cost for a /48 is really too low, and may be a /32 will become 
chea

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Max,

Thanks for your inputs.

Responding below in-line.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Maximilian Wilhelm <m...@rfc2324.org>
Fecha: viernes, 18 de mayo de 2018, 2:38
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

    Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

Hi,

> PI and PA are artificial names for the same thing.

They are not.

Please, enumerate what are the differences, so we can check one by one.

> There is only one type of Global Unicast Addresses in IPv6.

Not true.

Sorry, can you point me to the RFC that points to that assertion?


PI and PA are sliced from different pools which may have (I didn't evaluate
that by myself yet) different routing policies in the DFZ. At least
I've seen filters or BCOPs for PA space differ from PI space in the
means of what prefix lengths to accept.

If you look into my presentation you will see that I've already thought about 
that, so the NCC can continue with the same operational practices as per today:

" Actual IPv6 PI assignments are made from a different block. Even if it is an 
operational NCC issues, I believe it still makes sense for the NCC to keep that 
structure (a block for ISPs with /32 and bigger allocations) and another block 
for /48 and bigger allocations (may be up to /33 for organizations/end-sites). 
Also keep using sparse allocation for both, and allow, while possible that 
further allocations are made from an adjacent address block."


> As I already explained before, the same way the AGM created the end-user 
contract and the corresponding fee, they should be a new fee structure within 
the LIR contract, for those that have one of few /48s instead of /32 or /29, 
etc.

And there you are mixing GM and AP-WG again. This is neither a topic
for this WG, nor do I think that there would be any possible
consensus about a change in charging schema.

I know, but BOTH need to be worked somehow with some parallelism. I'm going to 
say this once more: We didn't have the end-user contract before I proposed the 
IPv6 PI, then the board and the AGM did the rest. So there is not any issue 
about repeating that.


And basicly I'm with some other here:

What is your real intent with all this? Simplification does not seem
to be it.

For full disclosure, if you still doubt about it: My intent is only doing work 
whenever I need it helps, for the good of the community. I'm probably the most 
objective guy here. I've no any LIR neither end-user (in any RIR), neither I 
plan. So, whatever is in the policies is not "affecting directly to me". I only 
had an experimental ASN and IPv6 prefix, many years ago, when I started playing 
with IPv6.

Despite that, because you seem to think that I'm hiding something, whatever I 
can say will not convince you. But put yourself in this situation. When anybody 
submit a policy proposal, should we always think that? If we start with this 
kind of prejudices, will never help debating on any topic. Not really smart.

So, once more, can you enumerate what are the special features from IPv6 PI, 
different that IPv6 PA, that I'm missing?

Put aside for a moment all the issues related to fees, because even the AGM 
could decide to keep the exact same fees for "end-users" as per today even if 
we remove the IPv6 PI. So that may not change this specific aspect of the 
overall discussion.


Best
Max





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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

PI and PA are artificial names for the same thing. There is only one type of 
Global Unicast Addresses in IPv6.

As I already explained before, the same way the AGM created the end-user 
contract and the corresponding fee, they should be a new fee structure within 
the LIR contract, for those that have one of few /48s instead of /32 or /29, 
etc.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Kai 
'wusel' Siering <wusel...@uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: miércoles, 16 de mayo de 2018, 22:06
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

Am 16.05.2018 um 14:52 schrieb JORDI PALET MARTINEZ via address-policy-wg:

> […]
> I believe we have several problems that my proposal is trying to fix.
> […]
> Thoughts?

To put it in a nutshell, I think you throw out the baby with bath water 
here: you're not simply "merging the requirements for PI and PA in a single 
policy", you'd take away any means for a non-LIR to request non-PA IP space. 
Moreover, you intend to force any current IPv6 PI holder into either becoming 
an LIR (which amounts to a 28fold cost increase: 50 => 1400 EUR/year) or to 
abandon the PIv6 space they build there infrastructure on. I don't yet 
understand what's your agenda, but I'm deeply concerned.

Anyway: I oppose this proposal. It would cause a lot harm for no obvious 
reason.
-kai







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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Responding below, in-line.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Martin 
Huněk <hun...@gmail.com>
Fecha: miércoles, 16 de mayo de 2018, 18:29
Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

in-line

Regards,
Martin
Dne středa 16. května 2018 17:45:01 CEST, JORDI PALET MARTINEZ via 
address-policy-wg napsal(a):
> Below, in-line.
> 
> Regards,
> Jordi
>  
>  
> 
> -Mensaje original-
> De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Martin Huněk <hun...@gmail.com>
> Fecha: miércoles, 16 de mayo de 2018, 17:28
> Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
> Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI
> 
>> Hi Jordi,
> 
>> As I understand it, the PA is only for a LIR and PI is also for 
sponsored organization. Also the PI is solely for the end user infrastructure 
and and PA can be further allocated or assigned.
> 
> This is our actual definition. We can change it whenever we want. What 
I'm asking is what is the *real* distinction among them. Forget for a minute in 
contracts, fee structure and so on. There is no need to call the same with 
different names if we don't want. I'm calling here for simplicity. Once we 
remove the sub-assignment obstacle, there is not anymore a difference.

Discussion should be about, if we want to / should remove such *obstacle*. 
I would personally prefer that policy about PI space would stay the same. Just 
RIPE NCC should be more investigative and restrictive when assigning those. 

Being Internet policy is very difficult. If we have ways to avoid that, is an 
easier way to achieve the same. Policies are for a fair distribution of the 
resources, to make that distribution simpler, not to have complex policies and 
then being unable to track how well anyone is behaving with them.

>> I'm not competent enough to tell if it is better to have the same 
contract with members and non-members, maybe someone from RIPE NCC can answer 
that.
> 
>> I think that they should be isolated because they should be used for 
different things. PA for networks with single upstream - they should receive 
ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On 
the other hand we all know that PI is used as small PA, without editing RIPE 
DB, of course.
> 
> There is not anymore an obligation, for many years, to have multihoming. 
So, no difference here.

Sure it is not an obligation, it is just my understanding what is meant by 
current policy or what it should mean.

>> By removing PI, you would had to allow non-members to receive PA or 
you would had to force every current PI holder to became LIR. I know that most 
of the new members are in RIPE just for IPv4, but in the distant IPv6 only 
future, what would be the result of such change? What would be the reason to be 
a member in such future?
> 
> Yes, that's the idea, please see my slides. PI holders will need to 
become members, maybe the fee will get an increase (something on the line of a 
small one-time setup fee and later on a proportion of the cost of a /32 if you 
are getting only a /48, etc., but this is for the membership to decide). What 
we all win with that is a fairer cost distribution and also an easier way to 
make sure that the rules are followed and nobody tricks the rules using a PI as 
PA. Specially for the NCC is much simpler.

Easy as a flat rate for every LIR. Actually this is the main problem 
problem for me. LIR should by the name work as local internet registry. This 
has been broken for IPv4 by IPv4 shortage. Not everyone should be forced to be 
a RIPE NCC member. I'm perfectly fine with 50 EUR fee for every /48 for those. 
Such organization which needs PI have no plans for assigning 

Is easier, but it is fair?

addresses to third parties, so why they should be LIR when they don't plan to 
act as one?

The problem is that once we accepted 2016-04, that got broken. End-users being 
assigned a /48 are using that now to sub-assign addresses to other end-users 
(employees, students, users of a hot-spot, etc.).

This would make IPv6 addresses less accessible. It is like LIR saying: "Do 
you want to have your own addresses or more then I gave you? Go to the RIPE NCC 
and pay them 1400 EUR/y! No matter what you do...". Those PI users would either 
loose protection of their own space or they would had to pay 28x more per year 
plus 2000 EUR sign up fee. What would do company outside of the interne

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Max,

I will not have any problem if you need to write something unpolite just to 
explain much better what is your view.

What I will not help in any discussion is just responding "I'm for" or "I'm 
against" without further explanations.

Otherwise, feel free to talk to me at any time during the rest of the week.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Max 
Tulyev <presid...@ukraine.su>
Fecha: miércoles, 16 de mayo de 2018, 19:22
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

Wrote a huge post. Tried to remove all the impolite phrases from it
then. Didn't manage to do that. Removed the whole post. So, in one sentence,

I am against this.
    

    16.05.18 15:52, JORDI PALET MARTINEZ via address-policy-wg пише:
> Hi all,
>
> For those that haven't been in the meeting, the slides are available at 
https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf
>
> I believe we have several problems that my proposal is trying to fix.
>
> 1) See my previous email on the clarification of IPv6 PI sub-assignments. 
Is not just a matter of IPv6, but also IPv4. This is an alternative solution 
(at least of the IPv6 part - we could do the same for IPv4 of course and also 
remove IPv4 PI).
>
> 2) It was clear in the meeting, as we *all* know, that many folks in the 
community (and not only in this region) are abusing the policy and they 
actually use end-user space (PI policies) to *assign* (call it sub-assign if 
you prefer it), to third parties.
>
> 3) It may be the case that this happens because the fee structure. An 
LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 
Euros). And end-user just pay 50 Euros per resource assignment. So, it makes 
sense to just pay for 50 Euros, and then you may be providing services using 
NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of 
IPv6. It is broken, of course, but people do that.
>
> 4) The fee scheme is somehow responsible of that as well, as there is in 
my opinion, unfairness. A big ISP having an IPv6 /20, or /24 or /29 or /32 is 
paying always the same. This is the only region that have a "flat" rate.
>
> 5) We could fix the point above, auditing every end-user. But we could 
also fix it in a better way by:
>   a) A policy change in the line the one I've proposed (see the slides 
and the links for a diff)
>   b) Having a single LIR contract, instead of LIR and end-user
>   c) This may be (as an option), also become a way to make a price scheme 
which is proportional to the amount of resources allocated.
>
> Note that we don't need to change the fee scheme, but it is an 
opportunity for taking a look into that. It may be perfectly possible to keep 
the cost of end-users as 50 Euros (for a single /48, for example), but having a 
single contract. I know perfectly that fees are not "policy", however only if 
we address that we can do correctly the policy. A demonstration of that: When I 
proposed the IPv6 PI and it reached consensus, it was needed to create the 
"end-user" contract and the corresponding fee, so is something that we have 
done before.
>
> I know that the proposed text may be very imperfect, for example the 
usage of "ISPs", but this is not the key now, there are for sure several 
alternatives to that. For example, we could just differentiate both cases with 
"LIR that do subsequent distributions initially qualify for /32 up to /29 etc. 
LIRs that do not do subsequent distributions initially qualify for a /48 for 
each end-site". So please, don't consider specific text at this point of the 
discussion.
>
> And last, but not least, repeating myself, we could do this just for 
IPv6, or also work in parallel in a policy proposal for IPv4 PI removal as 
well. This will be probably the best choice, so we can let the NCC to have a 
simplified policy, a single contract and consequently less overhead: 
Simplification for everyone.
>
> Thoughts?
>
>
> Regards,
> Jordi
>  
>  
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohi

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Below, in-line.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Martin 
Huněk <hun...@gmail.com>
Fecha: miércoles, 16 de mayo de 2018, 17:28
Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

Hi Jordi,

As I understand it, the PA is only for a LIR and PI is also for sponsored 
organization. Also the PI is solely for the end user infrastructure and and PA 
can be further allocated or assigned.

This is our actual definition. We can change it whenever we want. What I'm 
asking is what is the *real* distinction among them. Forget for a minute in 
contracts, fee structure and so on. There is no need to call the same with 
different names if we don't want. I'm calling here for simplicity. Once we 
remove the sub-assignment obstacle, there is not anymore a difference.


I'm not competent enough to tell if it is better to have the same contract 
with members and non-members, maybe someone from RIPE NCC can answer that.

I think that they should be isolated because they should be used for 
different things. PA for networks with single upstream - they should receive 
ALLOCATED-BY-LIR from LIR's PA. PI for customers with the second upstream. On 
the other hand we all know that PI is used as small PA, without editing RIPE 
DB, of course.

There is not anymore an obligation, for many years, to have multihoming. So, no 
difference here.

By removing PI, you would had to allow non-members to receive PA or you 
would had to force every current PI holder to became LIR. I know that most of 
the new members are in RIPE just for IPv4, but in the distant IPv6 only future, 
what would be the result of such change? What would be the reason to be a 
member in such future?

Yes, that's the idea, please see my slides. PI holders will need to become 
members, maybe the fee will get an increase (something on the line of a small 
one-time setup fee and later on a proportion of the cost of a /32 if you are 
getting only a /48, etc., but this is for the membership to decide). What we 
all win with that is a fairer cost distribution and also an easier way to make 
sure that the rules are followed and nobody tricks the rules using a PI as PA. 
Specially for the NCC is much simpler.


In my opinion PI should still be here, but only for a special cases, 
non-ISP non-LIR organizations. So if there will be any use of PI space by ISP 
for its clients, it should be immediately reclaimed by RIPE NCC. Also LIR 
should not be entitled to claim PI for itself. But this is just my point of 
view.

So then, again, let's roll back 2016-04, because is non-sense that somebody 
instead of using the addressing space for their own organization as end-user, 
is using it for a hotspot or datacenter.

I'm more and more convinced as we exchange emails on this, that either we 
clarify very well what is a sub-assignment (and if you follow the last couple 
of emails on that discussion you will see how difficult may be to clarify that 
with a "short" text), or we just put all in the same "class" of addressing 
space.


Sincerely,
Martin

    Dne středa 16. května 2018 16:10:13 CEST, JORDI PALET MARTINEZ via 
address-policy-wg napsal(a):
> Hi Martin,
> 
> I'm clear about the IPv4 situation. No discussion on that.
> 
> I also understand that both (ISP for special infrastructure and also 
large non-ISP) need addressing space. Call it PI or PA is another question.
> 
> Having a single contract doesn't goes against the need for both kind of 
organizations.
> 
> I think we both agree. What I'm saying is that there is no need to have 
both into different policies if are able to simplify for both organizations to 
have a single contract and a single policy (with of course, require a small 
different justification mechanism - or may be not even to make it much simpler).
> 
> Can you tell me why you believe we need to keep them *isolated* ? I mean 
specific needs that makes impossible to accommodate both into a single policy?
> 
> The only *real* difference in the policy is that one starts with /48 per 
end-site, the other with /32. Anything else?
> 
> Regards,
> Jordi
>  
>  
> 
> -Mensaje original-
> De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Martin Huněk <hun...@gmail.com>
> Fecha: miércoles, 16 de mayo de 2018, 16:01
> Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
> Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI
> 
> Hi Jordi,
> 
> I must say that I'm strongly against this propo

Re: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai,

Below, in-line.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Kai 
'wusel' Siering <wusel...@uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: miércoles, 16 de mayo de 2018, 16:47
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy 
- comments from today meeting

On 16.05.2018 14:19, JORDI PALET MARTINEZ via address-policy-wg wrote:
> Hi all,
>
> I've been asked to state what is the problem.
>
> I think it was clear in my slides, but anyway, here we go with all the 
problems I see:
>
> 1) The current policy text says "Providing another entity with separate 
addresses (not prefixes)".
>  To me this is inconsistent addresses instead of an address vs 
not-prefixes.

I think I mentioned this on 2016-04 already; any single address is always a 
prefix as well, /128 in v6.

So, to make sure I understood your point. You think that a single /128 prefix 
is ok to be sub-assigned (as per the current policy), but a single /64 prefix 
is not?
Or you will agree in a change that only fix that?

But your slide 3 shows nicely why I strictly oppose more meddling with this 
paragraph. We went from 42 words in »2.6 Assign« to 98 in the current policy 
text, which your proposal would boost to a staggering 134 words.
And that's without the necessary – but yet missing – definitions of 
»non-permanently« or what happens on links that are not »operated« by the 
assigment holder (i. e. a link a peer operates cannot use numbers from my 
assignment?). Not to mention the loophole that narrow band services are 
explicitely are allowed now — given 100 GBit/sec links are common these days, 
10 to 100 MBit/sec is definitely narrow band today, right?

Regarding the specific wording, you're totally right and we should decide *if* 
there is a way to re-formulate it.


But there is a point everyone seems to happily ignore: The text discussed 
last time, as well as this time, changes the basic definition of what an 
assignment is and "to assign" means. As such, that definition applies 
everywhere where the policy document talks about assignments.
Like e. g. in »5.4.3. Assignment to operator's infrastructure«: »An 
organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service 
infrastructure of an IPv6 service operator. Each assignment to a PoP is 
regarded as one assignment regardless of the number of users using the PoP. A 
separate assignment can be obtained for the in-house operations of the 
operator.«

That's the reason I initially suggested, even when discussing 2016-04, that the 
text should be only in the IPv6 PI section ... the consensus was in the other 
direction.

The more text we put into 2.6, the more difficult it will become to not 
violate the policy, for End Users, ISPs and even for LIRs. Any change to "2.6 
Assign" applies to PA and PI space alike.

> 3) If we allow sub-assignments, what is then the difference in between 
IPv6 PA and PI ?

You are barking at the wrong tree. "2.6 Assign" applies to PI and PA and 
disencourages sub-assignments (of any assigned space) "to other parties" anyway.

> So, I think it is clear we have not just one problem?

I do not see a real problem with the text of ripe-699 – unless I start 
nit-picking and take the policy apart, word by word. If one *wants*, the 
*intention* of the policy can be understood. If one does not want to understand 
the intention, more words will simply make things worse, not better.

This is the big problem in my opinion, and I actually forgot the mention it 
before. I think policy must be as much as possible, a text which has only one 
interpretation, even if that means it is longer. Otherwise, and I explained 
this in emails when discussing 2016-04, people that "follows" the policy 
process has advantage in terms of interpretation vs a newcomer that will read 
only the *policy text*, but not the impact analysis, and all the discussions 
used to clarify the policy text.




Regards,
-kai







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

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

Re: [address-policy-wg] proposal to remove IPv6 PI

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Martin,

I'm clear about the IPv4 situation. No discussion on that.

I also understand that both (ISP for special infrastructure and also large 
non-ISP) need addressing space. Call it PI or PA is another question.

Having a single contract doesn't goes against the need for both kind of 
organizations.

I think we both agree. What I'm saying is that there is no need to have both 
into different policies if are able to simplify for both organizations to have 
a single contract and a single policy (with of course, require a small 
different justification mechanism - or may be not even to make it much simpler).

Can you tell me why you believe we need to keep them *isolated* ? I mean 
specific needs that makes impossible to accommodate both into a single policy?

The only *real* difference in the policy is that one starts with /48 per 
end-site, the other with /32. Anything else?

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Martin 
Huněk <hun...@gmail.com>
Fecha: miércoles, 16 de mayo de 2018, 16:01
Para: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ 
<jordi.pa...@consulintel.es>
Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI

Hi Jordi,

I must say that I'm strongly against this proposal.

Reasons:
- Situation between IPv4 and IPv6 is quite different - reasons for 
canceling IPv4 PI was simply not enough space
- Not everyone in the business had to be a LIR and some large non ISP 
organization could be legitimate user of PI space
- Insufficient checks and under-educated LIRs doesn't necessary mean that 
concept of PI space is bad, only that it is misused

Now some details. Even in IPv4 there is still PI space left, not for the 
ordinary networks, but for the IXPs. It is a fact that there are missuses of 
IPv6 PI space like ISP running in PI space. But if we want to cast the blame, 
it would come to the uneducated LIR operators and partially to the RIPE NCC 
because it did not educate them well (or at least explain when to ask for PI in 
the LIR portal).

Personally, I had to ask my formal upstream (before we became LIR) 
specifically to make ALLOCATED-BY-LIR object and to make me mnt-lower, step by 
step because they didn't know how to do that. For such LIR it is easier to ask 
for PI just because they use to do that for the IPv4.

There are also some large companies that would be legitimate to use current 
PI space. Not every organization had to be in internet business, so it should 
not be a LIR at all. Current concept of every major end-user to be a LIR is 
broken because need of IPv4, lets not spoil the IPv6 world the same way.

Current PI space misuse could have been solved by more in depth checks. 
Like if the end user is an ISP, it is most likely misuse. Also if someone asks 
for PI, RIPE NCC should either pick up the phone or write an e-mail and ask LIR 
why they want to ask for PI.

Can RIPE NCC make video about proper way how to make allocations for LIR's 
"downstream"/client? Maybe place it in PI assignment wizard in LIR portal.

IPv4 shortage just broke the model LIR. Today just too much end users 
became a LIRs just to be given IPv4 space, but they would never serve as a 
local internet registry or would not know how to work as LIR. Canceling the 
IPv6 PI would not help to solve this problem, it would make it even worse, by 
pushing more and more end users to became LIR when they are actually not one.

Best regards
Martin

Dne středa 16. května 2018 14:52:57 CEST, JORDI PALET MARTINEZ via 
address-policy-wg napsal(a):
> Hi all,
> 
> For those that haven't been in the meeting, the slides are available at 
https://ripe76.ripe.net/presentations/97-RIPE-2018-05-v1.pdf
> 
> I believe we have several problems that my proposal is trying to fix.
> 
> 1) See my previous email on the clarification of IPv6 PI sub-assignments. 
Is not just a matter of IPv6, but also IPv4. This is an alternative solution 
(at least of the IPv6 part - we could do the same for IPv4 of course and also 
remove IPv4 PI).
> 
> 2) It was clear in the meeting, as we *all* know, that many folks in the 
community (and not only in this region) are abusing the policy and they 
actually use end-user space (PI policies) to *assign* (call it sub-assign if 
you prefer it), to third parties.
> 
> 3) It may be the case that this happens because the fee structure. An 
LIR, currently, pays 1.400 Euros per year (plus one-time setup-fee of 2.000 
Euros). And end-user just pay 50 Euros per resource assignment. So, it makes 
sense to just pay for 50 Euros, and then you may be providing services using 
NAT+CGN (in the case of IPv4) or a single /64 to each subscriber in the case of 
IPv6. It is broken, of course, but people do that.
  

[address-policy-wg] 2018-02 Assignment Clarification in IPv6 Policy - comments from today meeting

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

I've been asked to state what is the problem.

I think it was clear in my slides, but anyway, here we go with all the problems 
I see:

1) The current policy text says "Providing another entity with separate 
addresses (not prefixes)".
 To me this is inconsistent addresses instead of an address vs not-prefixes.

2) If the end-device need a /64 instead of a single address, as per RFC8273, 
then it is breaking the actual policy.

3) If we allow sub-assignments, what is then the difference in between IPv6 PA 
and PI ?

So, I think it is clear we have not just one problem?

Now, if we want to go further. Do we have the same problem with IPv4 if, for 
example a university, instead of using NAT, they also sub-assign public IPv4 
addresses to students?

Inputs?

Regards,
Jordi
 
 



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

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

[address-policy-wg] 2018-01 Organisation-LIR Clarification in IPv6 Policy - comments from today meeting

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

I tried to find the "mismatch" that Peter mention today in the meeting about 
this proposal text, however was unable to.

So, if Peter or somebody else can point to anything more specific, the authors 
will be happy to provide thougths for alternatives to the mismatching text.

Thanks!

Regards,
Jordi
 
 



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

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

Re: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR Clarification in IPv6 Policy)

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

 

This is a grammar details that doesn’t affect the policy proposal content. I’m 
fine either way, but of course, I’m not native English, and the way it is being 
used in the document right now, was the suggested NCC format.

 

So, I will say I’m happy if they choose one way or another, for consistence 
with the rest of the policies in the region.


Regards,

Jordi

 

 

De: address-policy-wg  en nombre de Scott 
Leibrand 
Fecha: viernes, 4 de mayo de 2018, 10:01
Para: Ian Dickinson 
CC: "address-policy-wg@ripe.net" 
Asunto: Re: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR 
Clarification in IPv6 Policy)

 

If LIR is pronounced “Elle-Eye-Are” (which is how I pronounce it) then “an LIR” 
is correct. It would only be “a LIR” if you pronounce it “Lear”. 

 

http://blog.apastyle.org/apastyle/2012/04/using-a-or-an-with-acronyms-and-abbreviations.html

Scott


On May 4, 2018, at 1:42 AM, Ian Dickinson  wrote:

There are a number of occurrences of "an LIR" (and also "An LIR") throughout 
the document that should be changed to "a LIR".
Presumably only s/Organisation/LIR/ was done.

Other than this grammar nit, I am happy the text matches the goal and I support 
it.

Ian

-Original Message-
From: address-policy-wg  On Behalf Of Marco 
Schmidt
Sent: 03 May 2018 16:08
To: address-policy-wg@ripe.net
Subject: [address-policy-wg] 2018-01 Review Phase (Organisation-LIR 
Clarification in IPv6 Policy)

Dear colleagues,

Policy proposal 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now 
in the Review Phase.

This proposal aims to clarify the wording used in ripe-699 regarding terms such 
as "organisation" and "LIR".

The proposal has been updated following the last round of discussion and is now 
at version v2.0. Some of the differences from version v1.0 include:
- Clarifies when the subsequent allocation policy applies
- Fixing some typos

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

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

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

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

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

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC 

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


Disclaimer

This email is private and may be confidential and is intended for the recipient 
only. If misdirected please notify us by telephone and return and confirm that 
it has been deleted from your system and any copies destroyed. If you are not 
the intended recipient you are strictly prohibited from using, printing, 
copying, distributing or disseminating this email or any information within it. 
We use reasonable endeavours to virus scan all emails leaving our organisation 
but no warranty is given that this email and any attachments are virus free. 
You should undertake your own virus checking. The right to monitor email 
communication through our networks is reserved by us.



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

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

Re: [address-policy-wg] inputs on possible policy proposal for IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Sebastian,

As said, is just an idea, and I'm not yet nailing down all the details, but I 
don't think, in general, and ISP that has advanced his deployment, will 
renumber ... so of course I will not suggest that as mandatory, only an option 
in case some want to do (there are a few ISPs that got their /29 and didn't 
deployed IPv6 at all, so it make sense for them).

On the other side, it will be nice, in order to understand how much is the 
impact of this, if the NCC can provide a summary of how many of the actual RIRs 
that have a non-nibble boundary allocation, will not be able to get it upgraded 
to the nibble-boundary one because the precedent space has been already 
allocated to someone else, etc.

Regards,
Jordi
 
 
-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Sebastian Wiesinger <sebast...@karotte.org>
Fecha: viernes, 4 de mayo de 2018, 6:52
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6

* JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> 
[2018-05-02 14:26]:
> Note that in the case of RIPE, we have a big difference with the
> other RIRs, because all them start with /32, while we updated our
> policy several years ago (because 6rd deployment), to allocated /29.
> This means that if we go for this policy, it will be justified to
> "upgrade" all the /29 allocations to a /28.

Hi,

I'm not sure I see the big benefit of upgrading to a /28 but on a
purely technical standpoint, "upgrading" is not possible in most cases
because RIPE NCC did not reserve a complete /28 for every LIR. So you
would end up with two /29 or you'd have to renumber your /29 to a new
/28.

Both options don't sound appealing to me.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
SCYTHE.
-- Terry Pratchett, The Fifth Elephant




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

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

Re: [address-policy-wg] inputs on possible policy proposal for IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Of course, in case it was not clear, I didn't want to mean "because ARIN did 
that, we should do the same as well". It was just a matter of providing context.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert 
Doering <g...@space.net>
Fecha: miércoles, 2 de mayo de 2018, 9:35
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: RIPE Address Policy WG List <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6

Hi,

On Wed, May 02, 2018 at 07:25:12AM -0500, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> ???As you probably know, ARIN amended some time ago their IPv6 policy 
proposal in order to make sure that the allocations to LIRs are aligned to the 
nibble boundary.

Speaking as a long-time IPv6 user, I see no real benefit in this.

Yes, a /29 means I have to set up 8 reverse DNS zones, instead of one.

Bummer.

And my IP management tool might need to learn about non-magic bit numbers
(but it will need to understand that anyway if I do reasonably-sized
internal suballocations, like "a /34 for a region" and not "a /36 because
the tool cannot do /34s").

"Just because ARIN does it" is also not a good reason to follow suit - 
like, "lots of people going for /36 allocations, because /32 is too
big and, priced-by-size, too expensive"...


(But this is strictly my *personal* opinion.  If there is sufficient 
support in the WG, I'll shepherd a corresponding proposal, of course)

Gert Doering
-- long time IPv6 allocation holder
-- 
have you enabled IPv6 on something today...?

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




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

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

Re: [address-policy-wg] inputs on possible policy proposal for IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Peter,

/48 is already in a nibble boundary, so no chance :-)

Despite that, initially I'm considering only the policy for IPv6 PA (LIRs/ISPs).

If the inputs provide a view that this should be the same for IPv6 PI, I've no 
issue in do that one as well, so in that case if you have previously justified, 
for example, a /47, you should automatically be able to get the /44.

However, if we believe that both should be proposed (nibble boundary for IPv6 
PA and nibble boundary for IPv6 PI) I think it will be better decoupled in 
separate policy proposals, to facilitate the discussion and possible consensus, 
and again no problem from my side to work on both.

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Peter 
Hessler <phess...@theapt.org>
Fecha: miércoles, 2 de mayo de 2018, 7:45
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] inputs on possible policy proposal for IPv6

On 2018 May 02 (Wed) at 07:25:12 -0500 (-0500), JORDI PALET MARTINEZ via 
address-policy-wg wrote:
:Hi all,
:
:As you probably know, ARIN amended some time ago their IPv6 policy 
proposal in order to make sure that the allocations to LIRs are aligned to the 
nibble boundary.
:
:In the context of another discussion in AfriNIC, Owen DeLong, suggested 
that we could do something similar.
:
:I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, 
LACNIC, APNIC), for that, but I will like to get some inputs before, and 
"sense" the feeling about that of the participants.
:
:Note that in the case of RIPE, we have a big difference with the other 
RIRs, because all them start with /32, while we updated our policy several 
years ago (because 6rd deployment), to allocated /29. This means that if we go 
for this policy, it will be justified to "upgrade" all the /29 allocations to a 
/28.
:

Using this justification, would that also grow all IPv6 PI /48s to a /44,
or only those that are not already at a nibble boundary?


:This is the example that Owen sent to the AfriNIC list:
:
:1. Figure out the number of end sites you expect to serve in your largest 
aggregation point
:   in 3-5 years.
:2. Round that to a nibble boundary (with a 25% minimum free space) (1-12 
end sites = 4 bits,
:   13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 
end sites = 16 bits,
:   49,153-786,432 = 20 bits, etc.)… Call this E.
:3. Figure out the number of aggregation points you expect to have in 3-5 
years. Round that up
:   to a nibble boundary with a 25% minimum free space (same as in step 2). 
Call this A.
:4. 48-(A+E) = prefix size.
:
:   Example: An ISP has 42,000 customers in it’s largest end site. It has 
128 end sites.
:   E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a 
/24.
:
:So, would you agree in doing something on this line?
:
:Thanks in advance for any inputs!
:
:Regards,
:Jordi
: 
: 
:
:
:
:**
:IPv4 is over
:Are you ready for the new Internet ?
:http://www.consulintel.es
:The IPv6 Company


-- 
Broad-mindedness, n.:
The result of flattening high-mindedness out.





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

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

[address-policy-wg] inputs on possible policy proposal for IPv6

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

As you probably know, ARIN amended some time ago their IPv6 policy proposal in 
order to make sure that the allocations to LIRs are aligned to the nibble 
boundary.

In the context of another discussion in AfriNIC, Owen DeLong, suggested that we 
could do something similar.

I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, 
LACNIC, APNIC), for that, but I will like to get some inputs before, and 
"sense" the feeling about that of the participants.

Note that in the case of RIPE, we have a big difference with the other RIRs, 
because all them start with /32, while we updated our policy several years ago 
(because 6rd deployment), to allocated /29. This means that if we go for this 
policy, it will be justified to "upgrade" all the /29 allocations to a /28.

This is the example that Owen sent to the AfriNIC list:

1.  Figure out the number of end sites you expect to serve in your largest 
aggregation point
in 3-5 years.
2.  Round that to a nibble boundary (with a 25% minimum free space) (1-12 
end sites = 4 bits,
13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 
end sites = 16 bits,
49,153-786,432 = 20 bits, etc.)… Call this E.
3.  Figure out the number of aggregation points you expect to have in 3-5 
years. Round that up
to a nibble boundary with a 25% minimum free space (same as in step 2). 
Call this A.
4.  48-(A+E) = prefix size.

Example: An ISP has 42,000 customers in it’s largest end site. It has 
128 end sites.
E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a 
/24.

So, would you agree in doing something on this line?

Thanks in advance for any inputs!

Regards,
Jordi
 
 



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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Kai,

 

Responses below, in-line.


Regards,

Jordi

 

 

De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Kai 
'wusel' Siering <wusel...@uu.org>
Organización: Unseen University, Department of Magic Mails
Fecha: martes, 17 de abril de 2018, 23:24
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment 
Clarification in IPv6 Policy)

 

Moin,

am 17.04.2018 um 16:51 schrieb JORDI PALET MARTINEZ via address-policy-wg:
I've also suggested the same text in the other 4 RIRs with equivalent policy 
proposal, because all them have the same problem.

>From my point of view, if there's a policy that's sound and valid for other 
>RIRs, they will adopt it over time. IF they struggle with similar issues 
>(which I frankly don't know).


Yes, I can confirm that in the other RIRs policy there is the same 
sub-assignment text as we initially had, so same issues.



The main point is to clarify the actual interpretation to make clear that it is 
allowed from up to a single /64, to use non-permanently, any number of 
addresses (not just a single one).

Above all, what exactly is unclear in "the actual interpretation" done by whom?


If you followed the previous discussion it was clear that actual policy text 
talks about a single address, but then the talks about /64 …



2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a 
hot-spot, with use multiple addresses (example, VMs) from a single /64, or the 
same situation if an employee brings any kind of device to the enterprise WiFi 
or wired network.

With "in a hot-spot" you refer to WiFi? The "assignment" of a specific prefix 
for a specific WiFi in all practical setups will be a permanent one — no-one 
rotates the /64s on their WiFi APs every other week or even year. So, as we're 
on a clarifying mission, what constitutes a) a "permanent" and b) a "[sub-] 
assignment"?


You’re confused here I think. We are talking about the address that get the 
customer of the hotspot, so what you get when you connect to that WiFi 
accesspoint. The access point may get a single /64 or may be is a router and is 
getting /56 so it has many /64s available to provisioning to each “customers” 
as per RFC8273 (for example).


ripe-699 tried to ensure that RIPE NCC does not "misinterpret" third parties 
getting leases (or, in the SLAAC case, just grabbing the MAC-based address) 
from a PI assignment as a "[sub-] assignment" of said address space. If the 
changed text actually will work as intended is yet to be seen — why the rush to 
change the policy text _again_?!

 

Because I don’t think it was a good change and I’d the option to appeal that or 
start a new proposal improving it.


It's my strong believe that adding more wording about what use isn't considered 
as a "[sub-] assignment" will only lead to more edge cases and more vague 
applications. 

 

I think in the other way around, we are making it clearer.

 
This means that I'm excluding the case of a data center allocating *permanent* 
/64 to server interfaces (non-permanent will be ok). Remember that 

I'm not a datacenter, but I run stuff in datacenters. Are you intending to 
forbid this use case? Are you actively trying to make PIv6 go away completely 
by disallowing any practical use?


No, this is not my intent. I’m asking the WG what they think on this (and I 
stated that my view may be wrong).

 
this is for PI, and my personal opinion on this is that, a datacenter, should 
be an LIR, so using PA.

A datacenter is a datacenter, an ISP is an ISP, and an End User is an End User; 
none of these are forced to become a LIR. Actually, PI, Provider Independent 
address space, can make much sense for an independent datacenter operator to 
run their infrastructure with — as well as for an ambitious End User.


Let’s see if the WG has that view as well. This is why I’m asking.


If an End User becomes an ISP, they still may use their PI address space for 
their infrastructure. The same applies to an End User or ISP who becomes a LIR 
... Please remember: »LIRs are generally ISPs whose customers are primarily End 
Users and possibly other ISPs.« It's not: »Any ISP must be a LIR in order to 
assign address space to their end users.« It's neither: »Anyone in need of IPv6 
address space must become an LIR.«

But let's review the suggested new policy text: »[…] The fact that a unique 
address or even a unique /64 prefix is non-permanently provided to third 
parties, on a link operated by the original receiver of the assignment, shall 
not be considered a sub-assignment.«

So, if I, as the assignment holder of PIv6 space, allocate a /64 for any of my 
family member's devices (e. g. a /64 for my gear, a /64 for my wife's and each 
kid's devices) for accountability (that is: legal) reasons, that's 
sub-assigning (again)? After all, 

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Sascha,

I see your point on the last sentence. The idea of that is avoiding someone to 
have the bright idea to use the point-to-point links to offer permanent service 
by means of "IPv6 NAT/NPT".

Maybe the wording is not the best. I just figured out an alternative one:

"The addressing of the point-to-point link can be permanent; however, it can't 
be used as an artifact to avoid provisioning IPv6 addresses to circumvent this 
policy."

May be the NCC can check if this make sense in english, or someone else can 
provide some other suggestions about how to say it, withou explicit mention to 
"IPv6 NAT/NPT" (which are just examples, as we could though in any way of 
"proxying", etc., and we prefer to avoid mentioning what technology ...).

Regards,
Jordi
 
 

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de "Sascha 
Luck [ml]" <a...@c4inet.net>
Fecha: martes, 17 de abril de 2018, 18:53
Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
CC: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment 
Clarification in IPv6 Policy)

    Hi Jordi,

On Tue, Apr 17, 2018 at 04:57:20PM +0200, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
>I've created an "online diff" so you can compare the actual text, with my 
proposal:
>
>https://www.diffchecker.com/SMXYO2rc

I have several issues with the proposal:

1) It perpetuates what may have been a good idea in 1990, viz the
PI/PA distinction, into IPv6. IMO it's long past time to stop
having special classes of addresses and to treat them as what
they are, numbers.

2) It looks a lot like micro-management, trying to make policy
for every edge case. Having said that, it seems to be necessary
as the NCC is using an unreasonable interpretation of existing
policy.

3) the last sentence of the policy text: 
"Only the addressing of
the point-to-point link itself can be permanent and that
addressing can't be used (neither directly or indirectly) for the
actual communication."
makes neither grammatical nor technical sense. 
for one thing, it's always "either/or" or "neither/nor" and
neither/nor mustn't be used after a preceding negative ("can't").
For the other, if this point-to-point assignment can't even *indirectly* be 
used
for communication, it can't be used for *anything* as traffic
from the downstream /64 would surely be routed via the
point-to-point link, thus using its addresses...

That said, I'd see no reason not to support the proposal *if*
that last sentence is removed (it's unneccessarily specific and
technically prohibitive)

Kind Regards,
Sascha Luck


>
>
>Regards,
>Jordi
>
>
>-Mensaje original-
>De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net>
>Responder a: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>
>Fecha: martes, 17 de abril de 2018, 16:52
>Para: <address-policy-wg@ripe.net>
>Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment 
Clarification in IPv6 Policy)
>
>Hi all,
>
>As you probably remember, during the discussion of the recently 
implemented 2016-04, I complained that we should not approve a policy proposal 
with a wording that creates (in my opinion), discrepancies between the NCC 
impact analysis and the policy text.
>
>I was suggested that it can always be improved ... so that's what I'm 
doing here.
>
>I've also suggested the same text in the other 4 RIRs with equivalent 
policy proposal, because all them have the same problem.
>
>The main point is to clarify the actual interpretation to make clear 
that it is allowed from up to a single /64, to use non-permanently, any number 
of addresses (not just a single one).
>
>So basically, what I'm saying is:
>1) Is not a sub-assignment a point-to-point (maximum a /64) even if 
this is permanent. However, the point-to-point can't be used as permanent 
addressing for "actual" transit (so you can't use the point-to-point addressing 
and then makeup an IPv6 NAT/NPT, or something similar for devices behind it).
>2) Is not a sub-assignment up to a /64 if non-permanent. Example a 
device in a hot-spot, with use multiple addresses (example, VMs) from a single 
/64, or the same situation if an employee brings any kind of device to the 
enterprise WiFi or wired network.
>
>This means that I'm excluding the case of a data center

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Max,

Thanks for the (quick) inputs!

To be honest, I was not sure that you also need that for your own case (or if 
you know other cases that need that).

I really think if you are a hosting/housing provider for third companies, you 
should become an LIR, but as said, this is only my personal view. Let's see 
what others believe.

By the way, it will be interesting to compare this with IPv4. Do we allow this 
case in IPv4? Or we need also a policy proposal to amend that?

Regards,
Jordi
 
 
-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de 
Maximilian Wilhelm <m...@rfc2324.org>
Fecha: martes, 17 de abril de 2018, 17:14
Para: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment 
Clarification in IPv6 Policy)

    Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit:

Hi,

> As you probably remember, during the discussion of the recently 
implemented 2016-04, I complained that we should not approve a policy proposal 
with a wording that creates (in my opinion), discrepancies between the NCC 
impact analysis and the policy text.
> 
> I was suggested that it can always be improved ... so that's what I'm 
doing here.
> 
> I've also suggested the same text in the other 4 RIRs with equivalent 
policy proposal, because all them have the same problem.
> 
> The main point is to clarify the actual interpretation to make clear that 
it is allowed from up to a single /64, to use non-permanently, any number of 
addresses (not just a single one).
> 
> So basically, what I'm saying is:
> 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this 
is permanent. However, the point-to-point can't be used as permanent addressing 
for "actual" transit (so you can't use the point-to-point addressing and then 
makeup an IPv6 NAT/NPT, or something similar for devices behind it).
> 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device 
in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or 
the same situation if an employee brings any kind of device to the enterprise 
WiFi or wired network.
> 
> This means that I'm excluding the case of a data center allocating 
*permanent* /64 to server interfaces (non-permanent will be ok). Remember that 
this is for PI, and my personal opinion on this is that, a datacenter, should 
be an LIR, so using PA.
> 
> This is an open question here, and I may be wrong.
> 
> So, what do you think on the overall proposal and specially in this last 
point (data center can be PI and then we should have a more complex text that 
allows that case)?

I like the overall thing, but I don't like the DC part (as you might
have guessed :)). My approach deliberately included housing/hosting as
you can read in the rationale and this is something I would like to
keep included for small hosters.

I think the argument of scale applies here. Having only a /48 for your
DC including your own infrastructure and some customer stuff won't get
you far (if you don't ignore RFCs and BCPs). So for me this would be
fine. If you grow, become an LIR, get a /29, be happy, everyone is
happy.

Best
Max
-- 
The real problem with C++ for kernel modules is:
the language just sucks.
-- Linus Torvalds





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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

As you probably remember, during the discussion of the recently implemented 
2016-04, I complained that we should not approve a policy proposal with a 
wording that creates (in my opinion), discrepancies between the NCC impact 
analysis and the policy text.

I was suggested that it can always be improved ... so that's what I'm doing 
here.

I've also suggested the same text in the other 4 RIRs with equivalent policy 
proposal, because all them have the same problem.

The main point is to clarify the actual interpretation to make clear that it is 
allowed from up to a single /64, to use non-permanently, any number of 
addresses (not just a single one).

So basically, what I'm saying is:
1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is 
permanent. However, the point-to-point can't be used as permanent addressing 
for "actual" transit (so you can't use the point-to-point addressing and then 
makeup an IPv6 NAT/NPT, or something similar for devices behind it).
2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a 
hot-spot, with use multiple addresses (example, VMs) from a single /64, or the 
same situation if an employee brings any kind of device to the enterprise WiFi 
or wired network.

This means that I'm excluding the case of a data center allocating *permanent* 
/64 to server interfaces (non-permanent will be ok). Remember that this is for 
PI, and my personal opinion on this is that, a datacenter, should be an LIR, so 
using PA.

This is an open question here, and I may be wrong.

So, what do you think on the overall proposal and specially in this last point 
(data center can be PI and then we should have a more complex text that allows 
that case)?

Thanks!

Regards,
Jordi
 
 
-Mensaje original-
De: address-policy-wg  en nombre de Marco 
Schmidt 
Fecha: martes, 17 de abril de 2018, 15:55
Para: 
Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment 
Clarification in IPv6 Policy)

Dear colleagues,

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

This proposal aims to clarify the definition of “Assign” in ripe-699 
(section 2.6). The non-permanent provision of up to a /64 prefix to third 
parties shall not be considered a sub-assignment.

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

As per the RIPE Policy Development Process (PDP), the purpose of this four 
week Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposer, with the agreement of the 
WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 15 May 2018.

Regards,

Marco Schmidt
Policy Officer
RIPE NCC 

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





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

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

Re: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Janos,

I will be in favor of this policy proposal if it means that those LIRs are 
going to contribute to gym cost for end-users (non-LIRs). Have you thought 
about that?

Regards,
Jordi
 
-Mensaje original-
De: address-policy-wg  en nombre de Janos 
Zsako 
Fecha: domingo, 1 de abril de 2018, 18:46
Para: "address-policy-wg@ripe.net Working Group" 
Asunto: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 
allocations from the last /8

Dear all,

Several existing and potential LIRs have complained about the fact that a 
/22 may not be
enough for starting an Internet service. While there is a general agreement 
that this
allocation size should not be changed during the last /8 policy, it may be 
useful to
make some exceptions in some properly justified cases.

There is also a general agreement that people should take care of their 
health, they
should eat healthy food and do sufficient physical exercise, possibly by 
going regularly
to the gym.

I have thought of a possibility to allocate up to a /20 from the last /8 
pool to the
companies that can prove that they encourage and help their employees to 
take care of
their help, and that the employees themselves do take advantage of these 
possibilities.

I already have a couple of initial suggestions for consideration, like the 
average
number of hours of workout per employee per week, the average Body Mass 
Index
(https://en.wikipedia.org/wiki/Body_mass_index) per employee, and a couple 
of similar
good ways of measuring the health status at the company. I also though that 
computing
a simple average may disadvantage larger companies, therefore some formula 
taking into
account the size of the different departments and the values measured there 
could be
worked out, similar to the HD ratio used in determining the address 
utilisation
(https://www.ripe.net/publications/docs/ripe-699#hd_ratio). This could make 
the proposal
more fair to large enterprises. There is, however, quite some work to be 
done to make
these ideas properly implementable.

I think we should set up a small task force to determine the criteria such 
LIRs should
meet. The time is pressing, we have to act quickly in order to be able to 
discuss the
proposal in Marseilles. Anyone who volunteers for the Task Force should 
contact me
ASAP. We can then come up with a formal proposal and present it to the 
working group,
by following the formal steps of the PDP.

I am looking forward to being contacted by the volunteers.

Best regards,
Janos

PS: I am sure some people, when they hear about a new policy proposal for 
IPv4, they
will come up with the usual argument that this is like arranging the deck 
chairs again.
I have to mention, however, that the latest scientific research proved that 
the sinking
of the Titanic could have been delayed by several hours if the deck chairs 
were properly
arranged in due time. Therefore, this proposal may also contribute to a 
better Internet
on the long run.

PS2: To those who had the patience to read this e-mail I wish a Happy 1 
April!





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

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

Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)

[JORDI PALET MARTINEZ via address-policy-wg]

Thanks Gert!

Further, having no inputs removes all the fun of the PDP!

In case you missed previous emails, to make it easier for you to comment, I've 
prepared an on-line diff so you can easily track the proposed changes:

https://www.diffchecker.com/2mGPoRbo

Also, the complete text of the proposal is here:

https://www.ripe.net/participate/policies/proposals/2018-01

Now folks don't have any excuse to not comment ;-)


Regards,
Jordi
 
-Mensaje original-
De: address-policy-wg  en nombre de Gert 
Doering 
Fecha: lunes, 19 de marzo de 2018, 16:48
Para: Marco Schmidt 
CC: 
Asunto: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR 
Clarification in IPv6 Policy)

Dear AP WG,

On Thu, Feb 22, 2018 at 03:34:25PM +0100, Marco Schmidt wrote:
> A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in 
IPv6 Policy" is now available for discussion.

This policy proposal was prompted by the discussion at the last RIPE
meeting, where the NCC brought up the issue that the IPv6 allocation policy 
talks about "organization" without ever defining what that is - "one LIR
account", "one legal organization" (which can hold multiple LIR accounts),
etc.

Jordi volunteered to clean up the text, and here's the proposed changes
- but without some feedback from *you*, we can't clean this up.

[..]
> We encourage you to review this proposal and send your comments to 
 before 23 March 2018.

Thus: feedback please.

Like

  - "the text matches the original intent as I have always understood the
policy, and we should go there"
  - "this is not my understanding of the original policy, because ..."
  - "never touch a working policy!"
  - "I do not see this as a big problem, but the new text works for me"

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

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




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

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

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

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert, all,

I agree with your summary, and also understand the point that is better to have 
"something" now and improve it.

In fact, yesterday I expressed the same view in anti-abuse, even against my 
previous opinion that we should do it "right" in a single "step".

Consequently, in view of improving this now "adopted" policy, this afternoon I 
will work on this a submit a possible improvement proposal to it.

I think I will also consider sending a proposal for update this PDP detail.

Thanks!

Regards,
Jordi
 
-Mensaje original-
De: address-policy-wg  en nombre de Gert 
Doering 
Fecha: viernes, 16 de marzo de 2018, 15:13
Para: Marco Schmidt 
CC: 
Asunto: Re: [address-policy-wg] 2016-04 concluded (IPv6 Sub-assignment 
Clarification)

Dear AP WG,

On Mon, Jan 15, 2018 at 11:59:19AM +0100, Marco Schmidt wrote:
> Proposal 2016-04, "IPv6 Sub-assignment Clarification", is now in 
Concluding Phase.
[..]
> Any objection must be made by 13 February 2018 and must be supported by 
an explanation.
> 
> If no substantive objections are raised by the end of Last Call, the 
proposal will complete the PDP and will be evaluated by the WG Chairs for 
consensus.


There was quite a bit of discussion in the Last Call, which is unusual,
and led to some more discussions between Marco, Sander and me how to
evaluate these.

We've decided that there is rough consensus to go forward and implement
the policy, because the discussions raised did not bring in new objections
to the policy itself, or issues with the policy process being followed(*).

So, the NCC will start implementing the proposal next week.


That said, some good points were raised

 - Kai Siering reminded me that I need to be a bit less sloppy when 
   summarizing objections raised - I should have spent a few more words
   pointing to the fact that the NCC's interpretation of the existing
   IPv6 PI policy has been brought up number of times (by the NCC RS)
   to the APWG, explaining why they interpret the "no sub-assignment"
   clause the way they are, and asking for guidance from the WG - which,
   at no point, brought up the response "single addresses by RA are good!"
   (so while the WG wasn't fully happy with the *outcome*, nobody challenged
   the *interpretation*)

 - Jordi Palet found a mismatch between IA and policy text, and there was
   discussion about interpretation of policy text, policy intent, and IA
   when in doubt.  Which is, undoubtly, quite a burden for new applicants
   to figure out what "is OK" and "what is not OK" - so the NCC volunteered
   to write a guidance page with examples to help explain in more words and 
   easier terms.  Of course I'll expect the working group to scrutinize 
   this page very thoroughly :-)

 - Jordi Palet also brought up the issue that the PDP does not have an
   "the WG chairs decide to extend the review phase" arrow in its state
   diagram - it does not.  Formally, one would need to close the review
   phase, declare "not enough input", declare "the next version of the 
   policy proposal has the same text, and we solicit input *again*", and
   start a new review phase.  Which is lots of overhead, so we've been
   doing this ("this" being "extend a phase *if not enough input received*")
   for many years now.

   (Incidentially, the anti-abuse WG had to do the same thing for their
   current 2017-02 proposal - "not enough clear guidance to declare a
   result either way", thus, "extend")


As soon as this is formally incorporated into the new policy text, I
welcome a new round of discussion about the IPv6 PI policy (as stated in 
the review phase) - ideally, with no formal text to start with, but as a
real *discussion* on "where do we want to go?".  Formal policy text can
come afterwards after there is some sort of rough agreement on the general
direction.

I'll reserve time for this on the agenda for Marseilles.

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

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




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

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized 

Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy)

[JORDI PALET MARTINEZ via address-policy-wg]

Thanks Marco!

To make it easy, I've prepared an online diff.

https://www.diffchecker.com/2mGPoRbo

Red color is actual text. Green is the proposed one.

Regards,
Jordi
 
-Mensaje original-
De: address-policy-wg  en nombre de Marco 
Schmidt 
Fecha: jueves, 22 de febrero de 2018, 15:34
Para: 
Asunto: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR 
Clarification in IPv6 Policy)

Dear colleagues,

A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in 
IPv6 Policy" is now available for discussion.

This proposal aims to clarify the wording used in ripe-684 regarding terms 
such as "organisation" and "LIR".

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

As per the RIPE Policy Development Process (PDP), the purpose of this four 
week Discussion Phase is to discuss the proposal and provide feedback to the 
proposer.

At the end of the Discussion Phase, the proposers, with the agreement of 
the WG Chairs, will decide how to proceed with the proposal.

We encourage you to review this proposal and send your comments to 
 before 23 March 2018.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC 

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





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

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