<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Marco,<div><br></div><div>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.</div><div><br></div><div>Stefan</div><div><br></div><div><br><div><div>Am 28.05.2013 um 13:12 schrieb MarcoH <<a href="mailto:marcoh@marcoh.net">marcoh@marcoh.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div>As was just discussing with Jan here in St Petersburg, I'm getting a bit confused about where we are heading. </div><div><br></div><div>Do we still want to compile a list of errors and find a way to "attach" this to the 554 document as an errata?</div><div><br></div><div>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)</div><div><br>MarcoH<div>-- </div><div>Sent from mobile, sorry for the typos</div></div><div><br>On 28 mei 2013, at 13:24, Tim Chown <<a href="mailto:tjc@ecs.soton.ac.uk">tjc@ecs.soton.ac.uk</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://3283/"><br><div><div>On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" <<a href="mailto:gvandeve@cisco.com">gvandeve@cisco.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-GB" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">I’ll bite for a 2th time<span class="Apple-converted-space"> </span><span style="font-family: Wingdings; ">J</span><span class="Apple-converted-space"> </span>… and will try to not bite for a third time<span class="Apple-converted-space"> </span><span style="font-family: Wingdings; ">J</span><o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Tjc> Out of interest, do vendors state compliance with 554 against certain product ranges?<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: rgb(112, 48, 160); ">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.</span></div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div lang="EN-GB" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: rgb(112, 48, 160); "><o:p></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Tjc>In reading around this, I stumbled on <a href="http://www.gossamer-threads.com/lists/cisco/nsp/165859" style="color: purple; text-decoration: underline; ">http://www.gossamer-threads.com/lists/cisco/nsp/165859</a>. 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!<o:p></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-family: Cambria, serif; color: rgb(112, 48, 160); ">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).</span></div></div></div></blockquote><br></div><div>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)</div><div><br></div><div>Tim</div></blockquote></div></blockquote></div><br></div></body></html>