Hi Job,
On 16-Dec-21 01:05, Job Snijders wrote:
Hi Brian, others,
(... apologies for potentially pulling this thread direction you didn't
have in mind when initiating this conversation)
So I changed the subject.
On Tue, Dec 14, 2021 at 10:34:29AM +1300, Brian E Carpenter wrote:
Do people think it's a good or bad idea to label pseudocode
in an RFC with <CODE BEGINS>?
I think pseudo-code in RFCs is a bad idea... regardless of the label! :-)
Pseudo-code literally is just fantasy speak; probably closer related to
dada poetry (it being a chaotic expression rather than something that is
productive!). Pseudo-code - by both definition and tradition - cannot be
interpreted in any meaningful way.
I disagree. But there are certainly at least two different cases:
1) Pseudocode used for descriptive or illustrative purposes, because
it is clearer and more compact than describing a mechanism in plain
text. I think there are many examples of this.
2) Pseudocode that claims to be mathematically precise, that could
in principle be interpreted by a computer, but in practice will
be interpreted by a software or hardware designer. One example is
RFC8986, which says:
"The pseudocode describing these behaviors details local processing
at a node. An implementation of the pseudocode is compliant as long
as the externally observable wire protocol is as described by the
pseudocode."
There is no compiler available for 'pseudo-code', so how can humans
ever stand a chance to make sense of what the authors intended?
I spent a lot of time on the draft that became RFC8986, to
understand exactly what it was describing and whether it violated
RFC8200, and I found that the pseudocode fragments were far more
precise and normative than the text.
I'd like to point out two examples:
Example #1: Dissemination of Flow Specification Rules (now RFC 8955)
-----------
One of the challenges with implementing Flowspec rule ordering was that
the original specification included pseudo-code, which was one of the
aspects that multiple implementers ended up mis-implementing to some
degree, because there was ambiguity: https://datatracker.ietf.org/doc/html/rfc5575#section-5.1
When the -bis effort started, it was pointed out that the pseudo-code
was highly problematic and one of the sources of confusion, which led to
the -bis document being needed in the first place! The authors agreed
and graciously contributed their time to improve the document by
replacing pseudo-code with python code.
Fantasy code: https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-04#section-5.1
Actual code: https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc5575bis-05#section-5.1
Anyone will agree that the actual code serves a purpose, whereas the
fantasy pseudo-code introduces more room for implementation error.
Yes, if it purports to be normative but is not correctly verified.
As far as I know, RFC8986 doesn't have that problem.
However, there's a problem in including "real" code as in your example.
Real code needs context, carries library dependencies with it, and
so on. The case that is behind my original message is very informal
pseudocode *derived from* running Python code. It would have been
totally unreasonable to use the original Python for illustrative
purposes.
Example #2: RPKI Origin Validation (RFC 6811)
-----------
This snippet increased confusion, rather than help prevent it:
https://datatracker.ietf.org/doc/html/rfc6811#section-2.1
I'll take your word for it. So, I agree, don't use pseudocode
for illustrative purposes when it might compete with normative
text.
---
All in all - I believe pseudo-code should be eradicated from the IETF's
body of work, rather than be wrapped or labeled. Use of pseudo-code
should be discouraged at all levels of our organization.
I believe that goes too far. But you draw attention to the dangers of
using pseudocode carelessly as pseudonormative material.
Brian
Kind regards,
Job
.
