RFC 3979

Intellectual Property Rights in IETF Technology

📅 published March 2005, from ietf

Hiii bestie 🎀 okay so this one is RFC 3979, Intellectual Property Rights in IETF Technology 🦋. It's a Best Current Practice (that's BCP 79), written by S. Bradner, Ed. from Harvard University, dated March 2005. It obsoletes RFC 3668 and updates RFC 2028 and RFC 2026 💅✨

Status of This Memo 📜

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract 💜

Okay so the IETF has policies about Intellectual Property Rights (IPR), like patent rights, for technologies developed in the IETF 🧚. The whole point is that IETF working groups and participants have as much info as possible about any IPR constraints on a technical proposal, which is so important ngl 🫶. These policies are also meant to benefit the Internet community and the public at large, while still respecting the legit rights of IPR holders 👑. This memo spells out those IPR policies for technology worked on within the IETF, and explains the goals the policies are built to hit 🔥.

This memo updates RFC 2026 and, together with RFC 3978, replaces Section 10 of RFC 2026. It also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. Iconic, periodt 💅

Table of Contents 🍓

   1.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Contributions to the IETF. . . . . . . . . . . . . . . . . . .  6
       3.1.  General Policy . . . . . . . . . . . . . . . . . . . . .  6
       3.2.  Rights and Permissions . . . . . . . . . . . . . . . . .  6
   4.  Actions for Documents for which IPR Disclosure(s) Have Been
       Received . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.  No Determination of Reasonable and Non-discriminatory
             Terms. . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Notice to be Included in RFCs. . . . . . . . . . . . . . . . .  8
   6.  IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . .  8

       6.1.  Who Must Make an IPR Disclosure? . . . . . . . . . . . .  9
       6.2.  The Timing of Providing Disclosure . . . . . . . . . . .  9
       6.3.  How Must a Disclosure be Made? . . . . . . . . . . . . . 11
       6.4.  What Must be in a Disclosure?. . . . . . . . . . . . . . 11
       6.5.  What Licensing Information to Detail in a Disclosure . . 12
       6.6.  When is a Disclosure Required? . . . . . . . . . . . . . 12
   7.  Failure to Disclose. . . . . . . . . . . . . . . . . . . . . . 12
   8.  Evaluating Alternative Technologies in IETF Working Groups . . 13
   9.  Change Control for Technologies. . . . . . . . . . . . . . . . 14
   10. Licensing Requirements to Advance Standards Track Documents. . 14
   11. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . 14
   12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       13.1. Normative References . . . . . . . . . . . . . . . . . . 15
       13.2. Informative References . . . . . . . . . . . . . . . . . 15
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17

1. Definitions 🎀

These are the definitions for terms used in this document. Other terms, like "IESG," "ISOC," "IAB," and "RFC Editor," are defined in [RFC2028], so go check there if you're confused 🙈

a. "IETF": In this document, the IETF includes everyone who takes part in meetings, working groups, mailing lists, functions and other activities organized or started by ISOC, the IESG or the IAB under the general name Internet Engineering Task Force or IETF. But it only counts to the extent of that participation 🦋

b. "IETF Standards Process": the stuff the IETF does in any of the settings described in 1(c) below 🔥

c. "IETF Contribution": any submission to the IETF that the Contributor intends to publish as all or part of an Internet-Draft or RFC (except RFC Editor Contributions, which are covered below), plus any statement made within an IETF activity. Those statements include oral statements in IETF sessions, and also written and electronic communications made at any time or place, as long as they're addressed to:

  • the IETF plenary session,
  • any IETF working group or portion thereof,
  • the IESG, or any member thereof on behalf of the IESG,
  • the IAB or any member thereof on behalf of the IAB,
  • any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices,
  • the RFC Editor or the Internet-Drafts function (except for RFC Editor Contributions described below).

Statements made outside of an IETF session, mailing list or other function, that are clearly not intended as input to an IETF activity, group or function, are not IETF Contributions in the context of this document 💀

d. "Internet-Draft": temporary documents used in the IETF and RFC Editor processes 🍓 Internet-Drafts get posted on the IETF web site by the IETF Secretariat and have a nominal maximum lifetime of 6 months in the Secretariat's public directory, after which they're removed. Note that Internet-Drafts are archived in lots of places on the Internet, and not all of those places remove expired ones 😭 Internet-Drafts that are under active consideration by the IESG are not removed from the Secretariat's public directory until that consideration is complete. Also, the author of an Internet-Draft can ask for the lifetime in the Secretariat's public directory to be extended before it expires ✨

e. "RFC": the basic publication series for the IETF. RFCs are published by the RFC Editor and, once published, are never modified 🔒 (See [RFC2026] Section 2.1)

f. "RFC Editor Contribution": an Internet-Draft the Contributor intends to submit to the RFC Editor for publication as an Informational or Experimental RFC, but that is not intended to be part of the IETF Standards Process 🧁

g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor Contributions. Note that under Section 3.3(a), the grant of rights for IETF Internet-Drafts specified in this document is perpetual and irrevocable, so it survives the Secretariat's removal of an Internet-Draft from the public directory, except as limited by Section 3.3(a)(C). (See [RFC2026] Sections 2.2 and 8) 👑

h. "IETF Documents": RFCs and Internet-Drafts, except for Internet-Drafts that are RFC Editor Contributions and the RFCs published from them 🌈

i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC Editor Contributions, and the RFCs that may be published from them 🦋

j. "Contribution": IETF Contributions or RFC Editor Contributions

k. "Contributor": an individual submitting a Contribution

l. "Reasonably and personally known": means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to show that an organization cannot purposely keep an individual in the dark about patents or patent applications just to dodge the disclosure requirement. But this requirement should not be read as requiring the IETF Contributor or participant (or their represented organization, if any) to do a patent search to find applicable IPR 🕵️‍♀️💅

m. "Implementing Technology": means a technology that implements an IETF specification or standard ⭐

n. "Covers" or "Covered" means that a valid claim of a patent or a patent application in any jurisdiction, or a protected claim, or any other Intellectual Property Right, would necessarily be infringed by exercising a right (e.g., making, using, selling, importing, distribution, copying, etc.) with respect to an Implementing Technology. For purposes of this definition, "valid claim" means a claim of any unexpired patent or patent application that has not been withdrawn, cancelled or disclaimed, and has not been held invalid by a court of competent jurisdiction in an unappealed or unappealable decision 🧚

o. "IPR" or "Intellectual Property Rights": means patent, copyright, utility model, invention registration, database and data rights that may Cover an Implementing Technology, whether those rights arise from a registration or renewal thereof, or an application therefore, in each case anywhere in the world 🌍✨

2. Introduction ✨

Okay so ever since RFC 2026 dropped, the IETF has been having a lot of debates about what Section 10 (the IPR disclosure part) actually means 😭. It's getting more and more common for working groups to run into claims of Intellectual Property Rights (IPR), like patent rights, about the tech they're discussing 🔥. So this doc's whole mission is to clear up the ambiguities in Section 10 of [RFC2026] that started all those fights, and to amplify the policy so everyone knows what the IETF is, or should be, doing 👑.

IPR disclosures can pop up at any point in the IETF Standards Process 🦋. That means before the first Internet-Draft is submitted, before RFC publication, or after an RFC is out and the working group has closed down. They can come from people submitting technical proposals as Internet-Drafts, from mailing lists or meetings, from other people in the working group, or from third parties who find out the work is going on (or has already gone on) 👀. They can be based on granted patents or on patent applications, and sometimes they're disingenuous, i.e., made to affect the IETF Standards Process instead of just informing it 💀.

RFC 2026, Section 10 set up three basic principles for dealing with IPR claims 💅:

  • (a) the IETF will make no determination about the validity of any particular IPR claim
  • (b) the IETF following normal processes can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted
  • (c) in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other participants, and applies whether they contribute in person, via email or by other means. The requirement applies to all IPR of the participant, the participant's employer, sponsor, or others represented by the participants, that is reasonably and personally known to the participant. No patent search is required.

Section 1 defines the terms used in this document 📚. Sections 3, 4 and 5 of this document cover the intellectual property issues that Section 10 of RFC 2026 used to address. Sections 6 thru 12 then explain the reasoning behind these rules, including some of the clarifications that have been made since RFC 2026 was adopted 🧚. The rules and procedures in this document are not meant to modify or alter the IETF's current policy toward IPR in the context of the IETF Standards Process. They're meant to clarify things and fill in procedural gaps 🌸.

A companion document, [RFC3978], deals with rights (like copyrights and trademarks) in Contributions, including the right of the IETF and its participants to publish and create derivative works of those Contributions 🎀. This document doesn't try to address those issues.

This document is not intended as legal advice. Readers are advised to consult their own legal advisors if they would like a legal interpretation of their rights or the rights of the IETF in any Contributions they make.

3. Contributions to the IETF 🌈

3.1. General Policy

In all matters of Intellectual Property Rights, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others 🫶.

3.2. Rights and Permissions

3.2.1. All Contributions

By submitting a Contribution, each person actually submitting it, and each named co-Contributor, is deemed to agree to the following terms and conditions 💖. They agree on their own behalf, and on behalf of the organizations the Contributor represents or is sponsored by (if any) when submitting the Contribution.

  • A. The Contributor represents that he or she has made or will promptly make all disclosures required by Section 6.1.1 of this document.
  • B. The Contributor represents that there are no limits to the Contributor's ability to make the grants, acknowledgments and agreements herein that are reasonably and personally known to the Contributor.
  • C. If the Contribution is an Internet-Draft, this agreement must be acknowledged, by including in the "Status of this Memo" section on the first page of the Contribution, the appropriate notices described in Section 5 of [RFC3978] 📝.

4. Actions for Documents for which IPR Disclosure(s) Have Been Received 🔍

  • (A) When any Intellectual Property Right is disclosed before publication as an RFC, with respect to any technology or specification, described in a Contribution in the manner set forth in Section 6 of this document, the RFC Editor shall ensure that the document include a note indicating the existence of such claimed Intellectual Property Rights in any RFC published from the Contribution. (See Section 5 below.)
  • (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any IPR, disclosed or otherwise, to any IETF technology, specification or standard, and will take no position on the validity or scope of any such IPR claims 🙈.
  • (C) Where Intellectual Property Rights have been disclosed for IETF Documents as provided in Section 6 of this document, the IETF Executive Director shall request from the discloser of such IPR, a written assurance that upon approval by the IESG for publication as RFCs of the relevant IETF specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to Implementing Technology under one of the licensing options specified in Section 6.5 below unless such a statement has already been submitted. The working group proposing the use of the technology with respect to which the Intellectual Property Rights are disclosed may assist the IETF Executive Director in this effort.

The results of this procedure shall not, in themselves, block publication of an IETF Document or advancement of an IETF Document along the standards track. A working group may take the results of this procedure into consideration when evaluating the technology, and the IESG may defer approval when a delay may facilitate obtaining such assurances. The results will, however, be recorded by the IETF Executive Director, and be made available online 🍓.

4.1. No Determination of Reasonable and Non-discriminatory Terms

The IESG will not make any explicit determination that the assurance of reasonable and non-discriminatory terms, or any other terms for the use of an Implementing Technology, has been fulfilled in practice 🤷‍♀️. It will instead apply the normal requirements for the advancement of Internet Standards. If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals, or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved, the IESG will presume that the terms are reasonable and to some degree non-discriminatory. (See RFC 2026, Section 4.1.3.) Note that this also applies to the case where multiple implementers have concluded that no licensing is required. This presumption may be challenged at any time, including during the Last-Call period by sending email to the IESG 📬.

5. Notice to be Included in RFCs 🎀

The RFC Editor will ensure that the following notice is present in all IETF RFCs and all other RFCs for which an IPR disclosure or assertion has been received prior to publication. Here's the exact wording, no edits, because it's legal text 🫶:

Disclaimer of validity:

"The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.  Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard.  Please address the information to the
IETF at ietf-ipr@ietf.org."

6. IPR Disclosures 💜

This section is all about the obligations that come with IPR disclosure 🧚.

This document refers to the IETF participant making disclosures, which fits the general IETF philosophy that participants act as individuals 🦋. A participant's obligation to make a disclosure is also considered satisfied if the IPR owner, or the participant's employer or sponsor, makes an appropriate disclosure in place of the participant doing so.

6.1. Who Must Make an IPR Disclosure?

6.1.1. A Contributor's IPR in his or her Contribution

Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6, which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6 🔥.

This requirement specifically includes Contributions made by any means, including electronic or spoken comments, unless the latter are rejected from consideration before a disclosure could reasonably be submitted. An IPR discloser is requested to withdraw a previous disclosure if a revised Contribution negates the previous IPR disclosure, or to amend a previous disclosure if a revised Contribution substantially alters the previous disclosure 💅.

Contributors must disclose IPR meeting the description in this section. There are no exceptions to this rule 🌈.

6.1.2. An IETF Participant's IPR in Contributions by Others

Any individual participating in an IETF discussion who reasonably and personally knows of IPR meeting the conditions of Section 6.6, which the individual believes Covers or may ultimately Cover a Contribution made by another person, or which such IETF participant reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6 👀.

6.1.3. IPR of Others ✨

Okay, so what if someone knows about IPR that could Cover IETF Contributions, but they don't have to disclose it because they don't meet the criteria in Section 6.6? 🤔 Think a different company owns it. 🏢 They're still encouraged to let the IETF know by emailing ietf-ipr@ietf.org 📧 bestie, that's the move! It should go out as soon as reasonably possible once they realize the connection 💖

6.2. The Timing of Providing Disclosure 🕰️

Timing matters SO much 😭 because working groups need as much info as they can get while they're comparing alternative solutions. It's giving "the more data the better" energy 🧠✨

6.2.1. Timing of Disclosure Under Section 6.1.1 💅

The IPR disclosure required under section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft, unless the required disclosure is already on file 🎀 For example, if the Contribution is an update to one that already has an IPR disclosure, and the new version doesn't change how that disclosure applies, then no new disclosure is needed. 🙌 But if it's a brand-new Contribution, or it changes an existing one so the revised version isn't Covered by the disclosed IPR anymore (or is Covered by new or different IPR), then a disclosure must be made 🔥

If a Contributor first learns about IPR in its Contribution that meets the conditions of Section 6.6 (like a new patent application, or spotting a relevant patent in a patent portfolio) after the Contribution was published in an Internet-Draft, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor 👀

Participants who realize that a Contribution will be or has been folded into a submission to be published in an Internet Draft, or is seriously being discussed in a working group, are strongly encouraged to make at least a preliminary disclosure 🫶 That disclosure should happen as soon as reasonably possible after they realize it, not waiting until the document is actually posted or ready to post. Don't be the person who waits until the last second, bestie 😭

6.2.2. Timing of Disclosure Under Section 6.1.2 🦋

The IPR disclosure required under section 6.1.2 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft or RFC, unless the required disclosure is already on file 💜 Participants who realize that the IPR will be or has been folded into a submission to be published in an Internet Draft, or is seriously being discussed in a working group, are strongly encouraged to make at least a preliminary disclosure. Same vibe as before: go early, go preliminary, don't wait for the big reveal 🎀

If a participant first learns about IPR that meets the conditions of Section 6.6 in a Contribution by another party (a new patent application, or finding a relevant patent in a patent portfolio) after that Contribution was published in an Internet-Draft or RFC, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the participant 🧚

6.3. How Must a Disclosure be Made? 📬

IPR disclosures are made by following the instructions at http://www.ietf.org/ipr-instructions. Easy peasy 🌸

6.4. What Must be in a Disclosure? 📝

6.4.1. The disclosure must list the numbers of any issued patents or published patent applications, or say that the claim is based on unpublished patent applications 🍓 It must also list the specific IETF or RFC Editor Document(s) or activity affected. If the IETF Document is an Internet-Draft, it must be referenced by its specific version number 🔢 And here's a tip the spec calls out: if the IETF Document has multiple parts and it isn't reasonably apparent which part is alleged to be Covered by the IPR in question, it's helpful if the discloser names the sections of the IETF Document that are alleged to be so Covered 🙈

6.4.2. If a disclosure was made on the basis of a patent application (published or unpublished), then, if the IESG or a working group chair asks for it, the IETF Executive Director can request a new disclosure saying whether any of the following has happened: the publication of a previously unpublished patent application, the abandonment of the application, and/or the issuance of a patent on it 🦄 If the patent has issued, the new disclosure must include the patent number. And if the claims of the granted patent differ from the application's claims in a way that's material to the relevant Contribution, it's helpful to describe any differences in applicability to the Contribution ✨ If the patent application was abandoned, the new disclosure must explicitly withdraw any earlier disclosures based on that application 💀

New or revised disclosures may be made voluntarily at any time 🌈

6.4.3. A blanket statement of possible IPR on every Contribution does not satisfy the disclosure requirement 🙅‍♀️ The whole point is to share info about specific IPR against specific technology being discussed in the IETF, so vague vibes don't cut it. For that same reason, a blanket statement of willingness to license all potential IPR under fair and non-discriminatory terms also doesn't count 😤

BUT (and this is the good part 💖), the requirement is satisfied by a blanket statement from the IPR discloser that they're willing to license all of their potential IPR meeting the requirements of Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an IETF specification on a royalty-free basis, as long as any other terms and conditions are disclosed in the IPR disclosure statement 👑

6.5. What Licensing Information to Detail in a Disclosure 💸

Since working groups use IPR disclosures while they evaluate alternative technical solutions, it's helpful to include licensing info in case Implementing Technologies need a license 🧠 Specifically, it's helpful to say whether, once the IESG approves the relevant IETF specification(s) for publication as RFCs, all persons will be able to get the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology in one of these ways: a) under a royalty-free and otherwise reasonable and non-discriminatory license, or b) under a license with reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without needing a license from the IPR holder 🫧

Including licensing info isn't mandatory, but it's encouraged so working groups have as much info as possible during their deliberations 🎀 And if adding licensing info would seriously hold up the submission, it's quite reasonable to submit the disclosure without it and then submit a new disclosure once the licensing info is available 🙌

6.6. When is a Disclosure Required? 🔍

IPR disclosures under Sections 6.1.1. and 6.1.2 are required for IPR that is owned directly or indirectly by the individual, or by their employer or sponsor (if any), or that such persons otherwise have the right to license or assert 💼

7. Failure to Disclose 🚫

Okay, this one's a little serious 🥺 There are cases where individuals aren't permitted by their employers, or by other factors, to disclose the existence or substance of patent applications or other IPR. But since disclosure is required for anyone submitting documents or taking part in IETF discussions, a person who doesn't disclose IPR for this reason (or any other reason) must not contribute to or participate in IETF activities about technologies they reasonably and personally know are Covered by IPR they won't disclose 🙅‍♀️ Contributing to or participating in IETF discussions about a technology without making the required IPR disclosures is a violation of IETF process 💀 Not it!

8. Evaluating Alternative Technologies in IETF Working Groups 🧩

Generally speaking, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing 💖 But working groups have the discretion to adopt technology with a commitment to fair and non-discriminatory terms, or even with no licensing commitment at all, if they feel the technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses ✨

Over the last few years, the IETF has gotten stricter about some security technologies 🔐 It's become common to have a mandatory-to-implement security technology in IETF technology specifications. This makes sure there's at least one common security technology in every implementation of such a specification that can be used in all cases 🫶 It doesn't stop the specification from including other security technologies whose use could be negotiated between implementations. The IETF consensus is that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it, or a royalty-free license is available to implementers of the specification, unless there's a very good reason to do otherwise 🙏 This limit doesn't extend to other security technologies in the same specification if they aren't listed as mandatory-to-implement 🌸

It's also worth noting that the absence of IPR disclosures is not the same thing as knowing there will be no IPR claims in the future 👀 People or organizations not currently involved in the IETF, or people or organizations that discover IPR they feel is relevant in their patent portfolios, can make IPR disclosures at any time 🦋

And one more thing 💅: the validity and enforceability of any IPR may be challenged for legitimate reasons, so the mere existence of an IPR disclosure should not automatically be taken to mean that the disclosed IPR is valid or enforceable 🧐 The IETF can't make an actual determination of validity, enforceability or applicability of any particular IPR claim. It's reasonable, though, for a working group to take into account its own opinions on the validity, enforceability or applicability of Intellectual Property Rights when evaluating alternative technologies 🧠✨

9. Change Control for Technologies 🔧

The IETF must have change control over the technology described in any standards track IETF Documents, so it can fix problems that may be discovered or produce other derivative works 🛠️

In some cases, the developer of patented or otherwise controlled technology may decide to hand over the right to evolve the technology to the IETF (a.k.a., "change control") 🤝 Setting up an agreement between the IETF and the technology's developer can be complex. (See [RFC1790] and [RFC2339] for examples 📚)

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 🔐

10. Licensing Requirements to Advance Standards Track IETF Documents ✨

okay bestie, so RFC 2026 Section 4.1.2 says: "If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process." 🧐 The main word to watch is "required" 👀 Just because IPR has been disclosed doesn't automatically mean you need a license to implement the tech. It's giving "exists" vs. "actually needed" 💅

So Section 4.1 of this document should be taken to apply to the case where there are multiple implementations, none of the implementers felt they needed to license the technology, and there are no plausible indications that any IPR holder(s) will try to enforce their IPR. 🦋 Literally no drama, no cap.

11. No IPR Disclosures in IETF Documents 🙅‍♀️

okay this one is so important 😭 IETF and RFC Editor documents must not contain any mention of specific IPR. All specific IPR disclosures must be submitted the way Section 6 describes 📝 Specific IPR disclosures must not be in the affected IETF and RFC Editor documents, because the reader could get misled 🙈

Here's the tea ☕ Including a particular IPR disclosure in a document could be read as the IETF, IESG, or RFC Editor having an opinion on whether the IPR is valid, enforceable, or applicable. And readers could also think the included disclosures are the only ones the IETF has received about that document. Main character energy would be a total mess 💀

So readers should always check the online web page for the full list of IPR disclosures the IETF has received about any Contribution: http://www.ietf.org/ipr/ 🌸

12. Security Considerations 🔐

This memo is about the IETF process, not any particular technology. 😤 There are security considerations when adopting any technology, whether it's IPR-protected or not. A working group should take those security considerations into account as one part of evaluating the technology, just like IPR is one part. There are no known issues of security with IPR procedures, though, so it's still worth checking every security angle on the actual tech 🛡️

13. References 📚

13.1. Normative References

  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 🧠
  • [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. 🏢
  • [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. 👥
  • [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, RFC 3978, January 2005. ✨

13.2. Informative References

  • [RFC1790] Cerf, V., "An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols", RFC 1790, April 1995. 🦋
  • [RFC2339] The Internet Society and Sun Microsystems, "An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols", RFC 2339, May 1998. 🌈

14. Acknowledgements 🫶

The editor would like to give a huge shoutout to the IETF IPR Working Group, and especially to Jorge Contreras of Hale and Dorr for his careful legal reviews of this and other IETF IPR-related and process documents. 👑 The editor would also like to thank Valerie See for her extensive comments and suggestions. 💖

Editor's Address 💌

Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA, 02138

Phone: +1 617 495 3864
EMail: sob@harvard.edu

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏

Intellectual Property 🧾

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to find such rights. 🕵️‍♀️ Info on the procedures for rights in RFC documents lives in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights can be found on the IETF online IPR repository at http://www.ietf.org/ipr. 📂

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬 🌷

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸 Thank you for reading all the way to the end, bestie 🎀✨

📦 where this page comes from