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)