On Wed, Oct 19, 2016 at 10:05:12AM +0200, Marco Schmidt wrote:
We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier.
- Policy proposals now contain a diff tool that allows easy comparison of different proposal versions ??? simply click on the ???View Changes??? symbol right beside the list of proposal versions. - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected.
thanks, it helped.
We encourage you to read the draft document and send any comments to <address-policy-wg@ripe.net> before 17 November 2016.
While I am not convinced that the proposal will achieve its goals "in the long run", I do not see significant harm and one could argue that there's no "long run" for v4 anyway. Take this as "can live with" in the spirit of rough consensus. However, the proposal text could benefit from another copy edit and there is an interesting discovery in the impact assessment. Looking at 5.3: Any address space that is not covered by other policies or marked to be returned to IANA, will be covered by the rules in section 5.1. This includes address space that is: o Returned to the RIPE NCC, o Allocated to the RIPE NCC from the IANA recovered pool as defined in the RIPE Policy "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA" o Given to the RIPE NCC by legacy holders the impact assessment says: [...]
IXP IPv4 assignments are the only resource type that currently has a special return policy defined. Section 6.1 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" states that "IP space returned by IXPs will be added to the reserved pool maintained for IXP use." Accordingly, any such returned IXP assignments are not added to the RIPE NCC's general available IPv4 pool.
The path to ripe-649 was inspired by having single document covering v4 policies, therefore no other document with "other policies" exists and thus the only exception to the applicability of 5.1 is in 6.1, which hardly qualifies as "other policies", leading to a confusing result. Also, the clause "not covered by other policies or marked to be returned to IANA" is kind of a hard read. A reference describing the return mark might be helpful as would the decoupling of the "or" clause. Other details include the use of transfer vs re-allocation or re-assigment, but I can take this to the author. [from the impact assessmant]
Returned IPv4 addresses from LIRs and End Users and addresses received from IANA's recovered pool are currently added to the RIPE NCC's available IPv4 pool. If this proposal is accepted, legacy resources that have been handed over to the RIPE NCC will also be added to the available pool. Currently, the RIPE NCC holds a total of ten /24 IPv4 legacy resources.
With apologies for lack of research; under what policy was this space "accepted" and not marked for return to IANA? -Peter