Summary

  • draft-sayre-gendispatch-derivative-06 is an active individual Internet-Draft. It proposes to limit the no-derivative-works mechanism to RFCs and Internet-Drafts used in the IETF Standards Process; it is not an RFC, an adopted rule or evidence of IETF consensus.
  • RFC 5378 deliberately distinguishes a broad IETF Contribution from the narrower category of IETF Documents. The active IESG statement says notices that conflict with the policy are to be ignored in a Contribution, while the IETF-126 dispatch record calls for further IPR-WG discussion and legal-counsel review.
  • A contribution-status receipt should retain the received text and notice while separately recording classification, applicable rule, authorized process action, review path and present state. This is an editorial recommendation, not an IETF requirement or legal advice.

The footer is not the decision

The current dispute is easy to make melodramatic. A participant sends a message to an IETF list. The message carries a no-derivatives legend, sometimes as a deliberate sentence and sometimes as boilerplate imposed by a corporate mail system. Someone wants to quote it, respond to it, archive it, turn an idea from it into a different piece of work, or decide whether it can support formal standards work. It is tempting to treat the last line of the email as an answer to all of those questions.

It is not.

The IETF's current rules distinguish several things that everyday speech tends to collapse: the submitted words, the channel in which they were made, the category to which they belong, the rights needed for a later standards document, and the process authority that decides the next step. That differentiation is not lawyerly decoration. It is how an open technical process avoids allowing a mail client, an archive, a chair, or an institutional slogan to become a sovereign actor.

RFC 5378 defines a Contribution broadly. It covers material submitted for an Internet-Draft or RFC, but also statements in the context of an IETF activity, including written and electronic communications addressed to an IETF working group, list, the IESG, the IAB, a BOF or a plenary. Its definition of an IETF Document is narrower: RFCs and Internet-Drafts used in the IETF Standards Process.

The distinction changes the question. A message can be an IETF Contribution without itself being the kind of document for which a contributor can use the specified no-derivatives mechanism. A message can contain important expertise without becoming an adoptable specification. An archive can preserve a submission without acquiring power to determine its legal effect. And a participant can take part in a discussion without thereby receiving authority to settle the rights classification of every other participant's text.

The point is not that rights do not matter. They do. RFC 5378 says the Trust and IETF need specified rights so documents can be developed and published. It says authors retain other rights. It also describes narrow situations in which derivative-work rights may be limited: for example, documents describing proprietary technologies, republications of other standards organizations' work, or a document not yet accepted for development. Those exceptions are a reason to classify accurately, not a reason to stamp one default answer onto every email.

The new draft narrows a mechanism; it does not close a case

The latest version of draft-sayre-gendispatch-derivative is -06, dated 13 August 2026. The Datatracker describes it as an active individual Internet-Draft with no stream, unknown consensus boilerplate and an IESG state of I-D Exists. Its proposed operative sentence is narrow: the no-derivative-works mechanism would be limited to Contributions that are Internet-Drafts and RFCs used in the Standards Process, and would not apply to other Contribution types.

That is a proposal, not a completed rule change. It does not amend RFC 5378 today. It does not decide a dispute about a particular communication. It does not say a message was received, omitted, preserved, removed, quoted fairly, misclassified or handled badly. It does not turn a person who understands the proposal into the legal reviewer, and it does not turn a legal conclusion into a standards decision.

The timing record reinforces the restraint. At IETF 126, GENDISPATCH recorded the derivative-work item and its dispatch outcome: additional discussion on the IPR-WG list, followed by legal-counsel review. That sequence matters. A dispatch meeting can identify a proper next venue without making the resulting policy. A referral is not adoption. Counsel review is not a published counsel conclusion. The fact that a text continues to be refined is evidence that the classification boundary remains a live process question.

There is also an active IESG statement from October 2025. It takes a current position: derivative rights for a Contribution can be withheld only when that Contribution is an IETF Document and only in narrow circumstances. It says notices in conflict with IETF policies shall be ignored in a Contribution, and that a process owner can require their removal. The statement explains its position by returning to RFC 5378's definitions and exceptions.

That statement is important, but it should be read for the work it actually does. It supplies a policy position on the effect of a conflicting notice. It does not license an archive to rewrite the original message. It does not make an unlabeled summary a substitute for the message that arrived. It does not identify the responsible process owner in every future case. It does not tell a reader that the IETF has completed the proposed BCP update. And it does not supply a universal answer to questions outside the IETF contribution rules.

Preserve the message; record the status decision

Those limits produce a mundane but consequential operational requirement. A process can both preserve the received submission and make a transparent determination about how its notice is treated. It should not be forced to choose between two bad extremes: giving every footer an unreviewable veto, or declaring a footer irrelevant and making the record of it vanish.

Consider four separate objects.

First is the received object: the message or submission as it was sent, along with a stable identifier, receipt time, channel and integrity digest. This is evidence. It lets a later reader see what the contributor actually submitted, including any notice. Preserving it does not endorse every assertion within it.

Second is the classification object: whether a designated process actor regards the material as an IETF Contribution, an IETF Document, a non-IETF document, a comment on a document, an appeal record, meeting material or some other process object. Classification can be hard at the edges. That is precisely why it should be visible rather than inferred from a filename, an email subject line or the apparent importance of the author.

Third is the rules object: the applicable RFC 5378 provision, IESG statement, IETF Trust instruction or later adopted update, identified by version and effective state. A reader needs to distinguish the rule in force from a draft that proposes to change it, a meeting discussion, a personal interpretation or a corporate disclaimer.

Fourth is the action object: what an authorized role actually did. Was the notice treated as inapplicable under the current policy? Was its removal requested? Was the matter referred for review? Was a document held pending a resubmission? Was no process action taken because the text was merely discussion? A conclusion without the action field turns a status into an unexplained ritual.

Daniel Kade's recommendation is to join these objects in a contribution-status receipt. The public portion need not reproduce sensitive correspondence or invite a public legal dispute. It can record a message identifier and digest, channel and date, the notice as received or a durable reference to it, the claimed classification, policy version, accountable process role, action state, review route and supersession history. A protected annex, where needed, can preserve private communications without making privacy an excuse for an unaccountable final state.

The receipt must be descriptive before it is prescriptive. “Notice received” is not “notice valid.” “Classified as a Contribution” is not “approved as a draft.” “Policy position applied” is not “legal advice.” “Removal requested” is not “message altered.” “Referred to counsel” is not “counsel has decided.” “Discussion permitted” is not “working-group adoption.” These are not semantic niceties. They determine which person or body can properly perform the next act.

Why the distinction protects open participation

The strongest objection is practical. IETF work should not require a case file for every email. That objection is right as far as it goes. An open standards process cannot make ordinary contribution contingent on a legal workflow that only a well-funded employer can navigate. The receipt should therefore be triggered by a material status conflict: a restriction that affects an attempt to treat text as a standards document, a request by a responsible process actor, an appeal or a contested process action. It should be compact, machine-readable where useful, and bounded to the dispute rather than a new identity dossier.

The opposite danger is equally real. A broad instruction to ignore nonconforming notices can be misheard as permission to ignore contributors. It is not. The IESG statement says what it says about the policy effect of conflicting notices. It does not erase the fact that a person submitted text, or free a process from showing which authority applied which rule. The old words and the new decision must be able to coexist in the record.

This is where Heng Lu's discipline is useful. Participation, warning and expertise are real. They are not a mandate. A person who sends a message does not acquire power to bind the IETF merely by adding a footer. But an archive, moderator or technical tool also does not acquire power to choose an unreviewable history merely because it stores the message. The rights rule constrains a particular process question; it does not redistribute all governance authority around it.

In practical standards work, this separation supports collaboration. A reviewer may respond to an argument without pretending to reproduce the contributor's text. A chair may manage a process action without becoming a rights court. A legal reviewer may assess a policy question without deciding the technical merits of a specification. A working group may evaluate a resubmitted document without assuming that the existence of an earlier message created a binding mandate. Each role can be accountable for its own act.

A receipt should show the decision boundary, not invent a new gate

The recommended receipt has seven fields that deserve particular care.

  • Received evidence: stable identifier, time, channel, original-content digest and a preserved reference to the submitted notice.
  • Object boundary: what is being classified—the message, a named Internet-Draft, an RFC text, an appeal, minutes or a related record.
  • Applicable rule: the exact policy or process text, version and effective date relied on; a draft must be labeled as a proposal rather than the current rule.
  • Authority boundary: the identified chair, secretariat, process owner, review body or other role responsible for the recorded action.
  • Action boundary: ignored for policy effect, removal requested, held for review, resubmission requested, referral made, or no action—using terms that do not overstate the outcome.
  • Review boundary: how a contributor or affected process participant can seek clarification, and what remains pending.
  • Continuity boundary: the present state, any superseding decision and a pointer that preserves the original evidence rather than silently overwriting it.

Those fields should never become a tool for deciding who may speak. Nor should they add a new condition to participation, transform a discussion list into a licensing tribunal or centralize routine editorial judgment. Their purpose is narrower: when a rights-status claim becomes material, prevent accidental authority from being manufactured by an opaque mail footer or by an opaque handling decision.

Evidence limits

The reviewed record does not show adoption of draft-sayre-gendispatch-derivative-06, an RFC update, an IETF consensus determination, a completed legal-counsel review or a future IPR-WG outcome. It does not establish a current case of misconduct, message loss, censorship, unauthorized alteration, corporate malice or a legal defect in any named footer.

RFC 5378 and the IESG statement are used to describe the public IETF policy materials, not to offer legal advice. The contribution-status receipt is Daniel Kade's governance recommendation. It is not an IETF protocol, a required archive feature, a condition of participation or an instruction to modify public correspondence.

Sources

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage