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

> On 20 Oct 2016, at 10:42, Plesa Niculae wrote: > > Hi Steffann, > > I strongly believe that we should have this conversation public. You switch > it to private, for the reason I don’t understand, because we have nothing to > hide and nobody to protect, I kindly ask you

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

Hi Ciprian, > I've heared this story over and over. Let's protect the pool, let's not waste > it and now, after 4 years the pool is almost the same size. The only reason that the pool is the size it is is because we received some last scraps from IANA. The number of addresses coming from IANA

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

On Saturday, October 22, 2016, Sander Steffann wrote: > Hi Arash, > > > If old businesses depend on selling IPv4 address to new comers and now > > looking to put some more value on their old blocks, their strategy should > > not be supported by 2016-03. > > I'm sorry, but

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

I’ll entertain your question here, although the question isn’t in relation to the policy proposal, but more about how transfers work .. If a company splits… it is actually very simple … you setup a second LIR .. ( Provided that we are talking about RIPE PA space.. ) … And you transfer the

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

Hi, Feel free to adjust the policy in a new policy proposal, if you think it is vital for the future. As the author of this policy I’m not going to include it in this one. The transfer statistics isn’t a contest between brokers/facilitators or a place for advertising in my opinion.

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

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

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

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

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

On Sat, Oct 22, 2016, at 23:30, Sander Steffann wrote: > > (Actually, it would not be ok, as »/64 or shorter« still prohibts use of > > /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or > > »shorter than /64«, I think, or SLAAC is not an option anymore.) > > You are

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

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

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

On 10/22/2016 02:30 PM, Sander Steffann wrote: [...] You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the

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

Hi Kai, * Kai 'wusel' Siering > (Which, btw, means there's no difference between PA and PI here. > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent > interpretation. Eeks.) > > [...] > > And 3rd party usage of IPv6 PI addresses is currently not allowed. > > Well, if reading