April 2014 - address-policy-wg

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Richard Hartmann 15 Apr '14

15 Apr '14

I am afraid that I didn't have time to review the text in-depth yet, but I agree with the general direction this is going. Richard

1 0

APWG agenda for RIPE 68, first draft
by Gert Doering 14 Apr '14

14 Apr '14

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Warsaw in the following time slots: Wednesday, May 14, 09:00 - 10:30 Wednesday, May 14, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Marco Schmidt, NCC RS - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE67 2013-03 Post-Depletion Reality Adjustment and Cleanup (consensus, policy) 2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers (consensus, policy) 2013-06 PA/PI Unification IPv6 Address Space (withdrawn) - brief overview over new proposals (if any) E. On Personal Identity - for internet resources registered to natural persons, what level of identity verification does the community require from the RIPE NCC? - with (hopefully) lots of input from the Anti-Abuse WG, on what they see necessary - results will be presented to NCC services WG, as this is important for the "due dilligence" considerations of the NCC D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) (+ discussion with the group) [might be moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back G. On SHOULDs and MUSTs - RFC 2119 language in RIPE documents followup to RIPE 67, findings by Marco Schmidt and Jan Zorz F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space (which will hopefully be restarted until then) 2014-01 Abandoning the Minimum Allocation Size for IPv4 (Carsten Schiefner) 2014-02 Allow IPv4 PI transfer (Erik Bais) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Rob Evans 09 Apr '14

09 Apr '14

> http://www.ripe.net/ripe/policies/proposals/2014-01 Overall I think this is a good thing, but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is? If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented? The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves. Cheers, Rob

11 26

report address policy violation
by Tom Norda 08 Apr '14

08 Apr '14

Hi: I know a RIPE member with an unused ipv4 /20 block not used in the last 2 years and i'm wondering if that's a RIPE community policy violation. I checked https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policiesbut i still have doubts if it is accepted or not. Best regards

2 1

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Tore Anderson 01 Apr '14

01 Apr '14

* Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-02 I think it makes sense to allow PI transfers, at least when taking into account that we already do so for PA. So I'm generally supportive of this proposal A few comments though: 1) The new policy says: «Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid». What exactly are the implications of this requirement? I am assuming that the «RIPE Registry» is not the RIPE DB; as the original criteria isn't documented in the RIPE DB to begin with. As I understand it, any criteria that somehow involves «operating a network» is a valid assignment criteria (cf. section 3.0.3), with no requirement for specifics. I'm thinking that it might be better to simply say something along the lines of an assignment being valid for as long as it is being used according to the policy, rather than worrying about the «original criteria» and how it possibly have changed. Most networks evolve and change over time; it wouldn't surprise me if a majority of assignments are now being used differently than originally documented in their associated assignment request form. That's not a bad thing though, is it? 2) Editorial: The new section 6.4 «Transfers of PI space» appears to me to be pretty much a carbon copy of section 5.5 «Transfers of Allocations» with a tiny bit changed here and there. Rather than duplicating all that text, would it not be better to move 5.5 out of section 5, and re-title and generalise it so that it applies equally to PI and PA? 3) The new section 6.4 speaks of «Non-approved transfers». Under which circumstances would a transfer not be approved, exactly? Do we really need this language anymore? (I'm regretting that 2013-03 didn't do away with it already. Oh well...) Tore

2 2

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Erik Bais 01 Apr '14

01 Apr '14

> You can find the full proposal at: > http://www.ripe.net/ripe/policies/proposals/2014-01 Support +1 Erik Bais

1 0