From Skeeve at eintellego.net Sat Jan 1 05:02:15 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sat, 1 Jan 2011 15:02:15 +1100 Subject: [ipv6-wg] [announcement] changing jobs In-Reply-To: References: Message-ID: <292AF25E62B8894C921B893B53A19D9739E22A0871@BUSINESSEX.business.ad> Congrats Marco ;-) Hopefully you will make it to the different conferences... maybe see you in Hong Kong at APNIC! ;-) ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Marco Hogewoning > Sent: Friday, 31 December 2010 2:13 AM > To: ipv6-wg > Cc: WG Chairs > Subject: [ipv6-wg] [annoucement] changing jobs > > Hi All, > > As some of you may already know, I will be changing jobs. As of January > 1st, I will join the RIPE NCC training department. This of course > raises the question wether I should stay as co-chair of this working > group. > > After talking with various people, including the NCC management, the > RIPE chair and the other WG co-chairs, we concluded that I can stay on > as a co-chair. However as the NCC has to remain neutral I will pull out > of any discussions regarding address policy or other proposals directly > related to the operations of the RIPE NCC. I will leave decisions > regarding these proposals up to David and Shane, the other two co- > chairs of this working group. > > If you have any questions or objections to this situation, please post > to the IPv6 WG list or to me directly. > > I would like to thank my former employer, XS4ALL Internet, for the time > and money they allowed me to spent on this working group over the past > years. > > Happy new year and hope to see you in 2011, > > Marco Hogewoning > > IPv6 working group co-chair From gvandeve at cisco.com Mon Jan 3 10:17:44 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 3 Jan 2011 10:17:44 +0100 Subject: [ipv6-wg] [annoucement] changing jobs In-Reply-To: References: Message-ID: <4269EA985EACD24987D82DAE2FEC62E502D588A9@XMB-AMS-101.cisco.com> Marco, Good to see dynamics in the IPv6 world. Looking fwd to keep working with you. Gunter Van de Velde Technical Leader - Cisco Systems Chair - Ipv6 Council - Belgian Chapter -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Marco Hogewoning Sent: donderdag 30 december 2010 16:13 To: ipv6-wg Cc: WG Chairs Subject: [ipv6-wg] [annoucement] changing jobs Hi All, As some of you may already know, I will be changing jobs. As of January 1st, I will join the RIPE NCC training department. This of course raises the question wether I should stay as co-chair of this working group. After talking with various people, including the NCC management, the RIPE chair and the other WG co-chairs, we concluded that I can stay on as a co-chair. However as the NCC has to remain neutral I will pull out of any discussions regarding address policy or other proposals directly related to the operations of the RIPE NCC. I will leave decisions regarding these proposals up to David and Shane, the other two co-chairs of this working group. If you have any questions or objections to this situation, please post to the IPv6 WG list or to me directly. I would like to thank my former employer, XS4ALL Internet, for the time and money they allowed me to spent on this working group over the past years. Happy new year and hope to see you in 2011, Marco Hogewoning IPv6 working group co-chair From patrik at frobbit.se Mon Jan 3 11:12:06 2011 From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 3 Jan 2011 11:12:06 +0100 Subject: [ipv6-wg] RIPE-501bis Message-ID: Hi, I hear that there are some discussions about a new version of RIPE 501 in other forums than this mailing list for this wg. More precisely in some LinkedIn Forum. Let me in a few words say that side discussions makes me somewhat nervous. This document do have a large impact on the market and although of course its existence should be announced widely, I do not want to see actual discussions that lead to new versions anywhere else than here on this mailing list. If for example editors do get feedback privately or elsewhere than here on the list, I expect I will see at least summaries of that discussion here. We at Cisco have read RIPE-501 in detail, we have compared the document with other similar requirements documents, and yes, we will come shortly with some suggestions for changes. Both based on our experience with other such documents (it would be good if they are somewhat similar), and feedback we already have got from customers of ours that tries to use RIPE-501. I.e. pure editorial changes on how the document is composed. Patrik F?ltstr?m From jan at go6.si Mon Jan 3 13:08:14 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 03 Jan 2011 13:08:14 +0100 Subject: [ipv6-wg] RIPE-501bis In-Reply-To: References: Message-ID: <4D21BC2E.60706@go6.si> On 3.1.2011 11:12, Patrik F?ltstr?m wrote: > Hi, Patrik, hi. > > I hear that there are some discussions about a new version of RIPE 501 in > other forums than this mailing list for this wg. More precisely in some > LinkedIn Forum. Link to the document have been posted in Linked-in IPv6 forum by some guy and there were some questions about it, precisely mainly about DHCPv6 client requested in hosts section. I don't count this as a discussion for new version of any kind, just clarification. > Let me in a few words say that side discussions makes me somewhat nervous. Agree. > This document do have a large impact on the market and although of course its > existence should be announced widely, I do not want to see actual discussions > that lead to new versions anywhere else than here on this mailing list. If > for example editors do get feedback privately or elsewhere than here on the > list, I expect I will see at least summaries of that discussion here. We expect to start with real work on this document in few days, keeping this list in sync with everything that is going on with the doc. Merike Kaeo is joining in as co-author of the document (thnx Merike) and my first thoughts over X-mass time were to extend the spec to include mobile nodes and CPE requirements. Just a thoughts, among many others. > > We at Cisco have read RIPE-501 in detail, we have compared the document with > other similar requirements documents, and yes, we will come shortly with some > suggestions for changes. Very good, I hear you and Ole did a splendid job checking RIPE-501 doc internally within you company and coleagues. Please, send proposed changes :) > Both based on our experience with other such > documents (it would be good if they are somewhat similar), Yes, we got requests from some entities to be in sync with their work, IPv6 Ready Logo program, NIST, and others. Let's see how that works... > and feedback we > already have got from customers of ours that tries to use RIPE-501. I.e. pure > editorial changes on how the document is composed. Brilliant! :) Jan Zorz P.S: ...wishes exciting and challenging new year :) From Woeber at CC.UniVie.ac.at Mon Jan 3 21:42:51 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 03 Jan 2011 20:42:51 +0000 Subject: [ipv6-wg] Re: [annoucement] changing jobs In-Reply-To: References: Message-ID: <4D2234CB.5020702@CC.UniVie.ac.at> Hi Marco, all the best with your (our :-) ) new challenge! I think it is the right approach to keep you involved directly as one of the co-chairs of the IPv6-WG. We can use any help fromn those who "did it", rather than "talking about IPv6" or doing questionnaires ;-) Looking forward to see you soon, Wilfried. Marco Hogewoning wrote: > Hi All, > > As some of you may already know, I will be changing jobs. As of January 1st, I will join the RIPE NCC training department. This of course raises the question wether I should stay as co-chair of this working group. > > After talking with various people, including the NCC management, the RIPE chair and the other WG co-chairs, we concluded that I can stay on as a co-chair. However as the NCC has to remain neutral I will pull out of any discussions regarding address policy or other proposals directly related to the operations of the RIPE NCC. I will leave decisions regarding these proposals up to David and Shane, the other two co-chairs of this working group. > > If you have any questions or objections to this situation, please post to the IPv6 WG list or to me directly. > > I would like to thank my former employer, XS4ALL Internet, for the time and money they allowed me to spent on this working group over the past years. > > Happy new year and hope to see you in 2011, > > Marco Hogewoning > > IPv6 working group co-chair > > From iljitsch at muada.com Tue Jan 4 12:30:04 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 4 Jan 2011 12:30:04 +0100 Subject: [ipv6-wg] 2010 IPv4 (and IPv6) Address Use Report Message-ID: <2AA374AD-5745-49AB-9306-1BF7F617935A@muada.com> [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use really takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address space given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use. From snash at arbor.net Wed Jan 5 10:39:38 2011 From: snash at arbor.net (Nash, Steve) Date: Wed, 5 Jan 2011 09:39:38 +0000 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Message-ID: Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com How networks grow(tm) ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evyncke at cisco.com Wed Jan 5 12:38:05 2011 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 5 Jan 2011 12:38:05 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: Message-ID: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> Steve, Do not you think that this is going too far? Especially if everyone is adding his/her own requirements... For example, I cannot imagine a residential CPE having any kind of flow export ;-) I would prefer to have RIPE-501 focus on the bare minimum requirements in order to get IPv6 deployed as soon as possible: this means enough requirements to be deployed in a secure, interoperable and manageable way but no more as we (at least I) prefer to have multiple 'compliant' devices. Hope this helps and does not sound to vendor originated (see my affiliation) -?ric From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Nash, Steve Sent: mercredi 5 janvier 2011 10:40 To: ipv6-wg at ripe.net Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com How networks grow(tm) ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Wed Jan 5 13:18:14 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 05 Jan 2011 13:18:14 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> Message-ID: <4D246186.9080706@go6.si> On 5.1.11 12:38, Eric Vyncke (evyncke) wrote: > Steve, > > Do not you think that this is going too far? Especially if everyone is adding > his/her own requirements... > > For example, I cannot imagine a residential CPE having any kind of flow export ;-) > > I would prefer to have RIPE-501 focus on the bare minimum requirements in order > to get IPv6 deployed as soon as possible: this means enough requirements to be > deployed in a secure, interoperable and manageable way but no more as we (at > least I) prefer to have multiple ?compliant? devices. Eric, hi. Yes, as primary author of RIPE-501 I completely agree with this statement. I was searching for words saying exactly same thing, well put :) On the other hand my thinking goes into direction, that what you say needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more". Optional requirements is a candy for those vendors, who did their homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level. > > Hope this helps and does not sound to vendor originated (see my affiliation) Eric, we know who you are ;) ;) Cheers, Jan From tjc at ecs.soton.ac.uk Wed Jan 5 14:50:49 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 5 Jan 2011 13:50:49 +0000 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D246186.9080706@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D246186.9080706@go6.si> <72FB10F8-137F-48DB-9F98-6F0B096C49AC@ecs.soton.ac.uk> Message-ID: On 5 Jan 2011, at 12:18, Jan Zorz @ go6.si wrote: > > Yes, as primary author of RIPE-501 I completely agree with this statement. I was searching for words saying exactly same thing, well put :) > > On the other hand my thinking goes into direction, that what you say needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more". > > Optional requirements is a candy for those vendors, who did their homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level. Well, as the document appears (to me) to be guidance for tender documents for large enterprises, then requesting flow exports for router/layer 3 equipment is reasonable. Were it a set of requirements for SOHO CPE, then it wouldn't be. A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. Tim From gvandeve at cisco.com Wed Jan 5 15:38:38 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Wed, 5 Jan 2011 15:38:38 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D246186.9080706@go6.si> <72FB10F8-137F-48DB-9F98-6F0B096C49AC@ecs.soton.ac.uk> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502D58F6C@XMB-AMS-101.cisco.com> <>start snip<> A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. <>end snip<> And as result drop those other features you desire to have? Resources are limited, even for a technology as IPv6. I can only applaud the work that Jan and team has done with RIPE-501. It is a good initiative and will help people get the best bang for their bucks within Europe. (and yes... it makes live a vendor slightly harder and in some way easier as it helps us prioritize. The recommendations in there are already quite in sync with other certifications for targeted 'very very' big vendor customers of vendors, so it is no surprise). What we (me and Cisco) have been seeing is users confused and ask for everything of RIPE-501, and that is an important reality check. What I would like to see in addition to the current RIPE-501, and I have been discussing this thought process with Jan already 1-2-1 is to make the document slightly larger, and add focus for common user scenario's... like NREN, University, small enterprise, medium enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I am not sure he is convinced, however I hope he is :-) and yes, just as Eric mentioned suggested I am taking my affiliation into account and at the same time try to work with the pragmatism of reality. G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Tim Chown Sent: woensdag 5 januari 2011 14:51 To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment On 5 Jan 2011, at 12:18, Jan Zorz @ go6.si wrote: > > Yes, as primary author of RIPE-501 I completely agree with this statement. I was searching for words saying exactly same thing, well put :) > > On the other hand my thinking goes into direction, that what you say needs to be done in "mandatory" sections of different equipment specs. I see "mandatory" sections as prerequisite for IPv6 to be "deployed in a secure, interoperable and manageable way but no more". > > Optional requirements is a candy for those vendors, who did their homework or at least biggest part of it. If tender iniciator says "mandatory is non-debatable, but you get more points for optional requirements and vendor with more optional requirements wins and gets the business", this might be a good reason why to implement as much IPv6 in equipment as it can be done. I see this as encouragement to develop and push IPv6 deployment on the next qualitative level. Well, as the document appears (to me) to be guidance for tender documents for large enterprises, then requesting flow exports for router/layer 3 equipment is reasonable. Were it a set of requirements for SOHO CPE, then it wouldn't be. A certain platform we have now in a campus setting does IPv6 flow exports, but only over IPv4 transport. By having a good set of recommendations for tenders we can hope that vendors improve that support, and adjust their roadmaps accordingly. Tim From jan at go6.si Wed Jan 5 15:52:26 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 05 Jan 2011 15:52:26 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502D58F6C@XMB-AMS-101.cisco.com> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D246186.9080706@go6.si> <72FB10F8-137F-48DB-9F98-6F0B096C49AC@ecs.soton.ac.uk> <4269EA985EACD24987D82DAE2FEC62E502D58F6C@XMB-AMS-101.cisco.com> Message-ID: <4D2485AA.1050806@go6.si> On 5.1.11 15:38, Gunter Van de Velde (gvandeve) wrote: > I can only applaud the work that Jan and team has done with RIPE-501. It > is a good initiative and will help people > get the best bang for their bucks within Europe. (and yes... it makes > live a vendor slightly harder and in some > way easier as it helps us prioritize. Thnx :) > The recommendations in there are > already quite in sync with other certifications > for targeted 'very very' big vendor customers of vendors, so it is no > surprise). What we (me and Cisco) have been seeing is users > confused and ask for everything of RIPE-501, and that is an important > reality check. True. We need to fix that. > > What I would like to see in addition to the current RIPE-501, and I have > been discussing this thought process with Jan already 1-2-1 > is to make the document slightly larger, and add focus for common user > scenario's... like NREN, University, small enterprise, medium > enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I > am not sure he is convinced, however I hope he is :-) This is getting complex. I am convinced we need to do that, but not sure how to do that in order not to confuse readers even harder. What is crossing my mind in this moment is online web application, where you start with selecting "I would like to choose my role (NREN, Eneterprise, ISP, ...)" or "I would like to specify by equipment type". If you choose "Role", then your progress goes on a different way, but if you choose "Equipment", then series of questions gets asked, like Sander mentioned me in one offlist email: Step 1: Do you need (a) IPv4 support (b) IPv6 support (c) Both Step 2: Do you need network management? (a) Yes (b) No Step 2a: Do you need to do flow exporting? (a) Yes (b) No Step 2b: Do you need to transport the flow exports over IPv6? (a) Yes (b) No etc... At the end you get the list of requirements you should ask for. Would this ease the selection process? If we need selection process that complex, than paper is not the right media, but online app would be nice choice. Any ideas? Cheers, Jan Zorz From shane at time-travellers.org Thu Jan 6 13:47:23 2011 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 06 Jan 2011 13:47:23 +0100 Subject: [ipv6-wg] 2010-06 is going to Last Call Message-ID: <1294318043.2691.1663.camel@shane-asus-laptop> Hello, The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net before then. Thanks, -- Shane From tjc at ecs.soton.ac.uk Thu Jan 6 15:50:24 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 6 Jan 2011 14:50:24 +0000 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2485AA.1050806@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D246186.9080706@go6.si> <72FB10F8-137F-48DB-9F98-6F0B096C49AC@ecs.soton.ac.uk> <4269EA985EACD24987D82DAE2FEC62E502D58F6C@XMB-AMS-101.cisco.com> <4D2485AA.1050806@go6.si> <91A50CED-1F48-4440-8082-D97A6B9A9594@ecs.soton.ac.uk> Message-ID: On 5 Jan 2011, at 14:52, Jan Zorz @ go6.si wrote: > On 5.1.11 15:38, Gunter Van de Velde (gvandeve) wrote: >> I can only applaud the work that Jan and team has done with RIPE-501. It >> is a good initiative and will help people >> get the best bang for their bucks within Europe. (and yes... it makes >> live a vendor slightly harder and in some >> way easier as it helps us prioritize. > > Thnx :) Absolutely, it's a really useful text. One of the IPv6 issues that has come up in the JANET community is how to obtain good independent advice on IPv6 requirements to include in procurements. Those requirements are much broader than for other 'new' technologies, and both include 'like for like' features for IPv4/IPv6 and new IPv6-specific features. > >> The recommendations in there are >> already quite in sync with other certifications >> for targeted 'very very' big vendor customers of vendors, so it is no >> surprise). What we (me and Cisco) have been seeing is users >> confused and ask for everything of RIPE-501, and that is an important >> reality check. > > True. We need to fix that. Fair point - RIPE-501 has some excellent suggestions, pointers and info in it, and not everyone will want everything. Though the primary audience is government and large enterprises. Vendors can still continue to prioritise feature releases based on the NIST and IPv6 Ready initiatives. >> >> What I would like to see in addition to the current RIPE-501, and I have >> been discussing this thought process with Jan already 1-2-1 >> is to make the document slightly larger, and add focus for common user >> scenario's... like NREN, University, small enterprise, medium >> enterprise and big enterprise, and then also for ISP tier-1 -2 -3 ... I >> am not sure he is convinced, however I hope he is :-) > > This is getting complex. I am convinced we need to do that, but not sure how to do that in order not to confuse readers even harder. Well, the flow export feature is just one that is likely to be desirable in large enterprise networks, and is certainly an issue I and others have raised when talking to vendor(s). Of course it's just one feature, and not a make or break one :) > > What is crossing my mind in this moment is online web application, where you start with selecting "I would like to choose my role (NREN, Eneterprise, ISP, ...)" or "I would like to specify by equipment type". > > ... > > Would this ease the selection process? If we need selection process that complex, than paper is not the right media, but online app would be nice choice. I think this would be a significant amount of work. I suspect the better approach is for some volunteers in appropriate communities to take RIPE-501, advertise it to those communities, and provide some suggestions as to which requirements are priorities for that community, e.g. for campus enterprise networks. There will, following the Option 1 model, be some (though not many) mandatory and optional features that have different priorities in that environment, or a small number of features that are missing and can be added. RIPE-501 provides a very nice foundation for such guidance. Whether vendors like what is in that guidance shouldn't really be a concern :) Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From strohbach at denic.de Thu Jan 6 16:03:04 2011 From: strohbach at denic.de (Joachim Strohbach) Date: Thu, 6 Jan 2011 16:03:04 +0100 Subject: [ipv6-wg] AUTO: Nicht erreichbar bis 11.1.2011 / Out of Office until 11.1.2011 Message-ID: Ich bin abwesend und kehre am 12.01.2011 zur?ck. Danke f?r Ihre E-Mail-Nachricht. Ich bin bis 11. Januar 2011 nicht im B?ro. In dringenden Angelegenheiten kontaktieren Sie bitte DENIC IT-Services (E-Mail: its at denic.de, Tel: (069) 27235-160 oder -250). ----- Thank you for your email message. I am not in the office until 11 January 2011. In urgent cases please contact DENIC IT-Services (e-mail: its at denic.de, Tel: +49 69 27235-160 or -250). -- Joachim Strohbach Leiter IT-Services / Head of IT-Services DENIC eG Kaiserstra?e 75-77 60329 Frankfurt am Main GERMANY E-Mail: strohbach at denic.de Fon: +49 69 27235-123 Fon: +49 69 27235-160 (Assistance) Fon: +49 69 27235-250 (IT-Services) Fax: +49 69 27235-239 SIP-URI: sip:123 at denic.de http://www.denic.de PGP-KeyID: 0x7A8A00FF, Fingerprint: 30AB 0F15 17D3 995F CA50 F0A8 EA30 B915 7A8A 00FF Angaben nach ? 25a Absatz 1 GenG: DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am Main) Vorstand: Sabine Dolderer, Helga Kr?ger, Carsten Schiefner, Dr. J?rg Schweiger Vorsitzender des Aufsichtsrats: Elmar Knipp Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "[db-wg] 2010-06 is going to Last Call" gesendet am 6.1.11 14:20:25. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. From snash at arbor.net Fri Jan 7 09:52:14 2011 From: snash at arbor.net (Nash, Steve) Date: Fri, 7 Jan 2011 08:52:14 +0000 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> Message-ID: Eric I agree with you that it would be excessive to make flow records mandatory on Residential CPE. However the Introduction says that the document is BCP for "governments and large enterprises" so I had considered residential CPE out-of-scope. To achieve the objectives you state of "secure,..and manageable..." I would say that instrumentation is essential. It is possible to identify devices more specifically. Mandatory should apply to: 1/ layer3 devices that are to be AS border routers 2/ layer3 CPE WAN-edge devices where the site offers service to off-site clients (and is therefore vulnerable to denial of service attacks) Most large enterprises today use flow instrumentation in IPv4, so overlooking it for v6 might be a mistake. If an organisation is convinced that it will not make use of flow data, then it can choose to ignore this recommendation, like any other in the document. I had not viewed this requirement as restrictive to vendor selection, as all the major vendors support flow (especially Cisco). But the requirement will help buyers to size equipment appropriately and avoid purchasing something in the short-term that is inadequate for the life of the device. Regards Steve From: Eric Vyncke (evyncke) [mailto:evyncke at cisco.com] Sent: 05 January 2011 11:38 To: Nash, Steve; ipv6-wg at ripe.net Subject: RE: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Steve, Do not you think that this is going too far? Especially if everyone is adding his/her own requirements... For example, I cannot imagine a residential CPE having any kind of flow export ;-) I would prefer to have RIPE-501 focus on the bare minimum requirements in order to get IPv6 deployed as soon as possible: this means enough requirements to be deployed in a secure, interoperable and manageable way but no more as we (at least I) prefer to have multiple 'compliant' devices. Hope this helps and does not sound to vendor originated (see my affiliation) -?ric From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Nash, Steve Sent: mercredi 5 janvier 2011 10:40 To: ipv6-wg at ripe.net Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com How networks grow(tm) ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpn-ip-office at kpn.com Fri Jan 7 11:54:57 2011 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Fri, 7 Jan 2011 11:54:57 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] 2010-06 is going to Last Call In-Reply-To: <1294320025.2691.1723.camel@shane-asus-laptop> References: <1294320025.2691.1723.camel@shane-asus-laptop> Message-ID: I support the proposal. With kind regards, ir. A.W. (Andries) Hettema KPN OZM KS&O B&I Internet +31 70 34 38290 andries.hettema at kpn.com -----Oorspronkelijk bericht----- Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Shane Kerr Verzonden: donderdag 6 januari 2011 14:20 Aan: db-wg at ripe.net; 'address-policy-wg at ripe.net' Onderwerp: [address-policy-wg] 2010-06 is going to Last Call Hello, [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net before then. Thanks, -- Shane From jan at go6.si Fri Jan 7 13:51:35 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 07 Jan 2011 13:51:35 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> Message-ID: <4D270C57.3000904@go6.si> On 7.1.11 9:52, Nash, Steve wrote: > Eric > > I agree with you that it would be excessive to make flow records mandatory on > Residential CPE. > > However the Introduction says that the document is BCP for ?governments and > large enterprises? so I had considered residential CPE out-of-scope. > > To achieve the objectives you state of ?secure,..and manageable...? I would say > that instrumentation is essential. > > It is possible to identify devices more specifically. Hi, I'm thinking about using If statement here under Mandatory sections (where needed): "If maintenance and export of flow records is needed, then Netflow 9 [RFC3917], must be supported with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device." Does this makes sense? Cheers, Jan Zorz From kzorba at otenet.gr Sat Jan 8 12:11:03 2011 From: kzorba at otenet.gr (kzorba at otenet.gr) Date: Sat, 08 Jan 2011 13:11:03 +0200 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D270C57.3000904@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> Message-ID: <20110108131103.17454p9thit02k3r@noc.otenet.gr> Greetings to all and happy new year. We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome. Regards, Kostas Zorbadelos From ahmed at tamkien.com Sun Jan 9 05:40:39 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Sun, 9 Jan 2011 06:40:39 +0200 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <20110108131103.17454p9thit02k3r@noc.otenet.gr> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> Message-ID: <9C4211C4139640679FB35240CB6ED2F2@mTOSH> Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. Access is where IPv4 is being depleted rapidly, thus mentioning how IPv6 can coexist with limited IPv4 addresses, with the objective of conserving consumer CPE cost by keeping IPv6 features on CPEs to the minimum, is needed. Two approaches should be covered in access: Tunneling for dual-stack access (such as TSP and 6RD for v6-in-v4, plus DS-Lite and DSTM for v4-in-v6), as well as Translation for single stack IPv6-only hosts using protocols such as NAT64/DNS64. Each protocol's suitability for rapid transition, as well as its edge network requirements, should be mentioned. Note that I am affiliated with an access vendor, gogo6 / Hexago, which runs the global Freenet6 network using tunneling CPEs and soft clients. Regards, -Ahmed From: kzorba at otenet.gr Sent: Saturday, January 08, 2011 1:11 PM To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Greetings to all and happy new year. We also used this document to extract basic features (in our environment) for customer CPEs. In my opinion, the "document" format must be preserved as a single place to contain the entire information. I guess 'if' statements like Jan mentions is one way to achieve the desired outcome. Regards, Kostas Zorbadelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcoh at marcoh.net Sun Jan 9 12:22:14 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 9 Jan 2011 12:22:14 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <9C4211C4139640679FB35240CB6ED2F2@mTOSH> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> Message-ID: <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From ahmed at tamkien.com Sun Jan 9 13:01:02 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Sun, 9 Jan 2011 14:01:02 +0200 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> Message-ID: My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts. Regards, -Ahmed From: Marco Hogewoning Sent: Sunday, January 09, 2011 1:22 PM To: Ahmed Abu-Abed Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Sun Jan 9 13:29:39 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 09 Jan 2011 13:29:39 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> Message-ID: <1294576179.1476.2.camel@Nokia-N900> ----- Original message ----- > My suggestion was to develop a best practice for consumer CPE > specifications based on existing IETF standards/drafts. > > Regards, > -Ahmed > Hi, Thank you for suggestion. Mandatory part should not be a big challenge, but optional section might be tricky... We'll try to compile first beta draft text for the CPE and see if community likes it and what we need to change/add. best, Jan Zorz > > > From: Marco Hogewoning > Sent: Sunday, January 09, 2011 1:22 PM > To: Ahmed Abu-Abed > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > Good point, and having a Consumer CPE spec as a RIPE standard would > > help for last mile access requirements. RIPE-501 only aimed for > > government and enterprise deployments. > > My personal preference would be to keep pointing to the work done in the > IETF. The problem with standards is, there usually are too many. Adding > another one will only lead to more confusion, let alone the time it will > take to get consensus. > > Grtx, > > MarcoH > > -- > "Good tests kill flawed theories; we remain alive to guess again" From ip at ioshints.info Sun Jan 9 13:54:12 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sun, 9 Jan 2011 13:54:12 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <1294576179.1476.2.camel@Nokia-N900> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <1294576179.1476.2.camel@Nokia-N900> Message-ID: <00bc01cbaffc$51c649c0$f552dd40$@info> It's probably best to start from the existing "Basic Requirements for IPv6 Customer Edge Routers" draft. You might also want to check whether a CPE-focused RIPE document wouldn't reinvent the wheel. http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz @ go6.si > Sent: Sunday, January 09, 2011 1:30 PM > To: Ahmed Abu-Abed; RIPE IPv6 > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > ----- Original message ----- > > My suggestion was to develop a best practice for consumer CPE > > specifications based on existing IETF standards/drafts. > > > > Regards, > > -Ahmed > > > > Hi, > > Thank you for suggestion. Mandatory part should not be a big challenge, > but optional section might be tricky... > > We'll try to compile first beta draft text for the CPE and see if > community likes it and what we need to change/add. > > best, Jan Zorz > > > > > > > From: Marco Hogewoning > > Sent: Sunday, January 09, 2011 1:22 PM > > To: Ahmed Abu-Abed > > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > > > > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > > > Good point, and having a Consumer CPE spec as a RIPE standard would > > > help for last mile access requirements. RIPE-501 only aimed for > > > government and enterprise deployments. > > > > My personal preference would be to keep pointing to the work done in the > > IETF. The problem with standards is, there usually are too many. Adding > > another one will only lead to more confusion, let alone the time it will > > take to get consensus. > > > > Grtx, > > > > MarcoH > > > > -- > > "Good tests kill flawed theories; we remain alive to guess again" From marcoh at marcoh.net Sun Jan 9 16:00:28 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 9 Jan 2011 16:00:28 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> Message-ID: <517699FB-E24A-414D-9696-132034FD952C@marcoh.net> Hi Ahmed, The IETF document I was refering to (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router) is basically that. If there is strong support from the community to do something similar and turn it into a RIPE document we could look into this, but I personally would stick with the IETF one instead of doing it all over again and possibly ending up with minor differences. From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one. Marco On 9 jan 2011, at 13:01, Ahmed Abu-Abed wrote: > My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts. > > Regards, > -Ahmed > > > From: Marco Hogewoning > Sent: Sunday, January 09, 2011 1:22 PM > To: Ahmed Abu-Abed > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. > > My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. > > Grtx, > > MarcoH > > -- > "Good tests kill flawed theories; we remain alive to guess again" From sander at steffann.nl Sun Jan 9 16:33:43 2011 From: sander at steffann.nl (Sander Steffann) Date: Sun, 9 Jan 2011 16:33:43 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <517699FB-E24A-414D-9696-132034FD952C@marcoh.net> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <517699FB-E24A-414D-9696-132034FD952C@marcoh.net> Message-ID: <20CE43D7-AC6A-4C8F-814D-0F7F42255D65@steffann.nl> > From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one. I fully agree. For RIPE-501 creating a document created one point for vendors and enterprises to focus on. Doing this again for CPEs when the IETF is already working on draft-ietf-v6ops-ipv6-cpe-router would be counter-productive. - Sander From jan at go6.si Sun Jan 9 15:33:24 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 09 Jan 2011 15:33:24 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <00bc01cbaffc$51c649c0$f552dd40$@info> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <1294576179.1476.2.camel@Nokia-N900> <00bc01cbaffc$51c649c0$f552dd40$@info> Message-ID: <1294583604.1713.2.camel@Nokia-N900> ----- Original message ----- > It's probably best to start from the existing "Basic Requirements for > IPv6 Customer Edge Routers" draft. You might also want to check whether > a CPE-focused RIPE document wouldn't reinvent the wheel. > > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 > > Ivan Ivan, hi. Ole already proposed this and I'm also looking into BBF TR124r2 as possible reference. /Jan > > > -----Original Message----- > > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > > Of Jan Zorz @ go6.si > > Sent: Sunday, January 09, 2011 1:30 PM > > To: Ahmed Abu-Abed; RIPE IPv6 > > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > > > > ----- Original message ----- > > > My suggestion was to develop a best practice for consumer CPE > > > specifications based on existing IETF standards/drafts. > > > > > > Regards, > > > -Ahmed > > > > > > > Hi, > > > > Thank you for suggestion. Mandatory part should not be a big challenge, > > but optional section might be tricky... > > > > We'll try to compile first beta draft text for the CPE and see if > > community likes it and what we need to change/add. > > > > best, Jan Zorz > > > > > > > > > > > From: Marco Hogewoning > > > Sent: Sunday, January 09, 2011 1:22 PM > > > To: Ahmed Abu-Abed > > > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > > > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" > > > comment > > > > > > > > > > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > > > > > Good point, and having a Consumer CPE spec as a RIPE standard would > > > > help for last mile access requirements. RIPE-501 only aimed for > > > > government and enterprise deployments. > > > > > > My personal preference would be to keep pointing to the work done in > > > the IETF. The problem with standards is, there usually are too many. > > > Adding another one will only lead to more confusion, let alone the > > > time it will take to get consensus. > > > > > > Grtx, > > > > > > MarcoH > > > > > > -- > > > "Good tests kill flawed theories; we remain alive to guess again" > From jan at go6.si Sun Jan 9 21:56:19 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 09 Jan 2011 21:56:19 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <20110108131103.17454p9thit02k3r@noc.otenet.gr> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> Message-ID: <4D2A20F3.40508@go6.si> On 8.1.2011 12:11, kzorba at otenet.gr wrote: > Greetings to all and happy new year. > > We also used this document to extract basic features (in our environment) > for customer CPEs. > In my opinion, the "document" format must be preserved as a single place to > contain the entire information. I guess 'if' statements like Jan mentions is > one way to achieve the desired outcome. Kostas, hi. If you did some stuff in that direction, can you send what you extracted from other sections and in your opinion fits the CPE requirements. All ideas and preliminary draft texts helps to go forward with the 501 doc. Regards, Jan P.S: Did we met in Athens at v6 TF meeting last summer? From kzorba at otenet.gr Sun Jan 9 22:32:02 2011 From: kzorba at otenet.gr (kzorba at otenet.gr) Date: Sun, 09 Jan 2011 23:32:02 +0200 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2A20F3.40508@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> Message-ID: <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> Quoting "Jan Zorz @ go6.si" : > On 8.1.2011 12:11, kzorba at otenet.gr wrote: >> Greetings to all and happy new year. >> >> We also used this document to extract basic features (in our environment) >> for customer CPEs. >> In my opinion, the "document" format must be preserved as a single >> place to contain the entire information. I guess 'if' statements >> like Jan mentions is one way to achieve the desired outcome. > > Kostas, hi. > Hi Jan, > If you did some stuff in that direction, can you send what you > extracted from other sections and in your opinion fits the CPE > requirements. > Since I am out of the office these days, I will get back to you with this in the following days. Another colleague gathered the requirements and we also consulted IETF documents from what I know. > All ideas and preliminary draft texts helps to go forward with the 501 doc. > From what I understood in the discussions of the thread, the idea will be to provide pointers in the 501 doc to IETF documents, right? Some people expressed concerns that the RIPE document should not duplicate IETF work or come up with any sort of differences. Of course the 501 doc is not any form of standard, just some work that will help in moving IPv6 deployment a bit closer... > Regards, Jan > P.S: Did we met in Athens at v6 TF meeting last summer? > Yes ;-) Regards, Kostas From jprins at betterbe.com Sun Jan 9 22:47:09 2011 From: jprins at betterbe.com (Jan Hugo Prins) Date: Sun, 09 Jan 2011 22:47:09 +0100 Subject: [ipv6-wg] [annoucement] changing jobs In-Reply-To: References: Message-ID: <4D2A2CDD.4000408@betterbe.com> Hi Marco, > > As some of you may already know, I will be changing jobs. As of January 1st, I will join the RIPE NCC training department. All the best with your new job. It's a pitty to see so many good people leave XS4ALL, but all the best for you. -- Met vriendelijke groet, Jan Hugo Prins Infra consultant E: jprins at betterbe.com W: www.betterbe.com From jan at go6.si Sun Jan 9 23:10:25 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 09 Jan 2011 23:10:25 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> Message-ID: <4D2A3251.3020101@go6.si> On 9.1.2011 22:32, kzorba at otenet.gr wrote: >> If you did some stuff in that direction, can you send what you extracted from >> other sections and in your opinion fits the CPE requirements. >> > > Since I am out of the office these days, I will get back to you with this in the > following days. > Another colleague gathered the requirements and we also consulted IETF documents > from what I know. Kostas, hi. Thnx, appreciated. > >> All ideas and preliminary draft texts helps to go forward with the 501 doc. >> > > From what I understood in the discussions of the thread, the idea will be to > provide pointers in the 501 doc to IETF documents, right? Some people expressed > concerns that the RIPE document should not duplicate IETF work or come up with > any sort of differences. > Of course the 501 doc is not any form of standard, just some work that will help > in moving IPv6 deployment a bit closer... I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people. Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy. Any thoughts? Cheers, Jan From ip at ioshints.info Mon Jan 10 08:46:47 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 10 Jan 2011 08:46:47 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2A3251.3020101@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> Message-ID: <002b01cbb09a$89af4b90$9d0de2b0$@info> Wouldn't it be easier to ask Ole to provide a list of mandatory and optional RFCs in his document than to extract them into another document (with all the resulting synchronization challenges)? > I'm still thinking and need a discussion first with authors and see what > community thinks - but pointing to RFC or draft is ok for us, we know how > to > read RFC and so on - problem is when somebody writes a tender for buying > ICT > equipment - in this case going to read RFC or draft or something might be > quite > complicated for some people. > > Not sure yet, do we just point to Ole's draft (that is excellent imho) or > do we > write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF > paper > (Ole is also editing that) and keep the list in sync if draft/RFC changes. > This > way tender initiator can just copy/paste RFCs and this way the job is > easy. > > Any thoughts? > > Cheers, Jan From Ragnar.Anfinsen at altibox.no Mon Jan 10 09:35:14 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Mon, 10 Jan 2011 09:35:14 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2A3251.3020101@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> Message-ID: Hi Jan, > Not sure yet, do we just point to Ole's draft (that is excellent imho) > or do we > write a list of mandatory RFCs that are 1:1 in sync with the draft and > BBF paper > (Ole is also editing that) and keep the list in sync if draft/RFC > changes. This > way tender initiator can just copy/paste RFCs and this way the job is > easy. > > Any thoughts? I think the best way is to point to the IETF document. There are no reason to duplicate the work, especially while it is in draft. I suggest that we work with the second update of the RIPE-501 document with the "Basic Requirements for IPv6 Customer Edge Routers" draft ans mandatory, and keep the updated RIPE document in draft until the IETF document gets a RFC number. When this is done there are no need to do any changes to the RIPE document if the IETF document changes. So my suggestion is to only refer to the IETF document, not to duplicate it. Best Regards? Ragnar Anfinsen Network Engineer? Altibox AS? From gvandeve at cisco.com Mon Jan 10 10:53:11 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 10 Jan 2011 10:53:11 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <00bc01cbaffc$51c649c0$f552dd40$@info> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <1294576179.1476.2.camel@Nokia-N900> <00bc01cbaffc$51c649c0$f552dd40$@info> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF1FD1@XMB-AMS-101.cisco.com> Keep in mind that the document Ivan kindly proposed is still work in process... and that the last has not been mentioned about it. It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear. G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Ivan Pepelnjak Sent: zondag 9 januari 2011 13:54 To: 'Jan Zorz @ go6.si'; 'Ahmed Abu-Abed'; 'RIPE IPv6' Subject: RE: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment It's probably best to start from the existing "Basic Requirements for IPv6 Customer Edge Routers" draft. You might also want to check whether a CPE-focused RIPE document wouldn't reinvent the wheel. http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jan Zorz @ go6.si > Sent: Sunday, January 09, 2011 1:30 PM > To: Ahmed Abu-Abed; RIPE IPv6 > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > ----- Original message ----- > > My suggestion was to develop a best practice for consumer CPE > > specifications based on existing IETF standards/drafts. > > > > Regards, > > -Ahmed > > > > Hi, > > Thank you for suggestion. Mandatory part should not be a big challenge, > but optional section might be tricky... > > We'll try to compile first beta draft text for the CPE and see if > community likes it and what we need to change/add. > > best, Jan Zorz > > > > > > > From: Marco Hogewoning > > Sent: Sunday, January 09, 2011 1:22 PM > > To: Ahmed Abu-Abed > > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > > > > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > > > Good point, and having a Consumer CPE spec as a RIPE standard would > > > help for last mile access requirements. RIPE-501 only aimed for > > > government and enterprise deployments. > > > > My personal preference would be to keep pointing to the work done in the > > IETF. The problem with standards is, there usually are too many. Adding > > another one will only lead to more confusion, let alone the time it will > > take to get consensus. > > > > Grtx, > > > > MarcoH > > > > -- > > "Good tests kill flawed theories; we remain alive to guess again" From gvandeve at cisco.com Mon Jan 10 10:58:48 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 10 Jan 2011 10:58:48 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <517699FB-E24A-414D-9696-132034FD952C@marcoh.net> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <517699FB-E24A-414D-9696-132034FD952C@marcoh.net> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF1FE1@XMB-AMS-101.cisco.com> I agree on this with Marco... A vendor would like to have centralization of certification requirements for operational cost and time investment effectiveness. Just imagine the potential effect... one certification for RIPE, one for ARIN, one for APNIC, etc... and then for the BBand forum, and for the v6 logo... Then another for governments etc... What is in current RIPE-501 is nice as it piggy-backs upon certification existing already which has attention of vendors already G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Marco Hogewoning Sent: zondag 9 januari 2011 16:00 To: Ahmed Abu-Abed Cc: RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Hi Ahmed, The IETF document I was refering to (http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router) is basically that. If there is strong support from the community to do something similar and turn it into a RIPE document we could look into this, but I personally would stick with the IETF one instead of doing it all over again and possibly ending up with minor differences. >From personal experience I can tell it's already hard to get vendors to follow the IETF, most CPE builders are more familiar with the broadband forum. Having yet another 'standard' from yet another body won't help in this. Especially when from a vendor's perspective, you have customer A pointing to one document en customer B asking to be compliant to another one. Marco On 9 jan 2011, at 13:01, Ahmed Abu-Abed wrote: > My suggestion was to develop a best practice for consumer CPE specifications based on existing IETF standards/drafts. > > Regards, > -Ahmed > > > From: Marco Hogewoning > Sent: Sunday, January 09, 2011 1:22 PM > To: Ahmed Abu-Abed > Cc: kzorba at otenet.gr ; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > On 9 jan 2011, at 05:40, Ahmed Abu-Abed wrote: > > > Good point, and having a Consumer CPE spec as a RIPE standard would help for last mile access requirements. RIPE-501 only aimed for government and enterprise deployments. > > My personal preference would be to keep pointing to the work done in the IETF. The problem with standards is, there usually are too many. Adding another one will only lead to more confusion, let alone the time it will take to get consensus. > > Grtx, > > MarcoH > > -- > "Good tests kill flawed theories; we remain alive to guess again" From ot at cisco.com Mon Jan 10 11:02:20 2011 From: ot at cisco.com (Ole Troan) Date: Mon, 10 Jan 2011 11:02:20 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502DF1FD1@XMB-AMS-101.cisco.com> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <1294576179.1476.2.camel@Nokia-N900> <00bc01cbaffc$51c649c0$f552dd40$@info> <4269EA985EACD24987D82DAE2FEC62E502DF1FD1@XMB-AMS-101.cisco.com> Message-ID: <6F06072D-D957-4878-B762-0114AE8696A1@cisco.com> Gunter, > Keep in mind that the document Ivan kindly proposed is still work in process... and that > the last has not been mentioned about it. > > It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear. let me correct that. the document is done. and will be published as an RFC shortly. to provide the background. -07 was sitting in the RFC editor queue awaiting normative referenced documents to progress. because of some issues with broken host implementations and multiple prefixes, we chose to reiterate the document one more time, to lessen the change of dual stack breakage. -09 is now making its way back onto the queue. (since the referenced documents are still to be published this did not in any way delay the CPE router draft). cheers, Ole From gvandeve at cisco.com Mon Jan 10 11:04:30 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 10 Jan 2011 11:04:30 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <6F06072D-D957-4878-B762-0114AE8696A1@cisco.com> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <9C4211C4139640679FB35240CB6ED2F2@mTOSH> <7CD36FD8-016B-4C34-A6AA-8733660A201B@marcoh.net> <1294576179.1476.2.camel@Nokia-N900> <00bc01cbaffc$51c649c0$f552dd40$@info> <4269EA985EACD24987D82DAE2FEC62E502DF1FD1@XMB-AMS-101.cisco.com> <6F06072D-D957-4878-B762-0114AE8696A1@cisco.com> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502DF1FF0@XMB-AMS-101.cisco.com> Happy to be corrected... and happy to see this CPE journey come to a final conclusion :-) G/ -----Original Message----- From: Ole Troan [mailto:ot at cisco.com] Sent: maandag 10 januari 2011 11:02 To: Gunter Van de Velde (gvandeve) Cc: Ivan Pepelnjak; Jan Zorz @ go6.si; Ahmed Abu-Abed; RIPE IPv6 Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment Gunter, > Keep in mind that the document Ivan kindly proposed is still work in process... and that > the last has not been mentioned about it. > > It is a good initial reference for this point in time, but to 'formaly' reference to it would result in a moving target I fear. let me correct that. the document is done. and will be published as an RFC shortly. to provide the background. -07 was sitting in the RFC editor queue awaiting normative referenced documents to progress. because of some issues with broken host implementations and multiple prefixes, we chose to reiterate the document one more time, to lessen the change of dual stack breakage. -09 is now making its way back onto the queue. (since the referenced documents are still to be published this did not in any way delay the CPE router draft). cheers, Ole From tjc at ecs.soton.ac.uk Mon Jan 10 12:54:05 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 10 Jan 2011 11:54:05 +0000 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2A3251.3020101@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> <0D359F34-7875-477C-9F8F-2FD3CDDB735D@ecs.soton.ac.uk> Message-ID: On 9 Jan 2011, at 22:10, Jan Zorz @ go6.si wrote: > > I'm still thinking and need a discussion first with authors and see what community thinks - but pointing to RFC or draft is ok for us, we know how to read RFC and so on - problem is when somebody writes a tender for buying ICT equipment - in this case going to read RFC or draft or something might be quite complicated for some people. > > Not sure yet, do we just point to Ole's draft (that is excellent imho) or do we write a list of mandatory RFCs that are 1:1 in sync with the draft and BBF paper (Ole is also editing that) and keep the list in sync if draft/RFC changes. This way tender initiator can just copy/paste RFCs and this way the job is easy. > > Any thoughts? I would assume the RFCs are what the vendors/implementors look to first, while the RIPE-501 text is, at least from what it says, aimed at enterprise sites writing procurement texts. So there's room in RIPE-501 to present the requirements in more general terms that are easier to (almost) cut and paste into tender documents. I think there's a lot of value in being able to point enterprises (e.g. universities) to RIPE-501 for procurement guidance. While some may be able to extract equivalent information from RFCs, RIPE-501 would in my view remain a valuable and useful abstraction of that information. Tim From ip at ioshints.info Mon Jan 10 13:01:06 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Mon, 10 Jan 2011 13:01:06 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> <0D359F34-7875-477C-9F8F-2FD3CDDB735D@ecs.soton.ac.uk> Message-ID: <000001cbb0be$1102c4a0$33084de0$@info> I absolutely agree with your who-needs-what perspective. However, in an ideal world, Ole's draft would contain the "Mandatory/Recommended/Optional RFCs" section that would be ready for a cut-and-paste into a procurement document, in which case RIPE-501bis would only need to refer to that section of Ole's (future) RFC (or even have a copy of it, with pointer to the source). Ivan > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Tim Chown > Sent: Monday, January 10, 2011 12:54 PM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment > > > On 9 Jan 2011, at 22:10, Jan Zorz @ go6.si wrote: > > > > > I'm still thinking and need a discussion first with authors and see what > community thinks - but pointing to RFC or draft is ok for us, we know how > to read RFC and so on - problem is when somebody writes a tender for > buying ICT equipment - in this case going to read RFC or draft or > something might be quite complicated for some people. > > > > Not sure yet, do we just point to Ole's draft (that is excellent imho) > or do we write a list of mandatory RFCs that are 1:1 in sync with the > draft and BBF paper (Ole is also editing that) and keep the list in sync > if draft/RFC changes. This way tender initiator can just copy/paste RFCs > and this way the job is easy. > > > > Any thoughts? > > I would assume the RFCs are what the vendors/implementors look to first, > while the RIPE-501 text is, at least from what it says, aimed at > enterprise sites writing procurement texts. So there's room in RIPE-501 > to present the requirements in more general terms that are easier to > (almost) cut and paste into tender documents. I think there's a lot of > value in being able to point enterprises (e.g. universities) to RIPE-501 > for procurement guidance. While some may be able to extract equivalent > information from RFCs, RIPE-501 would in my view remain a valuable and > useful abstraction of that information. > > Tim From jan at go6.si Tue Jan 11 16:03:13 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 11 Jan 2011 16:03:13 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <002b01cbb09a$89af4b90$9d0de2b0$@info> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> <002b01cbb09a$89af4b90$9d0de2b0$@info> Message-ID: <4D2C7131.2010501@go6.si> On 10.1.2011 8:46, Ivan Pepelnjak wrote: > Wouldn't it be easier to ask Ole to provide a list of mandatory and optional > RFCs in his document than to extract them into another document (with all the > resulting synchronization challenges)? Ivan hi, changing the document that is in IESG queue and "done" by IETF measures is not something anyone would want to do... :S /jan From dez at otenet.gr Mon Jan 17 16:09:08 2011 From: dez at otenet.gr (Dez) Date: Mon, 17 Jan 2011 17:09:08 +0200 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D2A3251.3020101@go6.si> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> Message-ID: <4D345B94.1070307@otenet.gr> Hello, On 01/10/2011 12:10 AM, Jan Zorz @ go6.si wrote: > On 9.1.2011 22:32, kzorba at otenet.gr wrote: >>> If you did some stuff in that direction, can you send what you >>> extracted from >>> other sections and in your opinion fits the CPE requirements. >>> >> >> Since I am out of the office these days, I will get back to you with >> this in the >> following days. >> Another colleague gathered the requirements and we also consulted >> IETF documents >> from what I know. > actually, the requirements were mostly gathered from http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-07 (haven't checked the diff with the new version yet). I agree with Marco and others about using the IETF doc as reference but I'm not sure if there's much of a point in making a RIPE document that basically points to the IETF draft. > I'm still thinking and need a discussion first with authors and see > what community thinks - but pointing to RFC or draft is ok for us, we > know how to read RFC and so on - problem is when somebody writes a > tender for buying ICT equipment - in this case going to read RFC or > draft or something might be quite complicated for some people. > > Not sure yet, do we just point to Ole's draft (that is excellent imho) > or do we write a list of mandatory RFCs that are 1:1 in sync with the > draft and BBF paper (Ole is also editing that) and keep the list in > sync if draft/RFC changes. This way tender initiator can just > copy/paste RFCs and this way the job is easy. > that last proposal makes sense to me > Any thoughts? > > Cheers, Jan > > cheers, Yannis From jan at go6.si Tue Jan 18 11:28:11 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 18 Jan 2011 11:28:11 +0100 Subject: [ipv6-wg] "Requirements For IPv6 in ICT Equipment" comment In-Reply-To: <4D345B94.1070307@otenet.gr> References: <317616CE96204D49B5A1811098BA8950038B5CB3@XMB-AMS-110.cisco.com> <4D270C57.3000904@go6.si> <20110108131103.17454p9thit02k3r@noc.otenet.gr> <4D2A20F3.40508@go6.si> <20110109233202.14355a9ryawcdxzm@noc.otenet.gr> <4D2A3251.3020101@go6.si> <4D345B94.1070307@otenet.gr> Message-ID: <4D356B3B.4050104@go6.si> Yannis, hi. On 1/17/11 4:09 PM, Dez wrote: > actually, the requirements were mostly gathered from > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-07 > (haven't checked the diff with the new version yet). I agree with > Marco and others about using the IETF doc as reference but I'm not > sure if there's much of a point in making a RIPE document that > basically points to the IETF draft. Facing the crossroad here... We would like to make the doc as simple as possible and pointing to RFC is easiest way to do this. On the other hand, not only simple, RIPE-501bis needs to be usefull and can be used even by people that don't read RFCs. > >> Not sure yet, do we just point to Ole's draft (that is excellent >> imho) or do we write a list of mandatory RFCs that are 1:1 in sync >> with the draft and BBF paper (Ole is also editing that) and keep the >> list in sync if draft/RFC changes. This way tender initiator can just >> copy/paste RFCs and this way the job is easy. >> > > that last proposal makes sense to me The key question here is how stable that draft is and what would be syncing efforts like. When looking from shape point of view, we have currently 4 sections of equipment, all of them says: Mandatory: ... [list] Optional: ... [list] And 5th section would say Mandatory -> external RFC. Hmm. Cheers, Jan From shane at time-travellers.org Tue Jan 18 14:59:33 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 18 Jan 2011 14:59:33 +0100 Subject: [ipv6-wg] RIPE 61 - IPv6 WG minutes now final In-Reply-To: <1292848522.2453.61.camel@shane-asus-laptop> References: <1292848522.2453.61.camel@shane-asus-laptop> Message-ID: <1295359173.16179.1998.camel@shane-asus-laptop> All, On Mon, 2010-12-20 at 13:35 +0100, Shane Kerr wrote: > These are the draft minutes from the IPv6 working group session at the > RIPE 61 meeting in Rome. > > Please send any comments/corrections within the next 4 weeks. It has been 4 weeks and I have not seen any comments or corrections, so these should now be considered final. -- Shane From mir at ripe.net Wed Jan 19 13:15:03 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 19 Jan 2011 13:15:03 +0100 Subject: [ipv6-wg] Re: The RIPE NCC's involvement in the World IPv6 Day In-Reply-To: <4D36CA5C.5000901@ripe.net> References: <4D36CA5C.5000901@ripe.net> Message-ID: <4D36D5C7.2070008@ripe.net> Dear colleagues, Apparently RIPE Labs didn't like the last article we published and is temporarily not available. We are investigating this and hope this will be fixed soon. I am very sorry for this inconvenience. Kind Regards, Mirjam Kuehne Mirjam Kuehne wrote: > [apologies for duplicates] > > Dear colleagues, > > We received some questions about the RIPE NCC's involvement in the World > IPv6 Day that is planned for 8 June 2011. > > Please see some ideas and suggestions on RIPE Labs: > > http://labs.ripe.net/Members/mirjam/ripe-ncc-and-world-ipv6-day > > We are looking for feedback and suggestions, especially from subscribers > of this working mailing list. > > Kind Regards, > Mirjam Kuehne > RIPE NCC > From mir at ripe.net Wed Jan 19 12:26:20 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 19 Jan 2011 12:26:20 +0100 Subject: [ipv6-wg] The RIPE NCC's involvement in the World IPv6 Day Message-ID: <4D36CA5C.5000901@ripe.net> [apologies for duplicates] Dear colleagues, We received some questions about the RIPE NCC's involvement in the World IPv6 Day that is planned for 8 June 2011. Please see some ideas and suggestions on RIPE Labs: http://labs.ripe.net/Members/mirjam/ripe-ncc-and-world-ipv6-day We are looking for feedback and suggestions, especially from subscribers of this working mailing list. Kind Regards, Mirjam Kuehne RIPE NCC From kristoff at belbone.net Fri Jan 21 13:22:35 2011 From: kristoff at belbone.net (Kristoff Bonne) Date: Fri, 21 Jan 2011 13:22:35 +0100 Subject: [ipv6-wg] And the IANA ipv4 depletion-day is ... yesterday ???? Message-ID: <4D397A8B.4040903@belbone.net> Hi, An interesting piece of news on the "ipv6depletion" website: http://www.ipv4depletion.com/?p=557#comments Because of two large delegations of the APNIC to two Chinese ISPs, the IANA depletion-day is moving real close. In fact, based on the rumours in the last comment, it has actually already happening but the IANA is holding back the allocation of the two last IANA "non-final" /8 blocks to APNIC for a couple of days to plan for a major media-event. (which - I guess- will not happen on a friday; so probably early next week). So, this leads us to the next question: What about a predection for the RIPE ipv4-depletion day? According the "bye-bye ipv4" applet I have running, the RIPE-pool currently has some 10.7 % still free: 279835 /24 left before the "final-/8" rules become to play. Any prediction how far we are from that point? Cheerio! Kr. Bonne. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3654 bytes Desc: S/MIME Cryptographic Signature URL: From ahmed at tamkien.com Sat Jan 22 06:32:34 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Sat, 22 Jan 2011 07:32:34 +0200 Subject: [ipv6-wg] Tool for /8 remaining Message-ID: Greetings, Does RIPE have any tool to indicate the remaining /8s , or portion thereof, in its own pool ? APNIC has a good one with recent history, see http://www.apnic.net/community/ipv4-exhaustion/graphical-information Regards, -Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Mon Jan 24 15:27:06 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 24 Jan 2011 15:27:06 +0100 Subject: [ipv6-wg] Future of the IPv6 CPE survey - Your Input Needed Message-ID: <4D3D8C3A.3060609@ripe.net> [apologies for duplicates] Dear colleagues, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask you for help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input-needed Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC From david.kessens at nsn.com Wed Jan 26 06:40:54 2011 From: david.kessens at nsn.com (David Kessens) Date: Tue, 25 Jan 2011 21:40:54 -0800 Subject: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <1294320025.2691.1723.camel@shane-asus-laptop> References: <1294320025.2691.1723.camel@shane-asus-laptop> Message-ID: <20110126054054.GA27563@nsn.com> [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > Hello, > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > The Review Phase for the RIPE policy proposal 2010-06 ended on > 2010-12-27 (Monday, 27 December 2010). > > You can see the policy proposal here: > > http://ripe.net/ripe/policies/proposals/2010-06.html > > There were some clarifications during the Review Phase, but nothing > indicating changes needed. > > David and I have decided that the proposal is ready for a Last Call. (As > co-author of the proposal, Marco has recused himself from any consensus > judgments.) > > The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 > February 2011). Please e-mail any final comments to ipv6-wg at ripe.net > before then. > > Thanks, > > -- > Shane From dr at cluenet.de Wed Jan 26 08:28:16 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Jan 2011 08:28:16 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <20110126072816.GA21768@srv03.cluenet.de> On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: > We have not received any input so far whether you support draft policy > 2010-06. Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Just dropping a proposal number and expecting all readers to use their web browser to find out what this 1234-56 is all about does probably act as a factual barrier. I know it does for me, not being paid for following RIPE mailing lists in detail. Just a suggestion. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jan at go6.si Wed Jan 26 09:14:47 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 26 Jan 2011 09:14:47 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126072816.GA21768@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> Message-ID: <4D3FD7F7.1030009@go6.si> On 1/26/11 8:28 AM, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >> We have not received any input so far whether you support draft policy >> 2010-06. > Perhaps it's a good idea to at least mention the title of the policy > proposal in the "last call" announcements so that folks can quickly > check wether they might have an opinion to voice or not. Agree. On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is. From he at uninett.no Wed Jan 26 09:58:26 2011 From: he at uninett.no (Havard Eidnes) Date: Wed, 26 Jan 2011 09:58:26 +0100 (CET) Subject: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <20110126.095826.196874534.he@uninett.no> Hi, I have two brief comments: The first one concerns the form of these announcements sent to the mailing list (and this doesn't just concern this particular proposal, if I recall correctly). Is it just me that find it obnoxious that nowhere in the announcement can there be found any hint as to what is proposed? I think that the lack of inclusion of even the title of the proposal creates a needless threshold for responding to it. For the record, the title of the proposal is "Registration Requirements for IPv6 End User Assignments". The only other comment I have is that 2^10 = 1024 != 1000. :) Other than that, I can't see anything wrong with the proposal. Best regards, - H?vard ------------------------------ > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > All, > > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. > > The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please > e-mail any final comments to ipv6-wg at ripe.net before then. > > Thanks, > > David & Shane > --- > > On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: >> Hello, >> >> [ Courtesy copy sent to address policy and database working groups. Please >> follow up on the ipv6-wg list. ] >> >> The Review Phase for the RIPE policy proposal 2010-06 ended on >> 2010-12-27 (Monday, 27 December 2010). >> >> You can see the policy proposal here: >> >> http://ripe.net/ripe/policies/proposals/2010-06.html >> >> There were some clarifications during the Review Phase, but nothing >> indicating changes needed. >> >> David and I have decided that the proposal is ready for a Last Call. (As >> co-author of the proposal, Marco has recused himself from any consensus >> judgments.) >> >> The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 >> February 2011). Please e-mail any final comments to ipv6-wg at ripe.net >> before then. >> >> Thanks, >> >> -- >> Shane > From andreas.larsen at ip-only.se Wed Jan 26 10:30:13 2011 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Wed, 26 Jan 2011 10:30:13 +0100 Subject: SV: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4D3FD7F7.1030009@go6.si> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> Message-ID: I support the proposal as-is. Regards Andreas -----Ursprungligt meddelande----- Fr?n: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] F?r Jan Zorz @ go6.si Skickat: den 26 januari 2011 09:15 Till: ipv6-wg at ripe.net ?mne: Re: [ipv6-wg] Re: 2010-06 is going to Last Call On 1/26/11 8:28 AM, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >> We have not received any input so far whether you support draft >> policy 2010-06. > Perhaps it's a good idea to at least mention the title of the policy > proposal in the "last call" announcements so that folks can quickly > check wether they might have an opinion to voice or not. Agree. On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is. From Remco.vanMook at eu.equinix.com Wed Jan 26 10:24:13 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 26 Jan 2011 09:24:13 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: Unsurprisingly, I support this proposal as-is :) Remco > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of David Kessens > Sent: woensdag 26 januari 2011 6:41 > To: ipv6-wg > Cc: db-wg at ripe.net; address-policy-wg at ripe.net > Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call > > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > All, > > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we prefer > to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. > > The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e- > mail any final comments to ipv6-wg at ripe.net before then. > > Thanks, > > David & Shane > --- > > On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > > Hello, > > > > [ Courtesy copy sent to address policy and database working groups. Please > > follow up on the ipv6-wg list. ] > > > > The Review Phase for the RIPE policy proposal 2010-06 ended on > > 2010-12-27 (Monday, 27 December 2010). > > > > You can see the policy proposal here: > > > > http://ripe.net/ripe/policies/proposals/2010-06.html > > > > There were some clarifications during the Review Phase, but nothing > > indicating changes needed. > > > > David and I have decided that the proposal is ready for a Last Call. > > (As co-author of the proposal, Marco has recused himself from any > > consensus > > judgments.) > > > > The last call period is four weeks, so will end 2010-02-03 (Thursday, > > 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net > > before then. > > > > Thanks, > > > > -- > > Shane 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 gvandeve at cisco.com Wed Jan 26 11:10:57 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Wed, 26 Jan 2011 11:10:57 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4D3FD7F7.1030009@go6.si> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502F6A6E8@XMB-AMS-101.cisco.com> I am new to this process.. so for me it saves more as the suggested 20 seconds :=-) G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: woensdag 26 januari 2011 9:15 To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] Re: 2010-06 is going to Last Call On 1/26/11 8:28 AM, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >> We have not received any input so far whether you support draft policy >> 2010-06. > Perhaps it's a good idea to at least mention the title of the policy > proposal in the "last call" announcements so that folks can quickly > check wether they might have an opinion to voice or not. Agree. On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is. From shane at time-travellers.org Wed Jan 26 11:13:40 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 26 Jan 2011 11:13:40 +0100 Subject: [ipv6-wg] Clear subject lines for policy discussions, was Re: 2010-06 is going to Last Call In-Reply-To: <20110126072816.GA21768@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> Message-ID: <1296036820.2425.912.camel@shane-asus-laptop> Daniel, On Wed, 2011-01-26 at 08:28 +0100, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: > > We have not received any input so far whether you support draft policy > > 2010-06. > > Perhaps it's a good idea to at least mention the title of the policy > proposal in the "last call" announcements so that folks can quickly > check wether they might have an opinion to voice or not. Just dropping a > proposal number and expecting all readers to use their web browser to > find out what this 1234-56 is all about does probably act as a factual > barrier. I know it does for me, not being paid for following RIPE > mailing lists in detail. Okay that makes sense. Looking at other announcements it seems like this is how things are normally done, and it was just an oversight on my side. Cheers, -- Shane From gvandeve at cisco.com Wed Jan 26 11:17:55 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Wed, 26 Jan 2011 11:17:55 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126072816.GA21768@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502F6A6F4@XMB-AMS-101.cisco.com> Some feedback: <> As an example, one would create ::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold. <> GV> Not sure why this is here in the intro... it's a valid and usefull anticipation, but I would place it somewhere else in the document as a motivation example. <>start<> 1.0 Motivation ... keep records of IPv6 address assignments ... <>end<> GV> What about using 'IPv6 subnet address assignments'? (I don't care about individual addresses in v6, but care about subnet addresses being used and the HD is calculated on that variable, not?) <>start<> 4.0 Functionality ... object may contain ... <>end<> GV>Is there a reason why it's a 'may' instead of a 'should' or 'must'? <>start<> 5.5 Registration ... End Site assignments ... <>end<> GV> What is an End-site assignment? If it's a SP doing this then I assume it is enterprise customer, however if it's an enterprise getting PI space, then what is end-site assignment? Maybe a loaded/naive question, but why not suggest anything larger then a /xx should be placed in the database? Ciao, G/ -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Daniel Roesen Sent: woensdag 26 januari 2011 8:28 To: ipv6-wg at ripe.net Subject: [ipv6-wg] Re: 2010-06 is going to Last Call On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: > We have not received any input so far whether you support draft policy > 2010-06. Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Just dropping a proposal number and expecting all readers to use their web browser to find out what this 1234-56 is all about does probably act as a factual barrier. I know it does for me, not being paid for following RIPE mailing lists in detail. Just a suggestion. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From marcoh at marcoh.net Wed Jan 26 11:33:01 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 26 Jan 2011 10:33:01 +0000 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502F6A6F4@XMB-AMS-101.cisco.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E502F6A6F4@XMB-AMS-101.cisco.com> Message-ID: Responding in my role as one of the proposers and authors of this document. Please see my comments inline: On Jan 26, 2011, at 10:17 AM, Gunter Van de Velde (gvandeve) wrote: > Some feedback: > > <> > As an example, one would create ::/36 with an assignment > size of /56. A simple MRTG graph over time showing the actual number of > assignments or customers can then be generated from the OSS/BSS system > or maybe even directly from the DHCPv6 servers involved. This would then > satisfy the need to verify the addresses are used efficiently enough and > the LIR meets the HD ratio required. It does so in a way to which most > LIRs are already familiar and without the need to disclose to any > specific information on individual End Users or the resource they hold. > <> > > GV> Not sure why this is here in the intro... it's a valid and usefull > anticipation, but I would place it somewhere else in the document as a > motivation example. Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ? > <>start<> > 1.0 Motivation > ... > keep records of IPv6 address assignments > ... > <>end<> > > GV> What about using 'IPv6 subnet address assignments'? > (I don't care about individual addresses in v6, but care about subnet > addresses being used and the HD is calculated on that variable, not?) I think the rest of the policy also simply talks about address assignments and allocations and not 'subnet assignments' > <>start<> > 4.0 Functionality > ... > object may contain > ... > <>end<> > > GV>Is there a reason why it's a 'may' instead of a 'should' or 'must'? Long story. The original text had a must there, it has something todo in the way the text of the document is converted into technical requirements for the RIPE NCC database group. The formal rule is that the attribute is optional so it has to be a may as you describe it. The 'must' will be the result of a business rule at another level. This came up during the impact analysis done by the NCC so Remco and I agreed in changing it. > <>start<> > 5.5 Registration > ... > End Site assignments > ... > <>end<> > > GV> What is an End-site assignment? If it's a SP doing this then I > assume it is enterprise > customer, however if it's an enterprise getting PI space, then what is > end-site assignment? > Maybe a loaded/naive question, but why not suggest anything larger then > a /xx should be placed in the database? PI is not relevant here as you are not allowed to make any sub assignments within a PI assignment. The definition of an end site is given elsewhere in the document (sec 2.9, current RIPE-481) and this will not be changed. Grtx, MarcoH (proposer) From gvandeve at cisco.com Wed Jan 26 11:38:01 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Wed, 26 Jan 2011 11:38:01 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E502F6A6F4@XMB-AMS-101.cisco.com> Message-ID: <4269EA985EACD24987D82DAE2FEC62E502F6A70A@XMB-AMS-101.cisco.com> > <> > As an example, one would create ::/36 with an assignment > size of /56. A simple MRTG graph over time showing the actual number of > assignments or customers can then be generated from the OSS/BSS system > or maybe even directly from the DHCPv6 servers involved. This would then > satisfy the need to verify the addresses are used efficiently enough and > the LIR meets the HD ratio required. It does so in a way to which most > LIRs are already familiar and without the need to disclose to any > specific information on individual End Users or the resource they hold. > <> > > GV> Not sure why this is here in the intro... it's a valid and usefull > anticipation, but I would place it somewhere else in the document as a > motivation example. Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ? GV> I was just surprised to see an example in the intro section... it is not that I disagree with it, however it's a strange place to see an example mentioned. From marcoh at marcoh.net Wed Jan 26 11:45:26 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 26 Jan 2011 10:45:26 +0000 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E502F6A70A@XMB-AMS-101.cisco.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4269EA985EACD24987D82DAE2FEC62E502F6A6F4@XMB-AMS-101.cisco.com> <4269EA985EACD24987D82DAE2FEC62E502F6A70A@XMB-AMS-101.cisco.com> Message-ID: On Jan 26, 2011, at 10:38 AM, Gunter Van de Velde (gvandeve) wrote: >> <> >> As an example, one would create ::/36 with an assignment >> size of /56. A simple MRTG graph over time showing the actual number > of >> assignments or customers can then be generated from the OSS/BSS system >> or maybe even directly from the DHCPv6 servers involved. This would > then >> satisfy the need to verify the addresses are used efficiently enough > and >> the LIR meets the HD ratio required. It does so in a way to which most >> LIRs are already familiar and without the need to disclose to any >> specific information on individual End Users or the resource they > hold. >> <> >> >> GV> Not sure why this is here in the intro... it's a valid and usefull >> anticipation, but I would place it somewhere else in the document as a >> motivation example. > > Forgive me for asking, are you commenting on the policy proposal itself > or on one of the draft documents which will be the result of this ? > > GV> I was just surprised to see an example in the intro section... it is > not that I disagree with it, however it's a strange place to see an > example mentioned. It could have gone in the rationale, but then again it might be worth explaining it in the beginning. But be aware this is just the proposal, t's a form used in the process. This is not the resulting text, these are in the draft documents listed in the heading. Marco (as the proposer) From sander at steffann.nl Wed Jan 26 12:20:43 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 26 Jan 2011 13:20:43 +0200 Subject: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <327D1528-7BD0-4CFE-A162-6EE3A84722E3@steffann.nl> Hello IPv6 WG, > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. I support this proposal Sander From Piotr.Strzyzewski at polsl.pl Wed Jan 26 13:06:01 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 26 Jan 2011 13:06:01 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4D3FD7F7.1030009@go6.si> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> Message-ID: <20110126120601.GC4419@hydra.ck.polsl.pl> On Wed, Jan 26, 2011 at 09:14:47AM +0100, Jan Zorz @ go6.si wrote: > On 1/26/11 8:28 AM, Daniel Roesen wrote: >> On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >>> We have not received any input so far whether you support draft policy >>> 2010-06. >> Perhaps it's a good idea to at least mention the title of the policy >> proposal in the "last call" announcements so that folks can quickly >> check wether they might have an opinion to voice or not. > Agree. > > On the other hand, it took me 20 seconds to find it. > > For everyone reference and help (saving 20 seconds): > http://ripe.net/ripe/policies/proposals/2010-06.html Under 3.0 section there is: "When needed, more specific inet6num objects are allowed to indicate a different assignment size within a certain range however only one level of more specifics is allowed." However rules put into 4.0 section allows to create multiple levels of inet6num objects with AGGREGATED-BY-LIR status. Is it ok? Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From marcoh at marcoh.net Wed Jan 26 13:55:45 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 26 Jan 2011 12:55:45 +0000 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126120601.GC4419@hydra.ck.polsl.pl> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> <20110126120601.GC4419@hydra.ck.polsl.pl> Message-ID: >> For everyone reference and help (saving 20 seconds): >> http://ripe.net/ripe/policies/proposals/2010-06.html > > Under 3.0 section there is: > "When needed, more specific inet6num objects are allowed to indicate a > different assignment size within a certain range however only one level > of more specifics is allowed." > > However rules put into 4.0 section allows to create multiple levels of > inet6num objects with AGGREGATED-BY-LIR status. Is it ok? In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html It says under 4.0: 4.0 Functionality When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules: ? The inet6num object may contain an optional attribute called "assignment-size:". ? The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself. ? A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or ?AGGREGATED-BY-LIR?. ? When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:? attribute becomes required. And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question Marco (Again strictly as proposer/co-author) From marty at akamai.com Wed Jan 26 15:07:31 2011 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 26 Jan 2011 09:07:31 -0500 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> Message-ID: On 1/26/11 12:40 AM, "David Kessens" wrote: > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. > I support this proposal. Best, -M< From matoa at vayu.net Wed Jan 26 15:57:49 2011 From: matoa at vayu.net (Mathieu Paonessa) Date: Wed, 26 Jan 2011 15:57:49 +0100 Subject: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <4D40366D.4040000@vayu.net> Hi All, On 1/26/11 6:40 AM, David Kessens wrote: > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. I also support this proposal. Cheers, Mathieu From cgrundemann at gmail.com Wed Jan 26 16:03:07 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 26 Jan 2011 08:03:07 -0700 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: On Tue, Jan 25, 2011 at 22:40, David Kessens wrote: > > [ Courtesy copy sent to address policy and database working groups. Please > ?follow up on the ipv6-wg list. ] > > All, > > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. I support this policy. ~Chris > The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please > e-mail any final comments to ipv6-wg at ripe.net before then. > > Thanks, > > David & Shane > --- > > On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: >> Hello, >> >> [ Courtesy copy sent to address policy and database working groups. Please >> ? follow up on the ipv6-wg list. ] >> >> The Review Phase for the RIPE policy proposal 2010-06 ended on >> 2010-12-27 (Monday, 27 December 2010). >> >> You can see the policy proposal here: >> >> http://ripe.net/ripe/policies/proposals/2010-06.html >> >> There were some clarifications during the Review Phase, but nothing >> indicating changes needed. >> >> David and I have decided that the proposal is ready for a Last Call. (As >> co-author of the proposal, Marco has recused himself from any consensus >> judgments.) >> >> The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 >> February 2011). Please e-mail any final comments to ipv6-wg at ripe.net >> before then. >> >> Thanks, >> >> -- >> Shane > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From ale at ipvision.dk Wed Jan 26 15:41:45 2011 From: ale at ipvision.dk (Allan Eising) Date: Wed, 26 Jan 2011 15:41:45 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <89E451A077DD1D4E8815102F2C0693811A9E132990@exch003.1StopIT.local> I support the proposal. Kind regards Allan Eising Network Engineer IP Vision A/S > All, > > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. > > The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please > e-mail any final comments to ipv6-wg at ripe.net before then. > > Thanks, > > David & Shane From nick at inex.ie Wed Jan 26 16:24:37 2011 From: nick at inex.ie (Nick Hilliard) Date: Wed, 26 Jan 2011 15:24:37 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <4D403CB5.4050102@inex.ie> On 26/01/2011 05:40, David Kessens wrote: > The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please > e-mail any final comments to ipv6-wg at ripe.net before then. I agree with the proposal. Nick From Piotr.Strzyzewski at polsl.pl Wed Jan 26 17:03:44 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 26 Jan 2011 17:03:44 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> <20110126120601.GC4419@hydra.ck.polsl.pl> Message-ID: <20110126160344.GC20654@hydra.ck.polsl.pl> On Wed, Jan 26, 2011 at 12:55:45PM +0000, Marco Hogewoning wrote: > In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html > > It says under 4.0: > > 4.0 Functionality > > When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules: > > ? The inet6num object may contain an optional attribute called "assignment-size:". > > ? The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself. > > ? A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or ?AGGREGATED-BY-LIR?. > > ? When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:? attribute becomes required. > > And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question So, according to third point I can create inet6num object with /36 size and status "AGGREGATED-BY-LIR" under my allocation, and then another inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this bigger one and then another one and so on. There is nothing about two levels less specific object. But maybe I don't understand this correctly. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From marcoh at marcoh.net Wed Jan 26 17:07:42 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 26 Jan 2011 16:07:42 +0000 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126160344.GC20654@hydra.ck.polsl.pl> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> <20110126120601.GC4419@hydra.ck.polsl.pl> <20110126160344.GC20654@hydra.ck.polsl.pl> Message-ID: On Jan 26, 2011, at 4:03 PM, Piotr Strzyzewski wrote: > On Wed, Jan 26, 2011 at 12:55:45PM +0000, Marco Hogewoning wrote: >> In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html >> >> It says under 4.0: >> >> 4.0 Functionality >> >> When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules: >> >> ? The inet6num object may contain an optional attribute called "assignment-size:". >> >> ? The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself. >> >> ? A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or ?AGGREGATED-BY-LIR?. >> >> ? When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:? attribute becomes required. >> >> And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question > > So, according to third point I can create inet6num object with /36 size > and status "AGGREGATED-BY-LIR" under my allocation, and then another > inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this > bigger one and then another one and so on. There is nothing about two > levels less specific object. But maybe I don't understand this correctly. You are righrt, it seems a bit strange ,without the policy that says only one level is allowed to it next to it (it's in another document). Please also take a look at the mail from Denis Walker on how the RIPE NCC will implement this and will be checking the grandparent object as well. Grtx, Marco From Piotr.Strzyzewski at polsl.pl Wed Jan 26 17:12:16 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 26 Jan 2011 17:12:16 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126072816.GA21768@srv03.cluenet.de> <4D3FD7F7.1030009@go6.si> <20110126120601.GC4419@hydra.ck.polsl.pl> <20110126160344.GC20654@hydra.ck.polsl.pl> Message-ID: <20110126161216.GD20654@hydra.ck.polsl.pl> On Wed, Jan 26, 2011 at 04:07:42PM +0000, Marco Hogewoning wrote: > > So, according to third point I can create inet6num object with /36 size > > and status "AGGREGATED-BY-LIR" under my allocation, and then another > > inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this > > bigger one and then another one and so on. There is nothing about two > > levels less specific object. But maybe I don't understand this correctly. > > You are righrt, it seems a bit strange ,without the policy that says only one level is allowed to it next to it (it's in another document). Please also take a look at the mail from Denis Walker on how the RIPE NCC will implement this and will be checking the grandparent object as well. That explains everything. I support this proposal. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From LHOFFMAN at bouyguestelecom.fr Wed Jan 26 17:12:14 2011 From: LHOFFMAN at bouyguestelecom.fr (HOFFMANN, Lionel) Date: Wed, 26 Jan 2011 17:12:14 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: OK I support this policy Lionel HOFFMANN Direction Technique Tel: 01 39 45 42 76 Mob: 06 60 31 42 76 Email: lhoffman at bouyguestelecom.fr Adresse: 13/15 avenue du Mar?chal juin 92360 MEUDON -----Message d'origine----- De : ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] De la part de Chris Grundemann Envoy? : mercredi 26 janvier 2011 16:03 ? : David Kessens Cc : ipv6-wg; db-wg at ripe.net; address-policy-wg at ripe.net Objet : Re: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call On Tue, Jan 25, 2011 at 22:40, David Kessens wrote: > > [ Courtesy copy sent to address policy and database working groups. > Please > follow up on the ipv6-wg list. ] > > All, > > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will > make it unequivocally clear that consensus was indeed reached. I support this policy. ~Chris > The last call period will end 2010-02-03 (Thursday, 3 February 2011). > Please e-mail any final comments to ipv6-wg at ripe.net before then. > > Thanks, > > David & Shane > --- > > On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: >> Hello, >> >> [ Courtesy copy sent to address policy and database working groups. >> Please >> follow up on the ipv6-wg list. ] >> >> The Review Phase for the RIPE policy proposal 2010-06 ended on >> 2010-12-27 (Monday, 27 December 2010). >> >> You can see the policy proposal here: >> >> http://ripe.net/ripe/policies/proposals/2010-06.html >> >> There were some clarifications during the Review Phase, but nothing >> indicating changes needed. >> >> David and I have decided that the proposal is ready for a Last Call. >> (As co-author of the proposal, Marco has recused himself from any >> consensus >> judgments.) >> >> The last call period is four weeks, so will end 2010-02-03 (Thursday, >> 3 February 2011). Please e-mail any final comments to >> ipv6-wg at ripe.net before then. >> >> Thanks, >> >> -- >> Shane > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org L'int?grit? de ce message n'?tant pas assur?e sur internet, la soci?t? exp?ditrice ne peut ?tre tenue responsable de son contenu ni de ses pi?ces jointes. Toute utilisation ou diffusion non autoris?e est interdite. Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. From denis at ripe.net Wed Jan 26 16:25:48 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 26 Jan 2011 16:25:48 +0100 Subject: [ipv6-wg] Proposed Implementation Plan for Policy Proposal 2010-06 in the RIPE Database Message-ID: <4D403CFC.9050100@ripe.net> [Apologies for duplicate emails] Dear Colleagues, To prepare for the possible acceptance of RIPE Policy Proposal 2010-06, "Registration Requirements for IPv6 End User Assignments", the Database Group at the RIPE NCC proposes the following implementation plan. We will implement a new attribute ("assignment-size:") in INET6NUM objects, add some business logic for its use and add a new value (AGGREGATED-BY-LIR) for the "status:" attribute of an INET6NUM object. Schema and syntax changes in INET6NUM objects: - New attribute "assignment-size:" - Syntax is numeric value > 0 - INET6NUM object will include "assignment-size:" as an optional, single attribute - "assignment-size:" will not be an inverse searchable attribute - New value for the "status:" attribute of an INET6NUM object will be AGGREGATED-BY-LIR Business rules: - "assignment-size:" is optional in INET6NUM objects but required if "status:" is AGGREGATED-BY-LIR - The value of "assignment-size:" must be greater than the prefix size of the INET6NUM object containing the attribute - Parent status of INET6NUM object with status AGGREGATED-BY-LIR can be: ALLOCATED-BY-RIR ALLOCATED-BY-LIR AGGREGATED-BY-LIR - If parent status is AGGREGATED-BY-LIR, grandparent status cannot be AGGREGATED-BY-LIR - If an object has the status AGGREGATED-BY-LIR, a more specific object can only have the status AGGREGATED-BY-LIR (subject to the aforementioned constraints) We will prepare implementation of this plan during the week commencing 31 January 2011. It will be deployed during the week commencing 7 February 2011 should RIPE Policy Proposal 2010-06 be formally approved. Regards, Denis Walker Business Analyst RIPE NCC Database Group From dr at cluenet.de Wed Jan 26 20:36:55 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Jan 2011 20:36:55 +0100 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <20110126193655.GA1684@srv03.cluenet.de> On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal". The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public. As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage. My opposition is solely about the assignment-size attribute being mandatory. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From andy at nosignal.org Wed Jan 26 21:24:30 2011 From: andy at nosignal.org (Andy Davidson) Date: Wed, 26 Jan 2011 20:24:30 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: On 26 Jan 2011, at 05:40, David Kessens wrote: > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will make it > unequivocally clear that consensus was indeed reached. [...] >> http://ripe.net/ripe/policies/proposals/2010-06.html I support this proposal. Andy From david.freedman at eu.clara.net Wed Jan 26 21:57:01 2011 From: david.freedman at eu.clara.net (David Freedman) Date: Wed, 26 Jan 2011 20:57:01 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <79C1BF34-5E37-48AF-9EC8-9C214D9E9A77@uk.clara.net> Support On 26 Jan 2011, at 20:42, "Andy Davidson" wrote: > > On 26 Jan 2011, at 05:40, David Kessens wrote: > >> We have not received any input so far whether you support draft policy >> 2010-06. While silence will in general be interpreted as consensus, we >> prefer to have a good number of statements of support as that will make it >> unequivocally clear that consensus was indeed reached. > [...] >>> http://ripe.net/ripe/policies/proposals/2010-06.html > > I support this proposal. > > Andy > From Fritsche at iabg.de Thu Jan 27 08:48:14 2011 From: Fritsche at iabg.de (Fritsche Wolfgang) Date: Thu, 27 Jan 2011 07:48:14 +0000 Subject: AW: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop>,<20110126054054.GA27563@nsn.com> Message-ID: <1A57CD3F2EA17346BB83C752FE423BE76C62C998@ExMbx1.iabg.de> I support this proposal. Wolfgang ________________________________________ Von: ipv6-wg-admin at ripe.net [ipv6-wg-admin at ripe.net]" im Auftrag von "David Kessens [david.kessens at nsn.com] Gesendet: Mittwoch, 26. Januar 2011 06:40 An: ipv6-wg Cc: db-wg at ripe.net; address-policy-wg at ripe.net Betreff: Re: [ipv6-wg] 2010-06 is going to Last Call [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > Hello, > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > The Review Phase for the RIPE policy proposal 2010-06 ended on > 2010-12-27 (Monday, 27 December 2010). > > You can see the policy proposal here: > > http://ripe.net/ripe/policies/proposals/2010-06.html > > There were some clarifications during the Review Phase, but nothing > indicating changes needed. > > David and I have decided that the proposal is ready for a Last Call. (As > co-author of the proposal, Marco has recused himself from any consensus > judgments.) > > The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 > February 2011). Please e-mail any final comments to ipv6-wg at ripe.net > before then. > > Thanks, > > -- > Shane From valeriu at roedu.net Thu Jan 27 09:01:02 2011 From: valeriu at roedu.net (Valeriu Vraciu) Date: Thu, 27 Jan 2011 10:01:02 +0200 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126193655.GA1684@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126193655.GA1684@srv03.cluenet.de> Message-ID: <4D41263E.7070501@roedu.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/26/11 9:36 PM, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >> We have not received any input so far whether you support draft policy >> 2010-06. While silence will in general be interpreted as consensus, we >> prefer to have a good number of statements of support as that will make it >> unequivocally clear that consensus was indeed reached. > > I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal". > > The only one who needs the assignment size is RIPE NCC when evaluating > new allocation requests or in audit. At that time, it's easy for the LIR > to provide this info to NCC for HD ratio evaluation. Following the > spirit of data protection, we shouldn't put (in a mandatory manner) more > potentially sensitive data into public databases without a good > justification for the need to have that data public. > > As a second reason, it allows folks running block lists to again start > blocking dynamic customer IP prefixes by automatically looking up the > assignment-size. Of course that makes no sense (as the /xy prefix will > belong to another customer next day), but as soon as those assignment-size > attributes will pop up, misguided folks _will_ start using them for > broken heuristics and cause colateral damage. > > My opposition is solely about the assignment-size attribute being > mandatory. > > Best regards, > Daniel > Hi, I agree with Daniel's arguments regarding the mandatory and visible status of the proposed new "assignment-size" attribute. Regards, Valeriu. ================================= Valeriu VRACIU Network Engineer at RoEduNet tel: +40 (232) 201003 fax: +40 (232) 201200 GSM: +40 (744) 615251 e-mail: valeriu.vraciu at roedu.net ================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1BJj0ACgkQncI+CatY9492fwCgiELB3MnMtLYpI1R/INqTgzsZ /DEAninsMzBnbJGgTVA+qfzMg2OoOTYl =JnxM -----END PGP SIGNATURE----- From dez at otenet.gr Thu Jan 27 09:27:02 2011 From: dez at otenet.gr (Yannis Nikolopoulos) Date: Thu, 27 Jan 2011 10:27:02 +0200 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126193655.GA1684@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126193655.GA1684@srv03.cluenet.de> Message-ID: <4D412C56.1070302@otenet.gr> On 01/26/2011 09:36 PM, Daniel Roesen wrote: > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: >> We have not received any input so far whether you support draft policy >> 2010-06. While silence will in general be interpreted as consensus, we >> prefer to have a good number of statements of support as that will make it >> unequivocally clear that consensus was indeed reached. > I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal". > > The only one who needs the assignment size is RIPE NCC when evaluating > new allocation requests or in audit. At that time, it's easy for the LIR > to provide this info to NCC for HD ratio evaluation. Following the > spirit of data protection, we shouldn't put (in a mandatory manner) more > potentially sensitive data into public databases without a good > justification for the need to have that data public. > > As a second reason, it allows folks running block lists to again start > blocking dynamic customer IP prefixes by automatically looking up the > assignment-size. Of course that makes no sense (as the /xy prefix will > belong to another customer next day), but as soon as those assignment-size > attributes will pop up, misguided folks _will_ start using them for > broken heuristics and cause colateral damage. > > My opposition is solely about the assignment-size attribute being > mandatory. > > Best regards, > Daniel > Daniel, I share your concerns as I had similar ones. You could always avoid using "remarks" and/or description for such published blocks. Of course, it's not bulletproof. In any case, I support the proposal regards, Yannis From Remco.vanMook at eu.equinix.com Thu Jan 27 09:34:01 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 27 Jan 2011 08:34:01 +0000 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <4D41263E.7070501@roedu.net> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126193655.GA1684@srv03.cluenet.de> <4D41263E.7070501@roedu.net> Message-ID: Daniel, Valeriu, I don't really see why publishing an assignment size alone would allow people to run block lists. People will run those regardless, and if they don't know what size prefix a customer has, they will assume one, and error on the side of caution - i.e. always assume a /48. Misguided people won't stop being misguided because of a lack of information. I wish that was true. As for your first argument, I don't think the RIPE NCC can do a proper job with some public oversight without publishing the assignment size. For IPv4 the world is pretty straightforward, because everybody knows that the size of a customer prefix in a dynamic pool is a /32 or somewhere close to that. It's not a /16. In IPv6, it can be anything from a /64 to a /48 - pretty much at the discretion of the ISP. It should be a surprise to absolutely nobody that ISPs who hand out /48s will go through their allocations a lot quicker than others handing out /64s, and as a result will end up with more address space. A published assignment size for dynamic pools helps to explain to the rest of the world why that is. And it protects your customers from misguided people who like to make assumptions that are safe for them, not your customers. Remco > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of Valeriu Vraciu > Sent: donderdag 27 januari 2011 9:01 > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] Re: 2010-06 is going to Last Call > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 1/26/11 9:36 PM, Daniel Roesen wrote: > > On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: > >> We have not received any input so far whether you support draft > >> policy 2010-06. While silence will in general be interpreted as > >> consensus, we prefer to have a good number of statements of support > >> as that will make it unequivocally clear that consensus was indeed > reached. > > > > I oppose on grounds of paragraph 2 of "Arguments Opposing the > Proposal". > > > > The only one who needs the assignment size is RIPE NCC when evaluating > > new allocation requests or in audit. At that time, it's easy for the > > LIR to provide this info to NCC for HD ratio evaluation. Following the > > spirit of data protection, we shouldn't put (in a mandatory manner) > > more potentially sensitive data into public databases without a good > > justification for the need to have that data public. > > > > As a second reason, it allows folks running block lists to again start > > blocking dynamic customer IP prefixes by automatically looking up the > > assignment-size. Of course that makes no sense (as the /xy prefix will > > belong to another customer next day), but as soon as those > > assignment-size attributes will pop up, misguided folks _will_ start > > using them for broken heuristics and cause colateral damage. > > > > My opposition is solely about the assignment-size attribute being > > mandatory. > > > > Best regards, > > Daniel > > > > Hi, > I agree with Daniel's arguments regarding the mandatory and visible status of > the proposed new "assignment-size" attribute. > > Regards, > Valeriu. > > ================================= > Valeriu VRACIU > Network Engineer at RoEduNet > tel: +40 (232) 201003 > fax: +40 (232) 201200 > GSM: +40 (744) 615251 > e-mail: valeriu.vraciu at roedu.net > ================================= > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1BJj0ACgkQncI+CatY9492fwCgiELB3MnMtLYpI1R/INqTgzsZ > /DEAninsMzBnbJGgTVA+qfzMg2OoOTYl > =JnxM > -----END PGP SIGNATURE----- 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 LMELE at infoclip.fr Thu Jan 27 10:06:00 2011 From: LMELE at infoclip.fr (Laurent MELE) Date: Thu, 27 Jan 2011 10:06:00 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <830252D2E2E7E34084708CB626F2419440E1BC85DA@iliv.ifc.local> > We have not received any input so far whether you support draft policy > 2010-06. While silence will in general be interpreted as consensus, we > prefer to have a good number of statements of support as that will > make it unequivocally clear that consensus was indeed reached. [...] >> http://ripe.net/ripe/policies/proposals/2010-06.html Support -- Laurent Mele Groupe INFOCLIP Directeur Technique 32 avenue Corentin Cariou 75 019 PARIS T?l : +33 (0) 1 43 18 19 20 Fax : +33 (0) 1 43 18 19 29 PGP KeyFingerPrint : 6E9D 5F72 6C21 1194 C00F? E6AC 6102 CCEA BD33 731A From kzorba at otenet.gr Thu Jan 27 10:38:46 2011 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Thu, 27 Jan 2011 11:38:46 +0200 Subject: [ipv6-wg] Re: 2010-06 is going to Last Call In-Reply-To: <20110126193655.GA1684@srv03.cluenet.de> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126193655.GA1684@srv03.cluenet.de> Message-ID: <201101271138.47619.kzorba@otenet.gr> On Wednesday, January 26, 2011 09:36:55 pm Daniel Roesen wrote: ... > I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal". > > The only one who needs the assignment size is RIPE NCC when evaluating > new allocation requests or in audit. ... I am sure that RIPE NCC is not the only interested party for the publication of an assignment-size attribute. I think the advantages clearly outweigh the disadvantages here. I support this proposal. Regards, Kostas From dr at cluenet.de Thu Jan 27 10:57:45 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 27 Jan 2011 10:57:45 +0100 Subject: [ipv6-wg] Re: Re: 2010-06 is going to Last Call In-Reply-To: <201101271138.47619.kzorba@otenet.gr> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> <20110126193655.GA1684@srv03.cluenet.de> <201101271138.47619.kzorba@otenet.gr> Message-ID: <20110127095745.GA23897@srv03.cluenet.de> On Thu, Jan 27, 2011 at 11:38:46AM +0200, Kostas Zorbadelos wrote: > I am sure that RIPE NCC is not the only interested party for the > publication of an assignment-size attribute. Interest != need. Publishing potentially sensitive data just because people are "interested" is not a good enough reason in my book of data protection principles. Next time people ask for weekly updated fill-level: attributes in PD pools so "interested" folks can "transparently" verify wether usage levels are according to the rules that NCC enforces (and obtain further business intelligence as a side effect, how convenient). Anyway, as the proposal is in Last Call, I'll rest my case. I'm still totally unconvinced that this a good idea. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From daniel at bit.nl Thu Jan 27 16:43:56 2011 From: daniel at bit.nl (Daniel Verlouw) Date: Thu, 27 Jan 2011 16:43:56 +0100 Subject: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: <1296143036.27351.23.camel@daniel> On Tue, 2011-01-25 at 21:40 -0800, David Kessens wrote: > > http://ripe.net/ripe/policies/proposals/2010-06.html support. -- Daniel Verlouw, Network Engineer BIT BV | info at bit.nl | +31 318 648688 KvK: 09090351 | GPG: 0x48ED5D99 | DV244-RIPE From Ragnar.Anfinsen at altibox.no Fri Jan 28 10:00:25 2011 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Fri, 28 Jan 2011 10:00:25 +0100 Subject: SV: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call In-Reply-To: <20110126054054.GA27563@nsn.com> References: <1294320025.2691.1723.camel@shane-asus-laptop> <20110126054054.GA27563@nsn.com> Message-ID: +1 Regards Ragnar Anfinsen Altibox AS [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg at ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote: > Hello, > > [ Courtesy copy sent to address policy and database working groups. Please > follow up on the ipv6-wg list. ] > > The Review Phase for the RIPE policy proposal 2010-06 ended on > 2010-12-27 (Monday, 27 December 2010). > > You can see the policy proposal here: > > http://ripe.net/ripe/policies/proposals/2010-06.html > > There were some clarifications during the Review Phase, but nothing > indicating changes needed. > > David and I have decided that the proposal is ready for a Last Call. (As > co-author of the proposal, Marco has recused himself from any consensus > judgments.) > > The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 > February 2011). Please e-mail any final comments to ipv6-wg at ripe.net > before then. > > Thanks, > > -- > Shane