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

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

05 May '14

* Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-03 Makes sense to me. Tore

1 0

Fwd: Updates to RIPE-500: Policy Development in RIPE
by Sander Steffann 04 May '14

04 May '14

Hello WG, Work is being done on ripe-500, the Policy Development Process (PDP). As the PDP is quite important to the Address _Policy_ Working Group this is probably of interest to you. Hans Petter Holen, our RIPE Deputy Chair, has posted the proposed new revision on the RIPE list. For those of you who are not subscribed to the RIPE list: here is a copy of his message. If you want to comment on this proposed new text please do so on the RIPE list. Sincerely, Sander APWG Co-chair Begin doorgestuurd bericht: > Van: Hans Petter Holen <hph(a)oslo.net> > Onderwerp: Updates to RIPE-500: Policy Development in RIPE > Datum: 4 mei 2014 13:55:55 CEST > Aan: ripe-list(a)ripe.net > > Dear colleagues, > The Working-group chairs have for some time been discussing how to improve the Policy Development Process as described in RIPE-500. A small task force with Brian Nisbet as the coordinator and Ondrej Filip, Nick Hilliard and Hans Petter Holen as members has worked out the final details in the text. > > The wg-chairs have reached consensus on the attached proposal. > > The main change in the PDP is to allow the Working-group Chairs of the working-group developing the policy to declare consensus. > > This allows for a more timely conclusion of the PDP, but also allows for the Working-group chairs collectively to act as an appeals body. > > I am circulating the new text now for community review and the intent is to put this in place at the coming RIPE meeting. > > > Yours Sincerely, > > Hans Petter Holen > RIPE Deputy Chair > >

1 0

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