[ipv6-wg] RIPE 554 Errata Page

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 at 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 at ecs.soton.ac.uk> wrote:
> 
>> 
>> On 28 May 2013, at 09:54, "Gunter Van de Velde (gvandeve)" <gvandeve at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ipv6-wg/attachments/20130528/d939bf94/attachment.html>