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
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
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
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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Wilhelm Boeddinghaus Sent: 27 May 2013 09:37 To: Peter Koch; ipv6-wg@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
[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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Wilhelm Boeddinghaus Sent: 27 May 2013 09:37 To: Peter Koch; ipv6-wg@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
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
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
Jan, On Mon, 27 May 2013 06:51:49 +0200 Jan Zorz <jan@pragma.si> 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
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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Shane Kerr Sent: lundi 27 mai 2013 10:21 To: Jan Zorz Cc: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE 554 Errata Page
Jan,
On Mon, 27 May 2013 06:51:49 +0200 Jan Zorz <jan@pragma.si> 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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Wilhelm Boeddinghaus Sent: 26. toukokuuta 2013 21:50 To: ipv6-wg@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
On 26.05.2013, at 20:50 , Wilhelm Boeddinghaus <wilhelm@boeddinghaus.de> 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
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
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
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
On 28 May 2013, at 09:07, MarcoH <marcoh@marcoh.net> 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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Tim Chown Sent: 28 May 2013 10:20 To: MarcoH Cc: Peter Koch; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] RIPE 554 Errata Page On 28 May 2013, at 09:07, MarcoH <marcoh@marcoh.net<mailto:marcoh@marcoh.net>> 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
On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> 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
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 <tjc@ecs.soton.ac.uk> wrote:
On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> 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
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 <marcoh@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 <tjc@ecs.soton.ac.uk> wrote:
On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> 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
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
On 28 May 2013, at 13:00, "Jan Zorz @ go6.si" <jan@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
- 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
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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of MarcoH Sent: mardi 28 mai 2013 08:43 To: ipv6-wg@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
On 29 May 2013, at 08:43, Eric Vyncke (evyncke) <evyncke@cisco.com> 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@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of MarcoH Sent: mardi 28 mai 2013 08:43 To: ipv6-wg@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
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) <evyncke@cisco.com> 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.
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@gmail.com] Sent: mercredi 29 mai 2013 11:00 To: Tim Chown Cc: Eric Vyncke (evyncke); MarcoH; ipv6-wg@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) <evyncke@cisco.com> 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.
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.
<evil smile>
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 ;)
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@go6.si] Envoyé : Thursday, May 30, 2013 12:02 PM À : ipv6-wg@ripe.net <ipv6-wg@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.
<evil smile>
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 ;)
On 05/30/2013 01:02 PM, Jan Zorz @ go6.si wrote:
Cheers, Jan
P.S: Compiling the lists of changes, will post the link when considerably long enough ;)
hello Jan (and list), if you're still compiling the list, you should add RFC7084 instead of RFC6204 (if you haven't already) cheers, Yannis
Hi,
if you're still compiling the list, you should add RFC7084 instead of RFC6204 (if you haven't already)
Thank you! All input is welcome :-) Sander
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
participants (15)
-
Daniel Karrenberg -
Eric Vyncke (evyncke) -
Gunter Van de Velde (gvandeve) -
Ivan Pepelnjak -
Jan Zorz -
Jan Zorz ＠ go6.si -
Jetten Raymond -
MarcoH -
Peter Koch -
Sander Steffann -
Shane Kerr -
Stefan Wahl (Technik) -
Tim Chown -
Wilhelm Boeddinghaus -
Yannis Nikolopoulos