From John.Collins at BIT.admin.ch Wed Aug 5 09:05:23 2015 From: John.Collins at BIT.admin.ch (John.Collins at BIT.admin.ch) Date: Wed, 5 Aug 2015 07:05:23 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <5D23C81DA72B5A4CACB3B12075F7B347D7E73768@SB00112A.adb.intra.admin.ch> Marco Schmidt wrote on 9.7.2015: > We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 August 2015. we support the proposal, therefore +1 from us. The interpretation of the NCC in their impact analysis strikes a good balance between too much liberalness, which might lead to undue waste of address space, and the constraints of the current policy. We are hopeful that the NCC has found a measureable and impartial way to identify the justifiable size of large allocations. The new policy would allow new address plan structuring arguments to be considered by the NCC - and this is important. Regards, John Collins LIR ch.swissgov From gert at space.net Thu Aug 6 16:04:38 2015 From: gert at space.net (Gert Doering) Date: Thu, 6 Aug 2015 16:04:38 +0200 Subject: [address-policy-wg] Consensus Reached on 2015-02 (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150806140438.GA97397@Space.Net> Dear Address-Policy WG, On Wed, Jul 08, 2015 at 11:10:56AM +0200, Marco Schmidt wrote: > The proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation", > is now in its Concluding Phase. > > The Address Policy Working Group co-Chairs have declared that consensus for > the proposal has been reached and it will now move to Last Call. [..] > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net > before 6 August 2015. The Concluding Phase has now ended. To our total surprise, no uproar of complaints about this proposal happened. More precisely, no comment was sent in Last Call at all - which, in this particular phase, is considered agreement with the proposal. Without further ado, I declare final consensus on this policy proposal! Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mschmidt at ripe.net Mon Aug 10 12:48:16 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 10 Aug 2015 12:48:16 +0200 Subject: [address-policy-wg] 2015-02 Proposal Accepted and Implemented (Keep IPv6 PI When Requesting IPv6 Allocation) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-641, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. This policy change removes the requirement that LIRs return their IPv6 Provider Independent (PI) assignment when requesting an IPv6 allocation if there are no specific routing requirements to justify both. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 The new RIPE Document is called ripe-650 and is available at: https://www.ripe.net/publications/docs/ripe-650 This proposal is implemented with immediate effect. Regards Marco Schmidt Policy Development Officer RIPE NCC From job at instituut.net Tue Aug 11 11:15:36 2015 From: job at instituut.net (Job Snijders) Date: Tue, 11 Aug 2015 11:15:36 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 Message-ID: <20150811091536.GL53906@Vurt.local> Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job From randy at psg.com Tue Aug 11 11:18:49 2015 From: randy at psg.com (Randy Bush) Date: Tue, 11 Aug 2015 18:18:49 +0900 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811091536.GL53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> Message-ID: > I've noted as an argument opposing this proposal: "An adversary could > try to deplete the pool of available ASNs." If someone has a workable > suggestion how to resolve that in policy, I am all ears, but I wouldn't > mind a pragmatic approach where we just trust our community and deal > with issues if and when they arise. after all, that has worked out so well for ipv4 space randy From sebastian at karotte.org Tue Aug 11 11:36:03 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 11 Aug 2015 11:36:03 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811091536.GL53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> Message-ID: <20150811093603.GA29309@danton.fire-world.de> * Job Snijders [2015-08-11 11:18]: > > I've noted as an argument opposing this proposal: "An adversary could > try to deplete the pool of available ASNs." If someone has a workable > suggestion how to resolve that in policy, I am all ears, but I wouldn't > mind a pragmatic approach where we just trust our community and deal > with issues if and when they arise. As we all have seen how well "our community" works for IPv4 from the last-/8 I would not like to see something like that happen again. We could use rough consensus to decide if someone gets a new AS number. (I'm only 85% joking). Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 581 bytes Desc: Digital signature URL: From tore at fud.no Tue Aug 11 12:09:04 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 11 Aug 2015 12:09:04 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811091536.GL53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> Message-ID: <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> Hi Job, > Following the outcome of the vote on the new charging scheme, the > inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck > as '1000', but most importantly the incessant need to obtain ASNs when > one needs them, we have a new simpler version of the proposal ready for > your consideration and review: > > """ > A new AS Number is only assigned when the End User has a need that > cannot be satisfied with an existing AS Number. RIPE NCC will > record, but not evaluate this need. It occurs to me that in the absence of an economic disincentive against hoarding, there is not really any realistic way forward here except to have the NCC continue to evaluate the applicant's need. That is not to say that "need" must necessarily be equated with "multihoming", as it is today. Two possible approaches: 1) The ?Job and Saku scratches their own itch? variant: 2014-03 is changed to simply add its authors' use case(s) to a list of valid use cases (alongside multihoming). If another applicant has some other use case he feels should also be valid, he'll just have to submit his own itch-scratching proposal. 2) Ask the NCC to maintain a public out-of-policy list of valid use cases. Whenever a new applicant comes with potentialy valid use case currently not on the list, APWG could be consulted and greenlight it using a much more informal and fast/lightweight consensus determining procedure than the PDP (e.g., sending a mail to APWG describing the use case and asking if anyone sees any problems with it, if N weeks of silence, it's good). If it ends up being shot down, the applicant can always try his luck with the PDP instead. Tore From gert at space.net Tue Aug 11 12:13:36 2015 From: gert at space.net (Gert Doering) Date: Tue, 11 Aug 2015 12:13:36 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> References: <20150811091536.GL53906@Vurt.local> <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> Message-ID: <20150811101336.GF84167@Space.Net> Hi, On Tue, Aug 11, 2015 at 12:09:04PM +0200, Tore Anderson wrote: > 2) Ask the NCC to maintain a public out-of-policy list of valid use > cases. Whenever a new applicant comes with potentialy valid use case > currently not on the list, APWG could be consulted and greenlight it > using a much more informal and fast/lightweight consensus determining > procedure than the PDP (e.g., sending a mail to APWG describing the use > case and asking if anyone sees any problems with it, if N weeks of > silence, it's good). If it ends up being shot down, the applicant can > always try his luck with the PDP instead. I like this :-) - of course I'd like to hear what RS would have to say about it ("we can do this" vs. "there are too many different cases to make sense out of this", etc.) - but the general idea is nicely lightweight and flexible... Gert Doering -- no hats (this is not formal PDP anyway right now!) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From job at instituut.net Tue Aug 11 12:12:14 2015 From: job at instituut.net (Job Snijders) Date: Tue, 11 Aug 2015 12:12:14 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811091536.GL53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> Message-ID: <20150811101214.GQ53906@Vurt.local> Hi APWG, It should be noted that the below message is an "in-between poll" to seek guidance for the next formal version. As Gert aptly pointed out to me, technically I now started a "random discussion". :-) Anyhow, please help us address the adversary argument. Kind regards, Job On Tue, Aug 11, 2015 at 11:15:36AM +0200, Job Snijders wrote: > Dear APWG, > > Following the outcome of the vote on the new charging scheme, the > inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck > as '1000', but most importantly the incessant need to obtain ASNs when > one needs them, we have a new simpler version of the proposal ready for > your consideration and review: > > """ > A new AS Number is only assigned when the End User has a need that > cannot be satisfied with an existing AS Number. RIPE NCC will > record, but not evaluate this need. > > The Autonomous System's routing policy should be defined with RPSL > in the RIPE RIPE Database. > > The RIPE NCC will assign the AS Number directly to the End User upon > a request that is properly submitted to the RIPE NCC either directly > or through a sponsoring LIR. AS Number assignments are subject to > the policies described in the RIPE Document, "Contractual > Requirements for Provider Independent Resource Holders in the RIPE > NCC Service Region". > """ > > diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 > full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt > > I've noted as an argument opposing this proposal: "An adversary could > try to deplete the pool of available ASNs." If someone has a workable > suggestion how to resolve that in policy, I am all ears, but I wouldn't > mind a pragmatic approach where we just trust our community and deal > with issues if and when they arise. > > Kind regards, > > Job From job at instituut.net Tue Aug 11 12:24:19 2015 From: job at instituut.net (Job Snijders) Date: Tue, 11 Aug 2015 12:24:19 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811101336.GF84167@Space.Net> References: <20150811091536.GL53906@Vurt.local> <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> <20150811101336.GF84167@Space.Net> Message-ID: <20150811102419.GT53906@Vurt.local> On Tue, Aug 11, 2015 at 12:13:36PM +0200, Gert Doering wrote: > On Tue, Aug 11, 2015 at 12:09:04PM +0200, Tore Anderson wrote: > > 2) Ask the NCC to maintain a public out-of-policy list of valid use > > cases. Whenever a new applicant comes with potentialy valid use case > > currently not on the list, APWG could be consulted and greenlight it > > using a much more informal and fast/lightweight consensus determining > > procedure than the PDP (e.g., sending a mail to APWG describing the use > > case and asking if anyone sees any problems with it, if N weeks of > > silence, it's good). If it ends up being shot down, the applicant can > > always try his luck with the PDP instead. This sounds like a lot of work. The complicated process would hurt legitimate users, as it is safe to assume an intentional haorder will just lie to the NCC to get the resources. "Let me see what is whitelisted... Sure... i have l3vpns.. sure..." > I like this :-) - of course I'd like to hear what RS would have to say > about it ("we can do this" vs. "there are too many different cases to > make sense out of this", etc.) - but the general idea is nicely > lightweight and flexible... A year ago Martin Hannigan remarked: "Why isn't "I'm connecting to a network and speaking BGP" with at least one peer good enough?" I agree with that sentiment. It might be interesting if we could shift the discussion away from "How to justify to RIPE NCC how you run your network" to a slightly different angle: "Helping the community prevent hoarding". Nothing more, nothing less. Kind regards, Job From swmike at swm.pp.se Tue Aug 11 12:32:53 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Aug 2015 12:32:53 +0200 (CEST) Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811091536.GL53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> Message-ID: On Tue, 11 Aug 2015, Job Snijders wrote: > I've noted as an argument opposing this proposal: "An adversary could > try to deplete the pool of available ASNs." If someone has a workable > suggestion how to resolve that in policy, I am all ears, but I wouldn't > mind a pragmatic approach where we just trust our community and deal > with issues if and when they arise. Cap the number of ASNs handed out until the policy is evaluated. RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 has been reached, please come back and tell us how it went. If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't used up a huge amount of this limited resource. Also, having an ASN costs money per year, right? So if someone wants to sit on 1000 ASNs, this will actually cost significant money? -- Mikael Abrahamsson email: swmike at swm.pp.se From job at instituut.net Tue Aug 11 12:44:21 2015 From: job at instituut.net (Job Snijders) Date: Tue, 11 Aug 2015 12:44:21 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: References: <20150811091536.GL53906@Vurt.local> Message-ID: <20150811104421.GV53906@Vurt.local> On Tue, Aug 11, 2015 at 12:32:53PM +0200, Mikael Abrahamsson wrote: > On Tue, 11 Aug 2015, Job Snijders wrote: > >I've noted as an argument opposing this proposal: "An adversary could try > >to deplete the pool of available ASNs." If someone has a workable > >suggestion how to resolve that in policy, I am all ears, but I wouldn't > >mind a pragmatic approach where we just trust our community and deal with > >issues if and when they arise. > > Cap the number of ASNs handed out until the policy is evaluated. > > RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 > has been reached, please come back and tell us how it went. > > If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't > used up a huge amount of this limited resource. Very interesting approach! We'd call it the "Anything goes" ASN pool. Arguably this approach mitigates the risk of depleting the entire pool. > Also, having an ASN costs money per year, right? So if someone wants to sit > on 1000 ASNs, this will actually cost significant money? ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on your bill. Unless the charging scheme is updated next year to bring changes in this area. The last AGM meeting made it clear to me that the community does not want to associate a linear cost with ASN assignment. Kind regards, Job From swmike at swm.pp.se Tue Aug 11 13:00:58 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Aug 2015 13:00:58 +0200 (CEST) Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811104421.GV53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> <20150811104421.GV53906@Vurt.local> Message-ID: On Tue, 11 Aug 2015, Job Snijders wrote: > ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on > your bill. Unless the charging scheme is updated next year to bring > changes in this area. The last AGM meeting made it clear to me that the > community does not want to associate a linear cost with ASN assignment. The LIR with the largest amount of ASNs, how many ASNs do they have? Why not say it starts to cost money after 3x this current value and for RIPE to report back when single ASN has more than 2x current max value? If (for instance) current max is 100 ASNs then limiting (at least for now) to 300ASNs per LIR might be a way to go? I have no idea how hard it is for RIPE to handle these limits though, I don't want to make up a lot of rules just hapazardly that then causes significant CAPEX/OPEX for RIPE. -- Mikael Abrahamsson email: swmike at swm.pp.se From elvis at velea.eu Tue Aug 11 13:02:13 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 11 Aug 2015 14:02:13 +0300 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811104421.GV53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> <20150811104421.GV53906@Vurt.local> Message-ID: <55C9D635.2050700@velea.eu> Hi, On 11/08/15 13:44, Job Snijders wrote: > On Tue, Aug 11, 2015 at 12:32:53PM +0200, Mikael Abrahamsson wrote: >> On Tue, 11 Aug 2015, Job Snijders wrote: >>> I've noted as an argument opposing this proposal: "An adversary could try >>> to deplete the pool of available ASNs." If someone has a workable >>> suggestion how to resolve that in policy, I am all ears, but I wouldn't >>> mind a pragmatic approach where we just trust our community and deal with >>> issues if and when they arise. >> Cap the number of ASNs handed out until the policy is evaluated. >> >> RIPE is allowed to hand out $NUMBER ASNs under this policy, when $NUMBER/2 >> has been reached, please come back and tell us how it went. >> >> If $NUMBER is in the 10k-50k range, and we're talking 32bit ASNs, we haven't >> used up a huge amount of this limited resource. > Very interesting approach! We'd call it the "Anything goes" ASN pool. > Arguably this approach mitigates the risk of depleting the entire pool. I also like this approach. I would even go further and say that only 32bit ASNs should be handed out using this approach. 16bit ASNs (the few hundred still remaining) should be handed out only based on multihoming/verification requirements while 32bit ASNs could be handed out upon request. I believe that using a very small (*) cap may require us to re-visit this proposal in a short period of time. I propose to cap at 1/8 of the 32bit ASN pool (~4 billion divided by # of RIRs and then divided by 8 = approx 100million) and re-visit the ASN policy once we have been notified by the RIPE NCC that we are 6-12 months into reaching this cap or when we notice that something has gone wrong and needs to be changed. regards, elvis (*) as the ASN32 pool is over 4 billion, 50k out of 4billion is very small From job at instituut.net Tue Aug 11 13:05:23 2015 From: job at instituut.net (Job Snijders) Date: Tue, 11 Aug 2015 13:05:23 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: References: <20150811091536.GL53906@Vurt.local> <20150811104421.GV53906@Vurt.local> Message-ID: <20150811110523.GW53906@Vurt.local> On Tue, Aug 11, 2015 at 01:00:58PM +0200, Mikael Abrahamsson wrote: > On Tue, 11 Aug 2015, Job Snijders wrote: > > >ASNs have no associated cost. Sitting on 1, 1k or 10k has no impact on > >your bill. Unless the charging scheme is updated next year to bring > >changes in this area. The last AGM meeting made it clear to me that the > >community does not want to associate a linear cost with ASN assignment. > > The LIR with the largest amount of ASNs, how many ASNs do they have? It is easier to focus on the End User with the largest amount of ASNs rather then the middle-person the LIR. I believe at a previous RIPE meeting it was highlighted in the APWG session that the largest consumer of ASNs has 100 ASNs (ignoring legacy). > Why not say it starts to cost money after 3x this current value and > for RIPE to report back when single ASN has more than 2x current max > value? If (for instance) current max is 100 ASNs then limiting (at > least for now) to 300ASNs per LIR might be a way to go? > > I have no idea how hard it is for RIPE to handle these limits though, I > don't want to make up a lot of rules just hapazardly that then causes > significant CAPEX/OPEX for RIPE. APWG cannot and will not decide on the charging scheme. As I mentioned before an attempt to start charging for ASNs was shot down by the last AGM. Kind regards, Job From nick at inex.ie Tue Aug 11 13:12:48 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 11 Aug 2015 12:12:48 +0100 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: <55568496.9040907@foobar.org> References: <55568496.9040907@foobar.org> Message-ID: <55C9D8B0.3050605@inex.ie> AP-WG, I've included below an email which was sent to the authors of 2014-03 as a followup to this email (dated Sat May 16 01:40:13 CEST 2015): > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-May/009982.html Saku, Job and I discussed these ideas but the discussions didn't come to anything. The suggestions below don't fix everything with ASN assignment because 100% solutions don't work. However they provide a practical and workable mechanism which trivially deals with the vast majority of cases, and provides a known working mechanism for creating a run-out pool for ASN16, all based on policy principals which are either in place for other resources, or else which have been tried and tested in practice. I'm planning to write this up as a formal policy proposal in the next short while, as an alternative to 2014-03. If anyone has suggestions or tweaks, please feel free to bring them up. Nick -------- Forwarded Message -------- Subject: Suggestions on a new asn assignment policy Date: Sat, 16 May 2015 00:43:18 +0100 From: Nick Hilliard To: Job Snijders , Saku Ytti CC: AP WG Chairs Saku, Job, WG Chairs, re: my email to ap-wg of a couple of moment ago, here are some ideas I've been mulling over: - if an end user wants a single ASN32 and they don't already have one, they should get it on the basis of entitlement. - if an end user wants more than one ASN32, they should get it on the basis of a needs-based policy. - if an end user wants one or more ASN16s, they should get it on the basis of an needs-based policy, unless the remaining pool of ASN16s has reached a certain threshold - regardless of the requirement, end users may only receive one ASN16 from the remaining pool, and this should be assigned on the basis of a needs-based policy. The needs criteria can be collated by both operator input and by taking a look at historical assignment reasons: the ripe ncc have 25 years of experience in assigning ASNs and have a large database of reasons that end-users have put forward on their application forms. But we already have a pretty good idea of what this list should include. Basing a new policy along the lines of these principals will provide the following: - no requirement for charging - trivially deals with the most common case, namely assignment of a single asn32 - a runout policy for asn16s which both has well-understood limitations and will probably be palatable to the ripe community, as it's proposed on a similar basis to the last /8 + will be subject to 24m rule. - no practical way of asn32 resource exhaustion because each application will be individually evaluated by an IPRA (either on the basis of 2007-01 for end-user authentication or else on the basis of needs evaluation once that authentication has been completed). - continuation of existing ASN16 policy until a hard limit is hit, after which a run-out policy will apply - conceptually very similar to ipv4 / ipv6 policy. - hopefully an end to lies on asn application forms for asn32s I don't know what you guys feel about these suggestions, but I think they could be used to create something a good deal better than what we have right now. If you want to use these suggestions to form 2014-03 v3.0, you are welcome to do so, but I would ask you kindly to acknowledge my input as appropriate. Alternatively, if either or both of you have got tired of 2014-03, I would be happy to take up the baton and run with something along the lines of the above. Nick From randy at psg.com Tue Aug 11 13:26:28 2015 From: randy at psg.com (Randy Bush) Date: Tue, 11 Aug 2015 20:26:28 +0900 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: <55C9D8B0.3050605@inex.ie> References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: > - if an end user wants a single ASN32 and they don't already have one, they > should get it on the basis of entitlement. > > - if an end user wants more than one ASN32, they should get it on the basis > of a needs-based policy. > > - if an end user wants one or more ASN16s, they should get it on the basis > of an needs-based policy, unless the remaining pool of ASN16s has reached a > certain threshold > > - regardless of the requirement, end users may only receive one ASN16 from > the remaining pool, and this should be assigned on the basis of a > needs-based policy. those last two do not correlate and, does end user include lir? randy From David.Huberman at microsoft.com Tue Aug 11 13:41:16 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Aug 2015 11:41:16 +0000 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: <55C9D8B0.3050605@inex.ie> References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: Respectfully, I think the WG is trying to solve a problem which doesn't exist. And I STRONGLY dislike policy discussions and text which penalize 99.9% of the people just trying to operate a network because of the 0.1% of idiots who might think it's fun to do something stupid. I believe ASNs should be given out to LIRs in an on-demand basis without cost and in an automated fashion. If at some point in the future, the NCC or community discovers some child has abused the system and taken an absurd number of ASNs, the NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the RIPE NCC Standard Service Agreement. David R Huberman Principal, Global IP Addressing Microsoft Corporation From ebais at a2b-internet.com Tue Aug 11 13:54:54 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 11 Aug 2015 13:54:54 +0200 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: <014301d0d42c$910444d0$b30cce70$@a2b-internet.com> I fully agree with David on this. The initial intent of the policy was to remove the multi-homing requirement when requesting for an AS number. Any stop that the NCC will use in their automated process of provisioning to detect that someone is abusing the system and stop further provisioning is all up to the NCC to implement. For all I care, they stop their automated provisioning after assigning 50 AS's within the last 12 months to $LIR.. And do additional requests manually ... It should not be at the APWG to dictate how they should implement this in software or policy imho. The AGM showed that the membership decided there will be no charge for ASn's for the near future. For a simple policy change like this, it is amazing how much we are looking at eachother in order to fluff this up ... If someone has a specific requirement for a 16 bit AS number ( yes they are on short supply atm .. ) feel free to ask the justification for it, or to ask if they can deal with a 32 bit ASn... If they can't and they really need a 16 Bit AS and the NCC doesn't have any anymore .. There is a transfer policy for AS numbers ... but let's not put more clutter in the policy than strictly required. Erik Bais From swmike at swm.pp.se Tue Aug 11 14:03:04 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Aug 2015 14:03:04 +0200 (CEST) Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: On Tue, 11 Aug 2015, David Huberman wrote: > If at some point in the future, the NCC or community discovers some > child has abused the system and taken an absurd number of ASNs, the NCC > has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the > RIPE NCC Standard Service Agreement. I just read 6.3, 9.3 and 9.4. I don't see which of these I would be in violation of if I went to RIPE NCC and asked for 10k ASNs "because I need them" under the proposed new policy of just recording reason. With the proposed policy of just recording reason given, I don't see how the resources can be revoked (because I have given reason and those reasons have been registered by RIPE NCC), at least not referring to 6.3, 9.3 and 9.4. -- Mikael Abrahamsson email: swmike at swm.pp.se From David.Huberman at microsoft.com Tue Aug 11 14:13:29 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Aug 2015 12:13:29 +0000 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: > I just read 6.3, 9.3 and 9.4. I don't see which of these I would be in violation of > if I went to RIPE NCC and asked for 10k ASNs "because I need them" under > the proposed new policy of just recording reason. Correct! Which is why I don't think I like the new policy. Existing ASN policy suffices if we simply strike one sentence about multi-homing (and then ask the NCC to generally automate the implementation). Existing ASN policy references the criteria in RFC1930 as justification for an ASN, and an audit can rely on the text to clear out any stupidity. Yes? From swmike at swm.pp.se Tue Aug 11 14:23:14 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Aug 2015 14:23:14 +0200 (CEST) Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: On Tue, 11 Aug 2015, David Huberman wrote: > Existing ASN policy suffices if we simply strike one sentence about > multi-homing (and then ask the NCC to generally automate the > implementation). Existing ASN policy references the criteria in RFC1930 > as justification for an ASN, and an audit can rely on the text to clear > out any stupidity. > > Yes? Hm, so you want to move to a model that does post-auditing in case of suspected misbehavior (which would involve revokation in case of abuse has been detected), instead of doing pre-auditing of each request? So this sounds like the model employed for DNS domains. This requires committes of impartial people judging the facts and blah blah blah. It also involves text how this process works. So while I am not opposed to this suggestion, I fear that's it's more complicated to implement than what might be obvious at first glance. -- Mikael Abrahamsson email: swmike at swm.pp.se From David.Huberman at microsoft.com Tue Aug 11 14:33:13 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Tue, 11 Aug 2015 12:33:13 +0000 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: > Hm, so you want to move to a model that does post-auditing in case of > suspected misbehavior (which would involve revokation in case of abuse has > been detected), instead of doing pre-auditing of each request? Correct. Automate and remove the hostmasters from making engineering decisions about OUR networks. > So this sounds like the model employed for DNS domains. This requires > committes of impartial people judging the facts and blah blah blah. It also > involves text how this process works. > > So while I am not opposed to this suggestion, I fear that's it's more > complicated to implement than what might be obvious at first glance. Strongly disagree. It relies on the NCC to do what the NCC has done well for 25 years: be a numbers registry. Where fraud is suspected or discovered, act in the best interests of the Internet. The NCC is well practiced in detecting and fighting fraud, and continually improves in this regard. Trust the NCC staff to do their jobs well; they know what they're doing. From swmike at swm.pp.se Tue Aug 11 15:03:04 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 Aug 2015 15:03:04 +0200 (CEST) Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: On Tue, 11 Aug 2015, David Huberman wrote: > Strongly disagree. It relies on the NCC to do what the NCC has done > well for 25 years: be a numbers registry. Where fraud is suspected or > discovered, act in the best interests of the Internet. The NCC is well > practiced in detecting and fighting fraud, and continually improves in > this regard. Trust the NCC staff to do their jobs well; they know what > they're doing. Well, I would like to hear this from NCC itself in that case. From what I can see, RIPE NCC doesn't currently have to necessary text in the contracts and policies to enable it to do what you want it to do. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at inex.ie Tue Aug 11 15:15:24 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 11 Aug 2015 14:15:24 +0100 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: <55C9F56C.9060604@inex.ie> On 11/08/2015 12:26, Randy Bush wrote: > those last two do not correlate they correlate until the run-out pool has been reached, at which point the last point takes precedence. > and, does end user include lir? always has. Nick From nick at inex.ie Tue Aug 11 15:27:50 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 11 Aug 2015 14:27:50 +0100 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: <55C9F856.7030405@inex.ie> David, thanks for your comments. On 11/08/2015 12:41, David Huberman wrote: > Respectfully, I think the WG is trying to solve a problem which doesn't > exist. the policy has one problem now and is facing ASN16 depletion in the future. The problem now is that you can only get an ASN if you are "multihomed" and there are a bunch of situations where this is causing unnecessary problems. People work around this by lying on the application form and this is not good stewardship of number resources. Regarding depletion, we have an option of viewing this as a problem, or not. I view it as a problem because BGP community support for ASN32 is very poor, and future entrants to the IP market will be penalised for being future entrants. There are substantial regulatory problem associated with existing market players effectively locking out future players, and given that the RIPE NCC has a monopoly in ip number resource assignments in this part of the world, this is an issue which would be best avoided if possible. > And I STRONGLY dislike policy discussions and text which penalize > 99.9% of the people just trying to operate a network because of the 0.1% > of idiots who might think it's fun to do something stupid. The suggestion provides for an ASN32 on demand to anyone who wants one without any justification. If you look at the numbers, this means that about 85% of ASN assignments can be automated fully. This is a serious win in terms of registry efficiency which directly benefits those 85% of assignments. The remaining 15% will have more relaxed policies in place after their first ASN assignment until the ASN16 pool has reached a certain point. Future market entrants will benefit by being given a toe-hold in the door, in the same way that future market entrants are given a toe-hold in the door with the last /8 ipv4 allocation policy. I.e. we already have a precedent for community support for this. > I believe ASNs should be given out to LIRs in an on-demand basis without > cost and in an automated fashion. At current run-rates, there are a 3-4 years of ASN16s left. This wouldn't be a problem if ASN32s were semantically identical to ASN16s, but unfortunately they are not. As has been pointed out repeatedly, there is a root cause problem here which is not being addressed by the IETF and if/when it's addressed, it will take may years to roll out - far longer than 3-4 years. > If at some point in the future, the NCC or community discovers some > child has abused the system and taken an absurd number of ASNs, the NCC > has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 of the > RIPE NCC Standard Service Agreement. As Mikael Abrahamsson points out, this is extremely difficult to implement in practice. Nick From ripe-wgs at radu-adrian.feurdean.net Tue Aug 11 22:42:23 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 11 Aug 2015 22:42:23 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811101336.GF84167@Space.Net> References: <20150811091536.GL53906@Vurt.local> <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> <20150811101336.GF84167@Space.Net> Message-ID: <1439325743.3825799.353722505.35D14515@webmail.messagingengine.com> On Tue, Aug 11, 2015, at 12:13, Gert Doering wrote: > I like this :-) - of course I'd like to hear what RS would have to say > about it ("we can do this" vs. "there are too many different cases to > make sense out of this", etc.) - but the general idea is nicely > lightweight and flexible... The idea is good, but I would really really want to see what does it give implementation-wise. Generally speaking a text like "interconnection with several (= how many ???) external (how do you really define external) entities" should cover the need for one AS. A second ASN (*autonomous* system) , well it should require a second "autonomous" system/entity respecting the same conditions. Now we should probably ask about NCC's capacity to evaluate what is "external" and "autonomous". For LIR creation it doesn't seem to be very effective at this task. It didn't seem very effective in the past for IP address allocation neither (criteria slightly different, but not so much). From ripe-wgs at radu-adrian.feurdean.net Tue Aug 11 22:51:15 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 11 Aug 2015 22:51:15 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811102419.GT53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> <20150811120904.4edc3c53@echo.ms.redpill-linpro.com> <20150811101336.GF84167@Space.Net> <20150811102419.GT53906@Vurt.local> Message-ID: <1439326275.3828885.353733681.4E9718D6@webmail.messagingengine.com> On Tue, Aug 11, 2015, at 12:24, Job Snijders wrote: > It might be interesting if we could shift the discussion away from "How > to justify to RIPE NCC how you run your network" to a slightly different > angle: "Helping the community prevent hoarding". Nothing more, nothing > less. Because AS numbers are still limited ressources. We are just making (since at least 5 years) the switch from 16-bit to 32-bit (which we found some time ago that it does not represent infinite). So for 16-bit ASNs, I find that yes, people should justify to RIPE NCC how do they run the network in order to get an unique number. For 32-bit ASNs, there is no problem YET, but let's not make a habit (quickly transformed into rule) about how to get exclusivity on unique numbers. From ripe-wgs at radu-adrian.feurdean.net Tue Aug 11 22:59:01 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 11 Aug 2015 22:59:01 +0200 Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 In-Reply-To: <20150811104421.GV53906@Vurt.local> References: <20150811091536.GL53906@Vurt.local> <20150811104421.GV53906@Vurt.local> Message-ID: <1439326741.3830289.353740017.5396F909@webmail.messagingengine.com> On Tue, Aug 11, 2015, at 12:44, Job Snijders wrote: > ASNs have no associated cost. To my understanding they do, but the cost is set to zero until further notice or vote. Someone please confirm or correct please ? From randy at psg.com Wed Aug 12 05:18:39 2015 From: randy at psg.com (Randy Bush) Date: Wed, 12 Aug 2015 12:18:39 +0900 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> Message-ID: > If at some point in the future, the NCC or community discovers some > child has abused the system and taken an absurd number of ASNs, the > NCC has the power to revoke the ASNs under sections 6.3, 9.3, and 9.4 > of the RIPE NCC Standard Service Agreement. there lurk lawyers. i don't think you want to go there. avoide as much as humanly possible. randy From d.baeza at tvt-datos.es Wed Aug 12 14:16:14 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 12 Aug 2015 14:16:14 +0200 Subject: [address-policy-wg] Promote the use of IRC Message-ID: <55CB390E.7000305@tvt-datos.es> Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #address-policy channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel From rb at isppro.de Wed Aug 12 14:29:50 2015 From: rb at isppro.de (Ronny Boesger) Date: Wed, 12 Aug 2015 14:29:50 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB390E.7000305@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> Message-ID: <55CB3C3E.2030903@isppro.de> Hi, +1 i think its worth a try, i am more on irc, so thats fine for me. Ronny Am 12.08.2015 um 14:16 schrieb Daniel Baeza (Red y Sistemas TVT): > Hi all, > > Yesterday, I've started a discussion in the member list about promoting > the use of IRC instead of Mail List for some kind of discussions, chit > chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #address-policy channel will be created and > administrated by the WG Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? > > Regards, > > --Daniel > -- Mit freundlichen Gruessen / kind regards, Ronny Boesger --- ISPpro Internet KG Lahnsteiner Strasse 7 07629 Hermsdorf Deutschland --- Web : http://www.isppro.de Email: rb at isppro.de Tel. : +49 (0) 3641 5044-32 Fax. : +49 (0) 3641 5044-33 Xing : http://www.xing.com/go/invite/4264552.b7506e --- Geschaeftsfuehrung: Dirk Seidel Handelsregister : Amtsgericht Jena, HRA 202638 Umsatzsteuer-Nr : 162/156/36600 Finanzamt ......: Jena USt-IdNr. ......: DE813856317 -------------- next part -------------- A non-text attachment was scrubbed... Name: rb.vcf Type: text/x-vcard Size: 285 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Wed Aug 12 14:44:30 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 12 Aug 2015 14:44:30 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB390E.7000305@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> Message-ID: <55CB3FAE.8090106@schiefner.de> Daniel, all - On 12.08.2015 14:16, Daniel Baeza (Red y Sistemas TVT) wrote: > Yesterday, I've started a discussion in the member list about promoting > the use of IRC instead of Mail List for some kind of discussions, chit > chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #address-policy channel will be created and > administrated by the WG Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? I would not go so far and call this a bad idea - but I am not at all easy about it either. Random (sub) groupings of whatever kind can and should most certainly be free to use whatever means of communication they see fit - but address policy stuff must IMHO stay on this mailing list. And only there! I for sure will not open yet another ingress channel I then would need to monitor. Cheers, -C. From jim at rfc1035.com Wed Aug 12 15:16:46 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 12 Aug 2015 14:16:46 +0100 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB3FAE.8090106@schiefner.de> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> Message-ID: <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> On 12 Aug 2015, at 13:44, Carsten Schiefner wrote: > I would not go so far and call this a bad idea So I will. :-) It's a bad idea. A Very Bad Idea. > - but I am not at all easy about it either. Me too! > Random (sub) groupings of whatever kind can and should most certainly be > free to use whatever means of communication they see fit - but address > policy stuff must IMHO stay on this mailing list. And only there! +100. The mailing list is supreme. We simply cannot have any confusion/ambiguity about how to make policy or which fora or tools are appropriate. I also do not like the idea of discussions about WG matters taking place behind (sort of) closed doors, for instance in a chat room or whatever which excludes those who cannot or will not have access to some IRC client. This would be the start of a very slippery and dangerous slope: policy development by twitter or facebook or dropbox or... If people want to use IRC or the latest flavour-of-the week Web2.0 fad, they are of course free to do so. But it must be clear to everyone doing this that whatever WG business gets discussed there has no significance of any sort until it comes to the mailing list. > I for sure will not open yet another ingress channel I then would need to > monitor. +100. Put bluntly, if a discussion about any WG matter does not take place on the mailing list, it simply didn't happen. From remco.vanmook at gmail.com Wed Aug 12 15:24:02 2015 From: remco.vanmook at gmail.com (remco van mook) Date: Wed, 12 Aug 2015 13:24:02 +0000 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> Message-ID: +1 on on everything that Jim just said. You're welcome to discuss any policy anywhere - in a pub, on IRC, on Facebook, other industry events, you name it - (and I know almost all of you do) but as long as it's not on the mailing list, it doesn't count for the policy development process. Also I'd like to echo the sentiment that it's yet another communications channel that I'd need to keep track of - I don't know where any of you finds the time to do so but I certainly don't have it. Best regards Remco (no hats) On Wed, Aug 12, 2015 at 3:17 PM Jim Reid wrote: > On 12 Aug 2015, at 13:44, Carsten Schiefner > wrote: > > > I would not go so far and call this a bad idea > > So I will. :-) It's a bad idea. A Very Bad Idea. > > > - but I am not at all easy about it either. > > Me too! > > > Random (sub) groupings of whatever kind can and should most certainly be > > free to use whatever means of communication they see fit - but address > > policy stuff must IMHO stay on this mailing list. And only there! > > +100. > > The mailing list is supreme. We simply cannot have any confusion/ambiguity > about how to make policy or which fora or tools are appropriate. > > I also do not like the idea of discussions about WG matters taking place > behind (sort of) closed doors, for instance in a chat room or whatever > which excludes those who cannot or will not have access to some IRC client. > This would be the start of a very slippery and dangerous slope: policy > development by twitter or facebook or dropbox or... > > If people want to use IRC or the latest flavour-of-the week Web2.0 fad, > they are of course free to do so. But it must be clear to everyone doing > this that whatever WG business gets discussed there has no significance of > any sort until it comes to the mailing list. > > > I for sure will not open yet another ingress channel I then would need to > > monitor. > > +100. Put bluntly, if a discussion about any WG matter does not take place > on the mailing list, it simply didn't happen. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doi at bva.bund.de Wed Aug 12 15:25:03 2015 From: doi at bva.bund.de (DOI (BIT I 5)) Date: Wed, 12 Aug 2015 13:25:03 +0000 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB3FAE.8090106@schiefner.de> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> Message-ID: +1 for Carsten's opinion I also prefer this mailing-list for AP discussions. Regards, Carsten Br?ckner -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Carsten Schiefner Gesendet: Mittwoch, 12. August 2015 14:45 An: Daniel Baeza (Red y Sistemas TVT) Cc: address-policy-wg at ripe.net Working Group Betreff: Re: [address-policy-wg] Promote the use of IRC Daniel, all - On 12.08.2015 14:16, Daniel Baeza (Red y Sistemas TVT) wrote: > Yesterday, I've started a discussion in the member list about > promoting the use of IRC instead of Mail List for some kind of > discussions, chit chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #address-policy channel will be created and > administrated by the WG Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and > some more irc servers linked to the Ripe one. > > What do you think? I would not go so far and call this a bad idea - but I am not at all easy about it either. Random (sub) groupings of whatever kind can and should most certainly be free to use whatever means of communication they see fit - but address policy stuff must IMHO stay on this mailing list. And only there! I for sure will not open yet another ingress channel I then would need to monitor. Cheers, -C. From zsako at iszt.hu Wed Aug 12 15:33:19 2015 From: zsako at iszt.hu (Janos Zsako) Date: Wed, 12 Aug 2015 15:33:19 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> Message-ID: <55CB4B1F.7040309@iszt.hu> Dear all, I can only agree with Jim and Remco. Let's keep the mailing list as an authoritative way to discuss the matters of any working group (not only Address Policy). Best regards, Janos 2015.08.12. 15:24 keltez?ssel, remco van mook ?rta: > +1 on on everything that Jim just said. You're welcome to discuss any policy anywhere - in a pub, on IRC, on Facebook, other industry events, you name it - (and I know almost all of you do) but as long as it's not on the mailing list, it doesn't count for the policy development process. > > Also I'd like to echo the sentiment that it's yet another communications channel that I'd need to keep track of - I don't know where any of you finds the time to do so but I certainly don't have it. > > Best regards > > Remco > (no hats) > > On Wed, Aug 12, 2015 at 3:17 PM Jim Reid > wrote: > > On 12 Aug 2015, at 13:44, Carsten Schiefner > wrote: > > > I would not go so far and call this a bad idea > > So I will. :-) It's a bad idea. A Very Bad Idea. > > > - but I am not at all easy about it either. > > Me too! > > > Random (sub) groupings of whatever kind can and should most certainly be > > free to use whatever means of communication they see fit - but address > > policy stuff must IMHO stay on this mailing list. And only there! > > +100. > > The mailing list is supreme. We simply cannot have any confusion/ambiguity about how to make policy or which fora or tools are appropriate. > > I also do not like the idea of discussions about WG matters taking place behind (sort of) closed doors, for instance in a chat room or whatever which excludes those who cannot or will not have access to some IRC client. This would be the start of a very slippery and dangerous slope: policy development by twitter or facebook or dropbox or... > > If people want to use IRC or the latest flavour-of-the week Web2.0 fad, they are of course free to do so. But it must be clear to everyone doing this that whatever WG business gets discussed there has no significance of any sort until it comes to the mailing list. > > > I for sure will not open yet another ingress channel I then would need to > > monitor. > > +100. Put bluntly, if a discussion about any WG matter does not take place on the mailing list, it simply didn't happen. > From gert at space.net Wed Aug 12 15:46:20 2015 From: gert at space.net (Gert Doering) Date: Wed, 12 Aug 2015 15:46:20 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB3FAE.8090106@schiefner.de> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> Message-ID: <20150812134620.GZ84167@Space.Net> Hi, On Wed, Aug 12, 2015 at 02:44:30PM +0200, Carsten Schiefner wrote: > Random (sub) groupings of whatever kind can and should most certainly be > free to use whatever means of communication they see fit - but address > policy stuff must IMHO stay on this mailing list. And only there! Emphasis on "what is not on this list has not happened" as far as formal(!) policy-making goes. OTOH, random sub-groups sitting together in a smoke-filled room, one or two or the other IRC channels, and throwing around ideas before bringing up something formal is a good thing - as long as it's clearly understood that this is informal. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mjehlenz at m2soft.com Wed Aug 12 15:57:29 2015 From: mjehlenz at m2soft.com (Moritz Julian Ehlenz) Date: Wed, 12 Aug 2015 15:57:29 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> Message-ID: <88F07C42-E4FB-4C9F-BC44-B121367A35E6@m2soft.com> Hi everyone, I do agree with Jim and Remco in that IRC would be yet another channel we?d all have to monitor. I therefore think that the relevant communication should stay on the existing mailing list. Best regards Moritz -- M2Soft GmbH Maarstra?e 65 53227 Bonn Telefon +49 228 823002-60 Amtsgericht Bonn 19 HRB 9727 Gesch?ftsf?hrung Marian Ehlenz Moritz Julian Ehlenz > Am 12.08.2015 um 15:24 schrieb remco van mook : > > +1 on on everything that Jim just said. You're welcome to discuss any policy anywhere - in a pub, on IRC, on Facebook, other industry events, you name it - (and I know almost all of you do) but as long as it's not on the mailing list, it doesn't count for the policy development process. > > Also I'd like to echo the sentiment that it's yet another communications channel that I'd need to keep track of - I don't know where any of you finds the time to do so but I certainly don't have it. > > Best regards > > Remco > (no hats) > > On Wed, Aug 12, 2015 at 3:17 PM Jim Reid wrote: > On 12 Aug 2015, at 13:44, Carsten Schiefner wrote: > >> I would not go so far and call this a bad idea > > So I will. :-) It's a bad idea. A Very Bad Idea. > >> - but I am not at all easy about it either. > > Me too! > >> Random (sub) groupings of whatever kind can and should most certainly be >> free to use whatever means of communication they see fit - but address >> policy stuff must IMHO stay on this mailing list. And only there! > > +100. > > The mailing list is supreme. We simply cannot have any confusion/ambiguity about how to make policy or which fora or tools are appropriate. > > I also do not like the idea of discussions about WG matters taking place behind (sort of) closed doors, for instance in a chat room or whatever which excludes those who cannot or will not have access to some IRC client. This would be the start of a very slippery and dangerous slope: policy development by twitter or facebook or dropbox or... > > If people want to use IRC or the latest flavour-of-the week Web2.0 fad, they are of course free to do so. But it must be clear to everyone doing this that whatever WG business gets discussed there has no significance of any sort until it comes to the mailing list. > >> I for sure will not open yet another ingress channel I then would need to >> monitor. > > +100. Put bluntly, if a discussion about any WG matter does not take place on the mailing list, it simply didn't happen. From office at ip4market.ru Wed Aug 12 16:21:50 2015 From: office at ip4market.ru (Staff) Date: Wed, 12 Aug 2015 17:21:50 +0300 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB390E.7000305@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> Message-ID: <55CB567E.2070500@ip4market.ru> Good idea, It's also good idea to setup web forum where all LIRs can discuss things and policies. Yuri at IP4market. On 12.08.2015 15:16, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi all, > > Yesterday, I've started a discussion in the member list about promoting > the use of IRC instead of Mail List for some kind of discussions, chit > chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #address-policy channel will be created and > administrated by the WG Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? > > Regards, > > --Daniel > From jkennedy at libertyglobal.com Wed Aug 12 16:37:01 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Wed, 12 Aug 2015 14:37:01 +0000 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <20150812134620.GZ84167@Space.Net> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> Message-ID: <13E63C78A6256E4A857726374FBF926E127EA2CF@NLAMSPEXMB022.upcit.ds.upc.biz> Hello, > random sub-groups sitting together in a smoke-filled room, one or two or the other IRC channels, and throwing around ideas before bringing up something formal is a good thing - as long as it's clearly understood that this is informal. +1 While no one wants this to snowball into multiple chat channels impossible to keep abreast of, I also think it's good to have a forum for informal chat. But I would urge minimalizing, say one sub-channel per WG. Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Gert Doering Sent: 12 August 2015 15:46 To: Carsten Schiefner Cc: address-policy-wg at ripe.net Working Group Subject: Re: [address-policy-wg] Promote the use of IRC Hi, On Wed, Aug 12, 2015 at 02:44:30PM +0200, Carsten Schiefner wrote: > Random (sub) groupings of whatever kind can and should most certainly > be free to use whatever means of communication they see fit - but > address policy stuff must IMHO stay on this mailing list. And only there! Emphasis on "what is not on this list has not happened" as far as formal(!) policy-making goes. OTOH, random sub-groups sitting together in a smoke-filled room, one or two or the other IRC channels, and throwing around ideas before bringing up something formal is a good thing - as long as it's clearly understood that this is informal. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From d.baeza at tvt-datos.es Wed Aug 12 16:46:45 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 12 Aug 2015 16:46:45 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <20150812134620.GZ84167@Space.Net> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> Message-ID: <55CB5C55.5040107@tvt-datos.es> Sorry, the IRC is NOT replacing this list. The IRC is to complement this (and the others) lists. I think is the perfect place to cook proposals, learn, know people (not in the fb way) and just chit chat about whatever. Here are good people with more or less experience that can help/teach on address-policy without spamming the list. Also, the IRC is not a place to "monitor". The list is the place to monitor what happens on address-policy or other ripe wg. The list will be the place to do what is intended to do. Votings will be on list, discussions will be on list, the whole PDP process will be on the list. For people with other chat ideas, I just said IRC because RIPE is already running one. We only need to improve it a little. Anyways, and just for saying, this is not a thing to "vote", anyone can join the idea or not. If enough people join, it can be an official communication channel. If not, we will just sit and chat in our little room :) Regards, From jim at rfc1035.com Wed Aug 12 16:53:40 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 12 Aug 2015 15:53:40 +0100 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB5C55.5040107@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> Message-ID: <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> On 12 Aug 2015, at 15:46, Daniel Baeza (Red y Sistemas TVT) wrote: > If enough people join, it can be an official communication channel. No. It can *never* be an official communication channel (whatever you mean by that). The only communication that matters for WG business is the mailing list. Everything else is just noise. From d.baeza at tvt-datos.es Wed Aug 12 16:57:36 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 12 Aug 2015 16:57:36 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> Message-ID: <55CB5EE0.4000706@tvt-datos.es> El 12/08/2015 a las 16:53, Jim Reid escribi?: > No. It can *never* be an official communication channel (whatever you mean by that). > > The only communication that matters for WG business is the mailing list. Everything else is just noise. > It can be *just official noise* :) From db at rrbone.net Wed Aug 12 17:00:33 2015 From: db at rrbone.net (Dominik Bay) Date: Wed, 12 Aug 2015 17:00:33 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB5EE0.4000706@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> Message-ID: <55CB5F91.2070003@rrbone.net> On 08/12/2015 04:57 PM, Daniel Baeza (Red y Sistemas TVT) wrote: > El 12/08/2015 a las 16:53, Jim Reid escribi?: >> No. It can *never* be an official communication channel (whatever you >> mean by that). >> >> The only communication that matters for WG business is the mailing >> list. Everything else is just noise. >> > > It can be *just official noise* :) Indeed, can we please stop the noise on the mailinglist. There are enough NOG/Ops channels around on IRC. From ripe-wgs.cs at schiefner.de Wed Aug 12 16:40:12 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 12 Aug 2015 16:40:12 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB567E.2070500@ip4market.ru> References: <55CB390E.7000305@tvt-datos.es> <55CB567E.2070500@ip4market.ru> Message-ID: <55CB5ACC.6010206@schiefner.de> Hi Yuri, On 12.08.2015 16:21, Staff wrote: > It's also good idea to setup web forum where all LIRs can discuss things > and policies. as long as the cross posting to the mailing list (and vice versa) would work I am all for it. Cheers, -C. From zsako at iszt.hu Wed Aug 12 17:06:23 2015 From: zsako at iszt.hu (Janos Zsako) Date: Wed, 12 Aug 2015 17:06:23 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB5EE0.4000706@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> Message-ID: <55CB60EF.7020206@iszt.hu> Dear Daniel, > El 12/08/2015 a las 16:53, Jim Reid escribi?: >> No. It can *never* be an official communication channel (whatever you mean by that). >> >> The only communication that matters for WG business is the mailing list. Everything else is just noise. >> > > It can be *just official noise* :) I am afraid I do not understand what you mean by "official noise". I think Jim's approach that "if a discussion about any WG matter does not take place on the mailing list, it simply didn't happen" is the correct one. Therefore, everybody is free to chat on IRC, but even if the number of participants is very high, all that is said there is "unofficial", as long as the ideas are not presented on the list as well. I have no objection to the setting up IRC if the above is accepted and respected by all participants. Best regards, Janos From d.baeza at tvt-datos.es Wed Aug 12 17:12:56 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 12 Aug 2015 17:12:56 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB60EF.7020206@iszt.hu> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> <55CB60EF.7020206@iszt.hu> Message-ID: <55CB6278.6040104@tvt-datos.es> El 12/08/2015 a las 17:06, Janos Zsako escribi?: > > I am afraid I do not understand what you mean by "official noise". > > I think Jim's approach that "if a discussion about any WG matter does not > take place on the mailing list, it simply didn't happen" is the correct one. > > Therefore, everybody is free to chat on IRC, but even if the number of > participants is very high, all that is said there is "unofficial", as long > as the ideas are not presented on the list as well. I have no objection to > the setting up IRC if the above is accepted and respected by all participants. > > Best regards, > Janos > Hi Janos, I will say it again, IRC is not replacing the list. IRC is complementing it. With official, I mean something like "RIPE Seal of Approval". In IRC PDP will not happens, but *can be* a good place to cook ideas. It will be as official as we want it to be, but again, it will never replace the Mailing List. From tom.hill at bytemark.co.uk Wed Aug 12 17:17:47 2015 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Wed, 12 Aug 2015 16:17:47 +0100 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB6278.6040104@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> <55CB60EF.7020206@iszt.hu> <55CB6278.6040104@tvt-datos.es> Message-ID: <55CB639B.2000905@bytemark.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/15 16:12, Daniel Baeza (Red y Sistemas TVT) wrote: > I will say it again, IRC is not replacing the list. IRC is > complementing it. With official, I mean something like "RIPE Seal > of Approval". In IRC PDP will not happens, but *can be* a good > place to cook ideas. It will be as official as we want it to be, > but again, it will never replace the Mailing List. There are already a number of unofficial IRC channels were a number of us congregate, and those already serve to help 'cook' ideas (for better or for worse) that are then discussed with _everyone_ on the WG lists if they prove to be useful. Any notion of an official IRC channel for this purpose, is either superfluous, or detracting from the proper process of discussing policy on the mailing lists. I'm in agreement with Jim, too. - -- Tom Hill Network Engineer Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 1904 890 890 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVy2ObAAoJEH2fKbrp2sQ6Z3QH/igDlbc/kHqCsPS6bO9Bp6I1 KqmnuihDk3deSTYDWS5CkNjFX6TqSEkxLVpwnQWT5cH2H4xscyBFCG8AlKz+/r5K aczk8ogroZRjLyGTevP2oI4ZhyhC6HCW6kc8LU/4ZYAHtZX6n/ZmDtTQ4Yqt9Aui boYQ64EaOsJ4WrXBsnB9RCxgfMkyDa1KC9v5E7GSJbigF68NInn3wguDZwvEa1Cs 0Vt4tX/fvfOwd7t3mxqLKsS3SF7R5+AfRIAwAz1frT+NpEmrSlb6uIyWUrmw71RK lwa3S/Tq8Nvp4DG8z5AIIxupJsOMM087MLy8ngv9+ry+giIlJQ9DB/dgZfloolM= =VFJ0 -----END PGP SIGNATURE----- From crimson at gweep.net Wed Aug 12 17:19:47 2015 From: crimson at gweep.net (Joe Provo) Date: Wed, 12 Aug 2015 11:19:47 -0400 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB6278.6040104@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> <55CB60EF.7020206@iszt.hu> <55CB6278.6040104@tvt-datos.es> Message-ID: <20150812151947.GA25534@gweep.net> On Wed, Aug 12, 2015 at 05:12:56PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: [snip] > I will say it again, IRC is not replacing the list. IRC is complementing > it. With official, I mean something like "RIPE Seal of Approval". In IRC > PDP will not happens, but *can be* a good place to cook ideas. It will > be as official as we want it to be, but again, it will never replace the > Mailing List. If you're seeking WG "approval" for an informal channel, I'm as confused as the rest of them. I can't speak for the WG chairs, but my read is "no"/ As for the RIPEIRC -- just use it! Loads of folks attach to those servers 'early' (before the meetings) and chatter tapers off sometimes days after. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From ripe-wgs.cs at schiefner.de Wed Aug 12 18:33:36 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 12 Aug 2015 18:33:36 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB6278.6040104@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <20150812134620.GZ84167@Space.Net> <55CB5C55.5040107@tvt-datos.es> <4803B935-05B7-4156-96FA-61858695547F@rfc1035.com> <55CB5EE0.4000706@tvt-datos.es> <55CB60EF.7020206@iszt.hu> <55CB6278.6040104@tvt-datos.es> Message-ID: <55CB7560.7080207@schiefner.de> Hi Daniel, On 12.08.2015 17:12, Daniel Baeza (Red y Sistemas TVT) wrote: > [...] With official, I mean something like "RIPE Seal of Approval". [...] I have weighed this for a quite bit now - but I still can't get the reasoning behind it. Even if I'd assume for a technical second that Hans Petter Holen and/or the WG Chairs collective and/or the NCC board would give such an IRC channel a sort of blessing: why would you need it? It appears to me that this is very similar to BoFs: they meet when a sufficient number of people think it's useful to meet. And then they do! The NCC is a mere facilitator here, organising the tech necessities: a room with chairs, some water maybe - but that's it. OTOH, this bunch of people could also easily meet in the next pub around the corner. Without anybody's prior blessing. Or such. Cheers, -C. From sander at steffann.nl Wed Aug 12 21:16:53 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 12 Aug 2015 21:16:53 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> Message-ID: <576F3EB6-477B-4328-B9DE-ED06FBB80CE2@steffann.nl> Hi, > Op 12 aug. 2015, om 15:24 heeft remco van mook het volgende geschreven: > > +1 on on everything that Jim just said. You're welcome to discuss any policy anywhere - in a pub, on IRC, on Facebook, other industry events, you name it - (and I know almost all of you do) but as long as it's not on the mailing list, it doesn't count for the policy development process. Yep, that is how it is going to be. And any argument that sounds like "But on IRC has said XYZ" will be ignored until that somebody posts his/her opinion on the mailing list. I am not going to keep IRC logs and search through them when somebody refers to an IRC discussion. In this working group *individuals* discuss address policy. Statements on behalf of groups, organisations, companies or some other person on IRC are not taken into account in policy discussions. Only statements made by real people themselves are taken into account :) > Also I'd like to echo the sentiment that it's yet another communications channel that I'd need to keep track of - I don't know where any of you finds the time to do so but I certainly don't have it. Yep. I have trouble enough as it is judging consensus based on mailing list data. Adding more sources of data can make my work as working group chair close to impossible. Cheers! Sander From saeed at ipm.ir Thu Aug 13 06:39:38 2015 From: saeed at ipm.ir (Saeed Khademi) Date: Thu, 13 Aug 2015 08:09:38 +0330 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CB390E.7000305@tvt-datos.es> References: <55CB390E.7000305@tvt-datos.es> Message-ID: <541D6F32F14F4B729176D261DD85A17F@Saeed> Good Morning, I've had a lot of bad memories of using IRC. Lot's of security holes and exploits are attached to this service in my mind. Kind Regards, Saeed. -----Original Message----- From: Daniel Baeza (Red y Sistemas TVT) Sent: Wednesday, August 12, 2015 3:46 PM To: address-policy-wg at ripe.net Working Group Subject: [address-policy-wg] Promote the use of IRC Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #address-policy channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel From garry at nethinks.com Thu Aug 13 09:15:35 2015 From: garry at nethinks.com (Garry Glendown) Date: Thu, 13 Aug 2015 09:15:35 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <576F3EB6-477B-4328-B9DE-ED06FBB80CE2@steffann.nl> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> <576F3EB6-477B-4328-B9DE-ED06FBB80CE2@steffann.nl> Message-ID: <55CC4417.1030707@nethinks.com> Hi, >> Also I'd like to echo the sentiment that it's yet another communications channel that I'd need to keep track of - I don't know where any of you finds the time to do so but I certainly don't have it. > Yep. I have trouble enough as it is judging consensus based on mailing list data. Adding more sources of data can make my work as working group chair close to impossible. +1! IRC has its uses, but for anything coming even close to be used for official use, it's useless ... I wouldn't want to set up a server/client to stay constantly connected, logging 99% junk just to keep up with anything that MAY come up that's important ... could you imagine the turmoil around 2015-1 if IRC had been used for part of the official discussion? -garry From woeber at cc.univie.ac.at Thu Aug 13 11:11:24 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 13 Aug 2015 11:11:24 +0200 Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CC4417.1030707@nethinks.com> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> <576F3EB6-477B-4328-B9DE-ED06FBB80CE2@steffann.nl> <55CC4417.1030707@nethinks.com> Message-ID: <55CC5F3C.1040304@cc.univie.ac.at> On 2015-08-13 09:15, Garry Glendown wrote: [...] > IRC has its uses, Indeed, like for "real time stuff" and information which is *not* relevant for a longer time and/or doesn't benefit from having a trail or log or documentation. > but for anything coming even close to be used for official use, IMHO there isn't such a thing as "official use", or "close to", as (usually) there's no trail or documentation. And, while I certainly would be the last one to prevent people from flocking together and chatting, or even professionally discussing issues, physically or in cyber-space, I do see the danger of *not* having the relevant contributions *again* on the mailing list, and thus by design also in the archive for later review. For that reason I am *against* "promoting" the use of IRC as a WG-affiliated or endorsed tool. Wilfried > it's useless ... I wouldn't want to set up a server/client > to stay constantly connected, logging 99% junk just to keep up with > anything that MAY come up that's important ... could you imagine the > turmoil around 2015-1 if IRC had been used for part of the official > discussion? > > -garry From swmike at swm.pp.se Thu Aug 13 12:04:57 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 13 Aug 2015 12:04:57 +0200 (CEST) Subject: [address-policy-wg] Promote the use of IRC In-Reply-To: <55CC5F3C.1040304@cc.univie.ac.at> References: <55CB390E.7000305@tvt-datos.es> <55CB3FAE.8090106@schiefner.de> <2F14C1EC-AE18-4EC8-B222-6D44BC8E64AD@rfc1035.com> <576F3EB6-477B-4328-B9DE-ED06FBB80CE2@steffann.nl> <55CC4417.1030707@nethinks.com> <55CC5F3C.1040304@cc.univie.ac.at> Message-ID: On Thu, 13 Aug 2015, Wilfried Woeber wrote: > For that reason I am *against* "promoting" the use of IRC as a WG-affiliated > or endorsed tool. I totally agree, I have no problem with having inofficial place for people to discuss, but the official place (the one that counts) is this mailing list. I have had really bad experience when having multiple official channels, it's never worked out in my experience. So I will join an IRC channel if one is created, but let's make sure everybody understands that it's an inofficial communications channel and if you come to any conclusions and want them to officially be part of the official discussion, they need to be brought to the mailing list. -- Mikael Abrahamsson email: swmike at swm.pp.se From ripe at europeiptv.net Fri Aug 14 09:09:04 2015 From: ripe at europeiptv.net (ripe at europeiptv.net) Date: Fri, 14 Aug 2015 08:09:04 +0100 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: References: Message-ID: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> Hello, I wonder what you think the community ripe to propose a new policy for IPv4 addressing, the proposal would be something like having another RIR as APNIC. We all know that RIPE currently has in place the policy for the last /8, the proposal is correct but, because it does not make eligible LIRs for another /22? The new /22 It would address that IANA has redistributed to RIPE. 45.128.0.0 - 45.159.255.255 45.8.0.0 - 45.15.255.255 45.80.0.0 - 45.95.255.255 and 2015-01 policy active, no transfer for next 24 months after allocation, and it is found necessary to use this new allocation, so it would prevent requested to speculate. I hope your views regarding this Regards. David From mschmidt at ripe.net Fri Aug 14 11:54:04 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 14 Aug 2015 11:54:04 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) Message-ID: Dear colleagues, A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this proposal and send your comments to before 14 September. Regards Marco Schmidt Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Fri Aug 14 12:17:25 2015 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 14 Aug 2015 11:17:25 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: On 14 August 2015 at 10:54, Marco Schmidt wrote: > https://www.ripe.net/participate/policies/proposals/2015-04 > > > We encourage you to review this proposal and send your comments to > before 14 September. Couple of questions/comments... >From 1.0 Shouldn't the scope be explicit as to what is/isn't included >From 2.1 "Transfers can be on a permanent or non-permanent basis." How is this going to be recorded and managed within the context of reflecting it being a non-permanent transfer? >From 2.2 "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)" Rather than "such as" this needs to be a definitive list of what is classed as a restricted resource >From 3.1 Again a list of conditions or references to policies that impose restrictions needed >From 4.0 M&A process is mentioned, should there be other references to this? Especially as M&A (as I understand it) allows 2.2 to be overridden General - As this is about transfers should this also cover returning resources to ripe NCC so all types of transfers be included - broadly support the unification of transfer policy into a single document, just things bits are missing or muddy J -- James Blessing 07989 039 476 From gert at space.net Fri Aug 14 13:11:48 2015 From: gert at space.net (Gert Doering) Date: Fri, 14 Aug 2015 13:11:48 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <20150814111148.GS84167@Space.Net> Hi, On Fri, Aug 14, 2015 at 11:54:04AM +0200, Marco Schmidt wrote: > A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been > made and is now available for discussion. To add a bit of info: this is the unified transfer policy Erik promised, that is "a new document that has the transfer policy for all transferrable resources" and all the other policy documents only refer to it. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Fri Aug 14 14:47:38 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 14 Aug 2015 14:47:38 +0200 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> Message-ID: <55CDE36A.50104@schiefner.de> Dear David, On 14.08.2015 09:09, ripe at europeiptv.net wrote: > Hello, I wonder what you think the community ripe to propose a new > policy for IPv4 addressing, the proposal would be something like having > another RIR as APNIC. > > > We all know that RIPE currently has in place the policy for the last /8, > the proposal is correct but, because it does not make eligible LIRs for > another /22? > > The new /22 It would address that IANA has redistributed to RIPE. > > 45.128.0.0 - 45.159.255.255 > 45.8.0.0 - 45.15.255.255 > 45.80.0.0 - 45.95.255.255 > > and 2015-01 policy active, no transfer for next 24 months after > allocation, and it is found necessary to use this new allocation, so it > would prevent requested to speculate. > > I hope your views regarding this even after having re-read this a couple of times I have not the slightest clue what you are aiming at. I am sorry. Best, -C. From David.Huberman at microsoft.com Fri Aug 14 18:45:03 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Fri, 14 Aug 2015 16:45:03 +0000 Subject: [address-policy-wg] Fwd: Suggestions on a new asn assignment policy In-Reply-To: <55C9F856.7030405@inex.ie> References: <55568496.9040907@foobar.org> <55C9D8B0.3050605@inex.ie> <55C9F856.7030405@inex.ie> Message-ID: Sorry for the delay in reply. I wrote: > > Respectfully, I think the WG is trying to solve a problem which > > doesn't exist. Nick Hilliard replied: > the policy has one problem now and is facing ASN16 depletion in the future. > > The problem now is that you can only get an ASN if you are "multihomed" and there are a bunch of > situations where this is causing unnecessary problems. People work around this by lying on the > application form and this is not good stewardship of number resources. I agree that the multi-homed sentence in the current ASN policy should be struck. By striking it, you allow the requestor to rely on the precepts in RFC1930 to make a technical argument for why they should be assigned an AS number. [Or, in a world where AS number requests are automated, allow the registrant to defend why they have the AS number.] With respect to 2-byte AS number depletion, Nick further wrote: > Regarding depletion, we have an option of viewing this as a problem, or not. > I view it as a problem because BGP community support for ASN32 is very > poor, and future entrants to the IP market will be penalised for being future > entrants. > > There are substantial regulatory problem associated with existing market > players effectively locking out future players, and given that the RIPE NCC > has a monopoly in ip number resource assignments in this part of the world, > this is an issue which would be best avoided if possible. This part I have a problem with, and is what I intended to reply to with my "the WG is trying to solve a problem which does not exist". 1) When I look at my table, there are over 38,000 unique prefixes being advertised to me that originate from, or propagate through, 4-byte AS numbers. 2) I work at a pretty darn big network, which relies heavily on BGP communities to make critical routing decisions. While our main AS is an old 2-byte, we have new deployments of significantly-sized networks which are only using 4-byte AS numbers, both for external BGP and for internal use. And it DOES work. Now, it certainly isn't easy. Our biggest challenge as a large network is figuring out how to have a single policy rule to cover both 2-byte and 4-byte communities together. We haven't overcome that hurdle yet. And there are niggly little challenges like the fact that JunOS doesn't support remove private 4-byte ASN in the code we are running. But we've found ways to engineer around the lack of feature support, and of course, we are constantly banging on our vendors to do better. 3) I am REALLY uncomfortable with making policy out of fear of future regulatory violations. We should concentrate on making the best policy for "the Internet" and leave the lawyers out of it. As engineers, we all know that there is no future for 2-byte AS numbers, and that operators and equipment must fully support 4-byte AS number implementation for both themselves and their peers. To that end, I'm against a policy which allows operators to plan on being able to obtain 2-byte AS numbers in the future to purposely avoid using a 4-byte AS number. It is my opinion that kind of thinking hurts everyone else trying to make 4-bytes Work. I hope I stated #3 clearly and wrote it accurately. I appreciate this discussion, and giving me the opportunity to provide my opinion. As always, I am happy to be shown that I am wrong :) David David R Huberman Principal, Global IP Addressing Microsoft Corporation From d.baeza at tvt-datos.es Sat Aug 15 09:41:32 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Sat, 15 Aug 2015 09:41:32 +0200 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <55CDE36A.50104@schiefner.de> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> Message-ID: <55CEED2C.4070202@tvt-datos.es> Hello Carsten, What I think David is trying to say is to make LIRs elegible for another /22 out from the 185/8. And He gives as example the recieved blocks from IANA: 45.128.0.0 - 45.159.255.255 45.8.0.0 - 45.15.255.255 45.80.0.0 - 45.95.255.255 This is a good example of a discussion that can happens out of the list and if a proposal comes then here is the place to discuss it. Now will happen a lot of -1 or +1 in the mail list for something that is NOT a proposal. PS: David, what you are trying to say have been discussed here and the answer is no. Regards, --Daniel El 14/08/2015 a las 14:47, Carsten Schiefner escribi?: > Dear David, > > On 14.08.2015 09:09, ripe at europeiptv.net wrote: >> Hello, I wonder what you think the community ripe to propose a new >> policy for IPv4 addressing, the proposal would be something like having >> another RIR as APNIC. >> >> >> We all know that RIPE currently has in place the policy for the last /8, >> the proposal is correct but, because it does not make eligible LIRs for >> another /22? >> >> The new /22 It would address that IANA has redistributed to RIPE. >> >> 45.128.0.0 - 45.159.255.255 >> 45.8.0.0 - 45.15.255.255 >> 45.80.0.0 - 45.95.255.255 >> >> and 2015-01 policy active, no transfer for next 24 months after >> allocation, and it is found necessary to use this new allocation, so it >> would prevent requested to speculate. >> >> I hope your views regarding this > > even after having re-read this a couple of times I have not the > slightest clue what you are aiming at. > > I am sorry. > > Best, > > -C. > From ripe at europeiptv.net Sat Aug 15 09:57:20 2015 From: ripe at europeiptv.net (ripe at europeiptv.net) Date: Sat, 15 Aug 2015 08:57:20 +0100 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <55CDE36A.50104@schiefner.de> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> Message-ID: <0e219b9cfdd52780edc333b8ec7110eb@europeiptv.net> Hello, The proposal is that once an LIR has received one /22 from 185/8, LIRs are eligible to apply for another /22, and that the blocks ranges are used that IANA has redistributed so far today is: 45.128.0.0 - 45.159.255.255 45.8.0.0 - 45.15.255.255 45.80.0.0 - 45.95.255.255 and that these allocations are governed by the policy 2015-01 as well. You know what I mean? ( I'm sorry for my English ). Regards. IPTV Europe El 2015-08-14 13:47, Carsten Schiefner escribi?: > Dear David, > > On 14.08.2015 09:09, ripe at europeiptv.net wrote: >> Hello, I wonder what you think the community ripe to propose a new >> policy for IPv4 addressing, the proposal would be something like >> having >> another RIR as APNIC. >> >> >> We all know that RIPE currently has in place the policy for the last >> /8, >> the proposal is correct but, because it does not make eligible LIRs >> for >> another /22? >> >> The new /22 It would address that IANA has redistributed to RIPE. >> >> 45.128.0.0 - 45.159.255.255 >> 45.8.0.0 - 45.15.255.255 >> 45.80.0.0 - 45.95.255.255 >> >> and 2015-01 policy active, no transfer for next 24 months after >> allocation, and it is found necessary to use this new allocation, so >> it >> would prevent requested to speculate. >> >> I hope your views regarding this > > even after having re-read this a couple of times I have not the > slightest clue what you are aiming at. > > I am sorry. > > Best, > > -C. From ripe at europeiptv.net Sat Aug 15 10:01:11 2015 From: ripe at europeiptv.net (ripe at europeiptv.net) Date: Sat, 15 Aug 2015 09:01:11 +0100 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <55CDE36A.50104@schiefner.de> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> Message-ID: <216f22ef00bab2ea2ed232bf985431e7@europeiptv.net> Hello Daniel, What you say, is not the idea that I have proposed, I responded to the list again and see if I understood better. regards. El 2015-08-14 13:47, Carsten Schiefner escribi?: > Dear David, > > On 14.08.2015 09:09, ripe at europeiptv.net wrote: >> Hello, I wonder what you think the community ripe to propose a new >> policy for IPv4 addressing, the proposal would be something like >> having >> another RIR as APNIC. >> >> >> We all know that RIPE currently has in place the policy for the last >> /8, >> the proposal is correct but, because it does not make eligible LIRs >> for >> another /22? >> >> The new /22 It would address that IANA has redistributed to RIPE. >> >> 45.128.0.0 - 45.159.255.255 >> 45.8.0.0 - 45.15.255.255 >> 45.80.0.0 - 45.95.255.255 >> >> and 2015-01 policy active, no transfer for next 24 months after >> allocation, and it is found necessary to use this new allocation, so >> it >> would prevent requested to speculate. >> >> I hope your views regarding this > > even after having re-read this a couple of times I have not the > slightest clue what you are aiming at. > > I am sorry. > > Best, > > -C. From ripe-wgs at radu-adrian.feurdean.net Sat Aug 15 12:33:08 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 15 Aug 2015 12:33:08 +0200 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <0e219b9cfdd52780edc333b8ec7110eb@europeiptv.net> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> <0e219b9cfdd52780edc333b8ec7110eb@europeiptv.net> Message-ID: <1439634788.189729.356869657.6CDED760@webmail.messagingengine.com> On Sat, Aug 15, 2015, at 09:57, ripe at europeiptv.net wrote: > Hello, The proposal is that once an LIR has received one /22 from > 185/8, LIRs are eligible to apply for another /22, and that the blocks > ranges are used that IANA has redistributed so far today is: > > 45.128.0.0 - 45.159.255.255 > 45.8.0.0 - 45.15.255.255 > 45.80.0.0 - 45.95.255.255 > > and that these allocations are governed by the policy 2015-01 as well. > > You know what I mean? ( I'm sorry for my English ). Hi, You are not the not the only one thinking about the "last /8 policy" revision. See https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf However, there are 2 conflicting point on which a number of community members insist (on both at the same time): - making the "last /8" pool (including recovered space) last as long as possible - no not reinstate needs-based policy Whatever touches the allocation policy would violate at least one of them. From gert at space.net Sat Aug 15 15:33:29 2015 From: gert at space.net (Gert Doering) Date: Sat, 15 Aug 2015 15:33:29 +0200 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <55CEED2C.4070202@tvt-datos.es> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> <55CEED2C.4070202@tvt-datos.es> Message-ID: <20150815133329.GV84167@Space.Net> Hi On Sat, Aug 15, 2015 at 09:41:32AM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > Now will happen a lot of -1 or +1 in the mail list for something that is > NOT a proposal. It's sort of the early beginning of the "discussion phase" - test the opinion of the community, and only submit something formal if there is sufficient support... (and adjust the proposal according to early feedback received). So it's not waste of energy to test ideas first :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From d.baeza at tvt-datos.es Sun Aug 16 12:05:13 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Sun, 16 Aug 2015 12:05:13 +0200 Subject: [address-policy-wg] New Proposal for IPv4 Allocations In-Reply-To: <20150815133329.GV84167@Space.Net> References: <7bcd534ecfa7f50b55e4ad588923c195@europeiptv.net> <55CDE36A.50104@schiefner.de> <55CEED2C.4070202@tvt-datos.es> <20150815133329.GV84167@Space.Net> Message-ID: <55D06059.8080403@tvt-datos.es> Hi, El 15/08/2015 a las 15:33, Gert Doering escribi?: > It's sort of the early beginning of the "discussion phase" - test the > opinion of the community, and only submit something formal if there is > sufficient support... (and adjust the proposal according to early > feedback received). So it's not waste of energy to test ideas first :-) > Of course is not a waste of energy. I didnt mean that and I'm sorry if it sound like that. What I want to mean is that maybe, and just maybe, some kind of more real-time communication channel (In my example was IRC, but is not the only one) to test/cook ideas first could be better than the list. And more for this case, if I understood the question of David, is something that have been discussed (in one time, proposed by me) before. Regards, --Daniel From frettled at gmail.com Mon Aug 17 18:26:30 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 17 Aug 2015 18:26:30 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < james.blessing at despres.co.uk> wrote: > On 14 August 2015 at 10:54, Marco Schmidt wrote: > > > https://www.ripe.net/participate/policies/proposals/2015-04 > Thanks for putting in the time and effort, Erik! Couple of questions/comments... > > From 1.0 > > Shouldn't the scope be explicit as to what is/isn't included > I agree that this would help. >From 2.1 > > "Transfers can be on a permanent or non-permanent basis." > > How is this going to be recorded and managed within the context of > reflecting it being a non-permanent transfer? > Wouldn't that be up to the RIPE NCC? >From 2.2 > > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit > ASNs)" > > Rather than "such as" this needs to be a definitive list of what is > classed as a restricted resource > I concur, but I don't think it should be listed in the same document. My first thought is that this list should be maintained by the RIPE NCC. Keeping that list in a separate document means changing fewer documents when policy changes, or reality reaches a pre-set limit set in policy. That separate list should reference the policy documents enabling the restrictions. >From 3.1 > > Again a list of conditions or references to policies that impose > restrictions needed > I'm a bit confused both by the point and by your response to it, maybe I'm just tired, but I think both could be clearer. :) >From 4.0 > > M&A process is mentioned, should there be other references to this? > Especially as M&A (as I understand it) allows 2.2 to be overridden > "The document proposes to include the transfer restrictions to mergers and acquisitions. This is done to make the policy more in line with the intention of the transfer policy restrictions when proposed." General > > - As this is about transfers should this also cover returning > resources to ripe NCC so all types of transfers be included > I'm not sure that this would be useful, but 2015-04 could 1) include a reference to the policy for that, and 2) make it even clearer that this is a document for transfers between resource holders. I don't think it's useful to consider the RIR a resource holder in this context. - broadly support the unification of transfer policy into a single > document, just things bits are missing or muddy > Agreed, but the document is largely clarifying more than muddying, IMHO. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From 8lb.7zin81 at gmail.com Wed Aug 19 14:55:57 2015 From: 8lb.7zin81 at gmail.com (8lb. 7zin) Date: Wed, 19 Aug 2015 15:55:57 +0300 Subject: [address-policy-wg] Help Re: address-policy-wg Digest, Vol 48, Issue 17 Message-ID: ??? ????????? ?? ?????? ????, ???: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2015-04 New Policy Proposal (RIPE Resource Transfer > Policies) (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Aug 2015 18:26:30 +0200 > From: Jan Ingvoldstad > > To: Address Policy Working Group > > Subject: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE > Resource Transfer Policies) > Message-ID: > < > CAEffzkzzpKA1aqUtUzESDJpLggLbOUdfMhaETmStDcRddPmUjg at mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < > james.blessing at despres.co.uk > wrote: > > > On 14 August 2015 at 10:54, Marco Schmidt > wrote: > > > > > https://www.ripe.net/participate/policies/proposals/2015-04 > > > > Thanks for putting in the time and effort, Erik! > > Couple of questions/comments... > > > > From 1.0 > > > > Shouldn't the scope be explicit as to what is/isn't included > > > > I agree that this would help. > > >From 2.1 > > > > "Transfers can be on a permanent or non-permanent basis." > > > > How is this going to be recorded and managed within the context of > > reflecting it being a non-permanent transfer? > > > > Wouldn't that be up to the RIPE NCC? > > >From 2.2 > > > > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit > > ASNs)" > > > > Rather than "such as" this needs to be a definitive list of what is > > classed as a restricted resource > > > > I concur, but I don't think it should be listed in the same document. > > My first thought is that this list should be maintained by the RIPE NCC. > > Keeping that list in a separate document means changing fewer documents > when policy changes, or reality reaches a pre-set limit set in policy. > > That separate list should reference the policy documents enabling the > restrictions. > > >From 3.1 > > > > Again a list of conditions or references to policies that impose > > restrictions needed > > > > I'm a bit confused both by the point and by your response to it, maybe I'm > just tired, but I think both could be clearer. :) > > >From 4.0 > > > > M&A process is mentioned, should there be other references to this? > > Especially as M&A (as I understand it) allows 2.2 to be overridden > > > > "The document proposes to include the transfer restrictions to mergers and > acquisitions. This is done to make the policy more in line with the > intention of the transfer policy restrictions when proposed." > > General > > > > - As this is about transfers should this also cover returning > > resources to ripe NCC so all types of transfers be included > > > > I'm not sure that this would be useful, but 2015-04 could 1) include a > reference to the policy for that, and 2) make it even clearer that this is > a document for transfers between resource holders. > > I don't think it's useful to consider the RIR a resource holder in this > context. > > - broadly support the unification of transfer policy into a single > > document, just things bits are missing or muddy > > > > Agreed, but the document is largely clarifying more than muddying, IMHO. > -- > Jan > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20150817/cf35e13e/attachment-0001.html > > > > End of address-policy-wg Digest, Vol 48, Issue 17 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From support at sonabusiness.nl Fri Aug 28 13:28:01 2015 From: support at sonabusiness.nl (SBS - Support) Date: Fri, 28 Aug 2015 13:28:01 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy Message-ID: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> Dear RIPE Address Policy Group, The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified. Regards, Walter This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Aug 28 13:55:07 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 28 Aug 2015 13:55:07 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> Message-ID: <20150828135507.0006dffb@echo.ms.redpill-linpro.com> * SBS - Support > The RIPE policy of allocating only a PA /22 to new LIR's and not > allocating any further IPv4 resources is highly detrimental to the > growth of new upcoming organisations and protects legacy Telco > operators, what are your thoughts on reviewing this and coming up > with a process to allocate further resources to new LIR's if the need > can be justified. If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations. None. Zip, zilch, zero. How would that have been any less detrimental? Tore From support at sonabusiness.nl Fri Aug 28 14:17:37 2015 From: support at sonabusiness.nl (SBS - Support) Date: Fri, 28 Aug 2015 14:17:37 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <20150828135507.0006dffb@echo.ms.redpill-linpro.com> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> Message-ID: <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> Hi Tore, That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources. Regards, Walter ---- On Fri, 28 Aug 2015 13:55:07 +0200 Tore Anderson <tore at fud.no> wrote ---- * SBS - Support <support at sonabusiness.nl> > The RIPE policy of allocating only a PA /22 to new LIR's and not > allocating any further IPv4 resources is highly detrimental to the > growth of new upcoming organisations and protects legacy Telco > operators, what are your thoughts on reviewing this and coming up > with a process to allocate further resources to new LIR's if the need > can be justified. If we hadn't done it that way, we would today not have had IPv4 addresses at all to allocate to new upcoming organisations. None. Zip, zilch, zero. How would that have been any less detrimental? Tore This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Aug 28 14:44:13 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 28 Aug 2015 14:44:13 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> Message-ID: <20150828144413.5c85987c@echo.ms.redpill-linpro.com> * SBS - Support > That is like running away from responsibility of policing usage based > on need and promoting illicit IP trading. If need is justified there > has to be a process to allocate additional IP resources. Where do you propose we locate these mythical ?additional IP[v4] resources? we should proceed to allocate based on justified need, exactly? Tore From wilhelm at boeddinghaus.de Fri Aug 28 14:50:34 2015 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Fri, 28 Aug 2015 14:50:34 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> Message-ID: <55E0591A.4000600@boeddinghaus.de> Hi Walter, be assured that the large telcos also need IPv4 addresses. If we return to need based policy, they will use up all remaining IPv4 addresses in a few days. This does not help anybody. But if you think anything should be changed, then please write a new policy proposal and start the discussion. Regards, Wilhelm Am 28.08.2015 um 14:17 schrieb SBS - Support: > Hi Tore, > > That is like running away from responsibility of policing usage based > on need and promoting illicit IP trading. If need is justified there > has to be a process to allocate additional IP resources. > > Regards, > Walter > > > ---- On Fri, 28 Aug 2015 13:55:07 +0200 *Tore Anderson * > wrote ---- > > * SBS - Support > > > > The RIPE policy of allocating only a PA /22 to new LIR's and not > > allocating any further IPv4 resources is highly detrimental to the > > growth of new upcoming organisations and protects legacy Telco > > operators, what are your thoughts on reviewing this and coming up > > with a process to allocate further resources to new LIR's if the > need > > can be justified. > > If we hadn't done it that way, we would today not have had IPv4 > addresses at all to allocate to new upcoming organisations. > > None. > > Zip, zilch, zero. > > How would that have been any less detrimental? > > Tore > > > > > This electronic message contains information from Sona Business > Services (SBS) which may be privileged and confidential. The > information is intended to be for the use of the individual(s) or > entity named above. If you are not the intended recipient, be aware > that any disclosure, copying, distribution or use of the contents of > this information is prohibited. If you have received this electronic > message in error, please notify us by telephone or e-mail and delete > this message immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.hill at bytemark.co.uk Fri Aug 28 14:28:19 2015 From: tom.hill at bytemark.co.uk (Tom Hill) Date: Fri, 28 Aug 2015 13:28:19 +0100 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> Message-ID: <55E053E3.7070306@bytemark.co.uk> Hi Walter, On 28/08/15 13:17, SBS - Support wrote: > That is like running away from responsibility of policing usage based on > need and promoting illicit IP trading. If need is justified there has to > be a process to allocate additional IP resources. Have you seen what's happened in North America recently? I don't think that is a good news situations for small/new ISPs, and yet the story for bigger ISPs doesn't seem to have changed as a result. Anyone trading IPs (illegitimate or legitimately) is likely to be rather happy about the situation, too. Now that we have an example of what happens when you run out of IPv4 without 'running down fairly', one would hope it's clearer now why the policy is in place. Best regards, -- Tom Hill Network Engineer Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 (0) 1904 890 890 From nick at inex.ie Fri Aug 28 15:13:46 2015 From: nick at inex.ie (Nick Hilliard) Date: Fri, 28 Aug 2015 14:13:46 +0100 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> Message-ID: <55E05E8A.705@inex.ie> On 28/08/2015 12:28, SBS - Support wrote: > The RIPE policy of allocating only a PA /22 to new LIR's and not allocating > any further IPv4 resources is highly detrimental to the growth of new > upcoming organisations and protects legacy Telco operators, what are your > thoughts on reviewing this and coming up with a process to allocate further > resources to new LIR's if the need can be justified. Anyone is free to suggest a better mechanism. If you have some ideas which are better that what's already there, please feel free to write a proposal. Nick From ripe-wgs at radu-adrian.feurdean.net Fri Aug 28 16:50:25 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 28 Aug 2015 16:50:25 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <20150828135507.0006dffb@echo.ms.redpill-linpro.com> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> Message-ID: <1440773425.1191803.368618753.6444A8D3@webmail.messagingengine.com> On Fri, Aug 28, 2015, at 13:55, Tore Anderson wrote: > If we hadn't done it that way, we would today not have had IPv4 > addresses at all to allocate to new upcoming organisations. Between the old policy (pre last-/8) and the new one, there is a whole lot of middleground. From ripe-wgs at radu-adrian.feurdean.net Fri Aug 28 16:53:50 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 28 Aug 2015 16:53:50 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <55E0591A.4000600@boeddinghaus.de> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> <55E0591A.4000600@boeddinghaus.de> Message-ID: <1440773630.1194130.368621241.2968BC13@webmail.messagingengine.com> On Fri, Aug 28, 2015, at 14:50, Wilhelm Boeddinghaus wrote: > be assured that the large telcos also need IPv4 addresses. If we return > to need based policy, they will use up all remaining IPv4 addresses in a > few days. This does not help anybody. There are 2 views of "needs-based": - allocate as much as needed (that clearly won't last long) - only allocate IF needed (what would be supposed to make things last longer - but it's gone) From tore at fud.no Fri Aug 28 17:51:18 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 28 Aug 2015 17:51:18 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <1440773425.1191803.368618753.6444A8D3@webmail.messagingengine.com> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <1440773425.1191803.368618753.6444A8D3@webmail.messagingengine.com> Message-ID: <20150828175118.7436bc84@envy.fud.no> * Radu-Adrian FEURDEAN > On Fri, Aug 28, 2015, at 13:55, Tore Anderson wrote: > > > If we hadn't done it that way, we would today not have had IPv4 > > addresses at all to allocate to new upcoming organisations. > > Between the old policy (pre last-/8) and the new one, there is a whole > lot of middleground. Certainly, but what's being asked for in this thread *is* essentially the old policy: ?If need is justified there has to be a process to allocate additional IP resources.? There's no middle ground (that I can think of, anyway) between the old and the new policy where we won't have to go against the above at some point, instead telling applicants something like ?while your need is justified, we're sorry, we won't be allocating you what you ask for?. In any case, Nick is right. If someone is unhappy about the current policy and thinks it could be better, that someone needs to submit an actual policy proposal. Until that happens it's not much point in rehashing this dicussion yet another time. Tore From gert at space.net Fri Aug 28 22:14:41 2015 From: gert at space.net (Gert Doering) Date: Fri, 28 Aug 2015 22:14:41 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <20150828135507.0006dffb@echo.ms.redpill-linpro.com> <14f743de3ae.11281ece539528.6916698202735010571@sonabusiness.nl> Message-ID: <20150828201441.GJ84167@Space.Net> Hi, On Fri, Aug 28, 2015 at 02:17:37PM +0200, SBS - Support wrote: > That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources. Do you have a few /8s available that the RIPE NCC could use to do that? IPv4 has run out. Choices are "distribute the rest in small scraps, so new entrants in the market can at least get *some* space" or "first come, first served, bam, nothing left" - almost everybody in the business is able to document need now, and if the NCC fulfills that, the remaining space is gone by end of August. ARIN has decided to run against the wall, and we'll see how well that works out - the other RIRs (including RIPE) have decided to go for "small scraps", and it seems to distribute the pain somewhat evenly... Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From randy at psg.com Sat Aug 29 13:45:45 2015 From: randy at psg.com (Randy Bush) Date: Sat, 29 Aug 2015 13:45:45 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> Message-ID: > The RIPE policy of allocating only a PA /22 to new LIR's and not > allocating any further IPv4 resources is highly detrimental to the > growth of new upcoming organisations and protects legacy Telco > operators, what are your thoughts on reviewing this and coming up with > a process to allocate further resources to new LIR's if the need can > be justified. as those egacy telcos got all that address space because they could justify it, what makes you think they would not have the very same justification fo rmassive need now? the thought behind one /22 per newcomer is to prevent the biggies from gobbling it all up instantly and to see that it is there to allw for new entrants. of course the new entrants will not get all they need. no one will; ipv4 space is gone; get over it. but they can get enough to nat or nat64 or whaever to at least get in the door. randy From gert at space.net Sun Aug 30 15:10:25 2015 From: gert at space.net (Gert Doering) Date: Sun, 30 Aug 2015 15:10:25 +0200 Subject: [address-policy-wg] Moving 2015-03 (Assessment Criteria for IPv6 Initial Allocation Size) to Last Call In-Reply-To: References: Message-ID: <20150830131025.GA13615@Space.Net> Dear AP WG, On Thu, Jul 09, 2015 at 02:19:35PM +0200, Marco Schmidt wrote: [..] > The draft document for version 2.0 of the policy proposal 2015-03, > "Assessment Criteria for IPv6 Initial Allocation Size", has now been > published, along with an impact analysis conducted by the RIPE NCC. > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 7 August 2015. the review phase for 2015-03 has ended (actually, quite a while ago, but it's vacation time... apologies). There was a bit of discussion and thoughtful contemplations about this proposal (and I have to say, very friendly and very constructive discussion, which I appreciate :-) ). If a clear opinion was voiced regarding the proposal itself, it was always supportive. So, I declare we have consensus, and move 2015-03 to Last Call. Marco will send the formal announcement for that in the next days. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what I have based my decision on. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase for V2.0, starting Jul 09, 2015 Support: Shahin Gharghi Carsten Brueckner Tore Anderson (notes that subsequent allocations are not covered) Andre Keller (notes disagreement with the assumptions in the impact analysis regarding routing table growth, but supports proposal) Annette Suedmeyer (plans to submit a follow-up proposal covering subsequent allocations) Silvia Hagen (some thoughts about "we should not be looking at IPv6 with mostly conservation in our minds", and questions about interpretation) John Collins Comments, Clarification: Mathew Newton / Marco Schmidt (side clarification about the evaluation to be done by the NCC) Tore Anderson / Mathew Newton / Sander Steffann / Jens 'Opteamax' (side discussion about subsequent allocations, returning of the initial /29 and asking for a larger *initial* allocation) Jens 'Opteamax' / Tore Anderson (side discussion about size of the reservation done enclosing the initial allocation) Silvia Hagen / Gert Doering / Sascha Luck / Mathew Newton / Marco Schmidt (side discussion about conservation, maths, and finding the right balance between "too liberal" and "too conservative") Opposing voices: - -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Mathew.Newton643 at official.mod.uk Sun Aug 30 15:38:40 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Sun, 30 Aug 2015 13:38:40 +0000 Subject: [address-policy-wg] Moving 2015-03 (Assessment Criteria for IPv6 Initial Allocation Size) to Last Call In-Reply-To: <20150830131025.GA13615@Space.Net> References: <20150830131025.GA13615@Space.Net> Message-ID: Hi Gert, > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Gert Doering > Sent: 30 August 2015 14:10 > So, I declare we have consensus, and move 2015-03 to Last Call. That's great news; thanks Gert. Indeed a big thank you to everyone involved in getting us to this stage. Regards, Mathew From hph at oslo.net Sun Aug 30 18:02:29 2015 From: hph at oslo.net (Hans Petter Holen) Date: Sun, 30 Aug 2015 18:02:29 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <55E05E8A.705@inex.ie> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <55E05E8A.705@inex.ie> Message-ID: <55E32915.3050304@oslo.net> On 28.08.2015 15:13, Nick Hilliard wrote: > Anyone is free to suggest a better mechanism. If you have some ideas which > are better that what's already there, please feel free to write a proposal. Maybe something along the lines of "you can have a second /22" after a certain period of time if you only have a /22. The rationale behind this could be that RIPE NCC got more address space than anticipated when the last /8 was made. According to https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly more than a /8 (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph) NRO June figures: https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2Fuploads%2FNRO_Q2_2015.pdf Afrinic: 2.7 RIPE NCC: 1.08 APNIC: 0,69 Lacnic: 0.16 Arin: 0.1 now down to 0.0015 So if somebody want to pursue this I suggest looking a t https://www.ripe.net/publications/docs/ripe-642 and create a proposal using the Policy template in Appendix B But it is really time to get serious about IPv6. (Since you can do Google and Facebook on v6 - what more do you want:-) -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From mschmidt at ripe.net Mon Aug 31 10:46:38 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 31 Aug 2015 10:46:38 +0200 Subject: [address-policy-wg] 2015-03 Last Call for Comments (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Dear colleagues, The proposal described in 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 29 September 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of the Working Group for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 29 September 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From d.baeza at tvt-datos.es Mon Aug 31 12:19:18 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 31 Aug 2015 12:19:18 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <55E32915.3050304@oslo.net> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <55E05E8A.705@inex.ie> <55E32915.3050304@oslo.net> Message-ID: <55E42A26.8020405@tvt-datos.es> Hi Hans, Do you know there is a "bug" in Android with IPv6? I had to disable IPv6 in all my customers due to this issue.(*) (*) https://code.google.com/p/android/issues/detail?id=79576 While IPv6 is not fully supported by the majority of the devices, it cant be deployed. Regards, El 30/08/2015 a las 18:02, Hans Petter Holen escribi?: > On 28.08.2015 15:13, Nick Hilliard wrote: >> Anyone is free to suggest a better mechanism. If you have some ideas which >> are better that what's already there, please feel free to write a proposal. > > Maybe something along the lines of "you can have a second /22" after a > certain period of time if you only have a /22. > > The rationale behind this could be that RIPE NCC got more address space > than anticipated when the last /8 was made. > According to > https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph > RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly > more than a /8 > (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph) > > NRO June figures: > https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2Fuploads%2FNRO_Q2_2015.pdf > > Afrinic: 2.7 > RIPE NCC: 1.08 > APNIC: 0,69 > Lacnic: 0.16 > Arin: 0.1 now down to 0.0015 > > So if somebody want to pursue this I suggest looking a t > https://www.ripe.net/publications/docs/ripe-642 > and create a proposal using the Policy template in Appendix B > > > But it is really time to get serious about IPv6. > (Since you can do Google and Facebook on v6 - what more do you want:-) > From hph at oslo.net Mon Aug 31 14:29:03 2015 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 31 Aug 2015 14:29:03 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <55E42A26.8020405@tvt-datos.es> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <55E05E8A.705@inex.ie> <55E32915.3050304@oslo.net> <55E42A26.8020405@tvt-datos.es> Message-ID: <55E4488F.9040001@oslo.net> On 31.08.2015 12:19, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi Hans, > > Do you know there is a "bug" in Android with IPv6? I am quite sure there are as many bugs in various systems. Acting professionally we should report these to the vendors and push to get them fixed. Some of the vendors take part in RIPE meetings - so working trough informal channels is also known to work. > > I had to disable IPv6 in all my customers due to this issue.(*) > > (*) https://code.google.com/p/android/issues/detail?id=79576 > > While IPv6 is not fully supported by the majority of the devices, it > cant be deployed. I do know that 8% of the traffic seen by Google is IPv6 http://www.google.com/intl/en/ipv6/statistics.html and that Google sees more than 35% from Belgium - http://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption So I beg to differ - IPv6 can indeed be deployed. Further discussion on deployment IPv6 belong in the IPv6 wg. In Address Policy you are welcome to propose changes to the policy. Hans Petter > > Regards, > > El 30/08/2015 a las 18:02, Hans Petter Holen escribi?: >> On 28.08.2015 15:13, Nick Hilliard wrote: >>> Anyone is free to suggest a better mechanism. If you have some >>> ideas which >>> are better that what's already there, please feel free to write a >>> proposal. >> >> Maybe something along the lines of "you can have a second /22" after a >> certain period of time if you only have a /22. >> >> The rationale behind this could be that RIPE NCC got more address space >> than anticipated when the last /8 was made. >> According to >> https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph >> >> RIPE NCC currently have 17.7 M IPv4 addresses left - which is slightly >> more than a /8 >> (https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph) >> >> >> NRO June figures: >> https://docs.google.com/viewer?url=https%3A%2F%2Fwww.nro.net%2Fwp-content%2Fuploads%2FNRO_Q2_2015.pdf >> >> >> Afrinic: 2.7 >> RIPE NCC: 1.08 >> APNIC: 0,69 >> Lacnic: 0.16 >> Arin: 0.1 now down to 0.0015 >> >> So if somebody want to pursue this I suggest looking a t >> https://www.ripe.net/publications/docs/ripe-642 >> and create a proposal using the Policy template in Appendix B >> >> >> But it is really time to get serious about IPv6. >> (Since you can do Google and Facebook on v6 - what more do you want:-) >> -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From gert at space.net Mon Aug 31 15:07:09 2015 From: gert at space.net (Gert Doering) Date: Mon, 31 Aug 2015 15:07:09 +0200 Subject: [address-policy-wg] RIPE IPv4 Allocation Policy In-Reply-To: <55E42A26.8020405@tvt-datos.es> References: <14f74107cb3.11d402e0228530.1640507412732108589@sonabusiness.nl> <55E05E8A.705@inex.ie> <55E32915.3050304@oslo.net> <55E42A26.8020405@tvt-datos.es> Message-ID: <20150831130709.GX84167@Space.Net> Hi, On Mon, Aug 31, 2015 at 12:19:18PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > Do you know there is a "bug" in Android with IPv6? > > I had to disable IPv6 in all my customers due to this issue.(*) > > (*) https://code.google.com/p/android/issues/detail?id=79576 I can't see why you would need to disable IPv6 completely just because one client OS does not support IPv6-*only* operation? Android works totally well in dual-stack networks - not using IPv6 if you mandate stateful DHCPv6, though. > While IPv6 is not fully supported by the majority of the devices, it > cant be deployed. "Some vendor's interpretation of Android" is hardly "the majority of devices"... Gert Doering -- deploying IPv6 in our office and wifi networks since 10+ years -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Mon Aug 31 23:22:09 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 31 Aug 2015 22:22:09 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <55E4C581.9060605@inex.ie> > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-04 first of all, a large thank-you for handling this policy aggregation. This will make things a lot easier for organisations to understand how RIPE transfer policy works. Although policy reworking like this is completely thankless, it's important to do. I've gone down through the new policy and compared it against the old. As expected, there is plenty of optimisation going on, but optimisation means changes and changes mean that we need to understand what's been changed. Enumerating some of the changes: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC.": this is completely new text. approve. ipv6 transfer policy: added "Transfers must be reflected in the RIPE Database. Transfers can be on a permanent or non-permanent basis.". approve. ipv6 transfer policy: removed "The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation". for the record, this is an interesting consequence of section 2.1, paragraph 3. I.e. no point in repeating policy that already exists. asn transfer policy: added "scarce resources ... cannot be transferred by the resource holder within 24 months". I don't disagree with this, nor with the genericisation of this transfer restriction. all policies: the tightening of the policy text in section 2.1 concerning who's currently responsible for the resource ("the original resource holder ... policies are applied") is good. asn + ipv6 policies: added statement that ripe policies apply for the duration of transfer and during the transfer process itself - to align with the ipv4 policy. This is good, but other RIRs may claim that their policies apply during the transfer process. Would it be worth discussing at a higher level whether there should be a global policy for which RIR policy applies during the transfer process? all policies: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC". Mmm. I'd be careful about inserting something like this. Can you explain the intention and the meaning of this clause? all policies: removed statement about publishing stats on non-approved transfers. Whoa, what's going on here? Not ok. Nick