ietf
[Top] [All Lists]

A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

2013-01-05 13:14:27
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I read the responses so far, and what can be said today is that there is 2
philosophies, with supporters in both camps.  The goal of the IETF is to make
the Internet work better, and I do believe that RFC 2119 is one of the
fundamental tool to reach this goal, but having two ways to use it does not
help this goal.

One way to find out would be to measure which philosophy results in the best
implementations.  Let's say that we can associate with each Standard Track RFC
one of these two philosophy.  If we had statistics on implementations then it
would be a simple matter of counting which one produce the less
interoperability problems, security issues and congestion problems (is there
other criteria?).  But as far as I know, there is no such data available -
maybe we should start collecting these, but that does not help for our current
problem.

Another way to look at it would be to run the following experiment:

1. Someone design a new protocol, something simple but not obvious, and write
in a formal language and keep it secret.

2. The same protocol is rewritten in RFC language but in two different
variants according to the two philosophies.  These also are kept secret.

3. The two variants are distributed randomly to a set of volunteer
implementers, who all implement the spec they received the best they can and
submit the result back, keeping their implementation secret.

4.  A test harness is written from the formal description, and all
implementations are run against each other, collecting stats related to the
criteria listed above (some criterion may be tricky to automatically assess,
we'll see).

5. Results are published, together with the protocol in formal form, the
specs, the results and the recommendation for one or the other philosophy.


That could be an interesting research project, and could even find some
funding from interested parties.


On 01/03/2013 09:15 PM, Dean Willis wrote:

I've always held to the idea that RFC 2119 language is for defining levels
of compliance to requirements, and is best used very sparingly (as
recommended in RFC 2119 itself). To me, RFC 2119 language doesn't make
behavior normative -- rather, it describes the implications of doing
something different than the defined behavior, from "will break the
protocol if you change it" to "we have reason to think that there might be
a reason we don't want to describe here that might influence you not to do
this" to "here are some reasons that would cause you to do something
different" and on to "doing something different might offend the
sensibilities of the protocol author, but probably won't hurt anything
else."

But I'm ghost-editing a document right now whose gen-art review suggested 
replacing the vast majority of "is" "does" and "are" prose with MUST. The 
comments seem to indicate that protocol-defining text not using RFC 2119 
language (specifically MUST) is "not normative".

This makes me cringe. But my co-editor likes it a lot. And I see smart
people like Ole also echoing the though that RFC 2119 language is what
makes text normative.

For example, the protocol under discussion uses TLS or DTLS for a plethora
of security reasons. So, every time the draft discusses sending a response
to a request, we would say "the node MUST send a response, and this
response MUST be constructed by (insert some concatenation procedure here)
and MUST be transmitted using TLS or DTLS.

Or, a more specific example:

For the text:

In order to originate a message to a given Node-ID or Resource-ID, a node 
constructs an appropriate destination list.


The Gen-ART comment here is: -First sentence: "a node constructs" -> "a
node MUST construct"


We'll literally end up with hundreds of RFC 2119 invocations (mostly MUST)
in a protocol specification.

Is this a good or bad thing? My co-editor and I disagree -- he likes 
formalization of the description language, and I like the English prose.
But it raises process questions for the IETF as a whole:

Are we deliberately evolving our language to use RFC 2119 terms as the 
principle verbs  of a formal specification language?

Either way, I'd like to see some consensus. Because my head is throbbing
and I want to know if it MUST hurt, SHOULD hurst, or just hurts. But I
MUST proceed in accordance with consensus, because to do otherwise would
undermine the clarity of our entire specification family.


- -- 
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)

iQIcBAEBCAAGBQJQ6Ht3AAoJECnERZXWan7ETHwP/1MwWKyX4ZoTqS2AZr5VdCwx
jGO/0+tbHppplfippPlJRR6cV5rfrrtkKp9j3Xbr477Jeuaaadjv3y0CfkGF+DUb
fDhcB/GQLiN1oC6s3cjiib46Rnd18Ela6xUAZleiLjKKoo0TJKfQ8oAt3tYonokK
onb95NAsF0FsbiqBzoUi23aEf/SFoKOg3a67DAt5XmntnNh5K6jVOmT4GFYtF3LB
vW6d1x0hI0INUSXzjypD+MaqzCgHvdxAjqx44qlrFjFYz7GLcRAR3Z5ynOCCfeBi
fM4xxGhytTYolrXdOQK1BgtUIewdCHMqPFZjclB2DiEITkUzxRrGKI5MizQEModB
8vwmJQJ0E98veMvBP5ce9eKPZP0gHMxEWMu2zgGulb2mLVxyfSfBIy2dIuqpHsUM
dWuvLzx1HJouZ4sFfCGMarpLvoYwYu1grL+oaJiPXd1TI26BCyI703gdQE1dBRhK
XrfIEgmP1VG1QhhBA6otLQlWfB0IGG2c80y0KOZ4x9rQ8Wn+Cxz4vQg6CvHPys+z
ClvFH4r/v3CpavSpugcD7sJAssfp9wbe9Jjw1pCPiXgs0fN+yQtQRIVDCSCQHNJ4
iWFtwExIDQyh/lKmJNlf8P3qBSmhzqvAG1B9bAZY9JroJoqY84kkgWKHRodAQ/HM
DqC0PVCig1bKYwZpT1Ov
=oOlZ
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>