Complaint regarding BCP 79 violations (D. J. Bernstein) - 2025-05-26
Response - 2025-06-17

On 2025-05-26, the Internet Architecture Board (IAB) received an appeal from D. J. Bernstein, “Complaint regarding BCP 79 violations.”

The appeal covers two matters, which we will refer to as “no known IPR claims” (Intellectual Property Rights) and “change control.”

Regarding “no known IPR claims”, the appeal’s arguments fail to account for the purpose of mandatory-to-implement security technology as defined in BCP 79 (RFC 8179, Section 7):

It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be used in all cases.

This makes it clear that “mandatory-to-implement” in this context is not any technology that is required to implement a given specification (e.g., as a normative reference), but instead a specific specification technique whereby an extension point defines one option that is required to be implemented in order to promote interoperability for that extension point.

Even if the appeal’s preferred reading of the phrase were honoured, we do not find a violation of the stated policy based upon the facts presented. In particular, it is reasonable to require IPR declarations to be made using a formal mechanism to be recognised for this purpose, and that mechanism is documented in RFC 8179, which updates RFC 2026 (and thus the text in question). Furthermore, it is clear that Working Group decisions were made with an awareness of the possibility of IPR claims, and it still came to consensus to progress the two drafts.

Addressing “change control” is not necessary due to the resolution of the previous matter. However, we refer back to the specific language addressing this in BCP 79 (RFC 8179, Section 8):

Note that there is no inherent prohibition against a Standards Track IETF Document making a normative reference to proprietary technology. For example, a number of IETF standards support proprietary cryptographic transforms.

This is not, as the appeal asserts, a requirement that any referenced proprietary technology needs to have change control handed over to the IETF; rather, it explicitly allows definition of optional extensions to protocols to reference proprietary technology that remains in third party hands – such as is the case in the document referenced in the appeal.

The IAB declines to direct or recommend any further action. Roman Danyliw, Warren Kumari, and Qin Wu recused themselves from consideration of this appeal.