This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Daniel Velea
elvis at velea.eu
Wed Nov 8 12:12:35 CET 2017
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 <jordi.palet at consulintel.es> 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
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]