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

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by James Blessing 01 May '14

01 May '14

On 30 April 2014 14:28, Marco Schmidt <mschmidt(a)ripe.net> wrote: > https://www.ripe.net/ripe/policies/proposals/2014-03 > Other than the use cases suggested in the document (which could be achieved using private ASNs) is there a reason for this that I'm missing? With other discussions about recovering non globally routed ASNs this just seem odd J -- James Blessing 07989 039 476

5 4

Re: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Fredy Kuenzler 01 May '14

01 May '14

Am 30.04.2014 15:28, schrieb Marco Schmidt: > A proposed change to RIPE Document ripe-525, "Autonomous System (AS) > Number Assignment Policies" is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 I support this proposal. However I suggest a small change in the text: "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing or private AS Number." should be "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing AS Number." Since we arrived in the 32bit-ASN century, private ASN should not matter anymore, i.e. noone should be forced to use private ASN permanently. Re hoarding: If someone thinks hoarding of AS206832 to AS207363 is useful, so be it... -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/

1 0

Re: [address-policy-wg] [policy-announce] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Richard Hartmann 01 May '14

01 May '14

Support. Richard Sent by mobile; excuse my brevity.

1 0

2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer)
by Marco Schmidt 01 May '14

01 May '14

Dear colleagues, The Discussion Period for the proposal 2014-02, "Allow IPv4 PI transfer" has been extended until 23 May 2014. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 30 Apr '14

30 Apr '14

Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 29 May 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE 67 Address Policy WG Draft Minutes
by Marco Schmidt 30 Apr '14

30 Apr '14

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 67 have now been published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-67 Please let us know any corrections or amendments. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

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