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

[Elvis Daniel Velea]

Hi Leo,

the […] you conveniently cut out from Randy’s e-mail does not look like a
proper call for volunteers and I bet that’s what Randy was pointing to.

Alex is very suited for the job (*) and he has my +1, but maybe you could
do the right thing as Randy suggested and do a proper call for volunteers so
we can all vote Alex in following the right process.

Elvis

* while I was his colleague at the NCC, Alex ran the PICG (Policy
Implementation and Coordination Group) within the NCC and implemented the
Impact Analysis into every policy proposal. Naming just two things (out of
hundreds) that make him more than just qualified to be an AP-WG Co-Chair


This message was sent from a mobile device. Some typos may be possible.


On Tue, Nov 28, 2023 at 8:15 AM Leo Vegoda  wrote:

> Hi Randy,
>
> On Tue, 28 Nov 2023 at 16:44, Randy Bush  wrote:
>
> [...]
>
> > that looks more like "we do not seek volunteers," and a strong singal
> > discouraging new blood.
> >
> > fwiw, i an a long term alex fan.  but i have enough german ancestry to
> > be over fond of process.  we really need to be careful of unintentional
> > gatekeeping.
>
> We called for volunteers in September. So far we have had one, Alex.
> He will present himself tomorrow. The WG will decide at RIPE 88.
>
> Kind regards,
>
> Leo
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
-- 

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

Re: [address-policy-wg] Consensus - 2023-02 - Minimum Size for IPv4 Temporary Assignments

[Elvis Daniel Velea]

on behalf of the authors we also thank you Leo, co-chairs and PDO for all
of your support.

elvis
co-author

On Mon, Jul 17, 2023 at 15:36 Leo Vegoda  wrote:

> Dear Working Group,
>
> No objections were raised during the Last Call phase. The community
> has achieved a consensus.
>
> The RIPE NCC can proceed with implementation.
>
> Our thanks to everyone who contributed to this discussion.
>
> Kind regards,
>
> Leo Vegoda, for the Address Policy WG co-chairs
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

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

[Elvis Daniel Velea]

Hi,

I remember talks about large communities in the late 2000s, I see that they
have only been standardized in 2017, a mere 6 years ago.. so the question
stands, although the exageration can be reduced to.. how many decades does
Mikrotik need to support it? :)

I’ve gone off rails, let’s see what Marco says and if it makes sense to
actively chase returns of unused 16bit ASNs.

elvis

On Mon, Jun 12, 2023 at 1:46 AM Gert Doering  wrote:

> Hi,
>
> On Mon, Jun 12, 2023 at 01:38:58AM -1000, Elvis Daniel Velea wrote:
> > I mean, 32bit ASNs have been around since 2007, do they need 25 years or
> > maybe 100 to code software/firmware that supports all numbers?
> >
> > /rant
>
> I welcome you to read up on "BGP camel"...
>
> (Note that this is not about "32 bit ASN" but about "large communities",
> which were only standardized a few years ago)
>
> 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
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

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

[Elvis Daniel Velea]

could this community convince Mikrotik to develop firmware to support all
the internet numbers (and not just the convenient ones) ? do we have anyone
from Mikrotik in this mailing list to explain what is stopping them from
developing software that supports BGP LC?

I mean, 32bit ASNs have been around since 2007, do they need 25 years or
maybe 100 to code software/firmware that supports all numbers?

/rant

elvis

On Mon, Jun 12, 2023 at 1:22 AM Gert Doering  wrote:

> Hi,
>
> On Mon, Jun 12, 2023 at 11:41:06AM +0100, Nick Hilliard wrote:
> > Gert Doering wrote on 12/06/2023 11:34:
> > > How would you translate this into "generic 32bit AS number usability"?
> >
> > this wasn't a comment about IXPs: many smaller organisations have
> > mikrotiks running with bgp on service provider networks, but are unable
> > to run BGP LC because of lack of support.
>
> Yes.  But what are - or should be - the consequences of this?
>
> Add a note to the long list of "Mikrotik leaves to be improved" and go on?
>
> 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
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

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

[Elvis Daniel Velea]

Hi Nick,

On Mon, Jun 12, 2023 at 00:25 Nick Hilliard  wrote:

> Elvis Daniel Velea wrote on 11/06/2023 10:06:
> > If someone could tell me why a 32bit ASN can not be used today (even
> > with 10 years old equipment), I’d appreciate it.
>
> there's plenty of kit out there which still doesn't support BGP Large
> Communities, particularly mikrotik routeros which only released an
> initial production implementation at around the beginning of 2022.
>
> Nick


thanks for that. I’m surprised to hear this, but heh, manufacturers can be
slow sometimes… very slow :(

It may, then, matter to some if an ASN is 16bit or not. I know that the NCC
had at some point (maybe still do) assigned 16bit ASNs upon request.
Curious to see some stats, if possible:
- how many requests come in for 16bit a year? how many are those of the
total ASN requests?
- how many 16bit ASNs are still in the pool and how many come back to the
free pool every year?

Just trying to see how many years until 16bit ASNs could only be issued by
the NCC only if returned.

On another note, I believe that there were a lot of 16bit ASNs in
quarantine because of references in various objects (mostly as-sets if I
recall correctly). Can you tell us, Marco, how many of those ASNs are
quarantined and why aren’t these removed out of quarantine and assigned?

elvis

-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

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

[Elvis Daniel Velea]

Hi Marco, everyone,

my take would be as follows:

The RIPE NCC could just send automated monthly/quarterly messages to ASN
holders if the ASN has not been seen in the global routing table for more
than 3/6/12 months. We could agree to this on the mailing list and this
could be a process and not necessarily a new policy proposal, this process
could also be adjusted every few years if needed.
Just notifications, no other follow-up or requests for return. I’d see the
message say something like: “ you received an ASN x months ago, this ASN
has not been seen in use in the global routing table for at least 3/6/12
months. You can return it if you do not have any plans to use it.  Just
reply to this message and we’ll return it to the free pool. You can always
come back and request an ASN from the RIPE NCC, should you have plans to
use one.” The message would also include how it is good stewardship both by
the RIPE NCC and the ASN holder to keep a clean registry by returning an
unused ASN to the free pool.

To be honest, in today’s environment, I don’t see why a differentiation
between 16bit and 32bit ASNs still exist. If someone could tell me why a
32bit ASN can not be used today (even with 10 years old equipment), I’d
appreciate it.

Also, I do agree that a clean registry is a priority for the NCC and the
community but I think work (FTEs) should be invested in this project only
for the part where the holder wants to return it and some work needs to be
done.

In the number transfer world, low number ASNs are worth ‘more’ due to them
being considered vanity numbers. However, I find it silly today to have
different policies, restrictions or processes for 16bit vs 32bit ASNs.

my 0.2c

Elvis

On Thu, Jun 8, 2023 at 22:25 Marco Schmidt  wrote:

> Dear colleagues,
>
> Thank you for the feedback received so far.
>
> As Aleksi noted, there are indeed valid reasons why ASNs seem to be
> unused. We have some data on this from our AS Number Clean up project.
> When asked if the resource is being used, about 2/3 of ASNs have been
> returned, about 1/3 are expected to be used soon, and only a very small
> number have been used by transit providers or IXPs.
>
> Of the more than 8,000 ASNs not visible in the routing system, about 52%
> are 16-bit ASNs.
>
> As mentioned by Kaj, the members of RIPE NCC clearly voted against
> charging for ASNs. So we wanted to ask this working group if there are
> other ways to improve the situation?
> Something that falls under the authority of the RIPE community, such as
> developing RIPE policies or guidelines for Registration Services.
> For example, are you in favour of us being more active in trying to
> clarify the status of ASNs that seem to have been unused for a long
> period of time?
>
> Kind regards,
>
> Marco Schmidt
> Manager Registration Services
> RIPE NCC
>
> On 08/06/2023 16:55, Nick Hilliard wrote:
> > Marco Schmidt wrote on 08/06/2023 14:30:
> >> We also plan to intensify our ongoing project to clean up unused
> >> Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have
> >> been recovered as part of this work so far. Do you support our
> >> approach here? And are there other ways we could improve the
> >> situation? Perhaps you could add clarification on requesting and
> >> returning ASNs in the relevant RIPE policy, or maybe we could give a
> >> stronger mandate and responsibility to the sponsoring LIRs.
> >
> > Hi Marco,
> >
> > There are good reasons to clean up unused ASN16s, as they are
> > categorised by policy as scarce resources. There isn't a compelling
> > reason to get as excited about ASN32s, other than to say that normal
> > good stewardship practices should apply.
> >
> > Unfortunately there is a disconnect between RIPE policy and RIPE NCC
> > practice in regard to charges for ASNs. This is a real shame because
> > paying for resources is one of the simpler ways of creating positive
> > pressure to return them if they're unused. The community would benefit
> > from the board re-thinking this.
> >
> > Nick
>
> --
>
> 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
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

Re: [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments)

[Elvis Daniel Velea]

Hi Massimo,

thank you for your message. Let me see if I have an answer to some of your
questions/comments. See inline.

On Tue, Mar 7, 2023 at 11:13 Massimo Candela  wrote:

> Hi all,
>
>
> I added in cc the MAT mailing list, which is frequented by researchers.
> I believe that is the right audience for this proposal.
>
>
> @MAT: Support for this proposal should be expressed before this Friday
> (March 10). See proposal below. Reply by keeping both list.
>
>
>
> @Addres-policy: I support this proposal.
>
>
thank you for your support.


> ---
> I also mention below a variation of this proposal, which could be it's
> own proposal/thread (suggestions welcome):
>
> There should be an easy way to do "temporary assignments" (which may or
> may not be the correct term in this case) to researchers/developers,
> starting from address space of a company which is "sponsoring" the
> research.
>
>
> The key part of what I would like to have is the possibility to provide
> somebody with access to LIR portal services but limited to a specific
> subset of my resources.
>
> In general, a company is not going to support a research/experiment by
> providing indiscriminate access to the LIR portal. Creating a new LIR or
> transferring prefixes is not a plausible solution in this context.
>

An existing LIR can do an assignment to a researcher/developer as we speak.
All assignments an LIR makes are ‘temporary’, some may last a day and some
may last 10 years…

If you want the researcher to have access to services like RPKI, they can
ask their LIR. In some cases, maybe temporary transfers could also be of
use.

Note that this proposal aims to update the temporary assignment proposal
that is currently in place. The RIPE NCC makes these temporary assignments
from a pool of IPs they have reserved specifically for this purpose.


> Also, I believe this would remove the need for an approval procedure
> from the RIPE NCC side: (1) if the address space used is of a company,
> there is less need to validate the research project motivations; and (2)
> the company "sponsoring" is also the one responsible for the address space.
>

I am not sure I understand what you mean by this. The NCC does not need to
approve any assignments made by LIRs. The NCC will need to approve
temporary assignments if the request is sent by an LIR (for an end-user)
based on the current temporary assignment policy.

Elvis


> Ciao,
> Massimo
>
>
> On 27/02/2023 16:44, Leo Vegoda wrote:
> > Hi,
> >
> > We've not had any feedback on this proposal yet.
> >
> > As a reminder, this proposal would set "the minimum assignment size to
> > a /24 while still allowing for a smaller assignment if requested by
> > the End User. This policy proposal also allows routing requirements to
> > justify the request for more than a /24 for research purposes."
> >
> > Support for the proposal, or arguments against it are welcome.
> >
> > Many thanks,
> >
> > Leo Vegoda
> > Address Policy WG co-chair
> >
> > On Thu, 9 Feb 2023 at 00:26, Angela Dall'Ara  wrote:
> >>
> >> Dear colleagues,
> >>
> >> A new RIPE Policy Proposal, 2023-02, "Minimum Size for IPv4 Temporary
> >> Assignments"
> >> is now available for discussion.
> >>
> >> This policy proposal recommends setting the minimum assignment size for
> >> temporary assignments to a /24 while still allowing for a smaller
> >> assignment if requested by the End User. This policy proposal also
> >> allows routing requirements to justify the request for more than a /24
> >> for research purposes.
> >>
> >> You can find the full proposal at:
> >> https://www.ripe.net/participate/policies/proposals/2023-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 proposers.
> >>
> >> At the end of the Discussion Phase, the proposers, with the agreement of
> >> the WG Chairs, will decide how to proceed with the proposal.
> >>
> >> The PDP document can be found at:
> >> https://www.ripe.net/publications/docs/ripe-781
> >>
> >> We encourage you to review this proposal and send your comments to
> >> address-policy-wg@ripe.net before 10 March 2023.
> >>
> >>
> >> Kind regards,
> >>
> >> Angela Dall'Ara
> >> Policy Officer
> >> RIPE NCC
> >>
> >>
> >> --
> >>
> >> To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/address-policy-wg
> >
>
> --
>
> 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
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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] Maximum size for current IPv4 allocations

[Elvis Daniel Velea]

hi,

On Mon, Aug 15, 2022 at 01:41 Bogdan Rotariu  wrote:

>
> On Aug 15, 2022, at 11:19, Ronald F. Guilmette 
> wrote:
>
> In message <301e0ef8-ed15-67d3-d390-7bea8571c...@ripe.net>,
>
> Marco Schmidt  wrote:
>
> On 15/08/2022 09:16, Gert Doering wrote:
>
> Hi,
>
>
> On Mon, Aug 15, 2022 at 12:10:49AM -0700, Ronald F. Guilmette wrote:
>
> What is the maximum size for current new IPv4 allocations in the RIPE
>
> region?
>
> /24  "if there is something to distribute at all"
>
>
> Just to confirm what Gert said.
>
>
> For more information please feel free to check our website about IPv4
>
> https://www.ripe.net/manage-ips-and-asns/ipv4
>
>
> as well the underlying RIPE policy which was published in November 2019
>
> https://www.ripe.net/publications/docs/ripe-733#51
>
>
> Thank you for the confirmation.  Unfortunately, I remain rather mystified
> by how the following IPv4 blocks, and the current RIPE WHOIS records that
> pertain to them, comport with what you and Gert have just now told me.
> Perhaps there is something that I am missing (?)
>
> ORG-AS976-RIPE:
>
> 31.44.32.0/20  created: 2022-06-24T06:46:34Z
> 46.21.16.0/21  created: 2022-06-24T06:46:34Z
> 46.21.28.0/22  created: 2022-06-24T06:46:34Z
> 77.220.64.0/19 created: 2022-06-23T09:56:04Z
> 185.155.176.0/22   created: 2022-06-23T09:56:04Z
> 185.155.184.0/22   created: 2022-06-24T06:46:34Z
> 193.221.216.0/23   created: 2022-06-24T06:46:33Z
> 193.222.104.0/23   created: 2022-06-24T06:46:33Z
>
>
> Regards,
> rfg
>
>
> P.S.  I would still be concerned, although perhaps a bit less concerned, if
> this organisation had not elected to place a fradulent and non-existant
> comnpany name into its public WHOIS organisation: record.  I would however
> still remain befuddled by how this organisation managed to be assigned
> some 72 times as much IPv4 address space as anybody else could get, all
> apparently less than 2 months ago.
>
> But there must be a reasoable explanation, I suppose.
>
>
when the RIPE NCC processes a transfer and needs to split a block, all the
smaller blocks that are transferred from the original large block will have
the date of the transfer as creation date

/elvis


>
> There is, those are transfers, check them here
> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics
> --
>
> 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
>
-- 
This message was sent from a mobile device. Some typos may be possible.
-- 

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

[Elvis Daniel Velea]

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"  address-policy-wg@ripe.net> 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] Contact details for End Users in the RIPE Database

[Elvis Daniel Velea]

Hi everyone,

On 4/16/19 05:18, ripedenis--- via address-policy-wg wrote:

Colleagues

Someone has kindly referred me to the conversation you had last 
November on this same paragraph 6.2. It's not surprising that there is 
some reluctance to discuss it again. BUT this is a different 
discussion. Last time you focussed on defining what type of network 
needs to be separately registered in the RIPE Database. I want to 
discuss the next step from that. Once you have decided a type of 
network needs to be separately registered then what information about 
that network needs to be entered into the RIPE Database?


Denis, I believe that the first e-mail sent by you was inviting the 
community to start a conversation. Furthermore, I believe that NOW is 
the right time to have this discussion and clarify what is required by 
policy (and maybe look at updating those policies as well) and put it in 
writing in a new privacy policy.


While GDPR is already in effect, the RIPE Database contains millions of 
contact details of private persons. Some ISPs currently use the RIPE DB 
as their customer database and register every single assignment they 
make to organisations or people. I doubt any of the people used by the 
ISPs as admin-c or tech-c in assignments actually know that their 
private data is made public in the RIPE DB. Lastly, and this can be 
fixed easily if we all ask for it, the RIPE NCC is creating every month 
hundreds of objects that contain personal details with the registration 
of new LIRs. The current state requires an update of policies and 
processes and can not continue like this much longer.


I doubt that everyone that has a person object (containing personal 
details - phone, e-mail, address, etc) in the RIPE Database even knows 
about their personal data being public. I also doubt that every person 
that registers a new LIR knows that their personal details will be 
published in the RIPE Database and made publicly available. There are 
several million person objects in the RIPE Database that (I believe) 
should have been deleted once GDPR kicked-in _or_ all of those persons 
should have been asked to confirm that they accept to have their private 
information made public in the RIPE Database.


To quote Peter Hessler "I am *not* happy for that data to be published 
widely on the internet, so I have censored them on purpose" - this is 
one way to hide personal details, many other companies/people have 
chosen to censor or provide less than accurate details.


Jan Ingvoldstad wants to see a better usable abuse contact information. 
This is one of the details that we are asking for. We are trying to make 
a list of contact information you all would like to see registered in 
the RIPE Database for resource holders and the questions in Denis' 
initial e-mail were supposed to start and steer the conversation into 
finding exactly those details - to then clarify and define where that 
information should be stored (role object, org object, maintainer, etc)


Michiel Klaver had an interesting idea "Maybe make more use of the 
'role'-objects? Within organisations people come and go, while their 
departments responsible for network operations and abuse keep rolling. 
Listing a department as role and using a shared e-mail address would 
reduce the ever increase of new person-objects in the database." and I 
believe that the use of the role objects should trump the use of the 
person object.


I personally believe that we should remove the person object from the 
RIPE Database and use roles/organizations/maintainers/etc instead.




I will come straight to the point, which should be controversial 
enough to start a discussion :) MY interpretation of the wording in 
6.2 is that the policy, as written, requires an ORGANISATION object to 
be created for these End Users if you register their network in the 
RIPE Database.


Let me explain my reasoning for this interpretation. The policy refers 
to the End User as either an individual or an organisation. In other 
words the End User is the '(legal) entity' that operates the network. 
Just as the LIR is the (legal) entity that holds the allocation 
resource. So when the policy requires the contact details of the End 
User, it is requiring the contact details of this operating entity. 
That is not the "xxx-c" attributes in the INETNUM object, it is an 
ORGANISATION object details.


I believe that first we need to decide what kind of data must be 
published in the RIPE Database and then decide in which objects to store 
that data - be it an organisation object, admin-c/tech-c/abuse-c, or a 
role object.


Once this is clear, we can amend current policies or propose a privacy 
policy and reference it in the other policies.





This takes us back to the long running discussion we had with 
"abuse-c:" where many members refused to create separate ORGANISATION 
objects for End Users just to add an "abuse-c:" for them. But as it is 
currently written, this is 

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

[Elvis Daniel Velea]

Gert,

while this was more of a cosmetic change and while this proposal did 
have support an no objections, I think that 4-5 e-mails of support 
should have at least required an extended discussion/review phase.


Especially since in last call nobody said a word.

my 2 cents.

Elvis


On 8/29/18 14:32, Gert Doering wrote:

Hi,

On Wed, Aug 29, 2018 at 07:20:07AM +0300, Aleksey Bulgakov wrote:

But is there any reasons to comment something? We did it for 2015-01, but
you declared consensus.

The mail where I declared consensus had a summary and detailed reasoning
why decisions were made.  That certain people did not like 2015-01 because
it broke their business model of requesting and quickly selling off /22s
is understandable, but that was the whole point of the change - so yes,
the community ignored those complaints.

You know quite well that the WG chairs look very closely at the discussion
and see if there is enough support to call it "rough consensus" or not
(and either send the proposal back, or extent the discussion/review phase)

Gert Doering
 -- APWG chair

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

[Elvis Daniel Velea]

Hi Jordi,

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

> On Nov 8, 2017, at 02:20, JORDI PALET MARTINEZ  
> wrote:
> 
> b. Arguments Opposing the Proposal
> It can be argued that this proposal could increase the number of PI request 
> to RIPE NCC.
> 
> Mitigation/counter-argument: This is not an issue and should not be 
> considered as a “bad-effect”.
> 
> The resulting policy could be used to circumvent the allocation policy, 
> avoiding creating a LIR.
> 
> Mitigation/counter-argument: This seems not to have sense as there must be a 
> justification process anyway, and because the starting point is /48, an ISP 
> willing to connect customers, will really want to be an LIR. Furthermore, if 
> we want to be restrictive on this, we could add a limitation that the maximum 
> sub-assignment can be /64.

how about... if we want to be restrictive - instead of limiting the size of the 
prefix, we limit the number of sub-assignments one can make from a PI?

elvis

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

[Elvis Daniel Velea]

Hi,

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

> On Nov 8, 2017, at 02:41, Gert Doering  wrote:
> 
> Hi,
> 
>> On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote:
>> Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) 
>> (that's music?)
> 
> Thanks.
> 
> So, basically, we have two possible approaches here:
> 
> proposed by Max (active proposal): 
>  keep the IPv6 PI policy as somewhat restrictive, trying to find wording 
>  that permits "some generally accepted" use-cases where other people's 
>  devices can get numbers from someone's IPv6 PI block
> 

I agree with Jordi. This is just a patch. This community can do better. 

> or, 
> 
> proposed by Jordi (new direction):
>  completely remove the restrictions on "letting other people use parts 
>  of someone's IPv6 PI block"
> 

much better, I would support

elvis

> 
> both would work to solve the (real) problem at hand, and Jordi's approach
> would certainly much easier than trying to come up with unambiguous wording
> to "permit some, disallow other" use cases.
> 
> Thanks for your proposal, and now let's see what the community wants :-)
> 
> Gert Doering
>-- APWG chair
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

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

[Elvis Daniel Velea]

Hi James,


On Tue, May 2, 2017 at 1:49 PM Kennedy, James <jkenn...@libertyglobal.com>
wrote:

> Hi Elvis Daniel, All,
>
> Though I would like to read the Impact Analysis before committing, I am in
> general support of this policy change. Improving transparency of basic IP
> transfer data is a good thing for the community for the aforementioned
> reasons. Particularly to improve the accuracy of transfer activity stats,
> trends and analysis.
>

thank you for your support. I hope that the IA will convince you to provide
your strong support to this policy proposal.


>
> And I like that LRHs are not forced to opt-in, though there will be a
> clear incentive to do so in order to have a LR transfer verified by the
> RIPE NCC.
>

I expected to see opposition from the LRHs if this proposal would have
included any limitations. That is why, on purpose, this policy proposal
does not limit any of the rights of the LRHs.

Kind regards,
Elvis


>
> Regards,
> James Kennedy
>
-- 
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: el...@v4escrow.net
Mobile: +1 (702) 970 0921

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

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

[Elvis Daniel Velea]

Hi,


On 4/27/17 11:57 AM, Carlos Friacas wrote:


On Wed, 26 Apr 2017, Elvis Daniel Velea wrote:

[...]
The way I see it, this policy proposal does not add extra 
requirements, it adds an extra service.


Which is exactly?

Transfer services according to the transfer policy.

and who will benefit from it?

the whole community

- only LRHs?

LRH will have the option to register the transfer.

- the whole community?

the community will see better stats on how much is transferred.

- non-LRHs?

non-LRHs who want to purchase a LR will have the confirmation of the 
RIPE NCC that the IP block transfer has been verified by a third-party 
(the NCC)


 I think protection (or just better alarms in place!) for Legacy 
address
 space is a good thing, however, i'm not sure an extra workload for 
the NCC
 and the LRH in the case they want to transfer their asset(s) is the 
way to

 go.
the extra workload is a document signed by the representatives of the 
two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind 
of documents on a daily basis so I doubt that would be a whole lot of 
extra workload - they will confirm during the Impact Analysis.


Sure. And what would exactly configures a failed verification?
A representative not having the proper authority to sign on behalf of 
the LRH. Or someone that has the maintainer password pretending to act 
on behalf of the LRH and trying to hijack the resource.




 I also agree with Sascha Luck's previous comment about LRH having to
 submit to an extra verification process.
As mentioned in my response to Sascha's e-mail, the LRH can and will 
still be able to update their objects in the RIPE Database even 
without any document signed.


You mean the "selling LRH"...?

yes
If my memory doesn't fail me, there are already some words about 
transfers on the current services' policy -- i need to double-check that.
LRH can be updated to point to an other company but a transfer in the 
real sense would only be confirmed once the RIPE NCC receives a signed 
document and can verify the signatory has the authority.



All this policy proposal does is that when the two parties want to 
finalise the transfer


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




and request RIPE NCC's confirmation,


LRHs currently don't need to do this...?
LRHs who have a contract with the RIPE NCC may need to request it, the 
ones that have opted not to have a contract are not required to present 
the RIPE NCC any kind of documentation, they can just update the object 
in the RIPE Database and that's it.




they will need to sign a document.
- the RIPE NCC would then verify the old holder is the legitimate LRH 
and


If the current holder has a services agreement in place with the NCC, 
this is already covered, right?

yes, I think.



- the RIPE NCC will also verify the transfer document is signed by 
authorised signatories on both the old and the new LRH.


Here, i think the NCC will only need to get a new services agreement 
signed with the *new* holder, if the new holder wishes to...


it's not that simple. What if the previous LRH does not have a services 
agreement? What if the new LRH does not want to sign one?



 In its current terms, i also object to this proposal.
Would there be any version that you would agree to, one that would 
consistently allow the RIPE NCC to publish the transfers of Intra-RIR 
legacy resources?


As i previously said, stats (and potential hijack alarms) are a good 
thing. But this version still needs a lot of work, and especially also 
strong support from the LRHs -- otherwise, this verification mechanism 
you're trying to suggest will not add anything...

What would you like me to work on? What is unclear.

The mechanism will provide the Buyer an option to request the RIPE NCC 
to verify and confirm (finalise) the transfer. I expect this requirement 
to become the standard for transfers of LR.


And again, the NCC only has business regarding the services it 
provides to LRHs, but not over the address space itself... i think we 
are all aware about that bit.
I am aware of this and this policy proposal does not aim to give the 
RIPE NCC additional powers over the LR.



Best Regards,
Carlos



Kind regards,
Elvis

--
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: el...@v4escrow.net
Mobile: +1 (702) 970 0921

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

[Elvis Daniel Velea]

Hi Sascha,


On 4/26/17 1:26 AM, Sascha Luck [ml] wrote:

Hi Elvis,

On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote:


What it will do is, for 'transfers' of Legacy space where both the 
old and the new holder want to have it verified by the RIPE NCC, both 
parties will need to sign a document where parties authorised to sign 
will confirm the change of the legacy holder (basically, a transfer).


Oh, this is *voluntary*? 
kinda... I am expecting all Buyers to request this process when they 
decide to receive a Legacy Resource. I would definitely request it if I 
knew the RIPE NCC can provide an additional confirmation.

This is not obvious from the language of
the proposed changes and one does not, perhaps, expect to see
anything non-mandatory in a RIPE policy document ;p

hehe

I tried to make this change as simple and as easy as possible for the 
LRHs. I knew that some would not agree with having additional 
requirements added, so I tried to make it as such that it would not be 
mandatory. I don't like to add barriers that could affect the registry 
in the long run.


Maybe we will need to have a version where the wording is more clear. 
Let's see what the others say and what will be the RIPE NCC's 
understanding of the text once they make the Impact Analysis.


So let me see if I have this right:

- Transfers of legacy space stay outside the NCC's purview to
 the extent they do now?

- LRH who *want* to have a resource transfer verified can do so
 by submitting verification paperwork of some description?
In an ideal world, all LRHs would want this as it would 'secure' their 
'transfer'.


- Changes in the db wrt legacy resources where the LRHs do *not*
 want this are marked as "non-verified by NCC" or something like
that but they are not rejected?
correct. A legacy resource that has been updated to reflect an other LRH 
will be marked somewhere in the lines of 'changed but not verified'.



Even after the comments above, do you still object to the proposal?


If my above understanding is correct, and an updated proposal
would insert some language to make the voluntary nature of the
transaction clearer, I'll withdraw my objection on that point.

ok, thank you for your understanding.

As
for the cost of it and possible defrayment of same, I'll wait for
the Impact Statement before making a decision.
I doubt there will be any significant cost. We'll have to wait for the 
NCC to complete their Impact Analysis.


Sorry for the misunderstanding, if that it was, and best regards,
Sascha Luck


thank you,
Elvis

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

[Elvis Daniel Velea]

Hi Carlos,


On 4/26/17 12:12 AM, Carlos Friacas wrote:


Greetings,

While the proposal's title seems to be a positive approach, as i read 
it, its main goal is to add extra requirements for LRH by changing 
«RIPE NCC Services to Legacy Internet Resource Holders».
The way I see it, this policy proposal does not add extra requirements, 
it adds an extra service.


I think protection (or just better alarms in place!) for Legacy 
address space is a good thing, however, i'm not sure an extra workload 
for the NCC and the LRH in the case they want to transfer their 
asset(s) is the way to go.
the extra workload is a document signed by the representatives of the 
two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of 
documents on a daily basis so I doubt that would be a whole lot of extra 
workload - they will confirm during the Impact Analysis.


I also agree with Sascha Luck's previous comment about LRH having to 
submit to an extra verification process.
As mentioned in my response to Sascha's e-mail, the LRH can and will 
still be able to update their objects in the RIPE Database even without 
any document signed.
All this policy proposal does is that when the two parties want to 
finalise the transfer and request RIPE NCC's confirmation, they will 
need to sign a document.

- the RIPE NCC would then verify the old holder is the legitimate LRH and
- the RIPE NCC will also verify the transfer document is signed by 
authorised signatories on both the old and the new LRH.


In its current terms, i also object to this proposal.
Would there be any version that you would agree to, one that would 
consistently allow the RIPE NCC to publish the transfers of Intra-RIR 
legacy resources? They currently publish all but these.


Best Regards,
Carlos Friaças


thank you,
elvis

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

[Elvis Daniel Velea]

e IPv4 
address brokers.
I represent an IPv4 address broker and can not see how this is going to 
help my business.

I am also a RIPE NCC member and I pay my yearly membership, just as you do.

I can already see who is a legacy resource holder and I can already see 
the changes in the RIPE Database; how would publishing the statistics of 
IP transfers of legacy resources be of any help to my company?

In order to identify all legacy changes, a confirmation will be
sent to the RIPE NCC to finalise the process (currently this is
only checked for legacy resources that have a contractual
relationship with the RIPE NCC or sponsoring LIR). This
verification requirement does not impact the transfer of legacy
resources or the updates in the RIPE Database. It only adds an
additional step to increase the registration quality.


What makes you think imposing a bureaucratic requirement on
legacy holders out of the blue will not be resisted? 
Why would someone resist it? It would add a security layer to the Buyer 
by having the RIPE NCC verify that the IP block transferred has the 
approval of the management of the original legacy holder.


It would also prevent hijackers (that may have gotten their hands on the 
password of a maintainer of a legacy resource) from transferring IP 
blocks they do not hold.

I remember
the discussions around formalising the legacy resource
relationship with the NCC and how the voluntary nature of any
such relationship was emphasized in order to get any sort of
consensus.
And, based on those discussions, this policy proposal does not require 
the RIPE NCC to approve the transfer of a Legacy. Where both parties 
request it by signing a transfer template, the RIPE NCC will confirm the 
transfer.

In short, this proposal has the potential to:

- benefit the few at a cost to all members,

what will be that cost?

- sour relations with legacy resource holders,

how so?

- have a deletorious effect on registry quality where resource
 holders do not wish to submit to a "verification" process,
they can still update the object, the RIPE NCC will only mark the update 
as not yet verified.


The current situation already has a negative impact on the registry and 
this policy proposal could fix it when both the old and the new legacy 
holder will sign a transfer template and the RIPE NCC verifies the 
authenticity of the signatories.


and therefore I, strenuously, object to this proposal (for
whatever that may be worth)

Even after the comments above, do you still object to the proposal?

Is there any method to achieve the end goal (publishing complete 
transfer statistics) you would not object to?


rgds,
Sascha Luck




Kind regards,
Elvis

--
Elvis Daniel Velea
V4Escrow LLC
Chief Executive Officer
E-mail: el...@v4escrow.net
Mobile: +1 (702) 970 0921

Re: [address-policy-wg] Cleaning up Unused AS Numbers

[Elvis Daniel Velea]

Hi Laurens,

the plan below looks fine. Please go ahead.

I've got a question about the ~300 reserved 16bit ASNs (as per the 
delegated extended file). Does the RIPE NCC have any plan to bring these 
into production as well?


Kind regards,

Elvis

On 3/23/17 5:18 AM, Laurens Hoogendoorn wrote:



Dear colleagues,

As previously mentioned at RIPE 73, we are planning a project to clean
up unused AS Numbers. You can find this presentation here:
https://ripe73.ripe.net/archives/video/1456/

According to ripe-679, "Autonomous System (AS) Number Assignment
Policies" if an organisation no longer uses as AS Number, it should be
returned to the free pool so it can be reassigned:
https://www.ripe.net/publications/docs/ripe-679

There are currently around 6,600 ASNs in our service region (held or
sponsored by 2,682 LIRs) that are not being advertised in the routing
system. This represents around 22% of the ~30,000 ASNs assigned by the
RIPE NCC.

There are a number of legitimate reasons why an ASN might not be
advertised in the routing system. However, it is also possible that
the holder doesn't exist anymore or the ASN is no longer needed. Not
only should unused ASNs be returned, but it's important to clean up
out of date registrations, which affect the quality of data in the
RIPE Registry.


Our Proposal

We plan to email the LIR or sponsoring LIR for each unannounced ASN
and ask if the resource is still needed. We will group together ASNs
that are sponsored or held by the same LIR to minimise the number of
emails.

We will ask if the ASN is currently being used or if there are plans
to start using the ASN in the coming three months. Organisations can
always request a new ASN in the future if they need one.

If we do not receive a reply or if the ASN will not be used within
three months, we will start the process of returning the ASN to the
free pool. The deregistration process will take three months, during
which time the LIR can still indicate that the ASN is needed. If the
ASN is still needed, the validity of the assignment (such as the
multihoming requirement) will not be re-evaluated.

We do not expect any significant cost or impact on other services, as
most of this process will be automated and we will not need to
re-evaluate the assignments. Contacting all relevant LIRs will take
less than six months.

Please review this proposal and send any comments or other feedback
before Thursday 6 April to .

Regards,

Laurens Hoogendoorn
Registration Services
RIPE NCC

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

[Elvis Daniel Velea]

Hi,

On 10/19/16 11:05 AM, Marco Schmidt wrote:

The goal of this proposal is to ban transfers of allocations made under the 
final /8 policy. Also the proposal specifies what resources must be added to 
the RIPE NCC IPv4 available pool.
I do not agree with this policy proposal and believe it will not fix 
anything, instead - it will harm the registry.

Some of the differences from version 2.0 include:

-Clarification that changes to holdership of address space as a result of 
company mergers or acquisitions are not affected by proposed transfer 
restriction

this fixes only a tiny bit of the problem.

-Legacy space handed over to the RIPE NCC will be added to the IPv4 
available pool
this has nothing to do with the policy proposal. I feel it's just some 
candy offered to sweeten the proposal itself.


This was the short version of my response. Those reading this e-mail 
during working hours, you can go back to work ;) those that still have 
some popcorn left, feel free to read further.


Below are the 6 most important reasons why I believe this policy 
proposal should not become policy:


1. This policy proposal will create two types of members.

a. the members that have received resources before 2012 + the members 
that can afford to 'buy' IP addresses allocated until recently (-2y from 
the date this policy proposal would be implemented)
b. the members that have only received resources after September 2012 
and can not afford to buy IP IP addresses at the market prices (but they 
can buy an unlimited number of these from the RIPE NCC at ~€4,5 
(€3,4/1st year + €1,4/2nd year - redistribution of profit)


The first type of member would be allowed to participate in an IP 
transfer market that was (until the implementation of this policy 
proposal, if ever) accessible to everyone and anyone with resources 
received from the RIPE NCC or an other member.
The second type of member will not be allowed to participate in this IP 
transfer market unless they buy first from an other member.


Some members have already been able to transfer their /22 received from 
the last /8. With the implementation of this policy proposal (if ever) I 
feel that we as a community will discriminate between those that have 
received their last /22 (and want/need, for various reasons to transfer 
it) 2 or more years before implementation and those that have received 
less than 2 years before the implementation (or any time after).


I know some of you do not like analogies. But I would compare this with 
2 people buying their cars. The first can buy the car and sell it 2 
years later, only because the purchase happened even just a few days 
before the car industry decides that cars can no longer be sold further. 
So, those that have bought their car and used it for 1.5 years will have 
to return it (for free) to the car manufacturer while others could have 
sold it because they were quick in the purchase process and bought it 
earlier.


So, I think that once this policy proposal would be implemented (if 
ever) it would discriminate the second type of member as they will not 
be allowed to participate in a well established IP transfer market with 
the IP addresses received from the RIPE NCC (and only with the IP 
addresses they need to buy from the market first).



2. This policy proposal will create yet an other color of IP addresses.

I believe and hope that in the near future we will start talking about 
the removal of colors and not about addition of more colors. Numbers are 
just numbers. There is no difference between a number received in 1990, 
one received after 1992 or one that has status PI or PA. Now, we want to 
add a color for numbers received after 2012...


My router does not know any difference between these numbers and nobody 
really cares. Do you think that PI holders care that they are not 
supposed to sub-assign that space to other customers ? Do you think the 
RIPE NCC has any say or can really verify who (and most importantly - 
how someone) is using any of these numbers?
The community decided to remove most of the barriers when 2013-03, 
2014-02, 2014-05 were approved and implemented. These policy proposals 
removed all the 'old' requirements and cleaned up the IPv4 policy so 
much that anyone can now do whatever they want with their IPv4 space 
(not that they could have not done it in the past, but they would have 
to lie to the RIPE NCC if they would have ever needed an additional 
allocation). This policy proposal tends to take us back to previous way 
of thinking, an old one - I think.


So, just adding more colors and barriers will only complicate things. 
And I've always liked policies and procedures that are clear and simple. 
As simple as possible.



3. This policy proposal will drive some IPv4 transfers underground.

We already know and have seen it in previous presentations that where 
the RIR system tries to impose some limitations, the real world invents 
something to circumvent those 

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

[Elvis Daniel Velea]

Hi Sander,

I think I should've carefully looked at Ingrid's e-mail, maybe through 
some glasses :)


Indeed, the message from Ingrid stated exactly what I was asking for.

I am still hoping to receive a message (it can be in private) from one 
of the the NCC's ops to see if we can find out why my initial message 
did not make it to the list.


Apologies for all the noise, at least this is not 'popcorn style' like 
yesterday's :)


Regards,

Elvis


On 10/20/16 7:33 PM, Sander Steffann wrote:

Hello Elvis,


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

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

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

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

Cheers,
Sander

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

[Elvis Daniel Velea]

Dear Sander, list,

below is an e-mail sent on 8/29 which did not make it to the list.

Dear RIPE NCC admins - please check and help me understand why the 
message forwarded below did not make it to the mailing list as the 
google mail server ( that is used to host my @velea.eu private e-mail 
address) shows it as delivered (in the Sent folder) and I did receive 
the (BCC'ed copy).
- please note, I am hiding the IP address and the from host in the 
headers below with '*x*'. If you need these details, please send me a 
message privately and I will share the IP address and even the name of 
my workstation.


Sander, please take this message into account as well. I hope/think that 
the message below could make a difference.


I am sorry for reacting so late, I did not know that my message did not 
make it to the list until I saw Sander's message with the summary.


Regards,
Elvis




 Forwarded Message 
Return-Path:<el...@velea.eu>
Received: 	from *x* ([*x.x.x.x*]) by smtp.googlemail.com with ESMTPSA id 
i80sm14433191wmf.11.2016.08.29.10.09.38 (version=TLS1_2 
cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 
10:09:38 -0700 (PDT)

Reply-To:   el...@velea.eu
Subject:Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED
References: 	<c988893b-d73d-4879-07b8-53ba50f4c...@ripe.net> 
<0a0dcd8a-a685-ed25-6837-0d807c370...@velder.li> 
<57a31aae.6060...@ripn.net> <m21t24zt1j.wl%ra...@psg.com> 
<20160804113710.gj79...@space.net> <m2y44cycc4.wl%ra...@psg.com> 
<20160804121033.gk79...@space.net> 
<b0218cfd-30fa-4c3e-5a2b-ebbd03cf9...@ripe.net>

To: address-policy-wg@ripe.net
From:   Elvis Daniel Velea <el...@velea.eu>
Message-ID: <48d42760-80dc-2e37-a436-e5ff46de0...@velea.eu>
Date:   Mon, 29 Aug 2016 20:09:37 +0300
User-Agent: 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) 
Gecko/20100101 Thunderbird/45.2.0

MIME-Version:   1.0
In-Reply-To:<b0218cfd-30fa-4c3e-5a2b-ebbd03cf9...@ripe.net>
Content-Type:   text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding:  8bit



Hi everyone,


On 8/5/16 4:41 PM, Ingrid Wijte wrote:

Dear colleagues,



Also, it might lead to deaggs (Markus' case) where a /14 that was
originally "in one LIR" would be "3x /16, plus some smaller fragments
in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14
won't get a ROA, and he'll have to announce more-specifics.

lemme see if i get this.  to have the owner registration correct, some
address space will have to be broken up and owned by multiple IRs, thus
fragmenting routing?  i like correct registration, but the commons has
become pretty polluted.


The main issue that we (the WG and the RIPE NCC) are trying to resolve
is the lack of clarity around the status and rights of these
assignments. It’s not necessarily the case that the End User
registration is incorrect. In many cases LIRs have put a lot of effort
into keeping this information up to date.

I believe that since these were PI assignments - the
holdership/ownership/call-it-whatever of the IP addresses stays with the
company to which this IP block was registered - the PI holder.

If the holder of the PI assignment agrees with the change of the block
from ASSIGNED PI to PA, that will mean they are giving up on their right
to hold/transfer the PI block.

I think the main issue here is: who owns the rights of these IP
addresses? If it's the LIR (because it was an allocation) - then they
could kick the end-user out at any time. If it's the end-user - well,
they should sign maintenance agreements as every PI holder and get those
PIs under the same rules as everyone else's.

I know of at least a few cases where the end-users have requested a PI
assignment and have received one. However, some of them have received
the PI assignments (approved by the RIPE NCC) from an ALLOCATED PI block
while others have received them directly from the RIPE NCC. In both
cases, the only one communicating with the RIPE NCC was the LIR. The
end-users had no idea of the difference between the two PI blocks.

That is why I believe that the NCC should talk to every PI holder from
those PI/unspecified allocations and see if they - the end-users - the
holders of the IP addresses - want to have the PI sponsored by an LIR
(and therefore sign a maintenance agreement) or if they may want the IP
block to be transferred to the LIR holding the large allocation (and
transformed into ASSIGNED PA).

The first step - talking to the allocation holder (the LIR) - is
logical. However, if you only talk to the LIR you will only see one side
of the story. It should be, I believe, the end-user that should decide
whether they give up on their right to those IPs which now have become
assets and are worth money.

Therefore, I think that the RIPE NCC should talk to every single company
holding a PI assignment from an ALLOCATED

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

[Elvis Daniel Velea]

Hi Sander,

On 7/22/16 1:41 AM, Sander Steffann wrote:

Hi Elvis,


I've had easier discussion to judge, and less repetitive-nonsensical ones.

it says awaiting decision from proposer and not from WG Chairs. That is why I 
was asking the proposer.

Just for clarity, this is what the PDP says:


[RIPE-642 section 2.2]
At the end of the Discussion Phase, the proposer, with the agreement of the WG 
chair, decides whether the proposal will move to the next phase (Review Phase) 
or if it should be withdrawn from the RIPE PDP, depending on the feedback 
received. This should be done no more than four weeks after the end of the 
Discussion Phase.
than maybe it should be made clearer on the webpage. While I do 
appreciate the 'upgrade' of the page - it used to be worse - it can be 
improved :)


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

In short: if you're going to be pedantic please read the relevant documents 
first. The discussion phase has ended. The microphones are closed. And give 
your chairs some breathing room to do their (volunteer) jobs properly.
I have, many times, I used to refer to the same documentation when I was 
a part-time trainer at the NCC :)


Again, the website says the phase is complete and is "Awaiting Decision 
from the Proposer". Maybe it should still be 'green' and not 'blue' and 
maybe it should say something else and not 'awaiting a decision from 
someone until one week ago'. For example, maybe it should say - 
Discussion Period ended on July 15th - 1-4 weeks until next 
phase/decision. Or maybe it should have more columns, one for each phase 
in this process (+ one for each of the periods in between the phases).

Cheers,
Sander

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

while I appreciate your position, I was under the impression that Gert - 
with his replies on June 20th - did take sides more than you did.


I will leave it to the WG Chairs Collective to decide if he did take 
sides or not and whether any of you can still decide consensus on this 
policy proposal (ripe-642 3.1 &4).
I do not intend to submit an appeal unless this policy proposal moves 
forward to Review Phase.. so I am waiting for the decision of the 
proposer - as the website says :)


regards,
Elvis

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

[Elvis Daniel Velea]

Hi again,

fatty fingers, wanted to still edit the last line and hit the wrong key...


On 7/21/16 11:14 PM, Elvis Daniel Velea wrote:


Hi,

just wondering why the page still says Awaiting Decision from Proposer 
- *15 July 2016*


Since you are around to respond, any idea when you you take a decision?

this was meant to say:
Since you are around to respond, any idea when you will make that 
decision? It's almost a week overdue.


cheers,
elvis


regards,
elvis

On 7/21/16 10:35 PM, remco.vanm...@gmail.com wrote:
He thought it needed to be withdrawn because he concluded that there 
was no consensus - and that conclusion is not his to make. So that's 
what Gert responded to.


Remco

Sent from my HTC

- Reply message -
From: "Riccardo Gori" <rg...@wirem.net>
To: <address-policy-wg@ripe.net>
Subject: [address-policy-wg] 2016-03 Discussion Period extended until 
15 July 2016 (Locking Down the Final /8 Policy)

Date: Thu, Jul 21, 2016 20:29

I see he said "I think".
I think list exists because everyone should be left free to express 
his own opinion, that's not taking decision.

regards
Riccardo

Il 21/07/2016 20:07, Gert Doering ha scritto:

Hi,

On Thu, Jul 21, 2016 at 08:40:38PM +0300, Aleksey Bulgakov wrote:

I think, it is time to withdraw this proposal due to we haven't reached the
consensus.

This is not your call to make.

Gert Doering
 -- APWG chair


--
Ing. Riccardo Gori
e-mail:rg...@wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile:https://it.linkedin.com/in/riccardo-gori-74201943

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

[Elvis Daniel Velea]

Hi,

just wondering why the page still says Awaiting Decision from Proposer - 
*15 July 2016*


Since you are around to respond, any idea when you you take a decision?

regards,
elvis

On 7/21/16 10:35 PM, remco.vanm...@gmail.com wrote:
He thought it needed to be withdrawn because he concluded that there 
was no consensus - and that conclusion is not his to make. So that's 
what Gert responded to.


Remco

Sent from my HTC

- Reply message -
From: "Riccardo Gori" <rg...@wirem.net>
To: <address-policy-wg@ripe.net>
Subject: [address-policy-wg] 2016-03 Discussion Period extended until 
15 July 2016 (Locking Down the Final /8 Policy)

Date: Thu, Jul 21, 2016 20:29

I see he said "I think".
I think list exists because everyone should be left free to express 
his own opinion, that's not taking decision.

regards
Riccardo

Il 21/07/2016 20:07, Gert Doering ha scritto:

Hi,

On Thu, Jul 21, 2016 at 08:40:38PM +0300, Aleksey Bulgakov wrote:

I think, it is time to withdraw this proposal due to we haven't reached the
consensus.

This is not your call to make.

Gert Doering
 -- APWG chair


--
Ing. Riccardo Gori
e-mail:rg...@wirem.net
Mobile:  +39 339 8925947
Mobile:  +34 602 009 437
Profile:https://it.linkedin.com/in/riccardo-gori-74201943
WIREM Fiber Revolution
Net-IT s.r.l.
Via Cesare Montanari, 2
47521 Cesena (FC)
Tel +39 0547 1955485
Fax +39 0547 1950285


CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by re-
plying toi...@wirem.net
 Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)



--
<http://v4escrow.net> 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

Re: [address-policy-wg] ipv6 assignments

[Elvis Daniel Velea]

Hi,

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

> On Jun 23, 2016, at 09:26, Gert Doering <g...@space.net> wrote:
>
> Hi,
>
>> On Wed, Jun 22, 2016 at 11:49:35PM +0300, Elvis Daniel Velea wrote:
>> let's also chip in the possibility to make /64 assignments while
>> redefining the definition. plenty that keep coming at the RIPE Meeting
>> with all kind of cases where they want to use IPv6 (PI) but membership
>> is not accesible.
>>
>> https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf
>
> No, IPv6 PI policy is a different topic and needs to be covered by a
> different proposal.

I only proposed this because in my mind it could have easily been
solved when redefining the end site definition.

/elvis

>
> Gert Doering
>-- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

Re: [address-policy-wg] ipv6 assignments

[Elvis Daniel Velea]

let's also chip in the possibility to make /64 assignments while
redefining the definition. plenty that keep coming at the RIPE Meeting
with all kind of cases where they want to use IPv6 (PI) but membership
is not accesible.

https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf

/elvis

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

> On Jun 22, 2016, at 23:40, Nick Hilliard  wrote:
>
> Gert Doering wrote:
>> But maybe now is the time to go where no man has gone this year, and
>> propose an IPv6 related policy proposal - any volunteers? :-)
>
> I'll take a look at it.
>
> Nick
>

Re: [address-policy-wg] 2016-03: trading the last /22?

[Elvis Daniel Velea]

Hi Gert,

I am surprised to see that you are defending this proposal more than
the proposer :)

> On Jun 20, 2016, at 12:33, Gert Doering 
[...]
> (Regarding the DB accuracy, I think Sander has answered this upthread
> in a way I find convincing: if trading for these /22s is limited, of
> course someone who trades "under the desk" will not be able to update
> the registry, so potentially someone else uses the /22 and can not document
> that.  Would I buy a /22 that I can not legally transfer into my LIR?

legally?

> No, because I'm all at the mercy of the seller - if he closes his LIR,
> "my" /22 is gone.  So I'd go and find a unencumbed /22 on the market - and
> in my book, this would mean "mission accomplished, trading discouraged")

If things would be so simple...

Look at what's happening in ARIN. Lots of transfers (some very large
ones as well) are done by means of financial/contractual artifices
(furures contracts and such) avoiding the needs based criteria from
the policy. Millions of IPs seem to change hands but the transfer are
not recorded in the registry.

While *you* would not trade a 'last allocated' block, it does not mean
that these will not trade.

I have been extremely happy with the very simple (non-restrictive)
transfer policy that we have had for years and I think this proposal
will only complicate things.

Yet an other colour of the IPv4 space is something we should avoid.
Numbers are numbers and giving them colours - legacy, anycast, PA, PI
-, and now non-transferable is something we as a community should
avoid. And if it were to still work on the IPv4 policy, I would do my
best to clean all these colours away and keep only one.

The M have been an issue for years and these will become the next
issue if this proposal gets accepted. I also await the response from
the NCC before commenting further on this issue.

I also do not think it's ok to have a policy change the status of a
resource 'in the middle of the game' and think that even if accepted,
this proposal should cause a change of status only from the moment it
is implemented.

>
> Gert Doering
>-- APWG chair

/elvis

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

[Elvis Daniel Velea]

Hi Remco,

On 6/16/16 6:39 PM, Nick Hilliard wrote:

Remco van Mook wrote:



I would encourage everyone to carefully read this second version (and not just respond 
"no, still hate it, kill it with fire") as it is quite different from the first 
version.


Still hate it, kill it!


Explicitly states that the current IPv4 allocation policy applies to
all available IPv4 address space held by the RIPE NCC that has not
been reserved or marked to be returned to IANA

This is probably useful.  It would also probably be useful to define a
term to replace the name "last /8" so that it can be referred to
specifically in the policy documentation, e.g. "the remaining
unallocated ipv4 pool" or something along those lines.  Totally not as
catchy as "the last /8", but sadly that is the nature of policy.
while updating this to a form where it would be very clear is something 
I applaud, I do not think it is a must.



Adds a consideration to the IPv4 allocation policy that the LIR
should conserve whole or part of their final /22 allocation for
interoperability purposes

Neutral on this.  People will do what they are going to do, even if it's
short-sighted.
a good addition, also feeling neutral on telling LIRs what to use the 
resources for.



Bans transfers of final /22 allocations
Changes the “status”field in the RIPE Database to reflect the
transferability of an INETNUM

I'm against this because it conflicts with the core purpose of the RIPE
registry, which is to ensure accurate registration of resources.
Formally banning transfers will not stop transfers; it will only stop
those transfers from being registered which will lead to inaccurate
registry information.
could not have said it better. While this is an interesting attempt, it 
will only drive _some_ transfers to the underground. Bad idea from my 
point of view.


Additionally, it would still apply retroactively and people which since 
2012 until 'yesterday' were allocated PA/transferable IPs (2 years after 
the moment of the allocation) will end up with an allocation that is no 
longer transferable. I do not like policy proposals that apply 
retroactively, you should have thought of this in 2012 before the 'run out'.




Overall, I am against the core proposal, namely banning transfers from
the remaining unallocated ipv4 pool.

+1

Nick


elvis

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

[Elvis Daniel Velea]

Hi,

On 6/7/16 1:17 AM, Jim Reid wrote:

On 6 Jun 2016, at 22:54, Aleksey Bulgakov  wrote:

Why are we talking about 185./8 only?

We are not. You might be though. :-)
Why are we still talking about this proposal? I was under the impression 
that it will be withdrawn soon after the RIPE Meeting.


If that is the case, let's withdraw it and stop the noise :) If not, 
Remco, please let us know what you want to do with it as it is obvious 
that this version will never be accepted.


thanks,
elvis

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

[Elvis Daniel Velea]

Hi Erik,

On 5/30/16 1:45 AM, Erik Bais wrote:


Hi Elvis,

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


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


that was my mistake, I was sure I had pointed it out in an older 
e-mail.. can't find it so it probably never made it to the list and was 
in draft status forever :)


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


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


well, this is what I was opposing to. However, after further discussions 
offline, I no longer think this is quite such a bad idea. So, I no 
longer oppose.


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



you never invited me there... I would've wanted to see the proof.


Thanks for the feedback.


so, +1 to the proposal.

cheers,
elvis


Regards,

Erik Bais

*Van:*address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] 
*Namens *Elvis Daniel Velea

*Verzonden:* woensdag 25 mei 2016 10:28
*Aan:* address-policy-wg@ripe.net
*Onderwerp:* Re: [address-policy-wg] opposition to 2015-04

Dears,

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


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


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


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


my 2 cents,
elvis

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

Dear all,

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

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

Kind regards,

Remco

--

<http://v4escrow.net>

    


  Elvis Daniel Velea


Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

[Elvis Daniel Velea]

Dears,

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


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


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


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


my 2 cents,
elvis

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

Dear all,

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

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

Kind regards,

Remco


--
<http://v4escrow.net>     


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

[Elvis Daniel Velea]

Hi,

On 2/9/16 2:26 AM, Elmar K. Bins wrote:

zs...@iszt.hu (Janos Zsako) wrote:


[...]

I support the nomination. I know Sander for more than 10 years.
He has been very active in the AP-WG for a long time and did a good
job as co-chair. I am glad he still has the energy and is willing to
continue. :)

Well, Janos, I am not really certain Sander would be the man for the job!

He is much too involved, does much too much work, keeps everybody in the
loop, is competent, has shown leadership skills, is overall a very
agreeable guy whom I like a lot since he appeared on the scene. I would
not want him wasted and lost in the maelstrom of beeing a WG chair.

Well, but maybe maybe he can survive this, too, so hell, yeah, choose
the guy, he's the best and most motivated one we have for the "job".

*SUPPORT*

*running away now* Elmar.


hahaha, well put.

+1 for Sander from me too.

Regards,
Elvis

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

[Elvis Daniel Velea]

Hi,

how would you explain it when a company (non-member) would ask why can a new 
LIR still receive a 16bit ASN and they can't?

my 2 cents,
elvis

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

PS: apologies for the top-post

> On Nov 13, 2015, at 00:46, Erik Bais  wrote:
> 
> Hi Peter, 
> 
>> Thinking out loud: We could also apply the "last /8 policy" to this.
>> After it goes into effect, each LIR can request one and only one 16b ASN.
>> 32b ASNs are allocated as normal (with the question asked, but not
>> evalutated).
> 
> I think that we are already beyond the point of handing out 1* 16b ASn to 
> each LIR and there isn't that much left in the free pool I'm guessing .. ( 
> that is my gut feeling .. ) 
> 
> But the NCC should be able to answer the total number in the RIPE pool ... 
> 
> Erik Bais 
> 
> 

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

[Elvis Daniel Velea]

Hi Garry,

On 10/20/15 4:12 PM, Garry Glendown wrote:

Guten Tag,

On 2015 Oct 20 (Tue) at 14:46:54 +0200 (+0200), Marco Schmidt wrote:
:https://www.ripe.net/participate/policies/proposals/2015-05

 From the proposed text:
   5.1.3.2. There is enough space in the free pool to perform the allocation

Is there a definition of "enough space in the free pool"?  Is it a
single /22?


According to the proposal I'd say yes ... of course, that's the basic
use case of a pool - to use it.

Anyway, maybe I have overlooked it, but there doesn't seem to be a
provision as to whether an actual need is documented, e.g. less than 25%
free of currently assigned space or less than 1 /24 available, whichever
is less.
we did not intend to include need based criteria back to the IPv4 
policy. It would be very difficult.
Imagine that I am an LIR and have a /22, this policy proposal is 
approved and I am using a /24 only. As there is no requirement for needs 
based justification, I can register a /23,/24 assignment to a 
'potential' customer and delete it once I got the second /22 allocation.


We could add in the policy that a small 'audit' (ARC) should be 
performed to verify that the LIR has recorded in the RIPE Database 
assignments for all the already used space. This way, we could help the 
registration goal.

-garry


cheers,
elvis

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

[Elvis Daniel Velea]

Hi Remco,

On 10/20/15 5:27 PM, Remco van Mook wrote:

Hi all,

(no hats)

I think this is a very bad idea*. The whole reason the final /8 policy looks 
the way it does (and is as far as I can see working *exactly* as intended) is 
so late entrants to this Internet game have a fair chance of establishing 
themselves without having to resort to commercial alternatives for IPv4 address 
space.
We started this discussion at least one year ago. We had a few 
presentations at RIPE Meetings and there were a few discussions on this 
topic on the mailing list. It was obvious that many of the new members 
registered after 2012 need more than the default /22.


Additionally, there are a couple other RIRs (APNIC, LACNIC) that have a 
similar policy and it seems to be working just fine.

For established LIRs, adding a trickle of additional address space probably 
won’t make a jot of a difference for their business and is likely not going to 
optimise the utilisation of those final scraps. The final /22 is *intended* to 
be used as a migration tool to IPv6, and is a crucial tool at that. I consider 
it a Very Good Thing Indeed that this region had the foresight that IPv6 won’t 
happen overnight once IPv4 runs out** and as long as we’re still talking about 
IPv6 adoption and not IPv4 deprecation, that tool should be available for as 
many organisations as possible.
Well, a /22 every 18 months may be helpful to those that need to work 
with only 1024 IPs.. That was the signal I received over the past months.


Finally, introducing this kind of change in policy at this point in time could 
well be argued as being anti-competitive and would end us up in a legal mess.
Can you please detail how it would be argued as being anti-competitive? 
This would apply to *all* members and each member would have access to 
it, provided they have not yet transferred (parts of) the allocations 
already received.


I hope you understand what we want to achieve. Give a chance to those 
that have registered as LIR after Sept. 2012 to receive a *bit* more 
space from the central registry (as the prices for small allocations via 
the transfer market is really high).
- would you agree with an other way to achieve this? If yes, please 
share your thoughts on how this proposal could be amended.


Remco

* So yes, dear chairs, please consider this e-mail to be against this proposal.
**Technically we have already run out a number of times, depending on your 
definition. None of those events has been earth-shaking, or induced major 
migrations to IPv6.


cheers,
Elvis

On 20 Oct 2015, at 14:46 , Marco Schmidt  wrote:

Dear colleagues,

A new RIPE Policy proposal, "Revision of Last /8 Allocation Criteria",
is now available for discussion.

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

You can find the full proposal at:

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

We encourage you to review this proposal and send your comments to
 before 18 November 2015.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

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

[Elvis Daniel Velea]

Hi James, Gert,

On 10/20/15 4:06 PM, Gert Doering wrote:

Hi,

On Tue, Oct 20, 2015 at 02:02:38PM +0100, James Blessing wrote:

On 20 October 2015 at 13:46, Marco Schmidt  wrote:


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

Can we limit it this to a /X to see what the impact is before throwing
the entire remaining v4 space under a bus?

not a bad idea, I like it.

We're in discussion phase right now, so everything goes... :-) - this is
really the phase where a proposal test the waters to see if it is generally
acceptable (potentially with minor corrections), needs larger surgery, or
is a total no-go...
let's collect the feedback and see if we need to come back with a second 
version.


(As for the impact: I hope the NCC will nicely do the math for us how
many LIRs we currently have that would be eligible to receive "more space"
and what their crystall balls have to say on the subsequent run-out date ;) )
Let's not forget that the crystal ball is just that... a guess. Nobody 
can predict how long will the free pool last.

- I hope this also answers Lu's question/comment.

gert

cheers,
elvis

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

[Elvis Daniel Velea]

Hi,

On 10/20/15 4:06 PM, Peter Hessler wrote:

On 2015 Oct 20 (Tue) at 14:46:54 +0200 (+0200), Marco Schmidt wrote:
:https://www.ripe.net/participate/policies/proposals/2015-05

 From the proposed text:
   5.1.3.2. There is enough space in the free pool to perform the allocation

Is there a definition of "enough space in the free pool"?  Is it a
single /22?

good question. Not sure what would happen if a single /22 is no longer 
available. My intention would be for the last allocation to be the 
remaining crumbs (even if less than a /22).


Currently, the proposal's intention is to allow allocations lower than a 
/22 as long as the total would be 1024 IPs.


regards,
elvis

Re: [address-policy-wg] Personal attacks - please stop (i ask for the 3rd time)

[Elvis Daniel Velea]

Hi Ciprian,

 so not that the policy is useless but it's proposal was a mistake.

Calling my proposal a mistake is very rude from you and I already asked 
you to stop being rude, before you started the thread below.


Even though I already responded to a message you have sent yesterday 
telling you that it's not nice what you are doing, you have continued to 
make false accusations and wrongfully interpret what others have said. 
Curious though, all the wrong interpretations were just to start attacks 
against me...


On 10/06/15 14:39, Ciprian Nica wrote:

Hi,

[...]

Please provide evidence for following claim, otherwise you are just making
accusation without any support evidence.

He approved your request for hudreds of thousands of IPs, even approved
this last-second allocation. 

And the reality is, Elvis has never on the position to make final decision
about our allocation.

You told us that. I can't know what happened during that allocations. I
only was refering to what you told us, that Elvis was the one that
approved your allocations. Maybe you know what happens behind the scene
but that should also bring some questions.
You, intentionally, misunderstood what Lu said and used your wrong 
assumptions to start an attack against me. I was under the impression 
that you are better than this but it seems you are not better than all 
the others that have been attacking me over this policy proposal because 
their 'business' was affected. I wonder what kind of business you have 
if you publicly attack persons and companies relying on your own false 
assumptions.



What Lu said was that during the evaluation of his requests, he was 
unhappy that I was very strict. He, as well as other RIPE NCC Members 
may have seen me as a very strict person when I was working at the RIPE 
NCC. That was only because I always thrive to be very good at my job and 
I have always verified (maybe too much) in depth all the documentation 
received from LIRs. Just as you have received the /28 IPv6 allocation 
(for your extremely large IPv6 deployment) some LIRs may have have 
received large IPv4 allocations when these were justified.
If you are complaining that your request got reduced from /13 to a /14, 
you should have complained at that time, you should have used all the 
tools you had if you think at that time the IPRAs were wrong - including 
the last option, request the arbiters to evaluate your request. You can 
not come back 3-4 years later to say, I could have received more if you 
would have been less strict (and assume that we have been less strict 
others), especially because you have no idea how strict the NCC IPRAs 
have been with Lu.


Ciprian, if you really wanted to contribute to this proposal, you were 
at the RIPE Meetings where this issue was discussed - however, you 
decided that the AP-WG is not worth of your effort and you did not voice 
any opinion.
Instead, you waited until the last day to start an attack against me 
(the proposer) and against some others that you feel 'received more IPs 
from the RIPE NCC than you' before the run-out in 2012.


[...]

Again, you are making false statement without any evidence, in reality, I
have never done any business with Elvis now and past.

I don't know anything about any relation that might be between you and
Elvis. You pointed him out as the one giving you the IPs (approving the
requests).


Lu never pointed out that I 'gave' him the IPs. He actually said that 
found me to be 'unfriendly' - while actually I was just strict, just as 
with all the other requests I evaluated in the 6 years spent at the NCC.


and before that you said:

 It is very interesting to find out that the IPs were allocated to you 
by the same person that has initiated this proposal.


only to then say:

 Yes, a few years ago he approved your allocations and now he is 
helping you sell the IPs.
 Obviously he only dreams about world peace and there is no conflict 
of interests here.


You know, and have been aware of this information for years, that one 
single IPRA could not approve /16 or larger allocations. However, you 
started to attack me implying that I have helped Lu receive the 
allocations and that then I tried to help him sell them.  Plus, you know 
(and Andrea Cima also reminded you in case you had forgotten) that no 
single IPRA could approve a /15 or larger allocation without a second 
IPRA's evaluation and management and senior management approval.


I really do not know what happened to you, Ciprian. But I would advise 
you to take a step or two back and look at all the things you have 
wrongfully interpreted from others' mails. You can contact me directly 
or Andrea Cima (RS Manager) if you have any questions about my activity 
at the RIPE NCC and stop talking about conflict of interests or all kind 
of conspiracy theories where there is none.


I await your apology for all the badmouthing over the past two days. 
Again, this was totally unexpected from you.


Ciprian

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

[Elvis Daniel Velea]

Hi Sacha,

On 11/05/15 19:00, Sascha Luck [ml] wrote:

In light of this, I will oppose this proposal. For what that will
turn out to be worth. 
if I understand correctly, you are opposing to the RIPE NCC's planned 
implementation of this proposal (under the terms and understanding of 
this Impact Analysis), is that correct?


What If once the policy proposal would become policy and would be 
implemented, _all all allocations made after the implementation date_ 
will need to have a 2 years 'buffer' - would that be acceptable?


I just want to clearly understand the reason for opposing.

regards,
Elvis
--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation)

[Elvis Daniel Velea]

On 15/04/15 00:48, Nick Hilliard wrote:

Looks good to me.  Support.

Nick

clean and simple. this should have been done years ago

+1 from me too

/elvis



On 14/04/2015 14:52, Marco Schmidt wrote:

Dear colleagues,

A proposed change to RIPE Document IPv6 Address Allocation and Assignment 
Policy
is now available for discussion.

You can find the full proposal at:

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

We encourage you to review this proposal and send your comments to
address-policy-wg@ripe.net before 13 May 2015.

Regards

Marco Schmidt
Policy Development Officer
RIPE NCC

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

[Elvis Daniel Velea]

Hi Sonia,

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


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


Regards,
Elvis

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

Dear all

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

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

Sonia Garbi Gomez
Finance Manager
RIPE NCC



--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

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

[Elvis Daniel Velea]

Hi Carsten,

not only that the loophole exists, but the RIPE NCC has even pointed it 
out in an RIPE Labs article (and several previous RIPE Meetings):

https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-statistics-2014

I think that the more we talk about it, the more this loophole will be 
(ab)used. The part that was just theoretical was estimating how long it 
will take a company to decide that instead of going to the market, they 
could actually go to the RIPE NCC and get a /16 or maybe a /12 at €2.3 - 
€3.4 per IP (depending in which quarter you decide to do it).
- this policy proposal will still not fix this issue, will just raise 
even more awareness.. this policy proposal is just trying to patch the 
transfer policy. we still need to discuss whether we want to touch the 
mergers and acquisitions process.


regards,
elvis


On 10/03/15 09:13, DOI (BIT I 5) wrote:


Hi Elvis,

I agree with your proposal. I’m interested in the fact: Are there such 
“loophole” cases right now or is it a theoretical problem, that could 
be happen if 2015-01 would not be accepted?


Regards,

Carsten

*Von:*address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] 
*Im Auftrag von *Elvis Daniel Velea

*Gese**ndet:*Montag, 9. März 2015 17:32
*An:* address-policy-wg@ripe.net
*Betreff:* Re: [address-policy-wg] 2015-01 New Policy Proposal 
(Alignment ofTransfer Requirements for IPv4 Allocations)


Hi everyone,

I have thinking at what to answer regarding the comments on this proposal.

Firstly, the /22 from the last /8 policy proposal aimed to create a 
method for anyone to receive at least a few (1024) IPv4 addresses by 
becoming a member of the RIPE NCC.
Even then, the proposers had noted that anyone can open multiple LIRs 
and receive from the RIPE NCC more than 1024 IP addresses and asked 
the RIPE NCC to be vigilant. [1]


What happens now is not in the spirit of that policy proposal as the 
/22 from the RIPE NCC does not have the two years holding period so a 
few found a way to make a business using this loophole.
This policy proposal is just trying to add the same holding period for 
a transfer of the /22 as it is already for the rest of the allocations 
made by the RIPE NCC.



While I do agree that if the RIPE NCC free pool would be depleted, the 
market would takeover and normalize the price, the community has 
decided to have IPv4 addresses available for anyone that
 wants to become a member of the RIPE NCC and therefore request  
receive a /22.
I think that a separate proposal could tackle this issue, there were 
some discussions last year (if I remember correctly) and some members 
of this community suggested the increasing the limit from /22 to /21. 
That may deplete the free pool faster, but it will still slowly bleed 
out in a few years.


If we do not agree that this policy proposal is fair and needed, I 
predict that we will see more and more companies opening LIRs just to 
make use of this loophole and make a profit from selling one or more 
/22s from the last /8.
Actually, this policy proposal may have already harmed the free pool 
because if it does not get approved, more people have found out of the 
loophole and nothing will stop them from using it, they will have the 
endorsement of the community to just go ahead and open multiple LIRs.
I would not be surprised to see a very large ISP or (content) hosting 
company setting up 1.000 LIRs to get 1million IP addresses.. and if 
they setup 1024 LIRs in the same 'day' they may even get a /12 as a 
contiguous block.
In that case, would you find it fair that if someone wants to use a 
loophole (1024 times) they can get a /12 from the RIPE NCC while 
others need to use the market?


Considering these, Martin (and whoever else does not like this policy 
proposal), please let me know if you oppose to to this proposal as it 
is written and if you have any suggestion on what would be acceptable.


regards,
Elvis


[1] https://www.ripe.net/ripe/policies/proposals/2010-02
Some organisations may set up multiple LIR registrations in an effort 
to get more address space than proposed. The RIPE NCC must be vigilant 
regarding these, but the authors accept that it is hard to ensure 
complete compliance.


--

http://v4escrow.net




  Elvis Daniel Velea


Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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





--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator

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

[Elvis Daniel Velea]

Hi Mikael,

On 19/02/15 18:57, Mikael Abrahamsson wrote:

On Wed, 11 Feb 2015, Elvis Daniel Velea wrote:

I'm waiting to get the feeling of the community on this proposal 
before starting a discussion on the members-discuss mailing list 
about the MA procedure.


My gut feeling is that I do not want new LIRs created to acquire a 
/22, immediately transfer it out, and close the LIR. Considering the 
market price on IPv4 addresses I have seen and the cost of creating a 
LIR, this would be below market price.
and this is the loophole this policy proposal wants to close. I have 
seen at least one example where an LIR was created, received a /22 and 
within a week sold it (and I suppose it also got closed just after that).


regards,
Elvis
--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

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

[Elvis Daniel Velea]

Hi Sascha,

On 20/02/15 11:37, Sascha Luck [ml] wrote:

On Fri, Feb 20, 2015 at 11:05:53AM +0100, Sander Steffann wrote:

Limiting entry to 1024 addresses is anti-competitive.


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


Well, you can't sue a shop for having run out of milk to sell...

I do see the point of running out quickly - stretching the ipv4
supply out as long as possible does damn us to this speculation
nonsense for decades to come. The question is whether running out 
quickly will force ipv6 to

happen and thus make ipv4 essentially useless as a speculation
object. The way I see it, there are conflicting goals here - protect the
investment of the big ipv4 players or cause enough pain to force
the switch to ipv6 in my lifetime. If it should be the job of the
RIRs to promote either goal (and I'm not sure it is) the latter
one would be the better outcome for the Internet in the long
term.
The limitation to only one /22 (from the last /8) per LIR has been 
approved by this community years ago. Reverting this policy proposal is 
a discussion that I would like to see in a separate thread and not part 
of the discussion of this policy proposal.


As for the proposal, I'm neutral tending towards opposition
pending further argument.

Can you explain why you tend to oppose so I could try to address your 
concerns?

rgds,
Sascha Luck


thanks,
elvis
--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

Re: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers)

[Elvis Daniel Velea]

Hi,

got my support as well ;)

cheers,
elvis

On 27/01/15 08:48, Örnberg, Eva E. wrote:

support

BR   ///   Eva
Registry TeliaNet
On 2015-01-26 10:38, Marco Schmidt wrote:

Dear colleagues,


The Review Phase Period for the proposal 2014-12, Allow IPv6 Transfers
has been extended until 10 February 2015.

We request your feedback, even if you have provided it during the 
initial

Discussion Phase, so that the Working Group Chairs can determine whether
there is rough consensus.

You can find the full proposal at:

 http://www.ripe.net/ripe/policies/proposals/2014-12


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


Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC








--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources)

[Elvis Daniel Velea]

Hi,

I like the latest version of the policy proposal and appreciate the fact 
that it is now (probably) compatible with ARIN's need-based transfer 
policy. I fully support it.


Kind regards,
Elvis

On 16/01/15 14:49, Marco Schmidt wrote:

Dear colleagues,

The draft documents for version 3.0 of the policy proposal 2014-05,
Policy for Inter-RIR Transfers of Internet Resources, have now been
published, along with an impact analysis conducted by the RIPE NCC.

Some of the differences from version 2.0 include:

- Introduction of needs justification for transfers from RIR regions that 
require need-based policies
- Explicit statement about when RIPE policies apply during a transfer
- Related wording adjustments in the summary and rationale of the proposal

You can find the full proposal and the impact analysis at:

 https://www.ripe.net/ripe/policies/proposals/2014-05
 
The draft documents are available at:


 https://www.ripe.net/ripe/policies/proposals/2014-05/draft

We encourage you to read the draft document text and send any comments
to address-policy-wg@ripe.net before 16 February 2015.

Regards,

Marco Schmidt
Policy Development Officer
RIPE NCC




--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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

Re: [address-policy-wg] 2014-07, 2014-08, 2014-10, 2014-11 (Language Clarification Proposals) - declaration of support

[Elvis Daniel Velea]

Hi Gert,

you can add a 4th person supporting all the below (me) :)

regards,
Elvis

PS: I can not believe we are still talking about language clarification 
proposals, I was under the impression we have already passed that step 
and everything was clarified before the RIPE Meeting in London :)


On 05/02/15 21:03, Gert Doering wrote:

Dear AP WG,

the review phase for 2014-07, 2014-08, 2014-10 and 2014-11 has ended
(a while ago, actually, but I found too many excuses to send timely
end-of-phase announcements - apologies).

I have decided to group together the announcements for all 4
language clarification proposals (SHOULD or MUST) because all
comments received in this review phase were support all 4! in
combined mails...  note that the fifth in the series (IXP prefixes,
2014-09) was withdrawn before review phase already.

One could argue that only three voices of support isn't overwhelming,
but since these are just clarifications and have been presented at
two RIPE meetings with support on the meeting as well, and nobody spoke
up opposing the changes, we think this is good enough to move ahead.

So, these proposals go to Last Call now.


For reference, a list of people that voiced support in the review phase
is appended below.  This is what we chairs have based our decision on.

If you disagree with my interpretation of what has been said and the
conclusion we have drawn from it, please let us know.

Gert Doering,
 Address Policy WG Chair


Review Phase, starting Dec 11, 2014

Support:
   Nick Hilliard (5489aefa.4040...@inex.ie, Language clarification proposal)
   Carsten Schiefner
   Sebastian Wiesinger

Opposing:
   nobody

Any other comments:
   nothing received






--
http://v4escrow.net 


 Elvis Daniel Velea


   Chief Executive Officer

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

Recognised IPv4 Broker/Facilitator in:

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