--On Tuesday, May 07, 2013 08:23 +1200 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 07/05/2013 02:10, l.wood@xxxxxxxxxxxx wrote: >> http://labs.apnic.net/blabs/?p=309 >> >> an excellent detective story on badly-written, poorly edited, >> standards track RFCs leading to interop problems. Enjoy. > > I don't that is quite right. The problem in this case is not > to do with linguistic quality. It's due to a lack of formal > verification among a set of interacting and cross-area RFCs. > (And the problem is wider, because there are two distinct > places in IETF standards where ABNF for the text > representation of IPv6 addresses can be found.) This is a case > where no amount of language editing would have helped. > Actually I used it a couple of months ago in a discussion with > some experts on formal verification, and they rather liked it > as a poster child for the need for formal methods in SDOs. And that is another oddity and perhaps another lesson. The robustness principle was formulated, not just as a general good idea, but because of the understanding that there was little or no aspiration in pre-IETF specifications to get every T crossed and I dotted. That level of precision is required for formal verification (about which there are other problems) or formal testing and certification (about which there are a different set of other problems). Not only was Jon aware that we often didn't go into that level of detail, but there was a case to be made that we didn't want to because it took too much time to get after the documents right after the design and specification were done (please reread that a few times). Maybe things have changed, but, if one actually believes the robustness principle, then, in the case Geoff cites, Exchange is simply non-conforming -- not because the spec prohibits rejecting on the basis of a fine distinction about IPv6 formats, but because doing so is unnecessary, inconsistent with the robustness principle, and, arguably, plain silly. And that is the other thing we lost when "Proposed Standard" went from "spec that might contain some problems, lack of clarity, and less than wonderful writing as long as there were no known technical defects" to "better get it right because it is probably the last chance and people are going to build and ship products on the basis of what it says". We now have expectations consistent with specs that can be formally verified and/or tested and that people will interpret narrowly and a procedural model designed for specs that are much less formal and complete. john john