Summary

  • The IETF Executive Director’s 6 October public report says the LLC helped the IESG resolve questions about reusing older RFC text in standards work; counsel reportedly clarified that the relevant right dates to RFC 1602, and a Chairs Wiki page had been drafted.
  • RFC 1602 §5.4 says its rights procedures apply to contributions submitted after 1 April 1994. For Internet standards documents published before that date, it directs readers to seek rights and permissions from people claiming rights in them.
  • The report labels RFC 5378 “BCP 9”; the RFC Editor catalog identifies RFC 5378 as BCP 78. That is a bibliographic mismatch, not evidence that counsel’s substantive view is wrong.

An author adding old text to a new standards document needs more than a rule number. The date the source document appeared, when its contribution entered the process and who supplied the material can each change which rights record matters. The IETF’s public Executive Director report for the 6 October LLC Board meeting brings that practical problem into view: it says the LLC has supported the IESG with questions from authors reusing older RFC content in standards-process work.

The report says people had assumed that free reuse began only with RFC 5378, while counsel clarified that the relevant right had existed since RFC 1602. It also says a Chairs Wiki guidance page was drafted. That is a meaningful operational update, but not a published legal opinion, a Board resolution or a case-specific permission. The report does not include the draft page or explain how counsel treated each class of source material.

The underlying texts make the time boundary consequential. RFC 1602, issued in March 1994, set out a revised Internet Standards Process. Its §5.4 says the procedures apply to contributions submitted after 1 April 1994. For Internet standards documents published before then, it says rights and permissions should be sought directly from those claiming rights. The present Datatracker record marks RFC 1602 as Legacy and Informational, and says RFC 2026 obsoleted it. Its historical role is relevant; its old status does not turn the memo into a current standard.

RFC 5378 is a different instrument: the 2008 Best Current Practice titled Rights Contributors Provide to the IETF Trust, catalogued as BCP 78. It updates RFC 2026 and explains rights for contributions made within IETF processes, including use in the IETF Standards Process under stated terms. The Board report’s “RFC 5378 (BCP 9)” parenthetical does not match the RFC Editor record: BCP 9 is the standards-process series associated with RFC 2026. The discrepancy should be corrected in guidance, but it does not establish a legal defect in counsel’s interpretation.

For authors, the practical question is not whether an RFC is “old” in the abstract. It is whether the passage is an IETF contribution, when the relevant contribution was submitted, whether it contains third-party material and whether the proposed reuse stays within the standards-process grant. RFC 1602’s pre-cutoff instruction prevents a simple “all RFCs since 1602 are free to copy” reading. The ED report does not say counsel authorized that broader claim.

The guidance will be most useful if it gives chairs a route to record the source RFC, the passage and its provenance, the relevant date, the applicable rights text and the point at which a direct inquiry is needed. A public, versioned page should also distinguish counsel’s interpretation from adopted policy and from an individual clearance. This recommendation follows an institutional distinction: community participation, an official report, legal interpretation and a Board-approved rule are different states of authority. No evidence here establishes that every possible rights question has already been answered.

Sources