From maildanrl at googlemail.com Thu Dec 1 18:53:03 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Thu, 1 Dec 2011 18:53:03 +0100 Subject: [address-policy-wg] Final minutes from RIPE 62 In-Reply-To: <4ED65180.5040904@ripe.net> References: <4ED65180.5040904@ripe.net> Message-ID: >Sander asked the audience to raise their hand to see who was in favour of removing the multihoming requirement for PI space and who was against this change. There were no strong majority either in favour or against, so he agreed to keep discussing this. Sigh. Time for a drink. Nevertheless, thanks for discussing this issue, hopefully consensus will be reached some day. regards Dan -- Dan Luedtke http://www.danrl.de From alexlh at ripe.net Mon Dec 5 16:20:27 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:20:27 +0100 Subject: [address-policy-wg] 128.0.0.0/16 configured as martians in some routers Message-ID: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC From alexlh at ripe.net Mon Dec 5 16:48:39 2011 From: alexlh at ripe.net (Alex Le Heux) Date: Mon, 5 Dec 2011 16:48:39 +0100 Subject: [address-policy-wg] 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <45D79898-3854-4671-AC9E-317A65C28FC7@ripe.net> Dear Colleagues, The correct prefix and pingable address list for the Debogonising Project is: prefix pinagble address 128.0.0.0/21 128.0.0.1 128.0.24.0/24 128.0.24.1 Our apologies for the oversight. Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC On Dec 5, 2011, at 16:20, Alex Le Heux wrote: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator > RIPE NCC From bengan at resilans.se Mon Dec 5 16:51:42 2011 From: bengan at resilans.se (Bengt =?iso-8859-1?q?G=F6rd=E9n?=) Date: Mon, 5 Dec 2011 16:51:42 +0100 Subject: [address-policy-wg] [ncc-announce] 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <201112051651.43186.bengan@resilans.se> m?ndagen den 5 december 2011 16.20.27 skrev Alex Le Heux: > Dear Colleagues, > > The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by > default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline > that this /16 should no longer be reserved as specialised address space. > > All allocations that were already issued have been exchanged and for now we > will hold this space in quarantine. > > We urge everyone to change the default behaviour of their Juniper routers: > > set routing-options martians 128.0.0.0/16 orlonger allow > set routing-options martians 191.255.0.0/16 orlonger allow > set routing-options martians 223.255.255.0/24 exact allow > > 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: > > http://www.ris.ripe.net/debogon/ > > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 Maybe atlas could come in handy here? regards, Bengt G?rd?n Resilans AB From fgkoehler at velia.net Mon Dec 5 16:54:01 2011 From: fgkoehler at velia.net (=?UTF-8?B?RnJhbnogR2VvcmcgS8O2aGxlcg==?=) Date: Mon, 05 Dec 2011 16:54:01 +0100 Subject: [address-policy-wg] [ncc-announce] 128.0.0.0/16 configured as martians in some routers In-Reply-To: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> References: <2DDABC15-3D2A-4044-B65D-A83FFB9E145F@ripe.net> Message-ID: <4EDCE919.8020306@velia.net> Am 05.12.11 16:20, schrieb Alex Le Heux: > To facilitate testing, the following prefixes are being announced: > > prefix pinagble address > > 128.0.0.0/16 128.0.0.1 > 128.0.8.0/21 128.0.8.1 > 128.0.24.0/24 128.0.24.1 Hello, can you confirm that the first two prefixes are propagated as advertised above? I see here: >show ip bgp 128.0.8.0/21 BGP4 : None of the BGP4 routes match the display condition >show ip bgp 128.0.0.0 Network Path *> 128.0.0.0/21 3549 3257 1103 12654 i From Tinet's route server: >show ip bgp 128.0.0.0 BGP routing table entry for 128.0.0.0/21, version 28585862 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 3257 1103 12654 >show ip bgp 128.0.8.0 % Network not in table route-server.as3257.net>show ip bgp 128.0.0.0/16 % Network not in table route-server.as3257.net>show ip bgp 128.0.8.0/21 % Network not in table Best regards, Franz Georg K?hler -- velia.net Internetdienste GmbH * Chemnitzer Str. 22 * 63452 Hanau Gesch?ftsf?hrer: Franz G. K?hler, Arek Akilli * AG Hanau * HRB 7588 Tel: 06181-1898119 * Fax: 06181-1898117 * e-mail: fgkoehler at velia.net From axel.pawlik at ripe.net Tue Dec 6 10:19:30 2011 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 06 Dec 2011 10:19:30 +0100 Subject: [address-policy-wg] RIPE NCC address request retracted Message-ID: <4EDDDE22.1060409@ripe.net> Dear colleagues, as a matter of good housekeeping I would like to announce that the RIPE NCC has retracted its request for addresses for "Business Operations", as presented at RIPE 63 (http://ripe63.ripe.net/presentations/53-resource-request.pdf). kind regards, Axel Pawlik From randy at psg.com Tue Dec 6 12:17:33 2011 From: randy at psg.com (Randy Bush) Date: Tue, 06 Dec 2011 20:17:33 +0900 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <4EDDDE22.1060409@ripe.net> References: <4EDDDE22.1060409@ripe.net> Message-ID: axel, > as a matter of good housekeeping I would like to announce > that the RIPE NCC has retracted its request for addresses > for "Business Operations", as presented at RIPE 63 > (http://ripe63.ripe.net/presentations/53-resource-request.pdf). ok, i'll bite. what is the ncc doing instead? or is the need no longer perceived? randy From axel.pawlik at ripe.net Tue Dec 6 13:36:20 2011 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 06 Dec 2011 13:36:20 +0100 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: References: <4EDDDE22.1060409@ripe.net> Message-ID: <4EDE0C44.3000001@ripe.net> Randy, > ok, i'll bite. what is the ncc doing instead? or is the need > no longer perceived? need continues. Have instructed staff to find fitting address space in the current holdings, and if needed, restructure / renumber. I should have insisted on that from the start, my responsibility... greetings, Axel From randy at psg.com Tue Dec 6 14:42:46 2011 From: randy at psg.com (Randy Bush) Date: Tue, 06 Dec 2011 22:42:46 +0900 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <4EDE0C44.3000001@ripe.net> References: <4EDDDE22.1060409@ripe.net> <4EDE0C44.3000001@ripe.net> Message-ID: hi axel, >> ok, i'll bite. what is the ncc doing instead? or is the need >> no longer perceived? > > need continues. Have instructed staff to find fitting address space in > the current holdings, and if needed, restructure / renumber. appreciate the answer. mfg randy From kurt_kayser at gmx.de Tue Dec 6 15:17:41 2011 From: kurt_kayser at gmx.de (Kurt Kayser) Date: Tue, 06 Dec 2011 15:17:41 +0100 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: References: <4EDDDE22.1060409@ripe.net> <4EDE0C44.3000001@ripe.net> Message-ID: <20111206141741.163150@gmx.net> Hi Axel, > >> ok, i'll bite. what is the ncc doing instead? or is the need > >> no longer perceived? > > > > need continues. Have instructed staff to find fitting address space in > > the current holdings, and if needed, restructure / renumber. > > appreciate the answer. True, ideally I would also like to see a comparison of effort of new address space to be used vs. legacy space analyzed and reorganized in order to save new request. (unit to measured in man-hours and amount of address space under discussion). Idea is to motivate people to start considering reorg vs. new blocks + requests for distribution. I also understand that above a certain size, this never would make sense. Regards, Kurt -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From nigel at titley.com Tue Dec 6 17:27:06 2011 From: nigel at titley.com (Nigel Titley) Date: Tue, 06 Dec 2011 16:27:06 +0000 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <20111206141741.163150@gmx.net> References: <4EDDDE22.1060409@ripe.net> <4EDE0C44.3000001@ripe.net> <20111206141741.163150@gmx.net> Message-ID: <4EDE425A.6090802@titley.com> On 06/12/11 14:17, Kurt Kayser wrote: > > True, ideally I would also like to see a comparison of effort of new address space to be used vs. legacy space analyzed and reorganized in order to save new request. (unit to measured in man-hours and amount of address space under discussion). > Idea is to motivate people to start considering reorg vs. new blocks + requests for distribution. I also understand that above a certain size, this never would make sense. > On the other hand I'd rather not see any more wasted time go down this rat-hole. Nigel From jim at rfc1035.com Tue Dec 6 18:00:14 2011 From: jim at rfc1035.com (Jim Reid) Date: Tue, 6 Dec 2011 17:00:14 +0000 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <4EDE425A.6090802@titley.com> References: <4EDDDE22.1060409@ripe.net> <4EDE0C44.3000001@ripe.net> <20111206141741.163150@gmx.net> <4EDE425A.6090802@titley.com> Message-ID: <5FC2BFBC-680A-406A-9343-01EDEDC9B37A@rfc1035.com> On 6 Dec 2011, at 16:27, Nigel Titley wrote: > On the other hand I'd rather not see any more wasted time go down > this rat-hole. +1 The (improper) request has been withdrawn and that's the end of it. Move on: nothing to see here. From nurani at netnod.se Tue Dec 6 21:15:38 2011 From: nurani at netnod.se (Nurani Nimpuno) Date: Tue, 6 Dec 2011 21:15:38 +0100 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <5FC2BFBC-680A-406A-9343-01EDEDC9B37A@rfc1035.com> References: <4EDDDE22.1060409@ripe.net> <4EDE0C44.3000001@ripe.net> <20111206141741.163150@gmx.net> <4EDE425A.6090802@titley.com> <5FC2BFBC-680A-406A-9343-01EDEDC9B37A@rfc1035.com> Message-ID: <9F36DC39-5483-4C2D-95D1-C34A86B8F063@netnod.se> On 6 dec 2011, at 18:00, Jim Reid wrote: > On 6 Dec 2011, at 16:27, Nigel Titley wrote: > >> On the other hand I'd rather not see any more wasted time go down this rat-hole. > > +1 > > The (improper) request has been withdrawn and that's the end of it. Move on: nothing to see here. Agreed. Let's not waste any further time on this. (And let's certainly not ask the RIPE NCC to spend any more time and resources on it.) Nurani From marty at akamai.com Wed Dec 7 03:46:39 2011 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 6 Dec 2011 20:46:39 -0600 Subject: [address-policy-wg] RIPE NCC address request retracted In-Reply-To: <4EDE0C44.3000001@ripe.net> Message-ID: On 12/6/11 7:36 AM, "Axel Pawlik" wrote: > > Randy, > >> ok, i'll bite. what is the ncc doing instead? or is the need >> no longer perceived? > > need continues. Have instructed staff to find fitting address > space in the current holdings, and if needed, restructure / renumber. > > I should have insisted on that from the start, my responsibility... > > greetings, Axel > > > > Thanks for setting a good example. Best, -M< From emadaio at ripe.net Wed Dec 7 15:47:22 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 07 Dec 2011 15:47:22 +0100 Subject: [address-policy-wg] Update in the RIPE document for IPv6 Allocation and Assignment policies Message-ID: <4EDF7C7A.3000605@ripe.net> Dear colleagues, An editorial correction has been made to ripe-523 "IPv6 Address Allocation and Assignment Policy". The updated document has been renumbered to ripe-538. It is available at: http://www.ripe.net/ripe/docs/ripe-538 There was a mismatch between the policy text and the index title for section 5.4.2. This mismatch occurred between the updates from ripe-421 to ripe-450. Apologies for any inconvenience caused. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Thu Dec 8 22:12:34 2011 From: gert at space.net (Gert Doering) Date: Thu, 8 Dec 2011 22:12:34 +0100 Subject: [address-policy-wg] status of 2011-02 Message-ID: <20111208211234.GV72014@Space.Net> Dear AP WG, 2011-02 has been a difficult one, and you have noticed the lack of visible progress. So let us explain, and propose a way forward. The RIPE policy development process calls for "consensus" to make policy from policy proposals. Sometimes it's very clear if consensus has been reached, and sometimes it's very clear that consensus has NOT been reached. When looking for consensus, we have to see if there are objections to the proposal, and if those objections are justified - see the beginning of section 2 of RIPE-500: 'In all phases of the RIPE PDP, suggestions for changes to the proposal and objections regarding the proposal must be justified with supporting arguments'. This is explicitly repeated in section 2.4. In 2011-02, we have the case of "rough consensus with objections": We have a number of people who spoke up in favour of the proposal, both during the discussion/review phases and during Last Call. A few persons had serious doubts about routing table growth and about PI in general, but still spoke in favour of the proposal, or abstained. One person opposes the proposal, based on worries about highly accelerated and thus unsustainable routing table growth as a consequence of the proposal. Given that some of the other RIRs already have less restrictive IPv6 PI policies, the available numbers on their PI assignments and the routes seen in the global IPv6 BGP table do not back this assumption. Neither does the data from the global IPv4 BGP table, where the RIPE region has always had a very relaxed PI policy. So the AP WG chairs have decided (after long discussion) that we do have rough consensus on this policy proposal, and the remaining objections will be ignored. Sander Steffann announced this at the APWG meeting - and one member of the WG spoke up at the microphone and disagreed with our conclusion. So we spent some more weeks discussing and thinking about this, and this is what we do now: - the WG chairs declare consensus - but the *working group* has the last word on any policy decision, so we call for two weeks of "Last Call" on this decision Procedure-wise, this is not about the *content* of the proposal now, and it's not useful to repeat the discussion about routing table growth etc. now - we've heard all arguments. What we need to decide now is whether the voices from the community so far form "rough consensus" on the proposal, or not. If you, the WG, decides that we do not have consensus, the policy proposal goes back to "discussion phase", and the proposer will need to work with those people that spoke up against the proposal to integrate their ideas, and come up with a new version of the policy proposal that might then reach consensus. sincerly yours, Gert Doering & Sander Steffann, APWG chairs -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From scottleibrand at gmail.com Thu Dec 8 23:53:07 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 8 Dec 2011 14:53:07 -0800 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <3525644164248418925@unknownmsgid> I agree that rough consensus has been established. Scott On Dec 8, 2011, at 1:12 PM, Gert Doering wrote: > Dear AP WG, > > 2011-02 has been a difficult one, and you have noticed the lack of > visible progress. So let us explain, and propose a way forward. > > The RIPE policy development process calls for "consensus" to make > policy from policy proposals. Sometimes it's very clear if consensus > has been reached, and sometimes it's very clear that consensus has > NOT been reached. > > When looking for consensus, we have to see if there are objections to the > proposal, and if those objections are justified - see the beginning of > section 2 of RIPE-500: 'In all phases of the RIPE PDP, suggestions > for changes to the proposal and objections regarding the proposal must > be justified with supporting arguments'. This is explicitly repeated in > section 2.4. > > In 2011-02, we have the case of "rough consensus with objections": > > We have a number of people who spoke up in favour of the proposal, both > during the discussion/review phases and during Last Call. A few persons > had serious doubts about routing table growth and about PI in general, but > still spoke in favour of the proposal, or abstained. > > One person opposes the proposal, based on worries about highly accelerated > and thus unsustainable routing table growth as a consequence of the > proposal. > > Given that some of the other RIRs already have less restrictive IPv6 PI > policies, the available numbers on their PI assignments and the routes > seen in the global IPv6 BGP table do not back this assumption. Neither > does the data from the global IPv4 BGP table, where the RIPE region has > always had a very relaxed PI policy. > > So the AP WG chairs have decided (after long discussion) that we do > have rough consensus on this policy proposal, and the remaining > objections will be ignored. Sander Steffann announced this at the > APWG meeting - and one member of the WG spoke up at the microphone > and disagreed with our conclusion. > > So we spent some more weeks discussing and thinking about this, and > this is what we do now: > > - the WG chairs declare consensus > > - but the *working group* has the last word on any policy decision, > so we call for two weeks of "Last Call" on this decision > > > Procedure-wise, this is not about the *content* of the proposal now, and > it's not useful to repeat the discussion about routing table growth etc. > now - we've heard all arguments. What we need to decide now is whether > the voices from the community so far form "rough consensus" on the > proposal, or not. > > If you, the WG, decides that we do not have consensus, the policy proposal > goes back to "discussion phase", and the proposer will need to work with > those people that spoke up against the proposal to integrate their ideas, > and come up with a new version of the policy proposal that might then > reach consensus. > > sincerly yours, > > Gert Doering & Sander Steffann, APWG chairs > > -- > 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 (89) 32356-444 USt-IdNr.: DE813185279 > From slz at baycix.de Fri Dec 9 00:23:16 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 9 Dec 2011 00:23:16 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <3589A1DF-D1E8-4854-8C0A-5119373EBDDC@baycix.de> Hi, thank you for carefully choosing your actions and wording about this, as a community member i appreciate that *thumbsup* ... [...] > So we spent some more weeks discussing and thinking about this, and > this is what we do now: > > - the WG chairs declare consensus > > - but the *working group* has the last word on any policy decision, > so we call for two weeks of "Last Call" on this decision > > > Procedure-wise, this is not about the *content* of the proposal now, and > it's not useful to repeat the discussion about routing table growth etc. > now - we've heard all arguments. What we need to decide now is whether > the voices from the community so far form "rough consensus" on the > proposal, or not. > > If you, the WG, decides that we do not have consensus, the policy proposal > goes back to "discussion phase", and the proposer will need to work with > those people that spoke up against the proposal to integrate their ideas, > and come up with a new version of the policy proposal that might then > reach consensus. ... but let me be a bit more blunt here (thank god i do not wear hats or chairs on my head usually), and say we do have (rough) consensus for a long time already and finally should move on. (My personal point of view of course, but i think there is only one person objecting violently, and i don't see anything about veto-rights in the PDP) I'm still happy to consider any new proposal how to do things better with PI from anyone. But keeping PIv6 different from PIv4 just isn't compatible with reality right now, and there are no signs of any real downsides. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From flo at degnet.de Fri Dec 9 04:25:20 2011 From: flo at degnet.de (Florian Fuessl) Date: Fri, 9 Dec 2011 04:25:20 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <3589A1DF-D1E8-4854-8C0A-5119373EBDDC@baycix.de> References: <20111208211234.GV72014@Space.Net> <3589A1DF-D1E8-4854-8C0A-5119373EBDDC@baycix.de> Message-ID: <50C0D928-4269-4A21-8E4C-4811EA9760C3@degnet.de> Sascha Lenz wrote Dez. 09 2011 - 00:23: > Hi, > > thank you for carefully choosing your actions and wording about this, as > a community member i appreciate that *thumbsup* ... > > [...] > > I'm still happy to consider any new proposal how to do things better with PI > from anyone. But keeping PIv6 different from PIv4 just isn't compatible with reality right now, > and there are no signs of any real downsides. > +1 it's irreproducible that it's currently not possible to assign PIv6 for recipients which can apply for PIv4. Why are we putting spokes in sb.'s wheels on moving forward to IPv6 at the moment? > -- > Mit freundlichen Gr??en / Kind Regards > > Sascha Lenz [SLZ-RIPE] > Senior System- & Network Architect Best regards, Florian Fuessl From immo.apwg at be.free.de Fri Dec 9 01:36:41 2011 From: immo.apwg at be.free.de (Immo 'FaUl' Wehrenberg) Date: Fri, 9 Dec 2011 01:36:41 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <20111209003641.GH15300@benabuFaUl.be.free.de> Gert Doering wrote: > - but the *working group* has the last word on any policy decision, > so we call for two weeks of "Last Call" on this decision As much as I like to see this policy change implemented and as much as I disagree with Geza, technically if someone is opposing (and I think all would agree that it was not trolling), then that is technically not an consensus. However, I'd like to hear Gezas opinion on wether rough consensus has been reached and would subscribe to his view on that. Regards, Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lutz at iks-jena.de Thu Dec 8 22:53:33 2011 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 8 Dec 2011 22:53:33 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <201112082153.pB8LrX27017772@belenus.iks-jena.de> > Procedure-wise, this is not about the *content* of the proposal now, and > it's not useful to repeat the discussion about routing table growth etc. > now - we've heard all arguments. What we need to decide now is whether > the voices from the community so far form "rough consensus" on the > proposal, or not. I'd like to have it back to discussion. My position is only formal: The proposal argues that a requirement (multihoming) is not longer needed, because there might be an other (assumed to be weaker) condition (own AS) for PIv6. I do accept the reasoning itself, but not the formal consequence drawn by the proposal. If somebody likes to have "A or B" instead of "A", it's not sufficent to remove "A". From randy at psg.com Fri Dec 9 10:09:15 2011 From: randy at psg.com (Randy Bush) Date: Fri, 09 Dec 2011 18:09:15 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111209003641.GH15300@benabuFaUl.be.free.de> References: <20111208211234.GV72014@Space.Net> <20111209003641.GH15300@benabuFaUl.be.free.de> Message-ID: > As much as I like to see this policy change implemented and as much as > I disagree with Geza, technically if someone is opposing (and I think > all would agree that it was not trolling), then that is technically > not an consensus. you may find http://en.wikipedia.org/wiki/Consensus_decision-making, especially the section on "Decision rules," usefully confusing. randy From slz at baycix.de Fri Dec 9 10:16:28 2011 From: slz at baycix.de (Sascha Lenz) Date: Fri, 9 Dec 2011 10:16:28 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111209003641.GH15300@benabuFaUl.be.free.de> References: <20111208211234.GV72014@Space.Net> <20111209003641.GH15300@benabuFaUl.be.free.de> Message-ID: Hi, > Gert Doering wrote: >> - but the *working group* has the last word on any policy decision, >> so we call for two weeks of "Last Call" on this decision > > As much as I like to see this policy change implemented and as much as > I disagree with Geza, technically if someone is opposing (and I think all > would agree that it was not trolling), then that is technically not an > consensus. > > However, I'd like to hear Gezas opinion on wether rough consensus has been > reached and would subscribe to his view on that. the PDP calls for rough consensus, not for unanimous consensus. There's a difference, check Randy's link or http://en.wikipedia.org/wiki/Consensus#Near-unanimous_consensus -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From jim at rfc1035.com Fri Dec 9 10:31:47 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Dec 2011 09:31:47 +0000 Subject: [address-policy-wg] defining consensus In-Reply-To: <20111209003641.GH15300@benabuFaUl.be.free.de> References: <20111208211234.GV72014@Space.Net> <20111209003641.GH15300@benabuFaUl.be.free.de> Message-ID: <11621E74-BB5E-428B-89DB-B2E090CB8595@rfc1035.com> On 9 Dec 2011, at 00:36, Immo 'FaUl' Wehrenberg wrote: > As much as I like to see this policy change implemented and as much as > I disagree with Geza, technically if someone is opposing (and I > think all > would agree that it was not trolling), then that is technically not an > consensus. No. You're describing unanimity: where everyone agrees or at least nobody objects. Consensus is when there's a lack of sustained, reasonable objection. That's the usual working definition used in most consensus-driven organisations, which includes RIPE. We can have consensus in RIPE without having unanimity. A single voice of complaint cannot be allowed to mean we can't declare consensus. Nobody at RIPE can have a veto on policy making. If they did, that would be utterly unworkable. IMO, the concerns Geza raised -- and has since withdrawn? -- fail to pass the test of sustained, reasonable objection. Nobody else seemed to support his position. Incidentally, consensus in a WG is whatever its chairs decide is consensus. That's why they're there. :-) And why there are further steps in the PDP to check that decision. If a small number object to a proposal that otherwise has overwhelming support, the WG chairs can quite reasonably declare consensus on that proposal. From james.blessing at despres.co.uk Fri Dec 9 10:52:19 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 9 Dec 2011 09:52:19 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: On 8 December 2011 21:12, Gert Doering wrote: > If you, the WG, decides that we do not have consensus, the policy proposal > goes back to "discussion phase", and the proposer will need to work with > those people that spoke up against the proposal to integrate their ideas, > and come up with a new version of the policy proposal that might then > reach consensus. I don't like the policy as I think its a bad idea (I'd rather IPv4 PI required multihoming if you want to make PI more 'equal'), but thats not the question on the slab... It seems that the majority believe the proposal has merit, that the majority of those that are against the proposal are actually concerned about the unintended consequences (table growth) rather than the policy itself. We have discussed alternatives that would 'brake' the table growth as part of the change but many have been written off as unworkable (and possibly a poor policy development idea) so it seems to me that we are in fact at a consensus *but* that the NCC should be tasked with monitoring impact and reporting at a fixed point in the future. J -- James Blessing 07989 039 476 From immo.ripe at be.free.de Fri Dec 9 10:47:44 2011 From: immo.ripe at be.free.de (Immo 'FaUl' Wehrenberg) Date: Fri, 9 Dec 2011 10:47:44 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: Message-ID: <20111209094744.GI15300@benabuFaUl.be.free.de> Randy, > > As much as I like to see this policy change implemented and as much as > > I disagree with Geza, technically if someone is opposing (and I think > > all would agree that it was not trolling), then that is technically > > not an consensus. > you may find http://en.wikipedia.org/wiki/Consensus_decision-making, > especially the section on "Decision rules," usefully confusing. Ok, you got me. It was late and my statemant was, as you pointed out, flawed. I'll have another try to get up a proper justification for my point: I'd like to point on the introduction of this article: "Consensus is defined [...] as, first, general agreement, and second, group solidarity of belief or sentiment." General agreement is established by these rules you refered to. However, "group solidarity of belief or sentiment" in my opinion isn't that easy. I personally am not sure wether we have "group solidarity of belief or sentiment" here, and I don't think we can declare it without Geza agreeing. To be clear here: that does not meen that Geza must agree on the proposal or withdraw his objections. I only ask wether he considers the groups belief and sentiment on accepting the proposal solidary. Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Jasper.Jans at espritxb.nl Fri Dec 9 11:01:13 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Fri, 9 Dec 2011 11:01:13 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD201046AB8A281@EXCH01.campus.local> I agree on consensus being there on this item. Jasper -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Gert Doering Sent: Thursday, December 08, 2011 10:13 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] status of 2011-02 Dear AP WG, 2011-02 has been a difficult one, and you have noticed the lack of visible progress. So let us explain, and propose a way forward. Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From t.schallar at avalon.at Fri Dec 9 11:22:11 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Fri, 09 Dec 2011 11:22:11 +0100 Subject: [address-policy-wg] defining consensus In-Reply-To: <11621E74-BB5E-428B-89DB-B2E090CB8595@rfc1035.com> References: <20111208211234.GV72014@Space.Net> <20111209003641.GH15300@benabuFaUl.be.free.de> <11621E74-BB5E-428B-89DB-B2E090CB8595@rfc1035.com> Message-ID: <4EE1E153.1010001@avalon.at> Jim Reid schrieb am 09.12.2011 10:31: > Incidentally, consensus in a WG is whatever its chairs decide is > consensus. That's why they're there. :-) And why there are further > steps in the PDP to check that decision. If a small number object to a > proposal that otherwise has overwhelming support, the WG chairs can > quite reasonably declare consensus on that proposal. I totally support that!!! :-) You may never ever get 100.0% agreement for /any/ decision. Nevertheless, a decision has to be made eventually. That's one big problem in democracy and there's no solution to that. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Fri Dec 9 11:49:01 2011 From: nick at inex.ie (Nick Hilliard) Date: Fri, 09 Dec 2011 10:49:01 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111209094744.GI15300@benabuFaUl.be.free.de> References: <20111209094744.GI15300@benabuFaUl.be.free.de> Message-ID: <4EE1E79D.5050408@inex.ie> On 09/12/2011 09:47, Immo 'FaUl' Wehrenberg wrote: > I personally am not sure wether we have "group solidarity of belief or > sentiment" here, and I don't think we can declare it without Geza agreeing. > > To be clear here: that does not meen that Geza must agree on the proposal > or withdraw his objections. I only ask wether he considers the groups belief > and sentiment on accepting the proposal solidary. Immo, You're arguing that the person who shouts loudest should have a veto. This is not consensus, and is not how APWG operates. Nick From jim at rfc1035.com Fri Dec 9 11:49:11 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Dec 2011 10:49:11 +0000 Subject: [address-policy-wg] consensus and 2011-02 In-Reply-To: <20111209094744.GI15300@benabuFaUl.be.free.de> References: <20111209094744.GI15300@benabuFaUl.be.free.de> Message-ID: On 9 Dec 2011, at 09:47, Immo 'FaUl' Wehrenberg wrote: > I personally am not sure wether we have "group solidarity of belief or > sentiment" here Luckily, this is not a decision you alone have to take for the rest of us. The WG does so collectively. The "group solidarity of belief or sentiment" of the WG is that there *is* consensus. [Or at least that's my impression.] If the AP WG chairs determine that the WG has arrived at a consensus, consensus is declared and the proposal goes on to the next stage of the PDP. If you personally are unsure if the WG has reached consensus on 2011-02, say so. And do it very clearly. For bonus points, explain why you have doubts. This might encourage others holding that view to that so too. Explaining why you are unsure would perhaps allow others to clarify matters. If there are enough people on the list saying they are unsure, then by definition we can't have consensus on the proposal in the WG because that level of doubt shows there is uncertainty about "group solidarity of belief or sentiment". > I don't think we can declare it without Geza agreeing. We can. And I think we already have. Geza's consent (or lack of opposition) is not critical to declaring consensus on 2011-02. He does not have a veto. Nobody does. From sander at steffann.nl Fri Dec 9 12:23:59 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 9 Dec 2011 12:23:59 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> Message-ID: <0F980AA2-55E8-486C-AC0F-C65D8A86C3AC@steffann.nl> Hi James, > *but* that the NCC should be tasked with monitoring impact and reporting at a fixed point in the future. We (as working group chairs) will take care of this. This is definitely something that needs to be monitored. We will (or let the NCC) report at least at every RIPE meeting. Met vriendelijke groet, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From pk at DENIC.DE Fri Dec 9 15:42:53 2011 From: pk at DENIC.DE (Peter Koch) Date: Fri, 9 Dec 2011 15:42:53 +0100 Subject: [address-policy-wg] consensus and 2011-02 In-Reply-To: References: <20111209094744.GI15300@benabuFaUl.be.free.de> Message-ID: <20111209144253.GR30174@x27.adm.denic.de> On Fri, Dec 09, 2011 at 10:49:11AM +0000, Jim Reid wrote: > >I don't think we can declare it without Geza agreeing. > > We can. And I think we already have. Geza's consent (or lack of > opposition) is not critical to declaring consensus on 2011-02. He does > not have a veto. Nobody does. either way this is not about executing a veto and the whole debate around a particular person's position misses the point and puts an unfair onus on that person. I'd rather wish the same logic would be applied to the undoubtedly high number of 'yes' votes(sic!). If it's all about 'one person cannot block' then tell me, how many would it need? Since the burden of proof seems to be on the 'objector' rather than the proponent, I cannot prove sky will fall, but I know that once sky starts falling, discussing the counter measures will become increasingly unpleasant. -Peter From jim at rfc1035.com Fri Dec 9 16:08:20 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Dec 2011 15:08:20 +0000 Subject: [address-policy-wg] consensus and 2011-02 In-Reply-To: <20111209144253.GR30174@x27.adm.denic.de> References: <20111209094744.GI15300@benabuFaUl.be.free.de> <20111209144253.GR30174@x27.adm.denic.de> Message-ID: On 9 Dec 2011, at 14:42, Peter Koch wrote: > If it's all about 'one person cannot block' then tell me, how many > would it need? The same number as it needs in the dnsop WG you chair at IETF Peter. :-) We both know this is not decided by absolute numbers Peter. The Chair(s) of the relevant WG exercise their best judgement on the position of the WG as a whole. [That's why they get the big bucks. :-)] If they believe there's consensus in the WG, that's the decision. They could decide that one lone voice knows better than the rest of the WG => further discussion or refinement of the proposal is needed. That will depend on the specific circumstances and the nature of that (isolated?) objection. Note too that the earlier discussion was sparked by the suggestion that there could be no consensus on 2011-02 unless Geza said this was OK. We both know that this is not how RIPE's consensus decision-making process works. You might recall how the DNS WG arrived at a consensus response to the DoC proposal for getting the DNS root signed a few years ago and who made the judgement on whether a consensus had been reached. Some people were unhappy or uncomfortable with aspects of that response yet it still managed to emerge as a consensus view of the WG. And ultimately of the RIPE community. From pk at DENIC.DE Fri Dec 9 15:28:56 2011 From: pk at DENIC.DE (Peter Koch) Date: Fri, 9 Dec 2011 15:28:56 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <20111209142856.GQ30174@x27.adm.denic.de> On Thu, Dec 08, 2011 at 10:12:34PM +0100, Gert Doering wrote: > So the AP WG chairs have decided (after long discussion) that we do > have rough consensus on this policy proposal, and the remaining > objections will be ignored. I would certainly hope that these objections will not be ignored but considered addressed. The important difference being that they have been taken seriously based on their own merits and found to be outweighed by the counter arguments (and/or there was no way to compromise). That's a judgement to be made and you've made it. In this case let me say, one could also reasonably come to a different conclusion. -Peter From t.schallar at avalon.at Fri Dec 9 16:22:58 2011 From: t.schallar at avalon.at (DI. Thomas Schallar) Date: Fri, 09 Dec 2011 16:22:58 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> References: <20111208211234.GV72014@Space.Net> Message-ID: <4EE227D2.8000907@avalon.at> I agree that rough consensus has been established. Thomas Gert Doering schrieb am 08.12.2011 22:12: > So the AP WG chairs have decided (after long discussion) that we do > have rough consensus on this policy proposal, and the remaining > objections will be ignored. From gert at space.net Fri Dec 9 16:30:27 2011 From: gert at space.net (Gert Doering) Date: Fri, 9 Dec 2011 16:30:27 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111209142856.GQ30174@x27.adm.denic.de> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: <20111209153027.GK72014@Space.Net> Hi, On Fri, Dec 09, 2011 at 03:28:56PM +0100, Peter Koch wrote: > On Thu, Dec 08, 2011 at 10:12:34PM +0100, Gert Doering wrote: > > > So the AP WG chairs have decided (after long discussion) that we do > > have rough consensus on this policy proposal, and the remaining > > objections will be ignored. > > I would certainly hope that these objections will not be ignored > but considered addressed. Yes. "For judging consensus, they will not be considered further", but of course (Sander already said so) we will take Geza and Mikael's concerns into account, and *will* monitor the routing table and assignment numbers. So this was a somewhat poor choice of words. > The important difference being that they > have been taken seriously based on their own merits and found > to be outweighed by the counter arguments (and/or there was no > way to compromise). That's a judgement to be made and you've made it. There was no way to compromise within the given policy text, so that's the decision we've taken. Yes. 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 (89) 32356-444 USt-IdNr.: DE813185279 From randy at psg.com Sat Dec 10 07:02:15 2011 From: randy at psg.com (Randy Bush) Date: Sat, 10 Dec 2011 15:02:15 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111209142856.GQ30174@x27.adm.denic.de> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: > I would certainly hope that these objections will not be ignored > but considered addressed. the concerns (which careful reading of the thread would show that i shared with geza) were not 'addressed' in the sense of overcome. we were just a teenie minority. and i, for one, did not consider it a battle worth being the objector. i agree with the chairs that rough consensus was reached. if the chickens come home to roost on this one, i'll laugh a little and sigh a lot. randy From turchanyi.geza at gmail.com Sat Dec 10 07:33:10 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 10 Dec 2011 07:33:10 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: Hello, I am glad to see that I am not alone. However, I am still worried that several people voted for a free beer. OK, free beer is nice if somebody is ready to pay it ;-(), but this case is a different one. The problem is that the limits of the technology can not be changed by voting and concensus declaration. AND the whole policy addresses global issues. The policy proposal was a very bad message for other regions. Liberty to pollut (in this case: the global routing table) is not a liberty for me. Thanks, G?za On Sat, Dec 10, 2011 at 7:02 AM, Randy Bush wrote: > > I would certainly hope that these objections will not be ignored > > but considered addressed. > > the concerns (which careful reading of the thread would show that i > shared with geza) were not 'addressed' in the sense of overcome. > randy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Sat Dec 10 09:01:42 2011 From: randy at psg.com (Randy Bush) Date: Sat, 10 Dec 2011 17:01:42 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: > I am still worried that several people voted for a free beer. geza, at my age i might be worried, but i am certainly not surprised. given a sufficiently large population, in this case i suspect three is large, someone will always vote for free beer. randy From turchanyi.geza at gmail.com Sat Dec 10 09:13:47 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sat, 10 Dec 2011 09:13:47 +0100 Subject: [address-policy-wg] consensus and 2011-02 In-Reply-To: References: <20111209094744.GI15300@benabuFaUl.be.free.de> <20111209144253.GR30174@x27.adm.denic.de> Message-ID: Hi Jim, I also think that your argument: 'one person can not block' is valid. However, I am not alone. I remember people from Norvege, Germany, Ukraine, etc, sharing the concerns or even expressing better than I did. Perhaps also you! Fredy Kuenzler - How More Specifics increase your transit bill (and ways to avoid it)this was a nice talk on Tuesday's plenary, explaining how and why to keep the routing table simpler and smaller - in a little bit different context. Unfortunately very few "PI+1 activists" attended.... Is the old concensus that we should listen to the others still valid? You do, I know, but what about these "PI+1 activists"? Best, G?za On Fri, Dec 9, 2011 at 4:08 PM, Jim Reid wrote: > On 9 Dec 2011, at 14:42, Peter Koch wrote: > > If it's all about 'one person cannot block' then tell me, how many >> would it need? >> > > The same number as it needs in the dnsop WG you chair at IETF Peter. :-) > > We both know this is not decided by absolute numbers Peter. The Chair(s) > of the relevant WG exercise their best judgement on the position of the WG > as a whole. [That's why they get the big bucks. :-)] If they believe > there's consensus in the WG, that's the decision. They could decide that > one lone voice knows better than the rest of the WG => further discussion > or refinement of the proposal is needed. That will depend on the specific > circumstances and the nature of that (isolated?) objection. > > Note too that the earlier discussion was sparked by the suggestion that > there could be no consensus on 2011-02 unless Geza said this was OK. We > both know that this is not how RIPE's consensus decision-making process > works. > > You might recall how the DNS WG arrived at a consensus response to the DoC > proposal for getting the DNS root signed a few years ago and who made the > judgement on whether a consensus had been reached. Some people were unhappy > or uncomfortable with aspects of that response yet it still managed to > emerge as a consensus view of the WG. And ultimately of the RIPE community. > > > > (BTW, thsi is not a RIPE matter, however, a global one) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Sun Dec 11 11:17:18 2011 From: jim at rfc1035.com (Jim Reid) Date: Sun, 11 Dec 2011 10:17:18 +0000 Subject: [address-policy-wg] consensus and 2011-02 In-Reply-To: References: <20111209094744.GI15300@benabuFaUl.be.free.de> <20111209144253.GR30174@x27.adm.denic.de> Message-ID: <93311490-92CC-4505-AB07-994CCD044F4B@rfc1035.com> On 10 Dec 2011, at 08:13, Turchanyi Geza wrote: > However, I am not alone. I remember people from Norvege, Germany, > Ukraine, > etc, sharing the concerns or even expressing better than I did. Yes, though they seem to be a lot quieter now. > Perhaps also you! Perhaps. :-) FWIW I am uncomfortable with this proposal, but not enough to oppose the general consensus view. Provided the NCC monitor the situation well, that should give us plenty of warning and time to react if Bad Things start to happen. Famous last words... We should remember that policies do not have to be perfect or live forever. They can always be changed or killed later. Whenever circumstances change, so should our policies. It may well be better to go with a less than perfect policy today (so stuff can get done) than hope the perfect policy might emerge tomorrow (and nothing gets done until that happens). ie First develop something that's "good enough" and then amend it in light of actual experience. > what about these "PI+1 activists"? This is always a problem. One way or another we're all proponents of free beer. [Economists call things like free beer "externalities": you push your costs and hassles elsewhere so somebody else pays for them.] We just have to live with this. Externalities are inherent to almost every system, not just RIPE policy making. From maildanrl at googlemail.com Sun Dec 11 12:55:36 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Sun, 11 Dec 2011 12:55:36 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: > In 2011-02, we have the case of "rough consensus with objections": Finally :) I agree on the rough consensus thing, and I am glad it finally happened. regards, Dan -- Dan Luedtke http://www.danrl.de From jan at go6.si Sun Dec 11 15:25:54 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 11 Dec 2011 15:25:54 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> Message-ID: <4EE4BD72.2030700@go6.si> On 12/10/11 7:33 AM, Turchanyi Geza wrote: > Liberty to pollut (in this case: the global routing table) is not a > liberty for me. maybe that would be real incentive to replace bgp with something that is more efficient and scales better. Jan From sander at steffann.nl Sun Dec 11 16:04:10 2011 From: sander at steffann.nl (Sander Steffann) Date: Sun, 11 Dec 2011 16:04:10 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE4BD72.2030700@go6.si> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> Message-ID: <2CBFC02E-6E43-4897-927B-2BA00BDBF02B@steffann.nl> >> Liberty to pollut (in this case: the global routing table) is not a >> liberty for me. > > maybe that would be real incentive to replace bgp with something that is more efficient and scales better. The ultimate address policy dream: giving out addresses without having to worry about the routing table ;-) Met vriendelijke groet, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From nick at inex.ie Sun Dec 11 16:27:45 2011 From: nick at inex.ie (Nick Hilliard) Date: Sun, 11 Dec 2011 15:27:45 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE4BD72.2030700@go6.si> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> Message-ID: <4EE4CBF1.9070206@inex.ie> On 11/12/2011 14:25, Jan Zorz @ go6.si wrote: > maybe that would be real incentive to replace bgp with something that is > more efficient and scales better. bgp isn't the problem here. In fact, BGP is doing just fine: it scales linearly according the number of prefixes, and is staying well behind moore's law, as you can run bgp calculation engines on commodity CPU. The problem we face is dealing with lookup engines which can process ever increasing numbers of prefixes at ever faster rates. Nick From turchanyi.geza at gmail.com Sun Dec 11 21:50:46 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Sun, 11 Dec 2011 21:50:46 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE4CBF1.9070206@inex.ie> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> Message-ID: Hi Nick, On Sun, Dec 11, 2011 at 4:27 PM, Nick Hilliard wrote: > On 11/12/2011 14:25, Jan Zorz @ go6.si wrote: > > maybe that would be real incentive to replace bgp with something that is > > more efficient and scales better. > > bgp isn't the problem here. In fact, BGP is doing just fine: it scales > linearly according the number of prefixes, and is staying well behind > moore's law, as you can run bgp calculation engines on commodity CPU. > > The problem we face is dealing with lookup engines which can process ever > increasing numbers of prefixes at ever faster rates. > > Nick > > OK, simplification might help, however, may I try to add more details? 1, It would be better not to forget the limits of the equipments installed in the current network (not negligabe percentage of the installed equipments with 500k IPv4 prefix capability only.). 2, As far as I know network convergence still needs several 10s of seconds in real life, even with faster CPU in the installed equipments. 3, YES: updating and accessing the FIB stored in the memory of line cards need time, and the time needed is hard to reduce. (No hope in "Moore low"). Plus: a 40GE, or a 100GE card needs even more complicated and costly arrangements of memory banks allowing timely access of FIB at line speed. Anyhow, do we agree that forward looking statements about the technology of the future and the policy that we accept today are two different issues? Do we agree that a clear, understandable limitation of the bad effects of the PI address space would be helpfull, and reduce the conflict between PI-funs and "clean-forwarding-table" networkers? I suggested a mesure: OK. let's allow PI allocations in exceptional cases until the number of PI allocations is below of the number of the LIR in the RIPE regions. (Other regions might accept the same, therefore it is easy to extend this policy limitaton at global level, and keeping the "pollution" low, globally). OR, do you want PI allocation for every village in certain continents? Best, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon Dec 12 00:55:17 2011 From: nick at inex.ie (Nick Hilliard) Date: Sun, 11 Dec 2011 23:55:17 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> Message-ID: <4EE542E5.2010309@inex.ie> On 11/12/2011 20:50, Turchanyi Geza wrote: > 1, It would be better not to forget the limits of the equipments installed > in the current network (not negligabe percentage of the installed > equipments with 500k IPv4 prefix capability only.). Routers with RE space for only 500k prefixes will soon be defunct if they aren't already. It's been pretty easy to project ipv4 RIB growth over the last several years. Take a look at: http://bgp.potaroo.net/bgprpts/bgp-active.png If you draw a straight line on the basis of any period after 2004, you'll see that we'll hit 500k prefixes some time in 2013. If you're using ipv6 or mpls or have a large IGP or have a l3vpn network, you're probably outside the bounds of 500k prefix routers. So I'm not really feeling very sympathetic to someone who's attempting to run a full DFZ on a 500k prefix box: either they haven't done their projections properly (in which case they need to consider a different career), or else they bought the box years ago, and it's been depreciated off their books. If you're using equipment that you many years ago, you shouldn't expect it to last forever, particularly if it has hard resource limits - e.g. forwarding table size. This is simply how hardware forwarding engines work. We're no longer able to run anything more than tiny networks on 7200s and J series boxes. It just doesn't work that way any more, and hasn't worked like that for years. > 2, As far as I know network convergence still needs several 10s of seconds > in real life, even with faster CPU in the installed equipments. More importantly, Moore's law has ensured that CPU speeds have increased faster than the DFZ BGP table has grown over the last number of years. BGP and routing churn are not the problem here. > Do we agree that a clear, understandable limitation of the bad effects of > the PI address space would be helpfull, and reduce the conflict between > PI-funs and "clean-forwarding-table" networkers? We're all adults and we all understand the implications of DFZ table growth. > I suggested a mesure: OK. let's allow PI allocations in exceptional cases > until the number of PI allocations is below of the number of the LIR in the > RIPE regions. (Other regions might accept the same, therefore it is easy to > extend this policy limitaton at global level, and keeping the "pollution" > low, globally). I'm not in favour of the idea of pulling a figure out of thin air and saying that we shouldn't allow any more ipv6 PI assignments than this. The number of LIRs in the RIPE region is no more relevant to a good quality PI assignment policy than any other randomly chosen number. > OR, do you want PI allocation for every village in certain continents? Let's not create a straw man argument. IPv4 didn't cause the sky to fall, and IPv6 won't cause it to fall either. If IPv6 PI starts showing signs of causing problems over the next couple of years, then we can change the policy. Nick From turchanyi.geza at gmail.com Mon Dec 12 08:38:00 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Mon, 12 Dec 2011 08:38:00 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE542E5.2010309@inex.ie> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> Message-ID: Hello Nick, I see that we still disagree on many points. On Mon, Dec 12, 2011 at 12:55 AM, Nick Hilliard wrote: > On 11/12/2011 20:50, Turchanyi Geza wrote: > > 1, It would be better not to forget the limits of the equipments > installed > > in the current network (not negligabe percentage of the installed > > equipments with 500k IPv4 prefix capability only.). > > Routers with RE space for only 500k prefixes will soon be defunct if they > aren't already. It's been pretty easy to project ipv4 RIB growth over the > last several years. Take a look at: > > http://bgp.potaroo.net/bgprpts/bgp-active.png > > If you draw a straight line on the basis of any period after 2004, you'll > see that we'll hit 500k prefixes some time in 2013. If you're using ipv6 > or mpls or have a large IGP or have a l3vpn network, you're probably > outside the bounds of 500k prefix routers. > The same trends coud not apply after the IPv4 address space run-out. An earlier (IPv4->IPv6) transition, or cleaning the announcements would stop the growth and even reduce the table. And not only the 500K limit could be reached soon if the size of the routing table is not considered important while deciding about policy, however, the 1000K limit as well. What affects a much larger chunk of the installed equipments. > > > > 2, As far as I know network convergence still needs several 10s of > seconds > > in real life, even with faster CPU in the installed equipments. > > More importantly, Moore's law has ensured that CPU speeds have increased > faster than the DFZ BGP table has grown over the last number of years. BGP > and routing churn are not the problem here. > I have still quastion marks: if a severe earthquake cuts an optical cable under the ocean how much time needed for the global routing to converge? Increasing the BGP table is easy.... changing the CPUs is theorically possible, but who should pay for it? > > Do we agree that a clear, understandable limitation of the bad effects of > > the PI address space would be helpfull, and reduce the conflict between > > PI-funs and "clean-forwarding-table" networkers? > > We're all adults and we all understand the implications of DFZ table > growth. > > > I suggested a mesure: OK. let's allow PI allocations in exceptional cases > > until the number of PI allocations is below of the number of the LIR in > the > > RIPE regions. (Other regions might accept the same, therefore it is easy > to > > extend this policy limitaton at global level, and keeping the "pollution" > > low, globally). > > I'm not in favour of the idea of pulling a figure out of thin air and > saying that we shouldn't allow any more ipv6 PI assignments than this. The > number of LIRs in the RIPE region is no more relevant to a good quality PI > assignment policy than any other randomly chosen number. > I agree that using the "number of LIRs in the region" as a unit might sound strange. BUT there are arguments in favour it: even politician might understand this mesure. Anyhow, the RIPE NCC should be financed and controlled by the LIRs, and not by the PI address space holders. > > OR, do you want PI allocation for every village in certain continents? > > Let's not create a straw man argument. IPv4 didn't cause the sky to fall, > and IPv6 won't cause it to fall either. If IPv6 PI starts showing signs of > causing problems over the next couple of years, then we can change the > policy. > > PI allocation MUST be stopped earlier then it cause more problems. There is no way to foresee the exact behaviour of address requestors: if PI requests became a fashion you might expect several tens of thousands of PI address block allocated within a year... and you wont be able to stop this within the framework of the current proposal. > Nick > > G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Mon Dec 12 09:24:16 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 12 Dec 2011 09:24:16 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE542E5.2010309@inex.ie> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> Message-ID: <4EE5BA30.7070204@go6.si> On 12/12/11 12:55 AM, Nick Hilliard wrote: > So I'm not really feeling very sympathetic to someone who's attempting to > run a full DFZ on a 500k prefix box: either they haven't done their > projections properly (in which case they need to consider a different > career), or else they bought the box years ago, and it's been depreciated > off their books. If you're using equipment that you many years ago, you > shouldn't expect it to last forever, particularly if it has hard resource > limits - e.g. forwarding table size. > > This is simply how hardware forwarding engines work. We're no longer able > to run anything more than tiny networks on 7200s and J series boxes. It > just doesn't work that way any more, and hasn't worked like that for years. I can see a picture of a man in an old carriage, complaining about building the highways (that a carriage simply cannot use). So you are effectively saying, that we are constraining the IPv6 address distribution because of "man in a carriage"? Jan From randy at psg.com Mon Dec 12 10:03:09 2011 From: randy at psg.com (Randy Bush) Date: Mon, 12 Dec 2011 18:03:09 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE5BA30.7070204@go6.si> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> <4EE5BA30.7070204@go6.si> Message-ID: > So you are effectively saying, that we are constraining the IPv6 > address distribution because of "man in a carriage"? horseshit he is saying that we have long experience of what causes routing table bloat and that we are about to repeat a mistake we made once already. randy From erik at bais.name Mon Dec 12 10:11:45 2011 From: erik at bais.name (Erik Bais) Date: Mon, 12 Dec 2011 10:11:45 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5186@EXVS002.netsourcing.lan> Hi Geza, ? I see that we still disagree on many points. I see your comments and I understand your concern, however as stated in the presentation on the policy, this is not a technical discussion as customers currently are registering for LIR membership to avoid the multi-homing requirement for PI v6. Having (end-)customers register for a LIR membership to avoid the multi-homing requirement or having v6 PI without the multi-homing requirement doesn't make a technical difference imho. I?ve had several customers already take the LIR route in order to avoid the multi-homing requirement. They ?bought? themselves into the community by becoming a LIR and suddenly nobody cares anymore if they are multi-homed or not and have their own v6 prefix. Other customers have stopped deployment of v6 altogether. As if there is still time to wait with the implementation of v6. None of us can look into the future, however if we see how the v6 PI uptake is in other regions with a similar policy in place, the worst case scenario isn?t going to be the reality. And both the community and the RIPE NCC will keep a close watch on growth of the number of prefixes. Regards, Erik Bais Co-author of 2011-02 From jan at go6.si Mon Dec 12 10:25:07 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 12 Dec 2011 10:25:07 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> <4EE5BA30.7070204@go6.si> Message-ID: <4EE5C873.1000104@go6.si> On 12/12/11 10:03 AM, Randy Bush wrote: >> So you are effectively saying, that we are constraining the IPv6 >> address distribution because of "man in a carriage"? > > horseshit > > he is saying that we have long experience of what causes routing table > bloat and that we are about to repeat a mistake we made once already. I agree, that not distributing the IPv6 space can prevent routing table bloat, but is this really the right way? can't we deal with that in any other way other than delaying IPv6 adoption? Cheers, Jan From randy at psg.com Mon Dec 12 10:49:44 2011 From: randy at psg.com (Randy Bush) Date: Mon, 12 Dec 2011 18:49:44 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE5C873.1000104@go6.si> References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> <4EE5BA30.7070204@go6.si> <4EE5C873.1000104@go6.si> Message-ID: > I agree, that not distributing the IPv6 space can prevent routing table > bloat, but is this really the right way? > > can't we deal with that in any other way other than delaying IPv6 > adoption? if you think this is delaying ipv6 adoption then you are utterly blind. for my opinion on what delayed ipv6 adoption see randy From jan at go6.si Mon Dec 12 10:59:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 12 Dec 2011 10:59:19 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> <4EE5BA30.7070204@go6.si> <4EE5C873.1000104@go6.si> Message-ID: <4EE5D077.6080708@go6.si> On 12/12/11 10:49 AM, Randy Bush wrote: > if you think this is delaying ipv6 adoption then you are utterly blind. > > for my opinion on what delayed ipv6 adoption see > > this seems very familiar and I agree (as you might suspect) :) But "constraining the distribution of IPv6 resources" is not helping either... As you once said "give me the tool to deal with idiots that deaggregate" - this might be also the case in IPv6 and PI without multihoming will not be the only reason. Cheers, Jan From nick at inex.ie Mon Dec 12 11:13:17 2011 From: nick at inex.ie (Nick Hilliard) Date: Mon, 12 Dec 2011 10:13:17 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> <4EE5BA30.7070204@go6.si> Message-ID: <4EE5D3BD.2060602@inex.ie> On 12/12/2011 09:03, Randy Bush wrote: > he is saying that we have long experience of what causes routing table > bloat and that we are about to repeat a mistake we made once already. that's exactly what I'm saying, except for the context in which I say it: we need to repeat the mistake of PI for ipv6 because there are no good alternatives for small-site v6 multihoming, and while historical context has shown us that routing bloat is a problem, it's a problem which was and remains manageable for at least v4 I still maintain my position on 2011-02 that removing the multihoming requirement is not a good idea because we no longer have the {address counting | multihoming} limiters which act as natural barriers in the case of ipv4 PI assignments. Nick From nick at inex.ie Mon Dec 12 11:16:27 2011 From: nick at inex.ie (Nick Hilliard) Date: Mon, 12 Dec 2011 10:16:27 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> <20111209142856.GQ30174@x27.adm.denic.de> <4EE4BD72.2030700@go6.si> <4EE4CBF1.9070206@inex.ie> <4EE542E5.2010309@inex.ie> Message-ID: <4EE5D47B.7010202@inex.ie> On 12/12/2011 07:38, Turchanyi Geza wrote: > I see that we still disagree on many points. Yes. The sensible thing to do when you cannot agree with someone is to agree to disagree. Nick From poty at iiat.ru Mon Dec 12 12:10:46 2011 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 12 Dec 2011 15:10:46 +0400 Subject: [address-policy-wg] status of 2011-02 Message-ID: >... we are constraining the IPv6 > address distribution because of ...? > > Jan > There are so many people using as the main and the last argument the concern about weak distribution of IPv6, that I'm personally becoming against anything they suggest. Vladislav Potapov Ru.iiat From Remco.vanMook at eu.equinix.com Mon Dec 12 12:44:11 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 12 Dec 2011 11:44:11 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111208211234.GV72014@Space.Net> Message-ID: On 08-12-11 22:12, "Gert Doering" wrote: >In 2011-02, we have the case of "rough consensus with objections": > >We have a number of people who spoke up in favour of the proposal, both >during the discussion/review phases and during Last Call. A few persons >had serious doubts about routing table growth and about PI in general, but >still spoke in favour of the proposal, or abstained. Gert, I fail to see how my comment from June 29th, quoted below, is part of your summary. Quote: While I do sympathise with the rationale behind the proposal, doing it this way strikes me as having an awful lot of (unintended?) side effects. I personally don't have a better suggestion to achieve resolution of the problem that this proposal aims to fix, but at the same time I'm unconvinced that everybody's who's been supporting the proposal has been doing so for the problem this policy aims to fix, and not one of its (again, unintended?) side effects. End quote. If we're going to have a meta-discussion about whether consensus has been reached, I think we should be clear on what the proposal intends to fix first. Agreeing with the rationale behind a proposal doesn't imply I agree with the text of the proposal as-is. Best, Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From gert at space.net Mon Dec 12 13:11:13 2011 From: gert at space.net (Gert Doering) Date: Mon, 12 Dec 2011 13:11:13 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111208211234.GV72014@Space.Net> Message-ID: <20111212121112.GT72014@Space.Net> Hi, On Mon, Dec 12, 2011 at 11:44:11AM +0000, Remco Van Mook wrote: > >In 2011-02, we have the case of "rough consensus with objections": > > > >We have a number of people who spoke up in favour of the proposal, both > >during the discussion/review phases and during Last Call. A few persons > >had serious doubts about routing table growth and about PI in general, but > >still spoke in favour of the proposal, or abstained. > > I fail to see how my comment from June 29th, quoted below, is part of your > summary. > > Quote: > While I do sympathise with the > rationale behind the proposal, doing it this way strikes me as having an > awful lot of (unintended?) side effects. I personally don't have a better > suggestion to achieve resolution of the problem that this proposal aims to > fix, but at the same time I'm unconvinced that everybody's who's been > supporting the proposal has been doing so for the problem this policy aims > to fix, and not one of its (again, unintended?) side effects. > End quote. I took that as an abstention. You voice doubts on the proposal and some doubts about the motivation of other supporters, while stating some support for the rationale - but I can't read a clear "I support the proposal" or "I do not support the proposal" here. > If we're going to have a meta-discussion about whether consensus has been > reached, I think we should be clear on what the proposal intends to fix > first. Now that would have been a nice statement in "Last Call" - where you didn't say anything, so we didn't see any opposition from you when trying to assess consensus. Now we're *past* the "Concluding Phase" from the PDP, and the only relevant question now is "has the PDP process been correctly followed, and (rough) consensus been achieved, or not". It's not unusual for people to voice somewhat-unspecific doubts about a proposal in one of the earlier phases of the PDP, but still go forward with the proposal, especially if they (as you added) have no better suggestions. Sometimes they clearly voice this (as Mikael did), sometimes we have to decide by "there is no sustained opposition in Last Call" that, well, there is no sustained opposition. But anyway - as I said: this has been a difficult one. If you think your concerns haven't been given enough weight, and we haven't achieved "rough consensus" as per the PDP, please say so. 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From Remco.vanMook at eu.equinix.com Mon Dec 12 13:22:17 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 12 Dec 2011 12:22:17 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111212121112.GT72014@Space.Net> Message-ID: On 12-12-11 13:11, "Gert Doering" wrote: >But anyway - as I said: this has been a difficult one. If you think >your concerns haven't been given enough weight, and we haven't achieved >"rough consensus" as per the PDP, please say so. Alright I'll bite. I don't think "rough consensus" has been achieved in this case and I think we can do the community a huge favor if the proposal is taken back to the drawing board. As said before, I'm sure that once we agree on what problem we're going to fix, it will be a lot easier to get a policy text in place that will meet consensus. Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From randy at psg.com Mon Dec 12 14:17:00 2011 From: randy at psg.com (Randy Bush) Date: Mon, 12 Dec 2011 22:17:00 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: Message-ID: > There are so many people using as the main and the last argument the > concern about weak distribution of IPv6 have faith. they will come up with more excuses and someone else to blame. the reality is that v6 deployment used to be very difficult. it is fairly easy now, but there are no clear business incentives to go through the effort. ipv4 runout is supplying the incentive. but expect a lot of whining, complaining, and blame shifting. randy From hendrik.volker at de.verizonbusiness.com Mon Dec 12 15:22:19 2011 From: hendrik.volker at de.verizonbusiness.com (Hendrik T. Voelker) Date: Mon, 12 Dec 2011 14:22:19 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: Message-ID: <4EE60E1B.6010100@de.verizonbusiness.com> On 12/12/11 13:17, Randy Bush wrote: >> There are so many people using as the main and the last argument the >> concern about weak distribution of IPv6 > > have faith. [...] there are no clear business incentives to > go through the effort. Oh there is but They do not want to see that. Only when they very suddenly and in a great hurry have to migrate all their infrastructure to IPv6 They will mumble something like it would have been a good idea to to that earlier. Cheers Hendrik -- Hendrik Voelker Server & Services Management EMEA Server Operations Verizon Deutschland GmbH Sebrathweg 20 D-44149 Dortmund GERMANY http://www.verizonbusiness.com/de/ tel +49-231-972-1565 fax +49-231-972-2587 PubKey 1024D/92479A5D EC1B 76F2 D69D 11C6 2611 5CD1 5269 9351 9247 9A5D Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Gesch?ftsf?hrer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Dominique Gaillard From gert at space.net Mon Dec 12 15:33:10 2011 From: gert at space.net (Gert Doering) Date: Mon, 12 Dec 2011 15:33:10 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <4EE60E1B.6010100@de.verizonbusiness.com> References: <4EE60E1B.6010100@de.verizonbusiness.com> Message-ID: <20111212143310.GY72014@Space.Net> Hi, On Mon, Dec 12, 2011 at 02:22:19PM +0000, Hendrik T. Voelker wrote: > On 12/12/11 13:17, Randy Bush wrote: > >> There are so many people using as the main and the last argument the > >> concern about weak distribution of IPv6 > > > > have faith. [...] there are no clear business incentives to > > go through the effort. > > Oh there is but They do not want to see that. Only when they very suddenly and > in a great hurry have to migrate all their infrastructure to IPv6 They will > mumble something like it would have been a good idea to to that earlier. Folks, may I call you to order, please? Feel free to discuss the merits of migrating to IPv6 or not - but if you want to do so, please change the Subject: line accordingly. This would be a new thread, and is not related to the question that needs discussing in *this* thread: has consensus been reached on 2011-02 or not. Thanks. 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 (89) 32356-444 USt-IdNr.: DE813185279 From lists-ripe at c4inet.net Mon Dec 12 18:39:30 2011 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 12 Dec 2011 17:39:30 +0000 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <20111212143310.GY72014@Space.Net> References: <4EE60E1B.6010100@de.verizonbusiness.com> <20111212143310.GY72014@Space.Net> Message-ID: <20111212173930.GA33966@cilantro.c4inet.net> On Mon, Dec 12, 2011 at 03:33:10PM +0100, Gert Doering wrote: >discussing in *this* thread: has consensus been reached on 2011-02 or not. I think yes, as this discussion seems not to be about "Multihoming, yes or no" but "We should abolish PI". cheers, Sascha Luck From mohta at necom830.hpcl.titech.ac.jp Tue Dec 13 05:06:13 2011 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 13 Dec 2011 13:06:13 +0900 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: Message-ID: <4EE6CF35.3060509@necom830.hpcl.titech.ac.jp> Randy Bush wrote: > have faith. they will come up with more excuses and someone else to > blame. the reality is that v6 deployment used to be very difficult. > it is fairly easy now, Repeating what I recently wrote to IETF ML... IPv6 is not operational, which is partly why most service providers refuse it. For example, to purposelessly enable multicast PMTUD, RFC2463 (ICMPv6) mandates routers generate ICMPv6 packet too big against multicast packets, which causes ICMPv6 packet implosions, which is not operational. For further details, see my presentation at the last APNIC: How Path MTU Discovery Doesn't work http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf W.r.t. your slides at Taipei IETF, 48bit address space with IPv4 address and port numbers is the end to end transparent water for salmon. For the transparency, see, for example, rfc3102: RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. Masataka Ohta From erik at bais.name Fri Dec 16 11:48:30 2011 From: erik at bais.name (Erik Bais) Date: Fri, 16 Dec 2011 11:48:30 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: References: <20111212121112.GT72014@Space.Net> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D51DE@EXVS002.netsourcing.lan> Hi Remco, > Alright I'll bite. I don't think "rough consensus" has been achieved in this case and I think we can do the community a huge favor if the proposal is taken back to the drawing board. As said before, I'm sure that once we agree on what problem > we're going to fix, it will be a lot easier to get a policy text in place that will meet consensus. The problem with the policy text is that the only textual change in the policy is: the removal of the multi-homed requirement for PI v6. The intention of the policy was (/ is) to bring the requirements for PI v4 and v6 more in line, without changing anything else that you still require or are not allowed to do when you request PI for v6. The change in the policy will allow people who don't WANT to become a LIR (or can't for legal reasons) or are not planning for multi-homing yet, the opportunity to start implementing v6 on independent resources if required. Currently the way around the current PI v6 multi-home requirement is: A) sign-up as a LIR and nobody asks you if you are planning to multi-home your v6 PA /32. Or B) don't implement v6 yet. (As if there is time to wait some more on delaying your v6 implementation.) Not everybody want to (or can) become a LIR for their own reasons, while they still have very valid points of requiring PI space on all other aspects and I speak from my own experience with some customers, most of the PI customers should be banned from anything that has a console attached to it as most of them have absolutely no clue how to manage a BGP setup. To sum things up, there is an escape that is already being used for those that can afford it and don't want to deal with the hostmasters questions on multi-homing requirements. (They buy their way into the community and we somehow we don't care anymore) That means that this is not a technical discussion imho, but a financial decision if we allow v6 without multi-homing. Current status as I see it: (Expensive) LIR membership = v6 without multihoming Or cheap PI = jump through hoops and required to implement multi-homing. This policy change will level the requirements to be similar (on the topic of multi-homing) as for v4 PI and for new LIR's. Regards, Erik Bais From sander at steffann.nl Fri Dec 16 12:45:08 2011 From: sander at steffann.nl (Sander Steffann) Date: Fri, 16 Dec 2011 12:45:08 +0100 Subject: [address-policy-wg] status of 2011-02 In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D51DE@EXVS002.netsourcing.lan> References: <20111212121112.GT72014@Space.Net> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D51DE@EXVS002.netsourcing.lan> Message-ID: <30729635-B72B-4690-A588-99FF7CAA8EDF@steffann.nl> Hi guys, >> Alright I'll bite. I don't think "rough consensus" has been achieved in this case and I think we can do the community a huge favor if the proposal is taken back to the drawing board. As said before, I'm sure that once we agree on what problem >> we're going to fix, it will be a lot easier to get a policy text in place that will meet consensus. > > The problem with the policy text is that the only textual change in the policy is: the removal of the multi-homed requirement for PI v6. The intention of the policy was (/ is) to bring the requirements for PI v4 and v6 more in line, without changing anything else that you still require or are not allowed to do when you request PI for v6. We are drifting off topic here. Please don't start discussing the *content* of the proposal. We finished the PDP phases where that was appropriate. At this point in the process we (as chairs) are only concerned if the outcome of those discussions, although not unanimous, can be called consensus. Thanks, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: