From sbras at ripe.net Thu May 2 10:25:08 2013 From: sbras at ripe.net (Sandra Bras) Date: Thu, 2 May 2013 10:25:08 +0200 Subject: [ipv6-wg] [training] New RIPE NCC IPv6 E-Learning tutorials Message-ID: [Apologies for duplicates] Dear colleagues, We are pleased to announce the launch of four new videos on IPv6 Transition Mechanisms as part of our online training. The topics include: - 6in4 - 6RD - NAT64 - DS-Lite You can watch them online at: https://www.ripe.net/lir-services/training/e-learning/ipv6/transition-mechanisms Stay tuned! We plan to announce more exciting E-Learning news in the coming months. RIPE NCC E-Learning tutorials are provided as a free service available to everyone. If you have any questions, please feel free to contact us at: e-learning at ripe.net. Happy learning, Sandra Br?s Trainer / E-Learning Project Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From randy at psg.com Thu May 2 16:33:33 2013 From: randy at psg.com (Randy Bush) Date: Thu, 02 May 2013 07:33:33 -0700 Subject: [ipv6-wg] [ncc-services-wg] [training] New RIPE NCC IPv6 E-Learning tutorials In-Reply-To: References: Message-ID: > We are pleased to announce the launch of four new videos on IPv6 > Transition Mechanisms as part of our online training. only 293 to go > The topics include: > - DS-Lite ahh yes. all the benefits of nat in the core plus fork-lift of all cpe. a brilliant scheme. randy From marcoh at marcoh.net Thu May 2 17:55:24 2013 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 2 May 2013 17:55:24 +0200 Subject: [ipv6-wg] RIPE 66 Draft Agenda version 2 Message-ID: <6FB3C53E-6965-40B3-9BE4-CF2DD639D379@marcoh.net> Dear Colleagues, Attached a copy of the latest draft agenda. As you may notice, this time round we opted for a couple of longer talks, which makes the speakers list a bit shorter than normal. Should there be any other topic you wish to discuss or you think we missed some important developments, please let us know. Your IPv6 WG Chairs, Marco, David and Shane Session 1 ? Wednesday, 15 May 13:00 ? 15:30 (Main Room) A) Welcome and Administrative Business B) ?Implementing Full IPv6 Support: More than Binding to an AF_INET6 Socket? Bert Hubert, PowerDNS/Netherlabs C) "non-working clients" - TBC Andrew Yourtchenko, Cisco D) ?The latest developments in DHCPv6? Tomek Mrugalski, Internet Software Consortium Session 2 ? Thursday, 16 May 09:00 ? 10:30 (Side Room) A) "Measuring Effectiveness of Happy Eyeballs" - TBC B) "IPv6 RIPEness Fifth Star" Vesna Manojlovic, RIPE NCC C) IPv6 Measurements Panel Organisers: - Marco Hogewoning, RIPE NCC - Meredith Whittaker, Google/M-Lab Panellist: - Geoff Huston, APNIC - Mark Townsley, Cisco - Steve Nash, Arbor Networks (TBC) - Heidi Kivek?s, FICORA (TBC) X) Close From mir at ripe.net Mon May 13 07:09:34 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 13 May 2013 07:09:34 +0200 Subject: [ipv6-wg] New on RIPE Labs: Implementing Fifth Start IPv6 RIPEness Message-ID: <5190758E.3030801@ripe.net> Dear colleagues, In this new article on RIPE Labs we present the first results of a fifth star for IPv6 RIPEness. This is a way to measure real IPv6 deployment in the RIPE NCC service region: https://labs.ripe.net/Members/emileaben/ipv6-ripeness-implementing-the-5th-star We would like to receive your feedback on a number of open question raised in the article. We also hope to see many of you at the IPv6 WG meeting in Dublin later this week where these results will be presented. Kind regards, Mirjam Kuehne RIPE NCC From daniel.karrenberg at ripe.net Wed May 15 21:38:48 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 May 2013 21:38:48 +0200 Subject: [ipv6-wg] MERIT Darknet Experiment, Guidance Sought in Routing WG Message-ID: <1675A5F3-DA90-466F-BA75-147D8CD07F6F@ripe.net> Some of you may remember the short discussion here last November about the MERIT Darknet experiment and the subsequent change in our permission to MERIT. This RIPE meeting we have heard a presentation from MERIT/US-DHS about first results: https://ripe66.ripe.net/presentations/121-v6darknet-ripe2013.pdf Given this, the RIPE NCC is seeking guidance on what our permission to MERIT should be in the future. Here are a couple of slides which we will present in the routing-wg: https://ripe66.ripe.net/presentations/259-20130515-v6-darknet.key.pdf Any reactions are welcome. I suggest to have any discussion over on routing-wg at ripe.net. Daniel From emadaio at ripe.net Tue May 21 14:43:32 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 21 May 2013 14:43:32 +0200 Subject: [ipv6-wg] Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects Message-ID: <519B6BF4.8020406@ripe.net> Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we?re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents We encourage you to read the edited draft of ripe-513 and send any comments to by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC From wilhelm at boeddinghaus.de Sun May 26 20:50:05 2013 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Sun, 26 May 2013 20:50:05 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page Message-ID: <51A2595D.4040902@boeddinghaus.de> Dear colleagues, as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. A errata page would make it possible to document minor but important changes of the content of the document. If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. Kind regards, Wilhelm Boeddinghaus From pk at DENIC.DE Sun May 26 23:10:38 2013 From: pk at DENIC.DE (Peter Koch) Date: Sun, 26 May 2013 23:10:38 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2595D.4040902@boeddinghaus.de> References: <51A2595D.4040902@boeddinghaus.de> Message-ID: <20130526211038.GH31051@x28.adm.denic.de> On Sun, May 26, 2013 at 08:50:05PM +0200, Wilhelm Boeddinghaus wrote: > anything in the document without getting a new RIPE document number. But > having to many different versions of the document confuses our audience. why is the audience less confused by the same number referencing different content? -Peter From sander at steffann.nl Mon May 27 00:07:51 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 27 May 2013 00:07:51 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <20130526211038.GH31051@x28.adm.denic.de> References: <51A2595D.4040902@boeddinghaus.de> <20130526211038.GH31051@x28.adm.denic.de> Message-ID: <0C36F444-C3F6-4759-8297-87E72D8873BE@steffann.nl> Hi Peter, >> anything in the document without getting a new RIPE document number. But >> having to many different versions of the document confuses our audience. > > why is the audience less confused by the same number referencing different > content? This is about 'same content, but with typo's fixed', not about completely new content. If the content changes then I agree we need a new number. Otherwise we end up with references like 'RIPE-554, the version just before they replaced RFC xxxx with RFC yyyy'. Companies must still be able to say things like 'our products comply to RIPE-554' without any confusion. Cheers, Sander From raymond.jetten at elisa.fi Mon May 27 08:05:50 2013 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 27 May 2013 09:05:50 +0300 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2595D.4040902@boeddinghaus.de> References: <51A2595D.4040902@boeddinghaus.de> Message-ID: Hello All, I don't see any reason why this would be a problem, i support the proposal. Ray -----Original Message----- From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Wilhelm Boeddinghaus Sent: 26. toukokuuta 2013 21:50 To: ipv6-wg at ripe.net Subject: [ipv6-wg] RIPE 554 Errata Page Dear colleagues, as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. A errata page would make it possible to document minor but important changes of the content of the document. If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. Kind regards, Wilhelm Boeddinghaus From jan at pragma.si Mon May 27 06:51:49 2013 From: jan at pragma.si (Jan Zorz) Date: Mon, 27 May 2013 06:51:49 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2595D.4040902@boeddinghaus.de> References: <51A2595D.4040902@boeddinghaus.de> Message-ID: <51A2E665.7090106@pragma.si> On 5/26/13 8:50 PM, Wilhelm Boeddinghaus wrote: > Dear colleagues, > > as shortly discussed in Dublin I suggest to set up an errata page > for the RIPE 554 document. Errors have been found, and we cannot > change anything in the document without getting a new RIPE document > number. But having to many different versions of the document confuses > our audience. > > A errata page would make it possible to document minor but important > changes of the content of the document. > > If the group says "yes" we could ask RIPE to help with a page like > this. It should be easily reachable from the download page of RIPE554. We need to make RIPE-554 a "living-document" of some sort, as we need to be able to correct typos, fix the newly found flaws and update the RFC numbers as they evolve. If that's achieved through an errata - I'm fine with that :) Cheers, Jan From wilhelm at boeddinghaus.de Mon May 27 09:37:04 2013 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Mon, 27 May 2013 09:37:04 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <20130526211038.GH31051@x28.adm.denic.de> References: <51A2595D.4040902@boeddinghaus.de> <20130526211038.GH31051@x28.adm.denic.de> Message-ID: <51A30D20.4080608@boeddinghaus.de> Am 26.05.2013 23:10, schrieb Peter Koch: > On Sun, May 26, 2013 at 08:50:05PM +0200, Wilhelm Boeddinghaus wrote: > >> anything in the document without getting a new RIPE document number. But >> having to many different versions of the document confuses our audience. > why is the audience less confused by the same number referencing different > content? > > -Peter > The audience for this document are the enterprises and public administration. They need help when they set up a tender. The vendors can live with changing document numbers, but not the enterprises and public administration. If major changes have to be made to the document we need a new number. This is also true for new sections or new RFCs. -Wilhelm From marcoh at marcoh.net Mon May 27 10:15:42 2013 From: marcoh at marcoh.net (MarcoH) Date: Mon, 27 May 2013 12:15:42 +0400 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2E665.7090106@pragma.si> References: <51A2595D.4040902@boeddinghaus.de> <51A2E665.7090106@pragma.si> Message-ID: <39CB87CD-927C-4100-A15D-156665C1C220@marcoh.net> > On 5/26/13 8:50 PM, Wilhelm Boeddinghaus wrote: >> Dear colleagues, >> >> as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. >> >> A errata page would make it possible to document minor but important changes of the content of the document. >> >> If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. > We need to make RIPE-554 a "living-document" of some sort, as we need to be able to correct typos, fix the newly found flaws and update the RFC numbers as they evolve. It should not be a "living document" IMHO, it should provide a stable anchor for people to reference. Any major change should actually result in a new document and to me that includes new or updated RFCs. Now with typos that is something different, mistakes happen and I agree that releasing a new reference to correct a comma or two swapped numbers (as is the case), we might need an errata list instead of pushing for a complete new document. > If that's achieved through an errata - I'm fine with that :) This has also been raised with the Working Group chair collective as it means a small but important change from the way RIPE Documents are currently handled. Community feedback on this issue is really important as there are different ways to handle these issues, while maintaining a consistent document series of outstanding quality, Marco Hogewoning Co-chair of the IPv6 working group From shane at time-travellers.org Mon May 27 10:20:33 2013 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 27 May 2013 10:20:33 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2E665.7090106@pragma.si> References: <51A2595D.4040902@boeddinghaus.de> <51A2E665.7090106@pragma.si> Message-ID: <20130527102033.32773947@earth.home.time-travellers.org> Jan, On Mon, 27 May 2013 06:51:49 +0200 Jan Zorz wrote: > On 5/26/13 8:50 PM, Wilhelm Boeddinghaus wrote: > > Dear colleagues, > > > > as shortly discussed in Dublin I suggest to set up an errata page > > for the RIPE 554 document. Errors have been found, and we cannot > > change anything in the document without getting a new RIPE document > > number. But having to many different versions of the document > > confuses our audience. > > > > A errata page would make it possible to document minor but > > important changes of the content of the document. > > > > If the group says "yes" we could ask RIPE to help with a page like > > this. It should be easily reachable from the download page of > > RIPE554. > We need to make RIPE-554 a "living-document" of some sort, as we need > to be able to correct typos, fix the newly found flaws and update the > RFC numbers as they evolve. Typos and other minor edits seem quite reasonable in an errata document. Updating an RFC is new content, IMHO. > If that's achieved through an errata - I'm fine with that :) I do think that both minor edits and mentioning new/updated RFC numbers is appropriate as errata though. To avoid having the RIPE document number become carved in stone across the whole planet, maybe we should encourage the use of something like "RIPE-554 or the latest version" (depending on context - a specific tender probably should not use that, but a guideline document probably should). -- Shane From jan at go6.si Mon May 27 10:44:39 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 27 May 2013 10:44:39 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <20130527102033.32773947@earth.home.time-travellers.org> References: <51A2595D.4040902@boeddinghaus.de> <51A2E665.7090106@pragma.si> <20130527102033.32773947@earth.home.time-travellers.org> Message-ID: <51A31CF7.8010805@go6.si> Shane, On 5/27/13 10:20 AM, Shane Kerr wrote: >> If that's achieved through an errata - I'm fine with that :) > I do think that both minor edits and mentioning new/updated RFC numbers > is appropriate as errata though. > > To avoid having the RIPE document number become carved in stone across > the whole planet, maybe we should encourage the use of something like > "RIPE-554 or the latest version" (depending on context - a specific > tender probably should not use that, but a guideline document probably > should). > When reading "RIPE-544 or the latest version" - actually versioning comes to my mind. We could potentially edit the document further, do erratas and when we reach a consensus that it's good enough for that point in time we issue a version of the document. RIPE-554.1 :) I know that this may impact bigger mechanism of documents organization for the whole RIPE community - or maybe not. It's up to community to decide if we can allow exceptions like this and use different approach just for exceptions. Cheers, Jan From evyncke at cisco.com Mon May 27 11:18:54 2013 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Mon, 27 May 2013 09:18:54 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <20130527102033.32773947@earth.home.time-travellers.org> References: <51A2595D.4040902@boeddinghaus.de> <51A2E665.7090106@pragma.si> <20130527102033.32773947@earth.home.time-travellers.org> Message-ID: <97EB7536A2B2C549846804BBF3FD47E112FE7DCF@xmb-aln-x02.cisco.com> Can we perhaps do something as the IEEE does (if not mistaken)? Not a wiki page, but, a monthly/quarterly release with specific TAGGING both in the document name and inside the document itself? Such as RIPE-554 then RIPE-554.201305 then RIPE-554.201307 .... Important, because I am afraid that we need to fix more than typos ;-) -?ric > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Shane Kerr > Sent: lundi 27 mai 2013 10:21 > To: Jan Zorz > Cc: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE 554 Errata Page > > Jan, > > On Mon, 27 May 2013 06:51:49 +0200 > Jan Zorz wrote: > > > On 5/26/13 8:50 PM, Wilhelm Boeddinghaus wrote: > > > Dear colleagues, > > > > > > as shortly discussed in Dublin I suggest to set up an errata page > > > for the RIPE 554 document. Errors have been found, and we cannot > > > change anything in the document without getting a new RIPE document > > > number. But having to many different versions of the document > > > confuses our audience. > > > > > > A errata page would make it possible to document minor but important > > > changes of the content of the document. > > > > > > If the group says "yes" we could ask RIPE to help with a page like > > > this. It should be easily reachable from the download page of > > > RIPE554. > > We need to make RIPE-554 a "living-document" of some sort, as we need > > to be able to correct typos, fix the newly found flaws and update the > > RFC numbers as they evolve. > > Typos and other minor edits seem quite reasonable in an errata document. > > Updating an RFC is new content, IMHO. > > > If that's achieved through an errata - I'm fine with that :) > > I do think that both minor edits and mentioning new/updated RFC numbers is > appropriate as errata though. > > To avoid having the RIPE document number become carved in stone across the > whole planet, maybe we should encourage the use of something like > "RIPE-554 or the latest version" (depending on context - a specific tender > probably should not use that, but a guideline document probably should). > > -- > Shane From gvandeve at cisco.com Mon May 27 11:21:43 2013 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 27 May 2013 09:21:43 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A30D20.4080608@boeddinghaus.de> References: <51A2595D.4040902@boeddinghaus.de> <20130526211038.GH31051@x28.adm.denic.de> <51A30D20.4080608@boeddinghaus.de> Message-ID: <67832B1175062E48926BF3CB27C49B240CEA5FC9@xmb-aln-x12.cisco.com> Why does the assumption live that vendors can easily live with changing numbers? It takes a lot of work to say product xyz supports RIPExxxx on each element within the document. A new document will make it required that the check for support is completely redone. In addition it would very good if the context of document RIPExxxx is not-changed with exception of spelling mistakes etc. How otherwise a vendor can say product xyz support RIPExxxxx on 1 Jan 2013 and assume that RIPExxxx is still the same document on 1 Jan 2014? So, if the document content changes then the number should change... but not too frequently as that will reduce the value of the document. G/ -----Original Message----- From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Wilhelm Boeddinghaus Sent: 27 May 2013 09:37 To: Peter Koch; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] RIPE 554 Errata Page Am 26.05.2013 23:10, schrieb Peter Koch: > On Sun, May 26, 2013 at 08:50:05PM +0200, Wilhelm Boeddinghaus wrote: > >> anything in the document without getting a new RIPE document number. >> But having to many different versions of the document confuses our audience. > why is the audience less confused by the same number referencing > different content? > > -Peter > The audience for this document are the enterprises and public administration. They need help when they set up a tender. The vendors can live with changing document numbers, but not the enterprises and public administration. If major changes have to be made to the document we need a new number. This is also true for new sections or new RFCs. -Wilhelm From training at ripe.net Mon May 27 12:12:25 2013 From: training at ripe.net (Training Team) Date: Mon, 27 May 2013 12:12:25 +0200 Subject: [ipv6-wg] [training] RIPE NCC Training Courses July-September 2013 Message-ID: <51A33189.1050408@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Rome, Chisinau, Munich, Moscow, Prague, London, Ljubljana, Yerevan, Malm?, Istanbul, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From daniel.karrenberg at ripe.net Mon May 27 16:22:35 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 27 May 2013 16:22:35 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEA5FC9@xmb-aln-x12.cisco.com> References: <51A2595D.4040902@boeddinghaus.de> <20130526211038.GH31051@x28.adm.denic.de> <51A30D20.4080608@boeddinghaus.de> <67832B1175062E48926BF3CB27C49B240CEA5FC9@xmb-aln-x12.cisco.com> Message-ID: <6E3A8CCD-2A23-4CEC-B502-0ACD85B8FACB@ripe.net> [disclaimer: I work for the RIPE NCC] [claimer: I co-authored a lot of RIPE documents] Let us learn from prior art. The IETF has a lot of hard learned experience with maintaining a very successful series of consensus documents. We should learn from how the RFC series evolved and avoid repeating the mistakes in that history as much as possible. For the most important lessons for the RIPE document series at this point in time are: - Published RIPE documents should never change at all. Reason: The texts are cached in thousands of places an a great variety of media. This cache needs to be consistent. - Typos and real errata should be published separately. IETF practice: http://www.rfc-editor.org/errata.php "Published RFCs never change. Although every published RFC has been submitted to careful proofreading by the RFC Editor and the author(s), errors do sometimes go undetected. Use the form on this page to query the errata database for entries related to an RFC. Errata are for the RFCs as available from rfc-editor.org. Search results from the RFC search engine will include hyperlinks to any corresponding errata entries." I also strongly believe we should look into adding a "RIPE Document Editor" function that has the responsibility for the editorial quality of documents and exercises it in a well defined and transparent process that stays clear of any perception of giving anyone undue influence on the content of documents. Daniel From wilhelm at boeddinghaus.de Mon May 27 23:20:15 2013 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Mon, 27 May 2013 23:20:15 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEA5FC9@xmb-aln-x12.cisco.com> References: <51A2595D.4040902@boeddinghaus.de> <20130526211038.GH31051@x28.adm.denic.de> <51A30D20.4080608@boeddinghaus.de> <67832B1175062E48926BF3CB27C49B240CEA5FC9@xmb-aln-x12.cisco.com> Message-ID: <51A3CE0F.3010008@boeddinghaus.de> The vendors follow the process of the changing and evolving document and notice when a document number changes. The poor guy at the enterprise does not follow the RIPE process closely or maybe not at all. He just does not notice when a new document comes out and they still work with the old document. I agree with Gunter and his argument about the vendors is of course very valid. I did not see this aspect, sorry. Wilhelm Am 27.05.2013 11:21, schrieb Gunter Van de Velde (gvandeve): > Why does the assumption live that vendors can easily live with changing numbers? > > It takes a lot of work to say product xyz supports RIPExxxx on each element within the document. > A new document will make it required that the check for support is completely redone. > > In addition it would very good if the context of document RIPExxxx is not-changed with exception of spelling mistakes etc. > How otherwise a vendor can say product xyz support RIPExxxxx on 1 Jan 2013 and assume that RIPExxxx is still the same document on 1 Jan 2014? > > So, if the document content changes then the number should change... but not too frequently as that will reduce the value of the document. > > G/ > > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Wilhelm Boeddinghaus > Sent: 27 May 2013 09:37 > To: Peter Koch; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE 554 Errata Page > > Am 26.05.2013 23:10, schrieb Peter Koch: >> On Sun, May 26, 2013 at 08:50:05PM +0200, Wilhelm Boeddinghaus wrote: >> >>> anything in the document without getting a new RIPE document number. >>> But having to many different versions of the document confuses our audience. >> why is the audience less confused by the same number referencing >> different content? >> >> -Peter >> > The audience for this document are the enterprises and public administration. They need help when they set up a tender. The vendors can live with changing document numbers, but not the enterprises and public administration. > > If major changes have to be made to the document we need a new number. > This is also true for new sections or new RFCs. > > -Wilhelm > From daniel.karrenberg at ripe.net Tue May 28 04:24:31 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 May 2013 04:24:31 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A2595D.4040902@boeddinghaus.de> References: <51A2595D.4040902@boeddinghaus.de> Message-ID: <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> On 26.05.2013, at 20:50 , Wilhelm Boeddinghaus wrote: > Dear colleagues, > > as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. > > A errata page would make it possible to document minor but important changes of the content of the document. > > If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. > > Kind regards, > > Wilhelm Boeddinghaus Let's also split off the generic discussion from the concrete matter at hand for ripe-554: do we have a draft of the errata? ifnot yet, anyone volunteering one? Daniel From marcoh at marcoh.net Tue May 28 08:43:28 2013 From: marcoh at marcoh.net (MarcoH) Date: Tue, 28 May 2013 10:43:28 +0400 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> Message-ID: > > Let's also split off the generic discussion from the concrete matter at hand for ripe-554: do we have a draft of the errata? ifnot yet, anyone volunteering one? The one mistake that I am aware of is: - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: Router Advertisement (RA) filtering [RFC4862] Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". Marco From pk at DENIC.DE Tue May 28 10:00:15 2013 From: pk at DENIC.DE (Peter Koch) Date: Tue, 28 May 2013 10:00:15 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> Message-ID: <20130528080015.GE16908@x28.adm.denic.de> On Tue, May 28, 2013 at 10:43:28AM +0400, MarcoH wrote: > - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: > > Router Advertisement (RA) filtering [RFC4862] > > Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". this sounds much more like a content update than an erratum to me. Fixing a - hypothetical - RFC number typo might be an erratum. The IETF (more precisely: the IETF stream in the RFC series) has quite some experience in distinguishing between typos (lexicographic errors), real errata and suggestions for an updated document. An errata process (and while RIPE does not have to follow the IETF model, theirs may serve as an example) should not strive to turn (RIPE) documents into "living" documents. As far as I recollect, RIPE documents have been considered immutable, except that we've never been precise about the 'canonical format'. I'd like to understand what the _real_ underlying problem is. Recommendations evolve, will be updated, superseded or eventually revoked. Anybody seriously relying on 501 needs to be on top of things to the extent that they check whether they are working with the latest wisdom. So maybe some boilerplate text (red herring, rathole, bikeshed) guiding the reader to ``RIPE's list of current RIPE docments'' from within the published document (as of the next version) would be helpful. But now I plea guilty designing a solution around a not well defined problem. -Peter From marcoh at marcoh.net Tue May 28 10:07:58 2013 From: marcoh at marcoh.net (MarcoH) Date: Tue, 28 May 2013 12:07:58 +0400 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <20130528080015.GE16908@x28.adm.denic.de> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> Message-ID: <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> On May 28, 2013, at 12:00 PM, Peter Koch wrote: > On Tue, May 28, 2013 at 10:43:28AM +0400, MarcoH wrote: > >> - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: >> >> Router Advertisement (RA) filtering [RFC4862] >> >> Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". > > this sounds much more like a content update than an erratum to me. > Fixing a - hypothetical - RFC number typo might be an erratum. It is quite a radical change, but I do think that one of the authors already confirmed this really was a mistake. But maybe Jan or Sander can give more details. But I'm with Daniel here in "let's first get a list" and wonder if this really is the only one or wether there are others. Marco From tjc at ecs.soton.ac.uk Tue May 28 10:20:10 2013 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 28 May 2013 09:20:10 +0100 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> Message-ID: On 28 May 2013, at 09:07, MarcoH wrote: > On May 28, 2013, at 12:00 PM, Peter Koch wrote: > >> On Tue, May 28, 2013 at 10:43:28AM +0400, MarcoH wrote: >> >>> - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: >>> >>> Router Advertisement (RA) filtering [RFC4862] >>> >>> Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". >> >> this sounds much more like a content update than an erratum to me. >> Fixing a - hypothetical - RFC number typo might be an erratum. > > It is quite a radical change, but I do think that one of the authors already confirmed this really was a mistake. But maybe Jan or Sander can give more details. > > But I'm with Daniel here in "let's first get a list" and wonder if this really is the only one or wether there are others. The above example looks like an errata to me. 4862 specifies how RAs are handled, not how to filter them appropriately as per 6105. The crux of the issue is who we're producing the document for, and why. My understanding is that the primary purpose is to allow enterprise and ISP administrators to understand recommended IPv6 requirements for common deployment scenarios, and in that light it should be kept as up to date as reasonable effort allows. If that means a new document number every couple of years, so be it. The RIPE 501 text, in its authoritative location, states it is updated by RIPE 554 (and really that should say OBSOLETED by, to be equivalent to IETF language), so there's a clear pointer to the new version. It may be that the document is also there to guide vendors on priorities, but I'm sure Gunter or any vendor employee can assess the diffs between 501 and 554 pretty quickly, as he could between 554 and whatever may come next. What we should avoid is moving the goalposts too frequently. Out of interest, do vendors state compliance with 554 against certain product ranges? In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! And yes, a list of proposed changes would be very useful. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms at uakom.sk Tue May 28 10:16:54 2013 From: ms at uakom.sk (Martin Stanislav) Date: Tue, 28 May 2013 10:16:54 +0200 Subject: [ipv6-wg] [address-policy-wg] Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects In-Reply-To: <519B6BF4.8020406@ripe.net> References: <519B6BF4.8020406@ripe.net> Message-ID: <20130528081654.GA9120@moon.uakom.sk> On Tue, May 21, 2013 at 02:43:32PM +0200, Emilio Madaio wrote: > > A draft of the policy document is now online and ready for community > review at: > > https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents May I suggest to omit the first occurence of "Only" in the section "2.1 Definitions" to keep to text more self-contained? Currently proposed text: Only the inet6num object may use the value of "AGGREGATED-BY-LIR" for the ?status:" attribute and contain the attribute ?assignment-size:?. Suggested change: The inet6num object may use the value of "AGGREGATED-BY-LIR" for the ?status:" attribute and contain the attribute ?assignment-size:?. Martin From jan at go6.si Tue May 28 10:46:56 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 28 May 2013 10:46:56 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> Message-ID: <51A46F00.3080003@go6.si> On 5/28/13 4:24 AM, Daniel Karrenberg wrote: > Let's also split off the generic discussion from the concrete matter > at hand for ripe-554: do we have a draft of the errata? ifnot yet, > anyone volunteering one? I can start forming a list of things that should be changed and then we can discuss it (and I pretty sure Sander and Merike will help me with this ;) ) One of the proposed changes is to remove one of RFCs that describes QOS. I got this email from one of the vendors: ------------------ We don?t believe RFC3140 should be required at all in RIPE554 . It does not seem relevant at all to IPv6 capability and for that matter no more to ipv4 directly . RFC3140 describes the encoding of PHB_ID that inband signaling protocols can use. As an exampe RFC3270 is describing how Diffserv is supported over MPLS networks and it does reference RFC3140 PHB_ID in some of the options. That seems very "remote" from IPv6 QoS to me. Bottom line we think RFC3140 should be removed from the RIPE554 requirement doc. Support for QoS [RFC2474] ------------------ There is also a detailed technical explanation there if needed later, but I would like to hear what others on this list thinks about this suggestion. I would also like other people to start sending suggestions or observations to this mailinglist, so I can capture them and add to the list of proposed changes. Cheers, Jan From gvandeve at cisco.com Tue May 28 10:54:55 2013 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Tue, 28 May 2013 08:54:55 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> Message-ID: <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> I'll bite for a 2th time :) ... and will try to not bite for a third time :) Tjc> Out of interest, do vendors state compliance with 554 against certain product ranges? GV> As far I am aware Cisco does not publicly state that support... We do see the requirement in nearly every RFP mentioning IPv6 (and not only in Europe people are referencing RIPE554). So it is an important reference for us. Keep doing the good work for a single reference for good common sense IPv6 behaviour. Tjc>In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! GV> Good point... My take is that a document like RIPE-554 should give people using it the confidence that they ask a vendor common sense features that are generally successfully deployed. I can understand the angle Tim is coming from, to pressure the innovativeness of suppliers, and see a need for that in some format or document, however the materialisation of that should not be a BCP like RIPE554. A BCP should document important features and technologies that are currently successfully deployed (and not features that tomorrow may be successfully deployed). G/ From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Tim Chown Sent: 28 May 2013 10:20 To: MarcoH Cc: Peter Koch; ipv6-wg at ripe.net Subject: Re: [ipv6-wg] RIPE 554 Errata Page On 28 May 2013, at 09:07, MarcoH > wrote: On May 28, 2013, at 12:00 PM, Peter Koch wrote: On Tue, May 28, 2013 at 10:43:28AM +0400, MarcoH wrote: - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: Router Advertisement (RA) filtering [RFC4862] Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". this sounds much more like a content update than an erratum to me. Fixing a - hypothetical - RFC number typo might be an erratum. It is quite a radical change, but I do think that one of the authors already confirmed this really was a mistake. But maybe Jan or Sander can give more details. But I'm with Daniel here in "let's first get a list" and wonder if this really is the only one or wether there are others. The above example looks like an errata to me. 4862 specifies how RAs are handled, not how to filter them appropriately as per 6105. The crux of the issue is who we're producing the document for, and why. My understanding is that the primary purpose is to allow enterprise and ISP administrators to understand recommended IPv6 requirements for common deployment scenarios, and in that light it should be kept as up to date as reasonable effort allows. If that means a new document number every couple of years, so be it. The RIPE 501 text, in its authoritative location, states it is updated by RIPE 554 (and really that should say OBSOLETED by, to be equivalent to IETF language), so there's a clear pointer to the new version. It may be that the document is also there to guide vendors on priorities, but I'm sure Gunter or any vendor employee can assess the diffs between 501 and 554 pretty quickly, as he could between 554 and whatever may come next. What we should avoid is moving the goalposts too frequently. Out of interest, do vendors state compliance with 554 against certain product ranges? In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! And yes, a list of proposed changes would be very useful. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Tue May 28 11:24:39 2013 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 28 May 2013 10:24:39 +0100 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> Message-ID: On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" wrote: > I?ll bite for a 2th time J ? and will try to not bite for a third time J > > Tjc> Out of interest, do vendors state compliance with 554 against certain product ranges? > > GV> As far I am aware Cisco does not publicly state that support... We do see the requirement in nearly every RFP mentioning IPv6 (and not only in Europe people are referencing RIPE554). So it is an important reference for us. Keep doing the good work for a single reference for good common sense IPv6 behaviour. Certainly RIPE 554 is a widely cited text, and an excellent one to point people at (and discuss) during IPv6 training. I don't think anyone questions the value of the text, or its overall quality. > Tjc>In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! > > GV> Good point? My take is that a document like RIPE-554 should give people using it the confidence that they ask a vendor common sense features that are generally successfully deployed. I can understand the angle Tim is coming from, to pressure the innovativeness of suppliers, and see a need for that in some format or document, however the materialisation of that should not be a BCP like RIPE554. A BCP should document important features and technologies that are currently successfully deployed (and not features that tomorrow may be successfully deployed). This is where I disagree (surprise). Take for example RFC 6946 and, soon, draft-ietf-6man-ext-transmit. These are examples of things that I think should be in 554 or its -bis. We shouldn't leave them out of the text because vendors choose not to implement them. Rather, vendors can state their "roadmaps" in their responses. Belive the roadmaps or not at your peril :) You could say the same about functionality such as RA or DHCPv6 snooping not so long ago... should we have omitted those in advance of implementation, despite them both being important? (And of course now there is also draft-ietf-v6ops-ra-guard-implementation) Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Tue May 28 12:19:02 2013 From: sander at steffann.nl (Sander Steffann) Date: Tue, 28 May 2013 12:19:02 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> Message-ID: >>> - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory support: >>> >>> Router Advertisement (RA) filtering [RFC4862] >>> >>> Where this should be probably be a requirement for RFC 6105 which actually is called "IPv6 Router Advertisement Guard". >> >> this sounds much more like a content update than an erratum to me. >> Fixing a - hypothetical - RFC number typo might be an erratum. No, this really is a typo in the RFC number. The intention is that 'Router Advertisement (RA) filtering' is mandatory. The meaning stays the same, but the RFC number is a typo. > It is quite a radical change, but I do think that one of the authors already confirmed this really was a mistake. But maybe Jan or Sander can give more details. > > But I'm with Daniel here in "let's first get a list" and wonder if this really is the only one or wether there are others. This is the only typo that we know of, and many people have looked at this document. We have has requests for other changes as well, but I agree that those are out of scope now. This typo has been known since when the document was just published. That was almost a year ago... Can we now please just fix the damn thing? Thanks, Sander From marcoh at marcoh.net Tue May 28 13:12:16 2013 From: marcoh at marcoh.net (MarcoH) Date: Tue, 28 May 2013 15:12:16 +0400 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> Message-ID: <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> As was just discussing with Jan here in St Petersburg, I'm getting a bit confused about where we are heading. Do we still want to compile a list of errors and find a way to "attach" this to the 554 document as an errata? Or are we now gaining momentum to do a full revision and release a new document superseding 554? Which of course should incorporate all the fixes as well (and probably introduce some new mistakes) MarcoH -- Sent from mobile, sorry for the typos On 28 mei 2013, at 13:24, Tim Chown wrote: > > On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" wrote: > >> I?ll bite for a 2th time J ? and will try to not bite for a third time J >> >> Tjc> Out of interest, do vendors state compliance with 554 against certain product ranges? >> >> GV> As far I am aware Cisco does not publicly state that support... We do see the requirement in nearly every RFP mentioning IPv6 (and not only in Europe people are referencing RIPE554). So it is an important reference for us. Keep doing the good work for a single reference for good common sense IPv6 behaviour. > > Certainly RIPE 554 is a widely cited text, and an excellent one to point people at (and discuss) during IPv6 training. I don't think anyone questions the value of the text, or its overall quality. > >> Tjc>In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! >> >> GV> Good point? My take is that a document like RIPE-554 should give people using it the confidence that they ask a vendor common sense features that are generally successfully deployed. I can understand the angle Tim is coming from, to pressure the innovativeness of suppliers, and see a need for that in some format or document, however the materialisation of that should not be a BCP like RIPE554. A BCP should document important features and technologies that are currently successfully deployed (and not features that tomorrow may be successfully deployed). > > This is where I disagree (surprise). Take for example RFC 6946 and, soon, draft-ietf-6man-ext-transmit. These are examples of things that I think should be in 554 or its -bis. We shouldn't leave them out of the text because vendors choose not to implement them. Rather, vendors can state their "roadmaps" in their responses. Belive the roadmaps or not at your peril :) You could say the same about functionality such as RA or DHCPv6 snooping not so long ago... should we have omitted those in advance of implementation, despite them both being important? (And of course now there is also draft-ietf-v6ops-ra-guard-implementation) > > Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Tue May 28 14:00:42 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 28 May 2013 14:00:42 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> Message-ID: <51A49C6A.9040504@go6.si> On 5/28/13 1:12 PM, MarcoH wrote: > As was just discussing with Jan here in St Petersburg, I'm getting a > bit confused about where we are heading. > > Do we still want to compile a list of errors and find a way to > "attach" this to the 554 document as an errata? > > Or are we now gaining momentum to do a full revision and release a new > document superseding 554? Which of course should incorporate all the > fixes as well (and probably introduce some new mistakes) > This is a complex question now ;) I suggest that I make two lists - one with mistakes and errata material in another one with significant changes suggestions. For a quick fix we could process "errata" small changes and when the other list with bigger changes grows enough that we collectively decide we need a new version of the document - we go and change it. Would that work? Cheers, Jan From swa at netsign.net Tue May 28 13:55:33 2013 From: swa at netsign.net (Stefan Wahl (Technik)) Date: Tue, 28 May 2013 13:55:33 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> Message-ID: <7CA315CE-4C4A-4AB5-B4B1-CB50B76D9004@netsign.net> Hi Marco, Normally I would give the document a revision number and a release note, stating changes and fixes. As long as the general statement does not change, this should be ok. Stefan Am 28.05.2013 um 13:12 schrieb MarcoH : > As was just discussing with Jan here in St Petersburg, I'm getting a bit confused about where we are heading. > > Do we still want to compile a list of errors and find a way to "attach" this to the 554 document as an errata? > > Or are we now gaining momentum to do a full revision and release a new document superseding 554? Which of course should incorporate all the fixes as well (and probably introduce some new mistakes) > > MarcoH > -- > Sent from mobile, sorry for the typos > > On 28 mei 2013, at 13:24, Tim Chown wrote: > >> >> On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" wrote: >> >>> I?ll bite for a 2th time J ? and will try to not bite for a third time J >>> >>> Tjc> Out of interest, do vendors state compliance with 554 against certain product ranges? >>> >>> GV> As far I am aware Cisco does not publicly state that support... We do see the requirement in nearly every RFP mentioning IPv6 (and not only in Europe people are referencing RIPE554). So it is an important reference for us. Keep doing the good work for a single reference for good common sense IPv6 behaviour. >> >> Certainly RIPE 554 is a widely cited text, and an excellent one to point people at (and discuss) during IPv6 training. I don't think anyone questions the value of the text, or its overall quality. >> >>> Tjc>In reading around this, I stumbled on http://www.gossamer-threads.com/lists/cisco/nsp/165859. This is an important topic - is the list there to set the bar for IPv6 functionality, or to provide a list that vendors can easily meet? I hope the former. Sorry Gunter! >>> >>> GV> Good point? My take is that a document like RIPE-554 should give people using it the confidence that they ask a vendor common sense features that are generally successfully deployed. I can understand the angle Tim is coming from, to pressure the innovativeness of suppliers, and see a need for that in some format or document, however the materialisation of that should not be a BCP like RIPE554. A BCP should document important features and technologies that are currently successfully deployed (and not features that tomorrow may be successfully deployed). >> >> This is where I disagree (surprise). Take for example RFC 6946 and, soon, draft-ietf-6man-ext-transmit. These are examples of things that I think should be in 554 or its -bis. We shouldn't leave them out of the text because vendors choose not to implement them. Rather, vendors can state their "roadmaps" in their responses. Belive the roadmaps or not at your peril :) You could say the same about functionality such as RA or DHCPv6 snooping not so long ago... should we have omitted those in advance of implementation, despite them both being important? (And of course now there is also draft-ietf-v6ops-ra-guard-implementation) >> >> Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Tue May 28 14:13:15 2013 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 28 May 2013 13:13:15 +0100 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A49C6A.9040504@go6.si> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <20130528080015.GE16908@x28.adm.denic.de> <855C5380-2040-4C82-A92F-0D52AAE50839@marcoh.net> <2461BB63-FE09-4875-B41E-DBB2A32EA64A@ecs.soton.ac.uk> <67832B1175062E48926BF3CB27C49B240CEA686F@xmb-aln-x12.cisco.com> <4EB22088-DC51-478C-9715-3DB0EA7BFA96@marcoh.net> <51A49C6A.9040504@go6.si> Message-ID: On 28 May 2013, at 13:00, "Jan Zorz @ go6.si" wrote: > On 5/28/13 1:12 PM, MarcoH wrote: >> As was just discussing with Jan here in St Petersburg, I'm getting a bit confused about where we are heading. >> >> Do we still want to compile a list of errors and find a way to "attach" this to the 554 document as an errata? >> >> Or are we now gaining momentum to do a full revision and release a new document superseding 554? Which of course should incorporate all the fixes as well (and probably introduce some new mistakes) >> > This is a complex question now ;) > > I suggest that I make two lists - one with mistakes and errata material in another one with significant changes suggestions. > > For a quick fix we could process "errata" small changes and when the other list with bigger changes grows enough that we collectively decide we need a new version of the document - we go and change it. > > Would that work? That sounds good. Tim > > Cheers, Jan > From merike at doubleshotsecurity.com Tue May 28 15:26:33 2013 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 28 May 2013 06:26:33 -0700 Subject: [ipv6-wg] RIPE 554 Errata Page Message-ID: <58006.1369747593@sonic.net> OK, just got caught up on thread... On Tue 28/05/13 5:13 AM , Tim Chown wrote: > On 28 May 2013, at 13:00, "Jan Zorz @ go6.si" wrote: > > > On 5/28/13 1:12 PM, MarcoH wrote: > >> As was just discussing with Jan here in St Petersburg, I'm getting a > bit confused about where we are heading. > >> > >> Do we still want to compile a list of errors and find a way to "attach" > this to the 554 document as an errata? > >> > >> Or are we now gaining momentum to do a full revision and release a new > document superseding 554? Which of course should incorporate all the fixes > as well (and probably introduce some new mistakes) > >> > > This is a complex question now ;) > > > > I suggest that I make two lists - one with mistakes and errata material > in another one with significant changes suggestions. > > > > For a quick fix we could process "errata" small changes and when the > other list with bigger changes grows enough that we collectively decide we > need a new version of the document - we go and change it. > > > > Would that work? > > That sounds good. Works for me too. The one known issue for RIPE 554 is (and has been for a long time as Sander pointed out), the fact that we should have had RFC6105 instead of RFC 4862 since the intent was to make RA filtering mandatory. Jan has approached me a few times to see about helping edit a newer version and I am OK with that as long as there are enough changes to warrant a completely new document. We don't want to turn out a new RIPE doc every time one new v6 related RFC is published but certainly we should keep track of enhancements and modifications on best practices as deployments continue and then turn out a new document (and obsolete previous one(s)). - merike From jan at go6.si Tue May 28 16:04:33 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 28 May 2013 16:04:33 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <58006.1369747593@sonic.net> References: <58006.1369747593@sonic.net> Message-ID: <51A4B971.5000304@go6.si> On 5/28/13 3:26 PM, Merike Kaeo wrote: > Jan has approached me a few times to see about helping edit a newer > version and I am OK with that as long as there are enough changes to > warrant a completely new document. We don't want to turn out a new > RIPE doc every time one new v6 related RFC is published but certainly > we should keep track of enhancements and modifications on best > practices as deployments continue and then turn out a new document > (and obsolete previous one(s)). Hey, We can wait until the list of big-change suggestions grows big enough that it makes sense to change the document and the number. (...or we simply wait for RIPE-666 number and change it then :) :) :) ) Cheers, Jan From evyncke at cisco.com Wed May 29 09:43:21 2013 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 29 May 2013 07:43:21 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> Message-ID: <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> Catching up... Waiting for RIPE-666 would be superb indeed ;-) More seriously, I believe that the document goal is to ease the job of end-users wanting to deploy IPv6 by selecting good solid devices off the shelves (i.e. also offered by several vendors) and not to pressure vendors to add new features. Let's be pragmatic here, RIPE is not the IETF. The RA-guard is kind of interesting because without the further refinements at work at the IETF, it is not so interesting anymore as it can be evaded but still useful for misconfigured devices of course. RFC 6620 (SAVI FCFS) RFC 6583 (NDP cache exhaustion) are also becoming available (at least for enterprise grade switches and should be there as well). As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer-3 device/switch which of course if you are a layer-3 port, you implement MLD (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which is applicable to a layer-2 port. It can appear as splitting hair but you cannot imagine the number of hours/calls I have to spend on this hair splitting... So, please remove the MLD snooping requirement from a layer-3 device. Last one, we could argue that OSPF trailer authentication is now a RFC 6506 even if it brings little value anyway and could be too fresh to have multiple implementations. Hope this helps -?ric > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of MarcoH > Sent: mardi 28 mai 2013 08:43 > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE 554 Errata Page > > > > > Let's also split off the generic discussion from the concrete matter at > hand for ripe-554: do we have a draft of the errata? ifnot yet, anyone > volunteering one? > > The one mistake that I am aware of is: > > - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory > support: > > Router Advertisement (RA) filtering [RFC4862] > > Where this should be probably be a requirement for RFC 6105 which actually > is called "IPv6 Router Advertisement Guard". > > Marco > From tjc at ecs.soton.ac.uk Wed May 29 10:33:56 2013 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 29 May 2013 09:33:56 +0100 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> <87189339-FA01-450F-8C42-56D1326CF631@ecs.soton.ac.uk> Message-ID: On 29 May 2013, at 08:43, Eric Vyncke (evyncke) wrote: > Catching up... > > Waiting for RIPE-666 would be superb indeed ;-) Be careful what you wish for. I got some (apparently very serious!) emails about making light of the devil when I proposed 6/6/6 as the date to turn off the 6bone and routing of 3ffe::/16. > More seriously, I believe that the document goal is to ease the job of end-users wanting to deploy IPv6 by selecting good solid devices off the shelves (i.e. also offered by several vendors) and not to pressure vendors to add new features. Let's be pragmatic here, RIPE is not the IETF. No, but the RIPE community should give the best possible advice to its members (and many, many non-members who are pointed at RIPE-554). The question here is defining "best". Is it best for the members' networking needs for the next five+ years that they will live with their purchasing decision for, or best in terms of making the vendors' job to tick all the boxes easy, because it's all already done. There is probably a middle ground to be found. > The RA-guard is kind of interesting because without the further refinements at work at the IETF, it is not so interesting anymore as it can be evaded but still useful for misconfigured devices of course. RFC 6620 (SAVI FCFS) RFC 6583 (NDP cache exhaustion) are also becoming available (at least for enterprise grade switches and should be there as well). So do you think RIPE-666 (or whatever it becomes :)) should cite these RFCs? I certainly do. The question if so is how. They are not mandatory, but they can certainly add value to a deployment. Similar to (perhaps) requesting 802.1X support in a switch. I think this discussion has agreed to do a minor errata update of 554, and to discuss what 554-bis might look like. In that case, should the above type of RFCs, and the ones I mentioned yesterday, be included? If so, how? Are they mandatory? Are they optional? Are they tagged as features that readers should ask vendors for their roadmaps for (and yes, I'm sure we've all been bitten by broken roadmap promises, but you have to take some leap of faith at some point for features that don't exist yet). > As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer-3 device/switch which of course if you are a layer-3 port, you implement MLD (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which is applicable to a layer-2 port. It can appear as splitting hair but you cannot imagine the number of hours/calls I have to spend on this hair splitting... So, please remove the MLD snooping requirement from a layer-3 device. You say "layer-3 device/switch", I think you really mean "layer 3-only device". If the device offers any layer 2 functionality, MLD snooping becomes important. We had this issue with a specific brand of printer that fell over in the face of seeing a few HD IPv6 IP-TV channels only last month. > Last one, we could argue that OSPF trailer authentication is now a RFC 6506 even if it brings little value anyway and could be too fresh to have multiple implementations. > > Hope this helps Discussion is good :) Tim > > -?ric > >> -----Original Message----- >> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf >> Of MarcoH >> Sent: mardi 28 mai 2013 08:43 >> To: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] RIPE 554 Errata Page >> >>> >>> Let's also split off the generic discussion from the concrete matter at >> hand for ripe-554: do we have a draft of the errata? ifnot yet, anyone >> volunteering one? >> >> The one mistake that I am aware of is: >> >> - Requirements for enterprise/ISP grade "Layer 2 switch" equipment Mandatory >> support: >> >> Router Advertisement (RA) filtering [RFC4862] >> >> Where this should be probably be a requirement for RFC 6105 which actually >> is called "IPv6 Router Advertisement Guard". >> >> Marco >> > > From ipepelnjak at gmail.com Wed May 29 10:59:32 2013 From: ipepelnjak at gmail.com (Ivan Pepelnjak) Date: Wed, 29 May 2013 10:59:32 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> <87189339-FA01-450F-8C42-56D1326CF631@ecs.soton.ac.uk> Message-ID: <51A5C374.7010907@gmail.com> Have to agree. MLD Snooping should be OPTIONAL (or not required) for L3 device __that has NO L2 forwarding functionality__. Not sure how many devices would match that description, and I'm almost positive this is not what Eric is looking for, but this is the only safe way to remove MLD snooping requirement. Explaining why you don't need MLD snooping on a L3-only port on a L2/L3 switch is customer education ;) Start by thanking the marketing "wizards" that turned bridges and routers into switches. Jan & Sander - can we get something along the lines of the first paragraph into Errata doc? Ivan On 29.05.2013 10:33 , Tim Chown wrote: > On 29 May 2013, at 08:43, Eric Vyncke (evyncke) wrote: > [...] >> As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer-3 device/switch which of course if you are a layer-3 port, you implement MLD (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which is applicable to a layer-2 port. It can appear as splitting hair but you cannot imagine the number of hours/calls I have to spend on this hair splitting... So, please remove the MLD snooping requirement from a layer-3 device. > You say "layer-3 device/switch", I think you really mean "layer 3-only device". If the device offers any layer 2 functionality, MLD snooping becomes important. We had this issue with a specific brand of printer that fell over in the face of seeing a few HD IPv6 IP-TV channels only last month. From evyncke at cisco.com Wed May 29 11:16:57 2013 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Wed, 29 May 2013 09:16:57 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A5C374.7010907@gmail.com> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> <87189339-FA01-450F-8C42-56D1326CF631@ecs.soton.ac.uk> <51A5C374.7010907@gmail.com> Message-ID: <97EB7536A2B2C549846804BBF3FD47E112FEC931@xmb-aln-x02.cisco.com> Ivan and Tim, As long as the 'MLD snooping' is not mandated for a layer-3 switch (and I do agree it is an oxymoron for people on this list) then I am fine. The verbiage could be something in the lines of Tim and Ivan, requiring/make optional MLD snooping ONLY for any layer-2 ports of the layer-3 switch. > -----Original Message----- > From: Ivan Pepelnjak [mailto:ipepelnjak at gmail.com] > Sent: mercredi 29 mai 2013 11:00 > To: Tim Chown > Cc: Eric Vyncke (evyncke); MarcoH; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE 554 Errata Page > > Have to agree. MLD Snooping should be OPTIONAL (or not required) for L3 > device __that has NO L2 forwarding functionality__. > > Not sure how many devices would match that description, and I'm almost > positive this is not what Eric is looking for, but this is the only safe way > to remove MLD snooping requirement. > > Explaining why you don't need MLD snooping on a L3-only port on a L2/L3 > switch is customer education ;) Start by thanking the marketing "wizards" > that turned bridges and routers into switches. > > Jan & Sander - can we get something along the lines of the first paragraph > into Errata doc? > > Ivan > > On 29.05.2013 10:33 , Tim Chown wrote: > > On 29 May 2013, at 08:43, Eric Vyncke (evyncke) wrote: > > [...] > >> As a vendor, we have an issue with 'MLD snooping (RFC 4541)' for a layer- > 3 device/switch which of course if you are a layer-3 port, you implement MLD > (RFC 3810) as stated in RIPE 554 but you do not implement the snooping which > is applicable to a layer-2 port. It can appear as splitting hair but you > cannot imagine the number of hours/calls I have to spend on this hair > splitting... So, please remove the MLD snooping requirement from a layer-3 > device. > > You say "layer-3 device/switch", I think you really mean "layer 3-only > device". If the device offers any layer 2 functionality, MLD snooping > becomes important. We had this issue with a specific brand of printer that > fell over in the face of seeing a few HD IPv6 IP-TV channels only last > month. From jan at go6.si Thu May 30 12:02:39 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 30 May 2013 12:02:39 +0200 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A5C374.7010907@gmail.com> References: <51A2595D.4040902@boeddinghaus.de> <03BFA93D-3219-4812-A8A5-893A807488D3@ripe.net> <97EB7536A2B2C549846804BBF3FD47E112FEC5E4@xmb-aln-x02.cisco.com> <87189339-FA01-450F-8C42-56D1326CF631@ecs.soton.ac.uk> <51A5C374.7010907@gmail.com> Message-ID: <51A723BF.5080608@go6.si> On 5/29/13 10:59 AM, Ivan Pepelnjak wrote: > Have to agree. MLD Snooping should be OPTIONAL (or not required) for L3 > device __that has NO L2 forwarding functionality__. Agree... > > Not sure how many devices would match that description, and I'm almost > positive this is not what Eric is looking for, but this is the only safe > way to remove MLD snooping requirement. > > Explaining why you don't need MLD snooping on a L3-only port on a L2/L3 > switch is customer education ;) Start by thanking the marketing > "wizards" that turned bridges and routers into switches. > > Jan & Sander - can we get something along the lines of the first > paragraph into Errata doc? As this suggestion makes total technical sense to me, I would say to change that line in something like: "If a support for device ports operating also in L2 mode is required, then the device must support MLDv2 snooping [RFC4541]" Now, the chairs and community needs to decide, if that falls under errata or is that a bigger change. Personal opinion: adding RFC6946, RFC 6620 (SAVI FCFS), RFC 6583 (NDP cache exhaustion) and other RFCs to the document - that's a big change and should go in next editorial of a -bis. Changing MLDv2 snooping from unconditional to "if functionality required" and still in mandatory section - that might be seen as not that big change after all. Cheers, Jan P.S: Compiling the lists of changes, will post the link when considerably long enough ;) From evyncke at cisco.com Thu May 30 12:15:53 2013 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Thu, 30 May 2013 10:15:53 +0000 Subject: [ipv6-wg] RIPE 554 Errata Page In-Reply-To: <51A723BF.5080608@go6.si> Message-ID: <97EB7536A2B2C549846804BBF3FD47E112FEF050@xmb-aln-x02.cisco.com> Jan I agree with your proposals. Both for new doc (even if I would love to get he security beefed up!) And for the errata/clarifications about MLD Eric ----- Message d'origine ----- De : Jan Zorz @ go6.si [mailto:jan at go6.si] Envoy? : Thursday, May 30, 2013 12:02 PM ? : ipv6-wg at ripe.net Objet : Re: [ipv6-wg] RIPE 554 Errata Page On 5/29/13 10:59 AM, Ivan Pepelnjak wrote: > Have to agree. MLD Snooping should be OPTIONAL (or not required) for L3 > device __that has NO L2 forwarding functionality__. Agree... > > Not sure how many devices would match that description, and I'm almost > positive this is not what Eric is looking for, but this is the only safe > way to remove MLD snooping requirement. > > Explaining why you don't need MLD snooping on a L3-only port on a L2/L3 > switch is customer education ;) Start by thanking the marketing > "wizards" that turned bridges and routers into switches. > > Jan & Sander - can we get something along the lines of the first > paragraph into Errata doc? As this suggestion makes total technical sense to me, I would say to change that line in something like: "If a support for device ports operating also in L2 mode is required, then the device must support MLDv2 snooping [RFC4541]" Now, the chairs and community needs to decide, if that falls under errata or is that a bigger change. Personal opinion: adding RFC6946, RFC 6620 (SAVI FCFS), RFC 6583 (NDP cache exhaustion) and other RFCs to the document - that's a big change and should go in next editorial of a -bis. Changing MLDv2 snooping from unconditional to "if functionality required" and still in mandatory section - that might be seen as not that big change after all. Cheers, Jan P.S: Compiling the lists of changes, will post the link when considerably long enough ;)