-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/15/2013 12:02 AM, Brian E Carpenter wrote: > On 15/01/2013 06:16, Dean Willis wrote: ... >> Seriously -- at what point does replacing all action verbs with 2119 >> language make the protocol spec LESS useful for compliance >> certification? > > Wrong question. What we (the IETF) care about is the existence of > interoperable implementations, not mathematical compliance. > > If you ask "at what point does replacing all action verbs with 2119 > language make the protocol spec LESS useful for coding interoperable > versions?", I think the answer will be something like "when it makes the > spec so ugly and difficult to read that people get things wrong as a > result." > > On 15/01/2013 06:19, Dean Willis wrote: >> On Jan 5, 2013, at 10:03 AM, John C Klensin <john-ietf@xxxxxxx> wrote: >> >>>> And, again, that is further complicated by the observation that IETF >>>> Standards are used for procurement and even for litigation about >>>> product quality. We either need to accept that fact and, where >>>> necessary, adjust our specification style to match or we run the risk >>>> of bodies springing up who will profile our Standards, write >>>> procurement-quality conformance statements for their profiles, and >>>> become, de facto, the real standards-setter for the marketplace (and >>>> obviously do so without any element of IETF consensus). >> >> I'm not sure that's not a good thing. Witness for example the work SIP >> Forum has done with the SIPConnect standards, which have made it MUCH >> easier to order a box that will work with a SIP Trunking service. > > I think there are cases of standards of extreme complexity, such as SIP, > where such profiles may be useful, because otherwise interoperability > cannot be achieved. I would not call SIP a standard of extreme complexity, but anyway there is more and more protocols on a similar complexity - just two protocols that I am working with currently - RSTP 2.0 and RELOAD - are of similar complexity. > But perhaps the lesson for the IETF here is slightly different - don't > design standards which allow that degree of complexity in the first place. There is no simple solution to a complex problem, so as the problems we try to solve increase in complexity, so are our solutions to them. But perhaps you are right in a way. Perhaps the problem is simply that RFC 2119, and the issues I and other see with the approach in using as little of the keywords as possible, was designed for a time when problems - and solutions - were simpler. Perhaps RFC 2119 imposes an upper limit on the complexity that a protocol developed with it can reach, and we are just hitting this threshold more and more often. I am not saying that it is a bad thing - I certainly like simple protocols, but perhaps the IETF is simply the wrong place for developing complex protocols. - -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ9Tu8AAoJECnERZXWan7EH5oQAK7GF0bHQipOJfZiizI0EJRJ TwWtJOjpI7gF81gWBUo5tgpNXWRPLWVoG5rzD4LgsustSJk1sWwNSTH6lcfm1J3Y BSRvUZFXR92Y7SJLcP7fdRKhVK4vYPSF6lNHuGM0busAmCfmUcXCPe5zxqcvxgYR aM+GjAUrzQlVe69oVIEQ2lSShEfaLWy+6pWkxuoylT/fPLWqxTTwb+EiuWsH5oHe u0v9YcohByTtxvXHUurBF7kbUMFjNUnDPEgt0BtjwcQciGo1Pjyy8SGvpNF9Tr9f 2mNjk+A+0b9kaIxP06qEPe4oe3m//HdexLOyqesFDdXNdpWGs4ETExiUfo5wOcJn QfgA6JF9AyQSVmmkXAv7v5YeNwa+PJk2FrTghl18CFyXdrDJL+6GkVwPEnA404Ek 1QY8Nnf+cpfwjNHk9iu19lDpo6uBpCWqvwFpvikWtMeQ5n6yQk434y1ZJ5GNSERU Bd55+PY5TMTLV1B7ZO0ViLQ7bmAJ+lsQ4DK2vz+3+UdJL0MvAUs2MIIlpCklqMJV iCm7gqDpfuiXzLm7vLuRgC6PgU9KGsbnKlispCb7T7sZjRgd9vqIfCwOpEQht4s8 X7v3+Ltzelapec4HwDerlhymoDUrPgn26lPFuqy1MtkjAqPqiRKszB3X/jMjoqLk CjkDUD5QfHD9Cwunr0Qv =bBSa -----END PGP SIGNATURE-----