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/address-policy-wg@ripe.net/
[address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Previous message (by thread): [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Sat Sep 21 00:25:58 CEST 2013
Filiz, > Good, then there is no need to change this in the policy for allocations. And that's the very reason for the 2nd amendment going into version 3 of the proposal, precisely to avoid changing how this works. The "last /8 policy" is *not* a target for 2013-03 (beyond merging it into the main policy text for cleanup/editorial purposes). > And to better address the need based concerns objecting your proposal, I > think you could consider taking the "intent" you mentioned above one > step further and have it explained to the RIPE NCC. The 2nd amendment was actually developed in collaboration with the NCC (in particular Andrea Cima from RS and Emilio Madaio from the PDO), in order to incorporate the feedback and objection received from yourself and Malcolm Hutty during the last review phase: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-August/008105.html > Accordingly, I think following will be a more appropriate wording: > 3. LIR must demonstrate its need for the IPv4 address space and /must > confirm it will make assignment(s) from the allocation./ > > replacing what you proposed: > 3. /The LIR must confirm it will make assignment(s) from the allocation/ The *only* thing that defines "need" for *allocations*, is an LIR's intent to make assignments to End Users and/or its own infrastructure. Keeping that in mind, the two sentences above are actually saying *exactly the same thing*! > Confirming to make assignments on its own is not enough in my belief. > But I would support a more explicit need-justification requirement as above. As above, the exact purpose of the the 2nd amendment was to ensure current practise was being upheld. Both because of the feedback from yourself and Malcolm; but also because the NCC felt that not having any "pledge of intent to use" on the requestors' part could potentially make the Dutch Tax Office see it as the NCC "selling IPv4", and withdrawing their advantageous non-profit status. As stated earlier, the amendment was developed in collaboration with the NCC to ensure we achieved exactly that, and accordingly, the Dutch Tax point was removed from the updated Impact Analysis. So I believe the amendment successfully does what it aimed to do. If what you are saying above is that you think there needs to be a stronger and more rigid validation of need in order to obtain the last /22 (for example: intent to assign at least a /23 instead of a /32 like today), then that is of course fine, but if so - it belongs in a separate policy proposal. I try really hard *not* to change the "last /8 policy" in 2013-03, and it is therefore not a suitable vessel for a "more-explicitification" of its allocation criteria. Best regards, Troe Anderson
- Previous message (by thread): [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)
- Next message (by thread): [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]