- address-policy-wg - mailman.ripe.net

IEEE TrustCom Deadline is Approaching: May 5, 2014
by Sandra Sendra 25 Apr '14

25 Apr '14

[Please accept our apologies if you receive multiple copies of this email] *********************** CFP ******************************* The 13th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-14) http://www.greenorbs.org/TrustCom2014/ 24-26 September 2014, Beijing, China Important Dates Workshop Proposal: May 5, 2014 Submission Deadline: 11:59PM (UTC/GMT+8 hours) May 5, 2014 (This is the firm deadline) Authors Notification: June 26, 2014 Final Manuscript Due: July 20, 2014 Publications Accepted and presented papers will be included in the IEEE CPS Proceedings. Distinguished papers presented at the conference, after further revision, will be published in special issues of the following high quality international journals (pending). - Computers & Security - Elsevier (Impact factor=0.868) - Concurrency and Computation: Practice and Experience - Wiley (Impact factor=0.636) - Security and Communication Networks - Wiley (Impact factor=0.414) - Future Generation Computer Systems - Elsevier (Impact factor=1.978) - Multimedia Tools and Applications - Springer (Impact factor=0.617) - Journal of Internet Technology (Impact factor=0.508) - Journal of Computer and System Sciences - Elsevier (Impact factor=1.157) Topics Trust Track - Trust semantics, metrics and models - Trusted computing platform - Trusted network computing - Trusted operating systems - Trusted software and applications - Trust in social networks - Trust in e-commerce and e-government - Trust in mobile and wireless communications - Risk and reputation management - Survivable computer systems/networks - Miscellaneous trust issues Security Track - Network security - Computer security - Database security - Web applications security - Security policy, model and architecture - Security in social networks - Security in parallel and distributed systems - Security in mobile and wireless communications - Security in grid/cloud/pervasive computing - Authentication, authorization and accounting - Miscellaneous security issues Privacy Track - Privacy in Web-based applications and services - Privacy in database systems - Privacy in parallel and distributed systems - Privacy in grid/cloud/pervasive computing - Privacy in mobile and wireless communications - Privacy in e-commerce and e-government - Privacy in network deployment and management - Privacy and trust - Privacy and security - Privacy and anonymity - Miscellaneous privacy issues Organisation Committee General Chairs: Jiaguang Sun, Tsinghua University, China Ivan Stojmenovic, University of Ottawa, Canada Program Chair: Yunhao Liu, Tsinghua University, China Publicity Chairs: Sandra Sendra Compte, Polytechnic University of Valencia, Spain Haojin Zhu, Shanghai Jiao Tong University, China Xiaodong Lin, University of Ontario Institute of Technology, Canada Workshop Chairs: Yang Xiang, Deakin University, Australia Kouichi Sakurai, Kyushu University, Japan Publication Chair: Jemal Abawajy, Deakin University, Australia Steering and Program Committees: Please see http://www.greenorbs.org/TrustCom2014/

1 0

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Wilfried Woeber 25 Apr '14

25 Apr '14

A couple of observations, fwiw, and no, I'm not going to assess the role of brokers :-) In general, let me start with the statement that I support all ideas to get rid of the different shapes and colours of address blocks. And that actually includes Legacy, as they are simply PI, just a tad older... How to deal with moving address space from a PI assignment to a different party? Well, I can see 2 *substantially* different scenarios: 1) the current holder of the address block doesn't need *all of it* any longer (and wants to get money from an interested party, but that's a side issue). 2) the current holder of the address block doesn't need *any* of the addresses any longer and wants to transfer the full block, in one chunk or in smaller pieces. Nr. 1 is pretty easy, and possible already or really soon now: convert the PI block to PA, thus become an LIR, and proceed according to the rules. Nr. 2 is more tricky. First of all, there was a good reason, why the resource was tightly bound to the requester. That background and assumption is also part of the basis for the low annual fee of €50,- per resource. Now, as soon as the original criteria are no longer in place, the resource MUST be returned. A PI holder offering the *full block* to an interested party (for money or for free) obviously matches that provision. The resource needs to get returned to the pool. So, why would we want to bend into this direction or that direction to create a special case for Nr. 2 to circumvent the existing policy? Just because some money is seen on the horizon? Which gets me to the point of *not* supporting this proposal! Wilfried.

7 8

2014-01 Draft Document and Impact Analysis will be produced (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 22 Apr '14

22 Apr '14

Dear colleagues, The discussion period for the proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-01 Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by David Monosov 21 Apr '14

21 Apr '14

Dear address-policy-wg, With such a policy in place, IP address broker needs to offers potential IP space buyers only a marginally lower price than the cost of being a LIR for the expected duration of use of the IPv4 PI space in question (and requesting this IP space from the last /8 or realizing an inter-LIR PA transfer) in order to create a perverse incentive for IPv4 address buyers to line the pockets of IP address brokers instead of stepping up and becoming members of the RIPE NCC. This policy appears to fail the most basic economic incentive test, and will in practice create a secondary and desirable 'asset class' from which IP transfer brokers benefit considerably more than the community as a whole. To deconstruct the arguments which purportedly support this proposal: a) "Currently the policy for PA and PI space isn’t the same and people don’t understand the difference between the various types of IP Space." Ignoring that this is a superfluous argument which goes in the face of nearly two decades of policy, this appears to argue that letting PI space be sold would somehow eliminate this distinction. This, of course, is disingenuous. If this is indeed the goal, a policy should be introduced to allow PI space to be converted into PA space and assigned to a LIR - this will enable its "transferability" and eliminate many of the concerns raised above by ensuring that all holders of "transferred" IPv4 space are first rate LIRs who contribute financially toward the operation of the RIPE NCC and fall under all obligations imposed on such. b) "There is already some trade in PI space, however it is not documented or registered, which doesn’t help to keep the registry updated." This is also disingenuous, as every IPv4 PI space holder has a contract with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, regularly verify and update these details in cooperation with the registrant. c) "A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger or acquisition of infrastructure." If a legitimate transfer has occurred as part of legitimate organizational restructuring, there is no disincentive to document it. The disincentive only exists if the registrant fears the transfer's legitimacy may be questioned, which is exactly the intention for non-transferable, end-user assigned PI space. Such transferred allocations could, and should, per current policy, be simply reclaimed. d) "We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the RIPE NCC to be able to transfer the IP space." Alternatively, elements which "bend the rules and truth" could be identified, and, within reason, have their resources reclaimed. Certainly, such enforcement can never be perfect - but speed traps also do not catch 100% of speeding cars. With a few documented instances, this would create tremendous uncertainty and disincentive to engage in such practices from the buy side, as it will mean that any resources acquired in this manner may very suddenly get written off. e) "The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it." See (a). It seems very disingenuous to make PI and PA "equal for purposes of transferability" but maintain the distinction in all other aspects. To summarize, I strongly object to this policy in its current form. I concur that the mobility of IPv4 PI space toward those who value it most is desirable - on the condition that this mobility occurs as part of a wider reform to eliminate the distinction between PA and PI status of IPv4 resources. This should result in equitable burden for all resource holders toward the RIPE NCC instead of lining the pockets of IP address brokers by helping address space speculators which presently hoard IPv4 PI assignments against policy realize profits at the expense of the community. -- Respectfully yours, David Monosov

5 7

Policy Proposal Implemented: 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text"
by Marisol Estrada 17 Apr '14

17 Apr '14

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text". In accordance with the new policy, the RIPE NCC will no longer require LIRs to complete a forecast-based documentation of need when requesting /22 IPv4 allocations, when making assignments to End Users, or when requesting approval for IPv4 transfers. Accordingly, this also means that the "Assignment Window" is no longer applicable. As a result, we have updated the following request forms and supporting notes: - IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-608 - Supporting Notes For The IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-609 - IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-610 - Supporting Notes for the IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-611 Both the Provider Aggregatable (PA) Assignment Request Form and the Supporting Notes for Provider Aggregatable (PA) Assignment Request Form have also been removed due to this change. RIPE NCC members can still access the list of their past assignments approved by the RIPE NCC as well as their Assignment Window history, which is available in the "Archive" section of the LIR Portal. The IP Analyser functionality of the LIR Portal has been changed, as explained at: https://labs.ripe.net/Members/AlexBand/modifications-to-the-ip-analyser-to-… The archived policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2013-03 The updated RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: http://www.ripe.net/ripe/docs/ripe-606 Kind regards Marisol Estrada RIPE NCC Registration Services

1 0

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