Re: [rfc-i] Table of conformance requirements.

Robert Sparks <> Thu, 18 June 2020 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B40DE3A0EEE; Thu, 18 Jun 2020 06:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GpmsKVcTJGU4; Thu, 18 Jun 2020 06:38:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A63973A0F08; Thu, 18 Jun 2020 06:38:21 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id CA93FF406F6; Thu, 18 Jun 2020 06:38:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83D40F406F6 for <>; Thu, 18 Jun 2020 06:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Cp9_MRIndFI for <>; Thu, 18 Jun 2020 06:38:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 7B260F406F5 for <>; Thu, 18 Jun 2020 06:38:10 -0700 (PDT)
Received: from unescapeable.local ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 05IDbw0n031542 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <>; Thu, 18 Jun 2020 08:37:59 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1592487479; bh=ktoYjYB/MnSSYZxKBrNN6r7aK+nNxjyVXH2KHzGl1ew=; h=Subject:To:References:From:Date:In-Reply-To; b=rcqllgoir0t/fDYgzHpHmc9cfUhPEN21yEJ/Xzpbu8Cd2ZP4NP4w3JMcWaIcFI9ee 9iEIn/H3jfUti6P1JGfWsRIFnAkvE9a3c872IaQXt6AW5FyY/1cuA8xiyb6+iheYPk DruUjo3+/jCMHShYbXGdAv6lOen+Vq+3GCxKphgw=
X-Authentication-Warning: Host [] claimed to be unescapeable.local
References: <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Thu, 18 Jun 2020 08:37:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Language: en-US
Subject: Re: [rfc-i] Table of conformance requirements.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "rfc-interest" <>

I have a script that builds such lists, and have used it for 20-ish 
years at this point in various contexts.

Some example output:

For the most part, its best use has been to help identify when there are 
meaningless, duplicate, or contradictory uses of the BCP14 keywords.

In interop testing (primarily the SIPit), having these requirements 
enumerated this way didn't help drive test behavior or the creation of 
test suites. It turned out that far more context was needed as a 
predicate to "I'm going to check this thing" than the isolated sentence 
containing the requirement. And agreeing on that context often turned 
out to be a subjective exercise (when that happened, I'd help put 
pressure on changing the spec to reduce the probability of different 

So, it's been somewhat helpful in my experience, but not helpful enough 
to try to build extra support for it into, say, the v3 grammar.


On 6/18/20 2:08 AM, Carsten Bormann wrote:
> There is a whole industry around requirements tracking.
> I’m sure the Ribose people can tell us more about that.
>> Each MUST in a specification should have at least one corresponding unit test to check compliance.
> Yeah sure.
> RFC 4120:
>     *  Principals MUST keep their secret keys secret.
> I’d love to see that unit test :-)
> The other problem is that we simply don’t state all requirements in BCP14 language.
> Very often, most requirements are stated in describing an architecture or a protocol; they are phrased as statements of fact.  Extracting and labeling these requirements for requirements tracking is an art form.
>> And this needs to be expressible somehow in XML.
> I played around some with using kramdown’s auto-indexing feature for BCP14 keywords.  With today’s xml2rfc, that gives you an index of BCP14 usage.  Not exactly what you want, but just a few lines of kramdown markdown.
> I never used the results of these experiments in a document, mainly because the lack of BCP14 language on so many of the actual requirements made the result too sketchy.
> Grüße, Carsten
> _______________________________________________
> rfc-interest mailing list
rfc-interest mailing list