-----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(_at_)jck(_dot_)com>
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(_at_)petit-huguenin(_dot_)org
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-----